idnits 2.17.1 draft-zcao-eap-id-protection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 10, 2017) is 2390 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3447' is mentioned on line 167, but not defined ** Obsolete undefined reference: RFC 3447 (Obsoleted by RFC 8017) == Missing Reference: 'RFC 3280' is mentioned on line 245, but not defined ** Obsolete undefined reference: RFC 3280 (Obsoleted by RFC 5280) == Missing Reference: 'RFC 3279' is mentioned on line 249, but not defined Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Cao 3 Internet-Draft Huawei 4 Intended status: Informational D. Liu 5 Expires: April 13, 2018 Alibaba 6 M. Qi 7 China Mobile 8 October 10, 2017 10 EAP Authentication Identity Protection 11 draft-zcao-eap-id-protection-00 13 Abstract 15 The EAP framework does not provide an effective way to protect the 16 peer's identity. This creates the risk of identity forgery. This 17 document revisits the EAP identity protection problem, and proposes a 18 solution to this problem via the use of Cryptographically Binding 19 Identity (CBID). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 13, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document . . . . . . . . . . . . . . 3 57 3. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Crypto-binding Identity Generation . . . . . . . . . . . 3 59 3.2. EAP Authentication using Crypto-Binding ID . . . . . . . 3 60 3.3. Extended EAP-Response/Identity Message Format . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 In the EAP framework [RFC3748], the EAP peer will respond with its 70 authentication identity in the EAP-Response/Identity message. Based 71 on the configuration with respect to the peer's identity, the EAP 72 Authentication Server will determine which EAP method to start with 73 this peer. But this creates potential security threats towards the 74 EAP identity. For example, suppose user A with identity ID-A is 75 configured to be authenticated with EAP-MD5 which is considered to be 76 a week authentication method, then an attacker M can 'steal' A's 77 identity by responding the EAP-Request/Identity message with IDA, so 78 that the server will authenticate M using EAP-MD5. In this way, 79 attackers obtain an easier way to be authenticated to the system and 80 then can harm the system in multiple ways. 82 Currently there are no direct solutions to conduct EAP identity 83 protection. One way introduced in RFC3748 is to neglect the EAP 84 identity exchange and let the server start with the same EAP method 85 for every user, and only after a secure tunnel is established can the 86 peer informs its identity to the server. Another common method to 87 avoid identity stolen is to use the anonymous identity, e.g., the 88 users within the same domain use the same ''anon@example.org'' to 89 initiate the EAP authentication. However, this anonymous identity 90 does not prevent the malicious to conduct the identity attack. 92 This document introduces an EAP identity protection mechanism. 93 Instead of using a native identity such as ''bob'' or 94 ''bob@example.org'', the EAP peer should generate a Cryptography- 95 Binding Identity (CBID) by hashing its public key so that the used 96 EAP identity is bind to the user's public key. The peer will include 97 this crypto-binding ID in the EAP-Response/Identity and sign the 98 message with its private key. In this way, an attacker has no way to 99 forge a valid public key that maps to the CBID and a valid signature 100 representing this public key. By using the CBID, EAP authentication 101 can be kept immune to the EAP identity threat. 103 2. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Proposed Solutions 111 We introduce our solution in this section. 113 3.1. Crypto-binding Identity Generation 115 Suppose the EAP peer has its own RSA public and private key pair (PK, 116 SK), it will generate its crypto-binding identity (CBID) as: 118 CBID = HASH (PK||OPTIONAL-CONTENT) (1) 120 Where the HASH algorithm is an one-way function so that it is 121 computational infeasible to do reverse derivation. The OPTIONAL- 122 CONTENT may contain the human readable user id and the domain name 123 information ''@example.org''. The OPTIONAL-CONTENT is configurable 124 and synchronized between the EAP Peer and Server 126 After the CBID is generated, the user will include this identity in 127 the EAP-Response/Identity message, and the server will configure an 128 EAP method with this identity. 130 3.2. EAP Authentication using Crypto-Binding ID 132 In this section, we will show how the proposed solution can prevent 133 attackers to forge other peers' identity by using CBID. 135 When an EAP peer A receives the EAP-Request/Identity, it will respond 136 with its crypto-binding identity CBID-A and a random number Ra 137 together with a signature on the whole message using its private key 138 SK-A and the RSA signature algorithm. The detailed message format 139 will be shown in Section.3.3. 141 The identity exchange procedure is depicted in Figure 1. The EAP 142 Peer, Authenticator and EAP Server definitions are align with RFC 143 3748. 145 +----------+ +-------------+ +----------+ 146 | EAP peer | |Authenticator| |EAP Server| 147 +----------+ +-------------+ +----------+ 148 | (1) | | 149 |<------------------| | 150 | | | 151 (2) | | 152 | (3a) | (3b) | 153 |------------------>|------------------->| 154 | | (4) 155 | | (5) | 156 | |<-------------------| 158 Figure 1: Identity Exchange using CBID 160 (1) The authenticator sends the EAP-Request/Identity to the peer; 162 (2) The EAP peer includes its CBID and generates a random number Ra, 163 and then uses the RSA signature algorithm to generate a signature 164 Sig. The peer first prepares a concatenation including the EAP Code, 165 Identifier, Length, Type, CBID and Random number, i.e. 166 Code||Identifier||Length||Type||CBID||Random. The peer then 167 generates the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC3447] 168 signature algorithm with the SHA-1 hash algorithm. The private key 169 (SK) and the concatenation created above are the inputs to the 170 generation operation. 172 (3) The EAP peer sends the concatenated EAP-Response/Identity message 173 (3a) to the EAP authenticator, the logic format of this message is 174 as: EAP-Response/ID (CBID||Random||PK||Sig). The authenticator 175 encapsulates this EAP-Response into the AAA message and forwards it 176 to the EAP authentication server (Msg 3b). The authenticator does 177 not need to check the validity of CBID. 179 (4) The EAP authentication server will check the validity of the 180 identity message. First, it checks if the equation 181 CBID=HASH(PK||OPTIONAL-CONTENT) holds true, if not, the server won't 182 continue. Second, it checks if the signature is valid by taking the 183 public key PK as the verification key. Only if the signature is 184 valid will the server start the EAP authentication method in (5); 186 (5) The EAP authentication server consults its local configuration 187 and starts authenticating the peer using the corresponding EAP 188 method. 190 With the above procedure, attackers cannot intrude the EAP framework 191 even if they can eavesdrop the transmitted EAP identity message. 192 First, due to the property of one way hash function, attackers are 193 not able to find another public key which maps to the same CBID. 194 Secondly, attackers cannot simply replay another user's identity 195 because they do not have access to the corresponding private key to 196 generate the valid signature. 198 3.3. Extended EAP-Response/Identity Message Format 200 Figure 2 depicts the extended EAP-Response/Identity message format. 202 o Code. Code=2, this is an EAP Response message; 204 o Identifier. The Identifier field is one octet, as specified in 205 RFC3748; 207 o Length. The Length field is two octets. The length of the whole 208 EAP Response message, in bytes, including the Code (1 byte), 209 Identifier(1 byte), and Length (2 byte), and the Type and Type 210 data(variable length); 212 o Type. One octet. This message contains peer identity information, 213 so the type value is 1 according to [RFC3748] . 215 o CBID: 160 bits, as generated in Equation(1); 217 o Random: 24 bits, generated by the peer, the peer should use random 218 generator with good enough randomness; 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Code | Identifier | Length | 223 +---------------+-----------------------------------------------+ 224 | Type=1 | | 225 +---------------+ | 226 | CBID (160 bit) | 227 | | 228 | +-----------------------------------------------| 229 | | Random (24 bit) | 230 |---------------+-----------------------------------------------| 231 | | 232 | Public Key (variable length) | 233 ~ ~ 234 +---------------------------------------------------------------+ 235 | | 236 ~ Signature (variable length) ~ 237 | | 238 +---------------------------------------------------------------+ 240 Figure 2: Extended EAP-Response/ID Message Format 242 Public key: This is a variable-length field containing the public key 243 of the address owner. The public key MUST be formatted as a DER- 244 encoded ASN.1 structure of the type SubjectPublicKeyInfo, defined in 245 the Internet X.509 certificate profile [RFC 3280]. RSA signature 246 algorithm is used, so the algorithm identifier MUST be rsaEncryption, 247 which is 1.2.840.113549.1.1.1, and the RSA public key MUST be 248 formatted by using the RSAPublicKey type as specified in 249 Section 2.3.1 of RFC3279 [RFC 3279]. The RSA key length SHOULD be at 250 least 384 bits. The length of this field is determined by the ASN.1 251 encoding. 253 o Signature: the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC 254 3447] signature algorithm with the SHA-1 hash algorithm. 256 4. Security Considerations 258 TBD 260 5. IANA Considerations 262 None 264 6. Acknowledgments 266 TBD 268 7. References 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, 272 DOI 10.17487/RFC2119, March 1997, 273 . 275 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 276 Levkowetz, Ed., "Extensible Authentication Protocol 277 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 278 . 280 Authors' Addresses 282 Zhen Cao 283 Huawei 284 Xinxi Rd 3 285 Beijing 100085 286 China 288 Email: zhencao.ietf@gmail.com 290 Dapeng Liu 291 Alibaba 292 Beijing 100022 293 China 295 Email: max.ldp@alibaba-inc.com 297 Minpeng Qi 298 China Mobile 299 Beijing 100053 300 China 302 Email: qiminpeng@chinamobile.com