Network Working Group Z. Cao Internet-Draft Huawei Intended status: Informational D. Liu Expires: April 13, 2018 Alibaba M. Qi China Mobile October 10, 2017 EAP Authentication Identity Protection draft-zcao-eap-id-protection-00 Abstract The EAP framework does not provide an effective way to protect the peer's identity. This creates the risk of identity forgery. This document revisits the EAP identity protection problem, and proposes a solution to this problem via the use of Cryptographically Binding Identity (CBID). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 13, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Cao, et al. Expires April 13, 2018 [Page 1] Internet-Draft EAP Identity Protection October 2017 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . 3 3.1. Crypto-binding Identity Generation . . . . . . . . . . . 3 3.2. EAP Authentication using Crypto-Binding ID . . . . . . . 3 3.3. Extended EAP-Response/Identity Message Format . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction In the EAP framework [RFC3748], the EAP peer will respond with its authentication identity in the EAP-Response/Identity message. Based on the configuration with respect to the peer's identity, the EAP Authentication Server will determine which EAP method to start with this peer. But this creates potential security threats towards the EAP identity. For example, suppose user A with identity ID-A is configured to be authenticated with EAP-MD5 which is considered to be a week authentication method, then an attacker M can 'steal' A's identity by responding the EAP-Request/Identity message with IDA, so that the server will authenticate M using EAP-MD5. In this way, attackers obtain an easier way to be authenticated to the system and then can harm the system in multiple ways. Currently there are no direct solutions to conduct EAP identity protection. One way introduced in RFC3748 is to neglect the EAP identity exchange and let the server start with the same EAP method for every user, and only after a secure tunnel is established can the peer informs its identity to the server. Another common method to avoid identity stolen is to use the anonymous identity, e.g., the users within the same domain use the same ''anon@example.org'' to initiate the EAP authentication. However, this anonymous identity does not prevent the malicious to conduct the identity attack. This document introduces an EAP identity protection mechanism. Instead of using a native identity such as ''bob'' or ''bob@example.org'', the EAP peer should generate a Cryptography- Binding Identity (CBID) by hashing its public key so that the used EAP identity is bind to the user's public key. The peer will include Cao, et al. Expires April 13, 2018 [Page 2] Internet-Draft EAP Identity Protection October 2017 this crypto-binding ID in the EAP-Response/Identity and sign the message with its private key. In this way, an attacker has no way to forge a valid public key that maps to the CBID and a valid signature representing this public key. By using the CBID, EAP authentication can be kept immune to the EAP identity threat. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Proposed Solutions We introduce our solution in this section. 3.1. Crypto-binding Identity Generation Suppose the EAP peer has its own RSA public and private key pair (PK, SK), it will generate its crypto-binding identity (CBID) as: CBID = HASH (PK||OPTIONAL-CONTENT) (1) Where the HASH algorithm is an one-way function so that it is computational infeasible to do reverse derivation. The OPTIONAL- CONTENT may contain the human readable user id and the domain name information ''@example.org''. The OPTIONAL-CONTENT is configurable and synchronized between the EAP Peer and Server After the CBID is generated, the user will include this identity in the EAP-Response/Identity message, and the server will configure an EAP method with this identity. 3.2. EAP Authentication using Crypto-Binding ID In this section, we will show how the proposed solution can prevent attackers to forge other peers' identity by using CBID. When an EAP peer A receives the EAP-Request/Identity, it will respond with its crypto-binding identity CBID-A and a random number Ra together with a signature on the whole message using its private key SK-A and the RSA signature algorithm. The detailed message format will be shown in Section.3.3. The identity exchange procedure is depicted in Figure 1. The EAP Peer, Authenticator and EAP Server definitions are align with RFC 3748. Cao, et al. Expires April 13, 2018 [Page 3] Internet-Draft EAP Identity Protection October 2017 +----------+ +-------------+ +----------+ | EAP peer | |Authenticator| |EAP Server| +----------+ +-------------+ +----------+ | (1) | | |<------------------| | | | | (2) | | | (3a) | (3b) | |------------------>|------------------->| | | (4) | | (5) | | |<-------------------| Figure 1: Identity Exchange using CBID (1) The authenticator sends the EAP-Request/Identity to the peer; (2) The EAP peer includes its CBID and generates a random number Ra, and then uses the RSA signature algorithm to generate a signature Sig. The peer first prepares a concatenation including the EAP Code, Identifier, Length, Type, CBID and Random number, i.e. Code||Identifier||Length||Type||CBID||Random. The peer then generates the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC3447] signature algorithm with the SHA-1 hash algorithm. The private key (SK) and the concatenation created above are the inputs to the generation operation. (3) The EAP peer sends the concatenated EAP-Response/Identity message (3a) to the EAP authenticator, the logic format of this message is as: EAP-Response/ID (CBID||Random||PK||Sig). The authenticator encapsulates this EAP-Response into the AAA message and forwards it to the EAP authentication server (Msg 3b). The authenticator does not need to check the validity of CBID. (4) The EAP authentication server will check the validity of the identity message. First, it checks if the equation CBID=HASH(PK||OPTIONAL-CONTENT) holds true, if not, the server won't continue. Second, it checks if the signature is valid by taking the public key PK as the verification key. Only if the signature is valid will the server start the EAP authentication method in (5); (5) The EAP authentication server consults its local configuration and starts authenticating the peer using the corresponding EAP method. With the above procedure, attackers cannot intrude the EAP framework even if they can eavesdrop the transmitted EAP identity message. First, due to the property of one way hash function, attackers are Cao, et al. Expires April 13, 2018 [Page 4] Internet-Draft EAP Identity Protection October 2017 not able to find another public key which maps to the same CBID. Secondly, attackers cannot simply replay another user's identity because they do not have access to the corresponding private key to generate the valid signature. 3.3. Extended EAP-Response/Identity Message Format Figure 2 depicts the extended EAP-Response/Identity message format. o Code. Code=2, this is an EAP Response message; o Identifier. The Identifier field is one octet, as specified in RFC3748; o Length. The Length field is two octets. The length of the whole EAP Response message, in bytes, including the Code (1 byte), Identifier(1 byte), and Length (2 byte), and the Type and Type data(variable length); o Type. One octet. This message contains peer identity information, so the type value is 1 according to [RFC3748] . o CBID: 160 bits, as generated in Equation(1); o Random: 24 bits, generated by the peer, the peer should use random generator with good enough randomness; Cao, et al. Expires April 13, 2018 [Page 5] Internet-Draft EAP Identity Protection October 2017 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +---------------+-----------------------------------------------+ | Type=1 | | +---------------+ | | CBID (160 bit) | | | | +-----------------------------------------------| | | Random (24 bit) | |---------------+-----------------------------------------------| | | | Public Key (variable length) | ~ ~ +---------------------------------------------------------------+ | | ~ Signature (variable length) ~ | | +---------------------------------------------------------------+ Figure 2: Extended EAP-Response/ID Message Format Public key: This is a variable-length field containing the public key of the address owner. The public key MUST be formatted as a DER- encoded ASN.1 structure of the type SubjectPublicKeyInfo, defined in the Internet X.509 certificate profile [RFC 3280]. RSA signature algorithm is used, so the algorithm identifier MUST be rsaEncryption, which is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted by using the RSAPublicKey type as specified in Section 2.3.1 of RFC3279 [RFC 3279]. The RSA key length SHOULD be at least 384 bits. The length of this field is determined by the ASN.1 encoding. o Signature: the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC 3447] signature algorithm with the SHA-1 hash algorithm. 4. Security Considerations TBD 5. IANA Considerations None Cao, et al. Expires April 13, 2018 [Page 6] Internet-Draft EAP Identity Protection October 2017 6. Acknowledgments TBD 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . Authors' Addresses Zhen Cao Huawei Xinxi Rd 3 Beijing 100085 China Email: zhencao.ietf@gmail.com Dapeng Liu Alibaba Beijing 100022 China Email: max.ldp@alibaba-inc.com Minpeng Qi China Mobile Beijing 100053 China Email: qiminpeng@chinamobile.com Cao, et al. Expires April 13, 2018 [Page 7]