idnits 2.17.1 draft-sheffer-emu-eap-eke-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 10, 2009) is 5553 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2284' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'RFC5114' is defined on line 995, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-14) exists of draft-harkins-emu-eap-pwd-03 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Check Point 4 Intended status: Standards Track G. Zorn 5 Expires: August 14, 2009 Network Zen 6 H. Tschofenig 7 Nokia Siemens Networks 8 S. Fluhrer 9 Cisco 10 February 10, 2009 12 An EAP Authentication Method Based on the EKE Protocol 13 draft-sheffer-emu-eap-eke-01 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 14, 2009. 38 Copyright Notice 40 Copyright (c) 2009 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 (http://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. 50 Abstract 52 The Extensible Authentication Protocol (EAP) describes a framework 53 that allows the use of multiple authentication mechanisms. This 54 document defines an authentication mechanism for EAP called EAP-EKE, 55 based on the Encrypted Key Exchange (EKE) protocol. This method 56 provides mutual authentication through the use of a short, easy to 57 remember password. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. EAP-EKE-ID . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.4. EAP-EKE-Commit . . . . . . . . . . . . . . . . . . . . . . 8 71 4.5. EAP-EKE-Confirm . . . . . . . . . . . . . . . . . . . . . 9 72 4.6. EAP-EKE-Failure and EAP-EKE-Protected-Failure . . . . . . 10 73 5. Cryptographic Operations . . . . . . . . . . . . . . . . . . . 11 74 5.1. Generating Keying Material . . . . . . . . . . . . . . . . 11 75 5.2. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 12 76 5.3. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 12 77 5.4. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 13 78 5.5. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 14 79 5.6. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 14 80 5.7. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 14 81 5.8. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 15 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 7.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 20 85 7.2. Diffie Hellman Group Considerations . . . . . . . . . . . 20 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 90 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 91 A.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 A.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 Appendix B. Design Options . . . . . . . . . . . . . . . . . . . 23 94 B.1. Number of Round Trips . . . . . . . . . . . . . . . . . . 23 95 B.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 The predominant access method for the Internet today is that of a 101 human using a username and password to authenticate to a computer 102 enforcing access control. Proof of knowledge of the password 103 authenticates the human to the computer. 105 Typically, these passwords are not stored on a user's computer for 106 security reasons and must be entered each time the human desires 107 network access. Therefore, the passwords must be ones that can be 108 repeatedly entered by a human with a low probability of error. They 109 will likely not possess high entropy and it may be assumed that an 110 adversary with access to a dictionary will have the ability to guess 111 a user's password. It is therefore desirable to have a robust 112 authentication method that is secure even when used with a weak 113 password in the presence of a strong adversary. 115 EAP-EKE is an EAP method [RFC3748] that addresses the problem of 116 password-based authenticated key exchange, using a possibly weak 117 password for authentication and to derive an authenticated and 118 cryptographically strong shared secret. This problem was first 119 described by Bellovin and Merritt in [BM92] and [BM93]. 120 Subsequently, a number of other solution approaches have been 121 proposed, for example [JAB96], [LUC97], [BMP00], and others. 123 This proposal is based on the original Encrypted Key Exchange (EKE) 124 proposal, as described in [BM92]. Some of the variants of the 125 original EKE has been attacked, see e.g. [PA97], and improvements 126 have been proposed. None of these subsequent improvements have been 127 incorporated into the current protocol. However, we have used only 128 the subset of [BM92] (namely the variant described in Section 3.1) 129 which has withstood the test of time and is believed secure as of 130 this writing. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. Protocol 140 3.1. Protocol Overview 142 EAP is a two-party protocol spoken between an EAP peer and an EAP 143 server (also known as "authenticator"). An EAP method defines the 144 specific authentication protocol being used by EAP. This memo 145 defines a particular method and therefore defines the messages sent 146 between the EAP server and the EAP peer for the purpose of 147 authentication and key derivation. 149 3.2. Message Flows 151 EAP-EKE defines three message exchanges: an Identity exchange, a 152 Commit exchange and a Confirm exchange. A successful authentication 153 is shown in Figure 1. 155 The peer and server use the EAP-EKE Identity exchange to learn each 156 other's identities and to agree upon a ciphersuite to use in the 157 subsequent exchanges. In the Commit exchange the peer and server 158 exchange information to generate a shared key and also to bind each 159 other to a particular guess of the password. In the Confirm exchange 160 the peer and server prove liveness and knowledge of the password by 161 generating and verifying verification data. 163 +--------+ +--------+ 164 | | EAP-EKE-ID/Request | | 165 | EAP |<------------------------------------| EAP | 166 | peer | | server | 167 | (P) | EAP-EKE-ID/Response | (S) | 168 | |------------------------------------>| | 169 | | | | 170 | | EAP-EKE-Commit/Request | | 171 | |<------------------------------------| | 172 | | | | 173 | | EAP-EKE-Commit/Response | | 174 | |------------------------------------>| | 175 | | | | 176 | | EAP-EKE-Confirm/Request | | 177 | |<------------------------------------| | 178 | | | | 179 | | EAP-EKE-Confirm/Response | | 180 | |------------------------------------>| | 181 | | | | 182 | | EAP-Success | | 183 | |<------------------------------------| | 184 +--------+ +--------+ 186 Figure 1: A Successful EAP-EKE Exchange 188 Schematically, the original exchange as described in [BM92] (and with 189 the roles reversed) is: 191 Server Peer 192 ------ ---- 193 E(Password, Y_S)) -> 194 <- E(Password, Y_P), E(SharedSecret, Nonce_P) 195 E(SharedSecret, Nonce_S | Nonce_P) -> 196 <- E(SharedSecret, Nonce_S) 198 Where: 199 o Y_S and Y_P are the server's (and respectively, the peer's) 200 ephemeral public key, i.e. g^x (mod p), g^y (mod p). 201 o Nonce_S, Nonce_P are random strings generated by the server and 202 the peer as cryptographic challenges. 203 o SharedSecret is the secret created by the Diffie-Hellman 204 algorithm, namely g^(x*y) (mod p). 205 The current protocol extends the basic cryptographic protocol, and 206 the regular successful exchange becomes: 208 EAP-EKE-ID/Request: S -> P 210 ID_S, CryptoProposals 212 EAP-EKE-ID/Response: S <- P 214 ID_P, CryptoSelection 216 EAP-EKE-Commit/Request: S -> P 218 E(Password, Y_S)) 220 EAP-EKE-Commit/Response: S <- P 222 E(Password, Y_P), E(Ke, Nonce_P) 224 EAP-EKE-Confirm/Request: S -> P 226 E(Ke, Nonce_S | Nonce_P), Auth_S 228 EAP-EKE-Confirm/Response: S <- P 230 E(Ke, Nonce_S), Auth_P 232 As shown in the exchange above, the following information elements 233 are added to the original protocol: identity values for both protocol 234 parties (ID_S, ID_P), negotiation of cryptographic protocols, and 235 signature fields to protect the integrity of the negotiated 236 parameters (Auth_S, Auth_P). In addition the shared secret is not 237 used directly. Note that a few details have been omitted for 238 clarity. 240 4. Packet Formats 242 4.1. EAP-EKE Header 244 The EAP-EKE header consists of the standard EAP header (see Section 4 245 of [RFC3748]), followed an EAP-EKE exchange type. The header has the 246 following structure: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Code | Identifier | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type | EKE-Exch | Data ... 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 2: EAP-EKE Header 258 The Code, Identifier, Length, and Type fields are all part of the EAP 259 header, and defined in [RFC3748]. The Type field in the EAP header 260 MUST be the value allocated by IANA for EAP-EKE version 1. 262 The EKE-Exch field identifies the type of EAP-EKE payload 263 encapsulated in the Data field. This document defines the following 264 values for the EKE-Exch field: 265 o 0x00: Reserved 266 o 0x01: EAP-EKE-ID exchange 267 o 0x02: EAP-EKE-Commit exchange 268 o 0x03: EAP-EKE-Confirm exchange 269 o 0x04: EAP-EKE-Failure message 270 o 0x05: EAP-EKE-Protected-Failure message 272 Further values of this EKE-Exch field are available via IANA 273 registration. 275 4.2. EAP-EKE Payloads 277 EAP-EKE payloads all contain the EAP-EKE header and encoded 278 information, which differs for the different exchanges. 280 4.3. EAP-EKE-ID 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | NumProposals | Reserved | Proposal ... 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 ... Proposal | IDType | Identity ... 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 3: EAP-EKE-ID Payload 292 The EAP-EKE-ID payload contains the following fields: 294 NumProposals: 296 The NumProposals field contains the number of proposals 297 subsequently contained in the Proposal field. In the EAP-EKE-ID/ 298 Request the NumProposals field MUST NOT be set to zero (0) and in 299 the EAP-EKE-ID/Response message the NumProposals field MUST be set 300 to one (1). The offered proposals in the Request are listed 301 contiguously in priority order, most preferable first. The 302 selected proposal in the Response MUST be fully identical with one 303 of the offered proposals. 305 Proposal: 307 Each proposal consists of four one-octet fields, in this order: 309 Group Description: 311 This field's value is taken from the IANA registry for Diffie- 312 Hellman groups defined in Section 6.4. 314 Encryption: 316 This field's value is taken from the IANA registry for 317 encryption algorithms defined in Section 6.1. 319 PRF: 321 This field's value is taken from the IANA registry for pseudo 322 random functions defined in Section 6.2. 324 MAC: 326 This field's value is taken from the IANA registry for keyed 327 message digest algorithms defined in Section 6.3 used to 328 provide integrity protection. 330 IDType 332 Denotes the Identity type. This is taken from the IANA registry 333 defined in Section 6. The server and the peer MAY use different 334 identity types. 336 The Identity field is always printable, and its meaning depends on 337 the values of the Code and IDType fields. 339 o EAP-EKE-ID/Request: server ID 340 o EAP-EKE-ID/Response: peer ID 342 The server SHOULD assert its own identity (e.g. its host name), or it 343 MAY use the peer's identity if it knows it before the protocol 344 starts. 346 The length of the Identity is computed from the Length field in the 347 EAP header. 349 4.4. EAP-EKE-Commit 351 In this exchange both parties send their encrypted ephemeral public 352 key, and the peer also includes a Challenge. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | DHComponent ~ 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 ~ ~ 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Commit_P ~ 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 ~ ~ 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 4: EAP-EKE-Commit Payload 367 DHComponent: 369 This field contains the password-encrypted Diffie-Hellman public 370 key, see Section 5.2. 372 Commit_P: 374 This field only appears in the response, and contains the 375 encrypted challenge value sent by the peer. See Section 5.3. 377 4.5. EAP-EKE-Confirm 379 In this exchange both parties complete the authentication by 380 generating a shared temporary key, authenticating the entire 381 protocol, and generating key material for the EAP consumer protocol. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Confirm_? ~ 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 ~ ~ 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Auth_? ~ 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 ~ ~ 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 5: EAP-EKE-Confirm Payload 397 Confirm_?: 399 This field contains the encrypted response to the other peer's 400 challenge, see Section 5.4 and Section 5.5. 402 Auth_? 404 This field signs the Identity and the negotiated fields, to 405 prevent downgrade attacks. See Section 5.4 and Section 5.5. 407 4.6. EAP-EKE-Failure and EAP-EKE-Protected-Failure 409 The EAP-EKE-Failure message format is defined as follows: 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Failure-Code | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 EAP-EKE-Failure Payload 419 The EAP-EKE-Protected-Failure payload format is defined as follows: 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Failure-Code | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 ... MAC ... 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 EAP-EKE-Protected-Failure Payload 433 The MAC field contains the keyed message digest computed with the MAC 434 algorithm selected during the initial exchange computed over the 435 Failure-Code using the MAC key (see Section 5 on how this key is 436 derived). A protected failure response can only be returned once the 437 MAC key has been derived. 439 Currently the following Failure-Code values are defined: 440 o 0x00000000: Reserved 441 o 0x00000001: No Error 442 o 0x00000002: Protocol Error 443 o 0x00000003: Password Not Found 444 o 0x00000004: Authentication Failure 445 o 0x00000005: Authorization Failure 446 o 0x00000006: No Proposal Chosen 448 Additional values of this field are available via IANA registration. 450 "No Error" is used for failure acknowledgement, see below. "Protocol 451 Error" indicates a failure to parse or understand a protocol message 452 or one of its payloads. "Password Not Found" indicates a password 453 for a particular user could not be located, making authentication 454 impossible. "Authentication Failure" indicates failure in the 455 cryptographic computation most likely caused by an incorrect 456 password, or an inappropriate identity type. "Authorization Failure" 457 indicates that while the password being used is correct, the user is 458 not authorized to connect. "No Proposal Chosen" indicates that the 459 peer is unwilling to select any of the cryptographic proposals 460 offered by the server. 462 When the peer encounters an error situation, it MUST respond with 463 either EAP-EKE-Failure or EAP-EKE-Protected-Failure, depending on 464 whether it believes a common MAC key has been agreed upon. The 465 server MUST send an EAP-Failure message to end the exchange. 467 When the server encounters an error situation, it MUST respond with 468 either EAP-EKE-Failure or EAP-EKE-Protected-Failure, depending on 469 whether it believes a common MAC key has been agreed upon. The peer 470 MUST send back either EAP-EKE-Failure or EAP-EKE-Protected-Failure 471 (corresponding to the server's selection), containing a "No Error" 472 failure code. Then the server MUST send an EAP-Failure message to 473 end the exchange. 475 5. Cryptographic Operations 477 5.1. Generating Keying Material 479 Keying material will always be derived as the output of the 480 negotiated prf algorithm. Since the amount of keying material needed 481 may be greater than the size of the output of the prf algorithm, we 482 will use the prf iteratively. We will use the terminology prf+ to 483 describe the function that outputs a pseudo-random stream based on 484 the inputs to a prf as follows: (where | indicates concatenation) 486 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 488 where: 489 T1 = prf(K, S | 0x01) 490 T2 = prf(K, T1 | S | 0x02) 491 T3 = prf(K, T2 | S | 0x03) 492 T4 = prf(K, T3 | S | 0x04) 494 continuing as needed to compute all required keys. The keys are 495 taken from the output string without regard to boundaries (e.g., if 496 the required keys are a 256-bit Advanced Encryption Standard (AES) 497 key and a 160-bit HMAC key, and the prf function generates 160 bits, 498 the AES key will come from T1 and the beginning of T2, while the HMAC 499 key will come from the rest of T2 and the beginning of T3). 501 The constant concatenated to the end of each string feeding the prf 502 is a single octet. prf+ in this document is not defined beyond 255 503 times the size of the prf output. 505 5.2. EAP-EKE-Commit/Request 507 The server computes 509 Y_S = g^x mod N, 511 where 'x' is a randomly chosen number in the range 2 .. N-1. The 512 randomly chosen number is the private key, and the calculated field 513 is the corresponding public key. The calculated value MUST NOT be 514 zero modulo N. If the peer receives a bad value for this field, it 515 MUST take action to disconnect or disable the link. Each of the 516 peers MUST use a fresh, random value for this field on each run of 517 the protocol. 519 Note: If Elliptic Curve Diffie-Hellman is used, the corresponding 520 additive group operations are to be understood. 522 The server transmits 524 DHComponent_S = E(prf+(password, "EAP-EKE Password"), Y_S), 526 encrypted using the algorithm negotiated during the previous 527 exchange. If required by the encryption algorithm/mode, the 528 encrypted field is preceded by an Initialization Vector (IV), whose 529 length depends on the algorithm. The IV value MUST be unpredictable. 531 When using block ciphers, it may be necessary to pad Y_S on the 532 right, to fit the encryption algorithm's block size. In such cases, 533 random padding MUST be used, and this randomness is critical to the 534 security of the protocol. Randomness recommendations can be found in 535 [RFC4086]. When decrypting this field, the real length of Y_S is 536 determined according to the negotiated Diffie Hellman group. 538 If the password needs to be stored on the server, it is RECOMMENDED 539 to store the randomized password value, i.e. prf+(password, ...), as 540 a password-equivalent, rather than the cleartext password. 542 5.3. EAP-EKE-Commit/Response 544 The peer computes 545 Y_P = g^y mod N 547 and sends 549 DHComponent_P = E(prf+(password, "EAP-EKE Password"), Y_P) 551 If the password is non-ASCII, it SHOULD be normalized by the peer 552 before the EAP-EKE message is constructed. The normalization method 553 is SASLprep, [RFC4013]. Note that the password is not null- 554 terminated. 556 Both sides calculate 558 SharedSecret = g^(x*y) mod N 560 The encryption key is computed: 562 Ke = prf+(SharedSecret, "EAP-EKE Ke" | ID_S | ID_P) 564 The MAC key is computed: 566 MAC = prf+(SharedSecret, "EAP-EKE MAC" | ID_S | ID_P) 568 And the peer generates 570 Challenge_P = E(Ke, Nonce_P), 572 where Nonce_P is a randomly generated binary string. Nonce_P has 573 length equal to the block size of E for block ciphers, or 32 octets 574 if E is a stream cipher. 576 5.4. EAP-EKE-Confirm/Request 578 The server sends: 580 Commit_S = E(Ke, Nonce_P | Nonce_S), 582 where Nonce_S is a randomly generated string, similar to Nonce_P. 584 It computes: 586 Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | 587 Nonce_S) 589 And sends: 591 Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE- 592 ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response), 594 where the literal string is encoded using ASCII with no zero 595 terminator. The messages are included in full, starting with the EAP 596 header, and including any possible future extensions. 598 5.5. EAP-EKE-Confirm/Response 600 The peer computes Ka, and sends: 602 Commit_P = E(Ke, Nonce_S) 603 Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/ 604 Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response) 606 5.6. MSK and EMSK 608 Following the last message of the protocol, both sides compute and 609 export the shared keys, each 512 bits in length: 611 MSK = prf+(SharedSecret, "EAP-EKE MSK" | ID_S | ID_P | Nonce_P | 612 Nonce_S) 613 EMSK = prf+(SharedSecret, "EAP-EKE EMSK" | ID_S | ID_P | Nonce_P | 614 Nonce_S) 616 5.7. Diffie-Hellman Groups 618 Many of the commonly used Diffie Hellman groups are inappropriate for 619 use in EKE. Most of these groups use a generator which is not a 620 primitive element of the group. As a result, an attacker running a 621 dictionary attack would be able to learn at least 1 bit of 622 information for each decrypted password guess. 624 Any MODP Diffie Hellman group defined for use in this protocol MUST 625 have the following properties, to ensure that it does not leak a 626 usable amount of information about the password: 627 1. The generator is a primitive element of the group. 628 2. The most significant 64 bits of the prime number are 1. 629 3. The group's order p is a "safe prime", i.e. (p-1)/2 is also 630 prime. 632 The last requirement is related to the strength of the Diffie Hellman 633 algorithm, rather than the password encryption. It also makes it 634 easy to verify that the generator is primitive. 636 We have defined the following groups: 638 o DHGROUP_EKE_14 is defined by: the prime number of Group 14 639 [RFC3526], with the generator 11 (decimal). 640 o Additional groups will be defined by future versions of this 641 document. 643 5.8. Mandatory Algorithms 645 To facilitate interoperability, the following algorithms are 646 mandatory to implement: 648 o ENCR_AES128_CBC (encryption algorithm) 649 o PRF_HMAC_SHA1 (pseudo random function and keyed message digest) 650 o DHGROUP_EKE_14 (DH-group) 652 6. IANA Considerations 654 This document allocates an EAP method type, for "EAP-EKE Version 1". 656 This document requires IANA to create the registries described in the 657 subsequent sections. Values can be added or modified in these 658 registries per Specification Required [RFC5226]. 660 6.1. Encryption Algorithm Registry 662 This section defines an IANA registry for encryption algorithms: 664 +-----------------+---------+----------------------------------+ 665 | Name | Value | Definition | 666 +-----------------+---------+----------------------------------+ 667 | Reserved | 0 | | 668 | ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode | 669 | | 2-127 | Available for allocation via IANA| 670 | | 128-255 | Reserved for private use | 671 +-----------------+---------+----------------------------------+ 673 6.2. Pseudo Random Function Registry 675 This section defines an IANA registry for pseudo random function 676 algorithms: 678 +---------------+---------+-------------------------------------+ 679 | Name | Value | Definition | 680 +---------------+---------+-------------------------------------+ 681 | Reserved | 0 | | 682 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 683 | | 2-127 | Available for allocation via IANA | 684 | | 128-255 | Reserved for private use | 685 +---------------+---------+-------------------------------------+ 687 6.3. Keyed Message Digest Registry 689 This section defines an IANA registry for keyed message digest 690 algorithms: 692 +---------------+---------+-------------------------------------+ 693 | Name | Value | Definition | 694 +---------------+---------+-------------------------------------+ 695 | Reserved | 0 | | 696 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 697 | | 2-127 | Available for allocation via IANA | 698 | | 128-255 | Reserved for private use | 699 +---------------+---------+-------------------------------------+ 701 6.4. Diffie-Hellman Group Registry 703 This section defines an IANA registry for Diffie-Hellman groups: 705 +----------------+---------+-------------------------------------------+ 706 | Name | Value | Definition | 707 +----------------+---------+-------------------------------------------+ 708 | Reserved | 0 | | 709 | DHGROUP_EKE_14 | 1 | 2048-bit MODP Group defined in this | 710 | | | document | 711 | | 2-127 | Available for allocation via IANA | 712 | | 128-255 | Reserved for private use | 713 +----------------+---------+-------------------------------------------+ 715 6.5. Identity Type Registry 717 In addition, an identity type registry is defined: 719 +-----------+---------+---------------------------------------------+ 720 | Name | Value | Definition | 721 +-----------+---------+---------------------------------------------+ 722 | Reserved | 0 | | 723 | ID_OPAQUE | 1 | A printable string whose format is | 724 | | | undefined | 725 | ID_NAI | 2 | A Network Access Identifier, as defined in | 726 | | | [RFC4282] (mandatory to implement) | 727 | ID_IPv4 | 3 | An IPv4 address, in binary format | 728 | ID_IPv6 | 4 | An IPv6 address, in binary format | 729 | ID_FQDN | 5 | A fully qualified domain name (mandatory to | 730 | | | implement) | 731 | | 6-127 | Available for allocation via IANA | 732 | | 128-255 | Reserved for private use | 733 +-----------+---------+---------------------------------------------+ 735 6.6. Failure-Code Registry 737 This section defines an IANA registry for the Failure-Code registry, 738 a 32-bit long code. Initial values are defined in Section 4.6. All 739 values up to 0xff000000 are available for allocation via IANA. The 740 remaining values up to 0xffffffff are available for private use. 742 7. Security Considerations 744 Any protocol that claims to solve the problem of password- 745 authenticated key exchange must be resistant to active, passive and 746 dictionary attack and have the quality of forward secrecy. These 747 characteristics are discussed further in the following paragraphs. 749 Resistance to Passive Attack A passive attacker is one that merely 750 relays messages back and forth between the peer and server, 751 faithfully, and without modification. The contents of the 752 messages are available for inspection, but that is all. To 753 achieve resistance to passive attack, such an attacker must not be 754 able to obtain any information about the password or anything 755 about the resulting shared secret from watching repeated runs of 756 the protocol. Even if a passive attacker is able to learn the 757 password, she will not be able to determine any information about 758 the resulting secret shared by the peer and server. 759 Resistance to Active Attack An active attacker is able to modify, 760 add, delete, and replay messages sent between protocol 761 participants. For this protocol to be resistant to active attack, 762 the attacker must not be able to obtain any information about the 763 password or the shared secret by using any of its capabilities. 764 In addition, the attacker must not be able to fool a protocol 765 participant into thinking that the protocol completed 766 successfully. It is always possible for an active attacker to 767 deny delivery of a message critical in completing the exchange. 768 This is no different than dropping all messages and is not an 769 attack against the protocol. 770 Resistance to Dictionary Attack For this protocol to be resistant to 771 dictionary attack any advantage an adversary can gain must be 772 directly related to the number of interactions she makes with an 773 honest protocol participant and not through computation. The 774 adversary will not be able to obtain any information about the 775 password except whether a single guess from a single protocol run 776 is correct or incorrect. 777 Forward Secrecy Compromise of the password must not provide any 778 information about the secrets generated by earlier runs of the 779 protocol. 781 [RFC3748] requires that documents describing new EAP methods clearly 782 articulate the security properties of the method. In addition, for 783 use with wireless LANs, [RFC4017] mandates and recommends several of 784 these. The claims are: 785 1. Mechanism: password. 786 2. Claims: 787 * Mutual authentication: the peer and server both authenticate 788 each other by proving possession of a shared password. This 789 is REQUIRED by [RFC4017]. 790 * Forward secrecy: compromise of the password does not reveal 791 the secret keys (MSK and EMSK) from earlier runs of the 792 protocol. 793 * Replay protection: an attacker is unable to replay messages 794 from a previous exchange either to learn the password or a key 795 derived by the exchange. Similarly the attacker is unable to 796 induce either the peer or server to believe the exchange has 797 successfully completed when it hasn't. 798 * Key derivation: a shared secret is derived by performing a 799 group operation in a finite cyclic group (e.g. exponentiation) 800 using secret data contributed by both the peer and server. An 801 MSK and EMSK are derived from that shared secret. This is 802 REQUIRED by [RFC4017]. 803 * Dictionary attack resistance: an attacker can only make one 804 password guess per active attack, and the protocol is designed 805 so that the attacker does not gain any confirmation of her 806 guess by observing the decrypted Y_x value (see below). The 807 advantage she can gain is through interaction not through 808 computation. This is REQUIRED by [RFC4017]. 809 * Session independence: this protocol is resistant to active and 810 passive attacks and does not enable compromise of subsequent 811 or prior MSKs or EMSKs from either passive or active attacks. 813 * Denial of Service resistance: it is possible for an attacker 814 to cause a server to allocate state and consume CPU. Such an 815 attack is gated, though, by the requirement that the attacker 816 first obtain connectivity through a lower-layer protocol (e.g. 817 802.11 authentication followed by 802.11 association, or 802.3 818 "link-up") and respond to two EAP messages--the EAP-ID/ 819 Request and the EAP-EKE-ID/Request. 820 * Man-in-the-Middle Attack resistance: this exchange is 821 resistant to active attack, which is a requirement for 822 launching a man-in-the-middle attack. This is REQUIRED by 823 [RFC4017]. 824 * Shared state equivalence: upon completion of EAP-EKE the peer 825 and server both agree on MSK, EMSK. The peer has 826 authenticated the server based on the Server_ID and the server 827 has authenticated the peer based on the Peer_ID. This is due 828 to the fact that Peer_ID, Server_ID, and the generated shared 829 secret are all combined to make the authentication element 830 which must be shared between the peer and server for the 831 exchange to complete. This is REQUIRED by [RFC4017]. 832 * Fragmentation: this protocol does not define a technique for 833 fragmentation and reassembly. 834 * Resistance to "Denning-Sacco" attack: learning keys 835 distributed from an earlier run of the protocol, such as the 836 MSK or EMSK, will not help an adversary learn the password. 837 3. Key strength: the strength of the resulting key depends on the 838 finite cyclic group chosen. Sufficient key strength is REQUIRED 839 by [RFC4017]. 840 4. Key hierarchy: MSKs and EMSKs are derived from the secret values 841 generated during the protocol run, using a negotiated pseudo- 842 random function. 843 5. Vulnerabilities (note that none of these are REQUIRED by 844 [RFC4017]): 845 * Protected ciphersuite negotiation: the ciphersuite proposal 846 made by the server is not protected from tampering by an 847 active attacker. However if a proposal was modified by an 848 active attacker it would result in a failure to confirm the 849 message sent by the other party, since the proposal is bound 850 by each side into its Confirm message, and the protocol would 851 fail as a result. 852 * Confidentiality: none of the messages sent in this protocol 853 are encrypted. 854 * Integrity protection: all messages in this protocol are 855 integrity protected. 856 * Channel binding: this protocol does not enable the exchange of 857 integrity-protected channel information that can be compared 858 with values communicated via out-of-band mechanisms. 860 * Fast reconnect: this protocol does not provide a fast 861 reconnect capability. 862 * Cryptographic binding: this protocol is not a tunneled EAP 863 method and therefore has no cryptographic information to bind. 864 * Identity protection: the EAP-EKE-ID exchange is not protected. 865 An attacker will see the server's identity in the EAP-EKE-ID/ 866 Request and see the peer's identity in EAP-EKE-ID/ Response. 868 7.1. Cryptographic Analysis 870 When analyzing the Commit exchange, it should be noted that the base 871 security assumptions are different from "normal" cryptology. 872 Normally, we assume that the key has strong security properties, and 873 that the data may have little. Here, we assume that the key has weak 874 security properties (the attacker may have a list of possible keys), 875 and hence we need to ensure that the data has strong properties 876 (indistinguishable from random). This difference may mean that 877 conventional wisdom in cryptology might not apply in this case. This 878 also imposes severe constraints on the protocol, e.g. the mandatory 879 use of random padding, and the need to define specific finite groups. 881 7.2. Diffie Hellman Group Considerations 883 It is fundamental to the dictionary attack resistance that the Diffie 884 Hellman public values Y_S and Y_P are indistinguishable from a random 885 string. If this condition is not met, then a passive attacker can do 886 trial-decryption of the encrypted DHComponent_P, DHComponent_S values 887 based on a password guess, and if they decrypt to a value which in 888 not a valid public value, they know that the password guess was 889 incorrect. 891 For MODP groups, Section 5.7 gives conditions on the group to make 892 sure that this criterion is met. For other groups (for example, 893 Elliptic Curve groups), some other means of ensuring this must be 894 employed. The standard way of expressing Elliptic Curve public 895 values does not meet this criterion, as a valid Elliptic Curve X 896 coordinate can be distinguished from a random string with probability 897 approximately 0.5. 899 A future version of this document might introduce a group 900 representation, and/or a slight modification of the password 901 encryption scheme, so that Elliptic Curve groups can be accommodated. 902 [BR02] presents several alternative solutions for this problem. 904 8. Acknowledgements 906 Much of this document was unashamedly picked from 908 [I-D.harkins-emu-eap-pwd] and [I-D.ietf-pppext-eap-srp-03], and we 909 would like to acknowledge the authors of these documents: Dan 910 Harkins, Glen Zorn, James Carlson, Bernard Aboba and Henry Haverinen. 911 We would like to thank David Jacobson and Steve Bellovin for their 912 useful comments. 914 9. References 916 9.1. Normative References 918 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 919 Hashing for Message Authentication", RFC 2104, 920 February 1997. 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, March 1997. 925 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 926 Authentication Protocol (EAP)", RFC 2284, March 1998. 928 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 929 Diffie-Hellman groups for Internet Key Exchange (IKE)", 930 RFC 3526, May 2003. 932 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 933 Levkowetz, "Extensible Authentication Protocol (EAP)", 934 RFC 3748, June 2004. 936 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 937 and Passwords", RFC 4013, February 2005. 939 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 940 Network Access Identifier", RFC 4282, December 2005. 942 9.2. Informative References 944 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 945 Password-Based Protocols Secure Against Dictionary 946 Attacks", Proc. IEEE Symp. on Research in Security and 947 Privacy , May 1992. 949 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 950 Exchange: A Password-Based Protocol Secure against 951 Dictionary Attacks and Password File Compromise", Proc. 952 1st ACM Conference on Computer and Communication 953 Security , 1993. 955 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 956 Password Authenticated Key Exchange Using Diffie-Hellman", 957 Advances in Cryptology, EUROCRYPT 2000 , 2000. 959 [BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite 960 Domains", Proc. of the RSA Cryptographer's Track (RSA CT 961 '02), LNCS 2271 , 2002. 963 [I-D.harkins-emu-eap-pwd] 964 Harkins, D. and G. Zorn, "EAP Authentication Using Only A 965 Password", draft-harkins-emu-eap-pwd-03 (work in 966 progress), November 2008. 968 [I-D.ietf-pppext-eap-srp-03] 969 Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 970 Authentication Protocol", draft-ietf-pppext-eap-srp-03 971 (work in progress), July 2001. 973 [JAB96] Jablon, D., "Strong Password-Only Authenticated Key 974 Exchange", ACM Computer Communications Review Volume 1, 975 Issue 5, October 1996. 977 [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary 978 Attacks Without Encrypting Public Keys", Proc. of the 979 Security Protocols Workshop LNCS 1361, 1997. 981 [PA97] Patel, S., "Number Theoretic Attacks On Secure Password 982 Schemes", Proceedings of the 1997 IEEE Symposium on 983 Security and Privacy , 1997. 985 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 986 Authentication Protocol (EAP) Method Requirements for 987 Wireless LANs", RFC 4017, March 2005. 989 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 990 Requirements for Security", BCP 106, RFC 4086, June 2005. 992 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 993 RFC 4306, December 2005. 995 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 996 Groups for Use with IETF Standards", RFC 5114, 997 January 2008. 999 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1000 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1001 May 2008. 1003 Appendix A. Change Log 1005 A.1. -01 1007 Revised following comments raised on the CFRG mailing list. In 1008 particular, added security considerations and a new DH group 1009 definition, to resolve the vulnerability in case the group's 1010 generator is not a primitive element. 1012 A.2. -00 1014 Initial version. 1016 Appendix B. Design Options 1018 B.1. Number of Round Trips 1020 We have looked at three options: 2 round trips, 3 round trips, and a 1021 normal run of 2 round trips with an optional third. Some of the 1022 decision factors include: 1024 o Performance (latency). 1025 o Crypto-agility, the ability to negotiate cryptographic algorithms. 1026 Ideally this applies to both the symmetric and asymmetric 1027 algorithms. 1028 o Complexity of the protocol state machine, when some messages are 1029 optional. 1030 o Dependence on a higher-level protocol sending the peer's identity 1031 before EAP-EKE starts, so that the correct password can be used. 1033 The initial version of this protocol has 3 round trips, primarily for 1034 simplicity. 1036 B.2. Fragmentation 1038 While similar documents ( [I-D.harkins-emu-eap-pwd]) provide 1039 fragmentation support at the level of the EAP method, we have decided 1040 that such support is unnecessary given the expected size of messages 1041 in EAP-EKE. 1043 Authors' Addresses 1045 Yaron Sheffer 1046 Check Point Software Technologies Ltd. 1047 5 Hasolelim St. 1048 Tel Aviv 67897 1049 Israel 1051 Email: yaronf@checkpoint.com 1053 Glen Zorn 1054 Network Zen 1055 1310 East Thomas Street 1056 #306 1057 Seattle, Washington 98102 1058 USA 1060 Phone: +1 (206) 377-9035 1061 Email: gwz@net-zen.net 1063 Hannes Tschofenig 1064 Nokia Siemens Networks 1065 Linnoitustie 6 1066 Espoo 02600 1067 Finland 1069 Phone: +358 (50) 4871445 1070 Email: Hannes.Tschofenig@gmx.net 1071 URI: http://www.tschofenig.priv.at 1073 Scott Fluhrer 1074 Cisco Systems. 1075 1414 Massachusetts Ave. 1076 Boxborough, MA 01719 1077 USA 1079 Email: sfluhrer@cisco.com