idnits 2.17.1 draft-sheffer-emu-eap-eke-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 : ---------------------------------------------------------------------------- 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 (January 29, 2009) is 5559 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 841, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 900, 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 (~~), 4 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 2, 2009 Network Zen 6 H. Tschofenig 7 Nokia Siemens Networks 8 January 29, 2009 10 An EAP Authentication Method Based on the EKE Protocol 11 draft-sheffer-emu-eap-eke-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 2, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 The Extensible Authentication Protocol (EAP) describes a framework 51 that allows the use of multiple authentication mechanisms. This 52 document defines an authentication mechanism for EAP called EAP-EKE, 53 based on the Encrypted Key Exchange (EKE) protocol. This method 54 provides mutual authentication through the use of a short, easy to 55 remember password. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 6 67 4.3. EAP-EKE-ID . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.4. EAP-EKE-Commit . . . . . . . . . . . . . . . . . . . . . . 8 69 4.5. EAP-EKE-Confirm . . . . . . . . . . . . . . . . . . . . . 9 70 4.6. EAP-EKE-Failure and EAP-EKE-Protected-Failure . . . . . . 9 71 5. Cryptographic Operations . . . . . . . . . . . . . . . . . . . 11 72 5.1. Generating Keying Material . . . . . . . . . . . . . . . . 11 73 5.2. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 12 74 5.3. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 12 75 5.4. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 13 76 5.5. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 14 77 5.6. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.7. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 14 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 85 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 86 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 Appendix B. Design Options . . . . . . . . . . . . . . . . . . . 21 88 B.1. Number of Round Trips . . . . . . . . . . . . . . . . . . 21 89 B.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 The predominant access method for the Internet today is that of a 95 human using a username and password to authenticate to a computer 96 enforcing access control. Proof of knowledge of the password 97 authenticates the human to the computer. 99 Typically, these passwords are not stored on a user's computer for 100 security reasons and must be entered each time the human desires 101 network access. Therefore, the passwords must be ones that can be 102 repeatedly entered by a human with a low probability of error. They 103 will likely not possess high entropy and it may be assumed that an 104 adversary with access to a dictionary will have the ability to guess 105 a user's password. It is therefore desirable to have a robust 106 authentication method that is secure even when used with a weak 107 password in the presence of a strong adversary. 109 EAP-EKE is an EAP method [RFC3748] that addresses the problem of 110 password-based authenticated key exchange, using a possibly weak 111 password for authentication and to derive an authenticated and 112 cryptographically strong shared secret. This problem was first 113 described by Bellovin and Merritt in [BM92] and [BM93]. 114 Subsequently, a number of other solution approaches have been 115 proposed, for example [JAB96], [LUC97], [BMP00], and others. 117 This proposal is based on the original Encrypted Key Exchange (EKE) 118 proposal, as described in [BM92]. None of the subsequent 119 improvements have been incorporated. However, we have used only the 120 subset of [BM92] (namely the variant described in Section 3.1) which 121 has withstood the test of time and is believed secure as of this 122 writing. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Protocol 132 3.1. Protocol Overview 134 EAP is a two-party protocol spoken between an EAP peer and an EAP 135 server (also known as "authenticator"). An EAP method defines the 136 specific authentication protocol being used by EAP. This memo 137 defines a particular method and therefore defines the messages sent 138 between the EAP server and the EAP peer for the purpose of 139 authentication and key derivation. 141 3.2. Message Flows 143 EAP-EKE defines three message exchanges: an Identity exchange, a 144 Commit exchange and a Confirm exchange. A successful authentication 145 is shown in Figure 1. 147 The peer and server use the EAP-EKE Identity exchange to learn each 148 other's identities and to agree upon a ciphersuite to use in the 149 subsequent exchanges. In the Commit exchange the peer and server 150 exchange information to generate a shared key and also to bind each 151 other to a particular guess of the password. In the Confirm exchange 152 the peer and server prove liveness and knowledge of the password by 153 generating and verifying verification data. 155 +--------+ +--------+ 156 | | EAP-EKE-ID/Request | | 157 | EAP |<------------------------------------| EAP | 158 | peer | | server | 159 | (P) | EAP-EKE-ID/Response | (S) | 160 | |------------------------------------>| | 161 | | | | 162 | | EAP-EKE-Commit/Request | | 163 | |<------------------------------------| | 164 | | | | 165 | | EAP-EKE-Commit/Response | | 166 | |------------------------------------>| | 167 | | | | 168 | | EAP-EKE-Confirm/Request | | 169 | |<------------------------------------| | 170 | | | | 171 | | EAP-EKE-Confirm/Response | | 172 | |------------------------------------>| | 173 | | | | 174 | | EAP-Success | | 175 | |<------------------------------------| | 176 +--------+ +--------+ 178 Figure 1: A Successful EAP-EKE Exchange 180 Schematically, the original exchange as described in [BM92] (and with 181 the roles reversed) is: 183 Server Peer 184 ------ ---- 185 E(Password, Y_S)) -> 186 <- E(Password, Y_P), E(SharedSecret, Nonce_P) 187 E(SharedSecret, Nonce_S | Nonce_P) -> 188 <- E(SharedSecret, Nonce_S) 190 The current protocol extends the basic cryptographic protocol, and 191 the regular successful exchange becomes: 193 EAP-EKE-ID/Request: S -> P 195 ID_S, CryptoProposals 197 EAP-EKE-ID/Response: S <- P 199 ID_P, CryptoSelection 201 EAP-EKE-Commit/Request: S -> P 203 E(Password, Y_S)) 205 EAP-EKE-Commit/Response: S <- P 207 E(Password, Y_P), E(SharedSecret, Nonce_P) 209 EAP-EKE-Confirm/Request: S -> P 211 E(SharedSecret, Nonce_S | Nonce_P), Auth_S 213 EAP-EKE-Confirm/Response: S <- P 215 E(SharedSecret, Nonce_S), Auth_P 217 As shown in the exchange above, the following information elements 218 are added to the original protocol: identity values for both protocol 219 parties, negotiation of cryptographic protocols, and signature fields 220 to protect the integrity of the negotiated parameters. 222 4. Packet Formats 223 4.1. EAP-EKE Header 225 The EAP-EKE header consists of the standard EAP header (see Section 4 226 of [RFC3748]), followed an EAP-EKE exchange type. The header has the 227 following structure: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Code | Identifier | Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Type | EKE-Exch | Data ... 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2: EAP-EKE Header 239 The Code, Identifier, Length, and Type fields are all part of the EAP 240 header, and defined in [RFC3748]. The Type field in the EAP header 241 MUST be the value allocated by IANA for EAP-EKE version 1. 243 The EKE-Exch field identifies the type of EAP-EKE payload 244 encapsulated in the Data field. This document defines the following 245 values for the EKE-Exch field: 246 o 0x00: Reserved 247 o 0x01: EAP-EKE-ID exchange 248 o 0x02: EAP-EKE-Commit exchange 249 o 0x03: EAP-EKE-Confirm exchange 250 o 0x04: EAP-EKE-Failure exchange 251 o 0x05: EAP-EKE-Protected-Failure exchange 253 Further values of this EKE-Exch field are available via IANA 254 registration. 256 4.2. EAP-EKE Payloads 258 EAP-EKE payloads all contain the EAP-EKE header and encoded 259 information, which differs for the different exchanges. 261 4.3. EAP-EKE-ID 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | ProposalNr | Reserved | Proposal ... 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 ... Proposal | IDType | Identity ... 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3: EAP-EKE-ID Payload 272 The EAP-EKE-ID payload contains the following fields: 274 ProposalsNr: 276 The ProposalNr field contains the number of proposals subsequently 277 contained in the Proposal field. In the EAP-EKE-ID/Request the 278 ProposalNr field MUST NOT be set to zero (0) and in the EAP-EKE- 279 ID/Response message the ProposalNr field MUST be set to one (1). 280 The offered proposals in the Request are listed contiguously in 281 priority order, most preferable first. The selected proposal in 282 the Response MUST be fully identical with one of the offered 283 proposals. 285 Proposal: 287 Each proposal consists of four one-octet fields, in this order: 289 Group Description: 291 This field's value is taken from the IANA registry for Diffie- 292 Hellman groups defined in Section 6.4. 294 Encryption: 296 This field's value is taken from the IANA registry for 297 encryption algorithms defined in Section 6.1. 299 PRF: 301 This field's value is taken from the IANA registry for pseudo 302 random functions defined in Section 6.2. 304 MAC: 306 This field's value is taken from the IANA registry for keyed 307 message digest algorithms defined in Section 6.3 used to 308 provide integrity protection. 310 IDType 312 Denotes the Identity type. This is taken from the IANA registry 313 defined in Section 6. The server and the peer MAY use different 314 identity types. 316 The Identity field is always printable, and its meaning depends on 317 the values of the Code and IDType fields. 319 o EAP-EKE-ID/Request: server ID 320 o EAP-EKE-ID/Response: peer ID 322 The server SHOULD assert its own identity (e.g. its host name), or it 323 MAY use the peer's identity if it knows it before the protocol 324 starts. 326 The length of the Identity is computed from the Length field in the 327 EAP header. 329 4.4. EAP-EKE-Commit 331 In this exchange both parties send their encrypted ephemeral public 332 key, and the peer also includes a Challenge. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | DHComponent ~ 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 ~ ~ 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Commit_P ~ 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 ~ ~ 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 4: EAP-EKE-Commit Payload 348 DHComponent: 350 This field contains the password-encrypted Diffie-Hellman public 351 key, see Section 5.2. 353 Commit_P: 355 This field only appears in the response, and contains the 356 encrypted challenge value sent by the peer. See Section 5.3. 358 4.5. EAP-EKE-Confirm 360 In this exchange both parties complete the authentication by 361 generating a shared temporary key, authenticating the entire 362 protocol, and generating key material for the EAP consumer protocol. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Confirm_? ~ 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 ~ ~ 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Auth_? ~ 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 ~ ~ 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 5: EAP-EKE-Confirm Payload 378 Confirm_?: 380 This field contains the encrypted response to the other peer's 381 challenge, see Section 5.4 and Section 5.5. 383 Auth_? 385 This field signs the Identity and the negotiated fields, to 386 prevent downgrade attacks. See Section 5.4 and Section 5.5. 388 4.6. EAP-EKE-Failure and EAP-EKE-Protected-Failure 390 The EAP-EKE-Failure message format is defined as follows: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Failure-Code | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 EAP-EKE-Failure Payload 400 The EAP-EKE-Protected-Failure payload format is defined as follows: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Failure-Code | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | | 408 ... MAC ... 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 EAP-EKE-Protected-Failure Payload 414 The MAC field contains the keyed message digest computed with the MAC 415 algorithm selected during the initial exchange computed over the 416 Failure-Code using the MAC key (see Section 5 on how this key is 417 derived). A protected failure response can only be returned once the 418 MAC key has been derived. 420 Currently the following Failure-Code values are defined: 421 o 0x00000000: Reserved 422 o 0x00000001: No Error 423 o 0x00000002: Protocol Error 424 o 0x00000003: Password Not Found 425 o 0x00000004: Authentication Failure 426 o 0x00000005: Authorization Failure 427 o 0x00000006: No Proposal Chosen 429 Additional values of this field are available via IANA registration. 431 "No Error" is used for failure acknowledgement, see below. "Protocol 432 Error" indicates a failure to parse or understand a protocol message 433 or one of its payloads. "Password Not Found" indicates a password 434 for a particular user could not be located, making authentication 435 impossible. "Authentication Failure" indicates failure in the 436 cryptographic computation most likely caused by an incorrect 437 password, or an inappropriate identity type. "Authorization Failure" 438 indicates that while the password being used is correct, the user is 439 not authorized to connect. "No Proposal Chosen" indicates that the 440 peer is unwilling to select any of the cryptographic proposals 441 offered by the server. 443 When the peer encounters an error situation, it MUST respond with 444 either EAP-EKE-Failure or EAP-EKE-Protected-Failure, depending on 445 whether it believes a common MAC key has been agreed upon. The 446 server MUST send an EAP-Failure message to end the exchange. 448 When the server encounters an error situation, it MUST respond with 449 either EAP-EKE-Failure or EAP-EKE-Protected-Failure, depending on 450 whether it believes a common MAC key has been agreed upon. The peer 451 MUST send back either EAP-EKE-Failure or EAP-EKE-Protected-Failure 452 (corresponding to the server's selection), containing a "No Error" 453 failure code. Then the server MUST send an EAP-Failure message to 454 end the exchange. 456 5. Cryptographic Operations 458 5.1. Generating Keying Material 460 Keying material will always be derived as the output of the 461 negotiated prf algorithm. Since the amount of keying material needed 462 may be greater than the size of the output of the prf algorithm, we 463 will use the prf iteratively. We will use the terminology prf+ to 464 describe the function that outputs a pseudo-random stream based on 465 the inputs to a prf as follows: (where | indicates concatenation) 467 prf+ (K,S) = T1 | T2 | T3 | T4 | ... 469 where: 470 T1 = prf (K, S | 0x01) 471 T2 = prf (K, T1 | S | 0x02) 472 T3 = prf (K, T2 | S | 0x03) 473 T4 = prf (K, T3 | S | 0x04) 475 continuing as needed to compute all required keys. The keys are 476 taken from the output string without regard to boundaries (e.g., if 477 the required keys are a 256-bit Advanced Encryption Standard (AES) 478 key and a 160-bit HMAC key, and the prf function generates 160 bits, 479 the AES key will come from T1 and the beginning of T2, while the HMAC 480 key will come from the rest of T2 and the beginning of T3). 482 The constant concatenated to the end of each string feeding the prf 483 is a single octet. prf+ in this document is not defined beyond 255 484 times the size of the prf output. 486 5.2. EAP-EKE-Commit/Request 488 The server computes 490 DHValue_S = g^x mod N, 492 where 'x' is a randomly chosen number in the range 2 .. N-1. The 493 randomly chosen number is the private key, and the calculated field 494 is the corresponding public key. The calculated value MUST NOT be 495 zero modulo N. If the peer receives a bad value for this field, it 496 MUST take action to disconnect or disable the link. Each of the 497 peers MUST use a fresh, random value for this field on each run of 498 the protocol. 500 The server transmits 502 DHComponent_S = E(prf+(password, "EAP-EKE Password"), DHValue_S), 504 encrypted using the algorithm negotiated during the previous 505 exchange. If required by the encryption algorithm/mode, the 506 encrypted field is preceded by an Initialization Vector (IV), whose 507 length depends on the algorithm. 509 In many cases (e.g. CBC mode) it may be necessary to pad DHValue_S 510 on the right, to fit the encryption algorithm's block size. In such 511 cases, random padding MUST be used, and this randomness is critical 512 to the security of the protocol. Randomness recommendations can be 513 found in [RFC4086]. When decrypting this field, the real length of 514 DHValue_S is determined according to the negotiated Diffie Hellman 515 group. 517 If the password needs to be stored on the server, it is RECOMMENDED 518 to store the randomized password value, i.e. prf+(password, ...), as 519 a password-equivalent, rather than the cleartext password. 521 5.3. EAP-EKE-Commit/Response 523 The peer computes 525 DHValue_P = g^y mod N 527 and sends 529 DHComponent_P = E(prf+(password, "EAP-EKE Password"), DHValue_P) 531 If the password is non-ASCII, it SHOULD be normalized by the peer 532 before the EAP-EKE message is constructed. The normalization method 533 is SASLprep, [RFC4013]. Note that the password is not null- 534 terminated. 536 Both sides calculate 538 DHShared = g^(x*y) mod N 540 The encryption key is computed: 542 Ke = prf+(DHShared, "EAP-EKE Ke" | ID_S | ID_P) 544 The MAC key is computed: 546 MAC = prf+(DHShared, "EAP-EKE MAC" | ID_S | ID_P) 548 And the peer generates 550 Challenge_P = E(Ke, Nonce_P), 552 where Nonce_P is a randomly generated binary string. Nonce_P has 553 length equal to the block size of E for block ciphers, or 32 octets 554 if E is a stream cipher. 556 5.4. EAP-EKE-Confirm/Request 558 The server sends: 560 Commit_S = E(Ke, Nonce_P | Nonce_S), 562 where Nonce_S is a randomly generated string, similar to Nonce_P. 564 It computes: 566 Ka = prf+(DHShared, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | 567 Nonce_S) 569 And sends: 571 Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE- 572 ID/Response | EAP-EKE-Commit_S | EAP-EKE-Commit_P), 574 where the literal string is encoded using ASCII with no zero 575 terminator. The messages are included in full, starting with the EAP 576 header, and including any possible future extensions. 578 5.5. EAP-EKE-Confirm/Response 580 The peer computes Ka, and sends: 582 Commit_P = E(Ke, Nonce_S) 583 Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/ 584 Response | EAP-EKE-Commit_S | EAP-EKE-Commit_P) 586 5.6. MSK and EMSK 588 Following the last message of the protocol, both sides compute and 589 export the shared keys, each 512 bits in length: 591 MSK = prf+(DHShared, "EAP-EKE MSK" | ID_S | ID_P | Nonce_P | 592 Nonce_S) 593 EMSK = prf+(DHShared, "EAP-EKE EMSK" | ID_S | ID_P | Nonce_P | 594 Nonce_S) 596 5.7. Mandatory Algorithms 598 To facilitate interoperability, the following algorithms are 599 mandatory to implement: 601 o ENCR_AES128_CBC (encryption algorithm) 602 o PRF_HMAC_SHA1 (pseudo random function and keyed message digest) 603 o DHGROUP_14 (DH-group) 605 6. IANA Considerations 607 This document allocates an EAP method type, for "EAP-EKE Version 1". 609 This document requires IANA to create the registries described in the 610 subsequent sections. Values can be added or modified in these 611 registries per Specification Required [RFC5226]. 613 6.1. Encryption Algorithm Registry 615 This section defines an IANA registry for encryption algorithms: 617 +-----------------+---------+----------------------------------+ 618 | Name | Value | Definition | 619 +-----------------+---------+----------------------------------+ 620 | Reserved | 0 | | 621 | ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode | 622 | | 2-127 | Available for allocation via IANA| 623 | | 128-255 | Reserved for private use | 624 +-----------------+---------+----------------------------------+ 626 6.2. Pseudo Random Function Registry 628 This section defines an IANA registry for pseudo random function 629 algorithms: 631 +---------------+---------+-------------------------------------+ 632 | Name | Value | Definition | 633 +---------------+---------+-------------------------------------+ 634 | Reserved | 0 | | 635 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 636 | | 2-127 | Available for allocation via IANA | 637 | | 128-255 | Reserved for private use | 638 +---------------+---------+-------------------------------------+ 640 6.3. Keyed Message Digest Registry 642 This section defines an IANA registry for keyed message digest 643 algorithms: 645 +---------------+---------+-------------------------------------+ 646 | Name | Value | Definition | 647 +---------------+---------+-------------------------------------+ 648 | Reserved | 0 | | 649 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 650 | | 2-127 | Available for allocation via IANA | 651 | | 128-255 | Reserved for private use | 652 +---------------+---------+-------------------------------------+ 654 6.4. Diffie-Hellman Group Registry 656 This section defines an IANA registry for Diffie-Hellman groups: 658 +------------+---------+--------------------------------------------+ 659 | Name | Value | Definition | 660 +------------+---------+--------------------------------------------+ 661 | Reserved | 0 | | 662 | DHGROUP_14 | 1 | 2048-bit MODP Group (#14), as defined in | 663 | | | [RFC3526] | 664 | | 2-127 | Available for allocation via IANA | 665 | | 128-255 | Reserved for private use | 666 +------------+---------+--------------------------------------------+ 668 6.5. Identity Type Registry 670 In addition, an identity type registry is defined: 672 +-----------+---------+---------------------------------------------+ 673 | Name | Value | Definition | 674 +-----------+---------+---------------------------------------------+ 675 | Reserved | 0 | | 676 | ID_OPAQUE | 1 | A printable string whose format is | 677 | | | undefined | 678 | ID_NAI | 2 | A Network Access Identifier, as defined in | 679 | | | [RFC4282] (mandatory to implement) | 680 | ID_IPv4 | 3 | An IPv4 address, in binary format | 681 | ID_IPv6 | 4 | An IPv6 address, in binary format | 682 | ID_FQDN | 5 | A fully qualified domain name (mandatory to | 683 | | | implement) | 684 | | 6-127 | Available for allocation via IANA | 685 | | 128-255 | Reserved for private use | 686 +-----------+---------+---------------------------------------------+ 688 6.6. Failure-Code Registry 690 This section defines an IANA registry for the Failure-Code registry, 691 a 32-bit long code. Initial values are defined in Section 4.6. All 692 values up to 0xff000000 are available for allocation via IANA. The 693 remaining values up to 0xffffffff are available for private use. 695 7. Security Considerations 697 Any protocol that claims to solve the problem of password- 698 authenticated key exchange must be resistant to active, passive and 699 dictionary attack and have the quality of forward secrecy. These 700 characteristics are discussed further in the following paragraphs. 702 Resistance to Passive Attack A passive attacker is one that merely 703 relays messages back and forth between the peer and server, 704 faithfully, and without modification. The contents of the 705 messages are available for inspection, but that is all. To 706 achieve resistance to passive attack, such an attacker must not be 707 able to obtain any information about the password or anything 708 about the resulting shared secret from watching repeated runs of 709 the protocol. Even if a passive attacker is able to learn the 710 password, she will not be able to determine any information about 711 the resulting secret shared by the peer and server. 712 Resistance to Active Attack An active attacker is able to modify, 713 add, delete, and replay messages sent between protocol 714 participants. For this protocol to be resistant to active attack, 715 the attacker must not be able to obtain any information about the 716 password or the shared secret by using any of its capabilities. 717 In addition, the attacker must not be able to fool a protocol 718 participant into thinking that the protocol completed 719 successfully. It is always possible for an active attacker to 720 deny delivery of a message critical in completing the exchange. 721 This is no different than dropping all messages and is not an 722 attack against the protocol. 723 Resistance to Dictionary Attack For this protocol to be resistant to 724 dictionary attack any advantage an adversary can gain must be 725 directly related to the number of interactions she makes with an 726 honest protocol participant and not through computation. The 727 adversary will not be able to obtain any information about the 728 password except whether a single guess from a single protocol run 729 is correct or incorrect. 730 Forward Secrecy Compromise of the password must not provide any 731 information about the secrets generated by earlier runs of the 732 protocol. 734 [RFC3748] requires that documents describing new EAP methods clearly 735 articulate the security properties of the method. In addition, for 736 use with wireless LANs, [RFC4017] mandates and recommends several of 737 these. The claims are: 738 1. Mechanism: password. 739 2. Claims: 740 * Mutual authentication: the peer and server both authenticate 741 each other by proving possession of a shared password. This 742 is REQUIRED by [RFC4017]. 743 * Forward secrecy: compromise of the password does not reveal 744 the secret keys (MSK and EMSK) from earlier runs of the 745 protocol. 746 * Replay protection: an attacker is unable to replay messages 747 from a previous exchange either to learn the password or a key 748 derived by the exchange. Similarly the attacker is unable to 749 induce either the peer or server to believe the exchange has 750 successfully completed when it hasn't. 751 * Key derivation: a shared secret is derived by performing a 752 group operation in a finite cyclic group (e.g. exponentiation) 753 using secret data contributed by both the peer and server. An 754 MSK and EMSK are derived from that shared secret. This is 755 REQUIRED by [RFC4017]. 757 * Dictionary attack resistance: an attacker can only make one 758 password guess per active attack. The advantage she can gain 759 is through interaction not through computation. This is 760 REQUIRED by [RFC4017]. 761 * Session independence: this protocol is resistant to active and 762 passive attacks and does not enable compromise of subsequent 763 or prior MSKs or EMSKs from either passive or active attacks. 764 * Denial of Service resistance: it is possible for an attacker 765 to cause a server to allocate state and consume CPU. Such an 766 attack is gated, though, by the requirement that the attacker 767 first obtain connectivity through a lower-layer protocol (e.g. 768 802.11 authentication followed by 802.11 association, or 802.3 769 "link-up") and respond to two EAP messages--the EAP-ID/ 770 Request and the EAP-EKE-ID/Request. 771 * Man-in-the-Middle Attack resistance: this exchange is 772 resistant to active attack, which is a requirement for 773 launching a man-in-the-middle attack. This is REQUIRED by 774 [RFC4017]. 775 * Shared state equivalence: upon completion of EAP-EKE the peer 776 and server both agree on MSK, EMSK. The peer has 777 authenticated the server based on the Server_ID and the server 778 has authenticated the peer based on the Peer_ID. This is due 779 to the fact that Peer_ID, Server_ID, and the generated shared 780 secret are all combined to make the authentication element 781 which must be shared between the peer and server for the 782 exchange to complete. This is REQUIRED by [RFC4017]. 783 * Fragmentation: this protocol does not define a technique for 784 fragmentation and reassembly. 785 * Resistance to "Denning-Sacco" attack: learning keys 786 distributed from an earlier run of the protocol, such as the 787 MSK or EMSK, will not help an adversary learn the password. 788 3. Key strength: the strength of the resulting key depends on the 789 finite cyclic group chosen. For example, [RFC5114] defines new 790 groups available for use with this protocol. Using groups from 791 [RFC5114] the strength can vary from 80 bits (for the 1024-bit 792 MODP with 160-bit Prime Subgroup) to 256 bits (for the 521-bit 793 Random ECP Group). Other groups can be defined and the strength 794 of those groups depends on their definition. This is REQUIRED by 795 [RFC4017]. 796 4. Key hierarchy: MSKs and EMSKs are derived from the secret values 797 generated during the protocol run, using a negotiated pseudo- 798 random function. 799 5. Vulnerabilities (note that none of these are REQUIRED by 800 [RFC4017]): 801 * Protected ciphersuite negotiation: the ciphersuite proposal 802 made by the server is not protected from tampering by an 803 active attacker. However if a proposal was modified by an 804 active attacker it would result in a failure to confirm the 805 message sent by the other party, since the proposal is bound 806 by each side into its Confirm message, and the protocol would 807 fail as a result. 808 * Confidentiality: none of the messages sent in this protocol 809 are encrypted. 810 * Integrity protection: all messages in this protocol are 811 integrity protected. 812 * Channel binding: this protocol does not enable the exchange of 813 integrity-protected channel information that can be compared 814 with values communicated via out-of-band mechanisms. 815 * Fast reconnect: this protocol does not provide a fast 816 reconnect capability. 817 * Cryptographic binding: this protocol is not a tunneled EAP 818 method and therefore has no cryptographic information to bind. 819 * Identity protection: the EAP-EKE-ID exchange is not protected. 820 An attacker will see the server's identity in the EAP-EKE-ID/ 821 Request and see the peer's identity in EAP-EKE-ID/ Response. 823 8. Acknowledgements 825 Much of this document was unashamedly picked from 826 [I-D.harkins-emu-eap-pwd] and [I-D.ietf-pppext-eap-srp-03], and we 827 would like to acknowledge the authors of these documents: Dan 828 Harkins, Glen Zorn, James Carlson, Bernard Aboba and Henry Haverinen. 830 9. References 832 9.1. Normative References 834 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 835 Hashing for Message Authentication", RFC 2104, 836 February 1997. 838 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 839 Requirement Levels", BCP 14, RFC 2119, March 1997. 841 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 842 Authentication Protocol (EAP)", RFC 2284, March 1998. 844 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 845 Diffie-Hellman groups for Internet Key Exchange (IKE)", 846 RFC 3526, May 2003. 848 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 849 Levkowetz, "Extensible Authentication Protocol (EAP)", 850 RFC 3748, June 2004. 852 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 853 and Passwords", RFC 4013, February 2005. 855 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 856 Network Access Identifier", RFC 4282, December 2005. 858 9.2. Informative References 860 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 861 Password-Based Protocols Secure Against Dictionary 862 Attacks", Proc. IEEE Symp. on Research in Security and 863 Privacy , May 1992. 865 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 866 Exchange: A Password-Based Protocol Secure against 867 Dictionary Attacks and Password File Compromise", Proc. 868 1st ACM Conference on Computer and Communication 869 Security , 1993. 871 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 872 Password Authenticated Key Exchange Using Diffie-Hellman", 873 Advances in Cryptology aEUR" EUROCRYPT 2000 , 2000. 875 [I-D.harkins-emu-eap-pwd] 876 Harkins, D. and G. Zorn, "EAP Authentication Using Only A 877 Password", draft-harkins-emu-eap-pwd-03 (work in 878 progress), November 2008. 880 [I-D.ietf-pppext-eap-srp-03] 881 Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 882 Authentication Protocol", draft-ietf-pppext-eap-srp-03 883 (work in progress), July 2001. 885 [JAB96] Jablon, D., "Strong Password-Only Authenticated Key 886 Exchange", ACM Computer Communications Review Volume 1, 887 Issue 5, October 1996. 889 [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary 890 Attacks Without Encrypting Public Keys", Proc. of the 891 Security Protocols Workshop LNCS 1361, 1997. 893 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 894 Authentication Protocol (EAP) Method Requirements for 895 Wireless LANs", RFC 4017, March 2005. 897 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 898 Requirements for Security", BCP 106, RFC 4086, June 2005. 900 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 901 RFC 4306, December 2005. 903 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 904 Groups for Use with IETF Standards", RFC 5114, 905 January 2008. 907 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 908 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 909 May 2008. 911 Appendix A. Change Log 913 A.1. -00 915 Initial version. 917 Appendix B. Design Options 919 B.1. Number of Round Trips 921 We have looked at three options: 2 round trips, 3 round trips, and a 922 normal run of 2 round trips with an optional third. Some of the 923 decision factors include: 925 o Performance (latency). 926 o Crypto-agility, the ability to negotiate cryptographic algorithms. 927 Ideally this applies to both the symmetric and asymmetric 928 algorithms. 929 o Complexity of the protocol state machine, when some messages are 930 optional. 931 o Dependence on a higher-level protocol sending the peer's identity 932 before EAP-EKE starts, so that the correct password can be used. 934 The initial version of this protocol has 3 round trips, primarily for 935 simplicity. 937 B.2. Fragmentation 939 While similar documents ( [I-D.harkins-emu-eap-pwd]) provide 940 fragmentation support at the level of the EAP method, we have decided 941 that such support is unnecessary given the expected size of messages 942 in EAP-EKE. 944 Authors' Addresses 946 Yaron Sheffer 947 Check Point Software Technologies Ltd. 948 5 Hasolelim St. 949 Tel Aviv 67897 950 Israel 952 Email: yaronf@checkpoint.com 954 Glen Zorn 955 Network Zen 956 1310 East Thomas Street 957 #306 958 Seattle, Washington 98102 959 USA 961 Phone: +1 (206) 377-9035 962 Email: gwz@net-zen.net 964 Hannes Tschofenig 965 Nokia Siemens Networks 966 Linnoitustie 6 967 Espoo 02600 968 Finland 970 Phone: +358 (50) 4871445 971 Email: Hannes.Tschofenig@gmx.net 972 URI: http://www.tschofenig.priv.at