idnits 2.17.1 draft-sheffer-emu-eap-eke-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 6, 2010) is 5221 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: Informational ---------------------------------------------------------------------------- ** 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-12 == Outdated reference: A later version (-01) exists of draft-krawczyk-hkdf-00 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: Informational G. Zorn 5 Expires: July 10, 2010 Network Zen 6 H. Tschofenig 7 Nokia Siemens Networks 8 S. Fluhrer 9 Cisco 10 January 6, 2010 12 An EAP Authentication Method Based on the EKE Protocol 13 draft-sheffer-emu-eap-eke-04 15 Abstract 17 The Extensible Authentication Protocol (EAP) describes a framework 18 that allows the use of multiple authentication mechanisms. This 19 document defines an authentication mechanism for EAP called EAP-EKE, 20 based on the Encrypted Key Exchange (EKE) protocol. This method 21 provides mutual authentication through the use of a short, easy to 22 remember password. Compared with other common authentication 23 methods, EAP-EKE is not susceptible to dictionary attacks. Neither 24 does it require the availability of public-key certificates. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on July 10, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 8 74 4.3. EAP-EKE-ID . . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.4. EAP-EKE-Commit . . . . . . . . . . . . . . . . . . . . . . 10 76 4.5. EAP-EKE-Confirm . . . . . . . . . . . . . . . . . . . . . 11 77 4.6. EAP-EKE-Failure . . . . . . . . . . . . . . . . . . . . . 11 78 4.7. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13 79 4.8. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 13 80 4.9. Channel Binding Values . . . . . . . . . . . . . . . . . . 14 81 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 15 82 5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 15 83 5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 15 84 5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 16 85 5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 17 86 5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 17 87 6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 17 88 6.1. Generating Keying Material . . . . . . . . . . . . . . . . 17 89 6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 18 90 6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 19 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 24 94 8.2. Diffie Hellman Group Considerations . . . . . . . . . . . 24 95 8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 25 96 8.4. Identity Protection, Anonymity and Pseudonymity . . . . . 25 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 101 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 102 A.1. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 103 A.2. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 A.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 A.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 109 1. Introduction 111 The predominant access method for the Internet today is that of a 112 human using a username and password to authenticate to a computer 113 enforcing access control. Proof of knowledge of the password 114 authenticates the human to the computer. 116 Typically, these passwords are not stored on a user's computer for 117 security reasons and must be entered each time the human desires 118 network access. Therefore, the passwords must be ones that can be 119 repeatedly entered by a human with a low probability of error. They 120 will likely not possess high entropy and it may be assumed that an 121 adversary with access to a dictionary will have the ability to guess 122 a user's password. It is therefore desirable to have a robust 123 authentication method that is secure even when used with a weak 124 password in the presence of a strong adversary. 126 EAP-EKE is an EAP method [RFC3748] that addresses the problem of 127 password-based authenticated key exchange, using a possibly weak 128 password for authentication and to derive an authenticated and 129 cryptographically strong shared secret. This problem was first 130 described by Bellovin and Merritt in [BM92] and [BM93]. 131 Subsequently, a number of other solution approaches have been 132 proposed, for example [JAB96], [LUC97], [BMP00], and others. 134 This proposal is based on the original Encrypted Key Exchange (EKE) 135 proposal, as described in [BM92]. Some of the variants of the 136 original EKE have been attacked, see e.g. [PA97], and improvements 137 have been proposed. None of these subsequent improvements have been 138 incorporated into the current protocol. However, we have used only 139 the subset of [BM92] (namely the variant described in Section 3.1 of 140 the paper) which has withstood the test of time and is believed 141 secure as of this writing. 143 2. Terminology 145 This document uses Encr(Ke, ...) to denote encrypted information, and 146 Prot(Ke, Ki, ...) to denote encrypted and integrity protected 147 information. 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 3. Protocol 155 3.1. Protocol Overview 157 EAP is a two-party protocol spoken between an EAP peer and an EAP 158 server (also known as "authenticator"). An EAP method defines the 159 specific authentication protocol being used by EAP. This memo 160 defines a particular method and therefore defines the messages sent 161 between the EAP server and the EAP peer for the purpose of 162 authentication and key derivation. 164 3.2. Message Flows 166 EAP-EKE defines three message exchanges: an Identity exchange, a 167 Commit exchange and a Confirm exchange. A successful authentication 168 is shown in Figure 1. 170 The peer and server use the EAP-EKE Identity exchange to learn each 171 other's identities and to agree upon a ciphersuite to use in the 172 subsequent exchanges. In the Commit exchange the peer and server 173 exchange information to generate a shared key and also to bind each 174 other to a particular guess of the password. In the Confirm exchange 175 the peer and server prove liveness and knowledge of the password by 176 generating and verifying verification data. 178 +--------+ +--------+ 179 | | EAP-EKE-ID/Request | | 180 | EAP |<------------------------------------| EAP | 181 | peer | | server | 182 | (P) | EAP-EKE-ID/Response | (S) | 183 | |------------------------------------>| | 184 | | | | 185 | | EAP-EKE-Commit/Request | | 186 | |<------------------------------------| | 187 | | | | 188 | | EAP-EKE-Commit/Response | | 189 | |------------------------------------>| | 190 | | | | 191 | | EAP-EKE-Confirm/Request | | 192 | |<------------------------------------| | 193 | | | | 194 | | EAP-EKE-Confirm/Response | | 195 | |------------------------------------>| | 196 | | | | 197 | | EAP-Success | | 198 | |<------------------------------------| | 199 +--------+ +--------+ 201 Figure 1: A Successful EAP-EKE Exchange 203 Schematically, the original exchange as described in [BM92] (and with 204 the roles reversed) is: 206 Server Peer 207 ------ ---- 209 E(Password, Y_S)) -> 211 <- E(Password, Y_P), E(SharedSecret, Nonce_P) 213 E(SharedSecret, Nonce_S | Nonce_P) -> 215 <- E(SharedSecret, Nonce_S) 217 Where: 218 o Y_S and Y_P are the server's (and respectively, the peer's) 219 ephemeral public key, i.e. g^x (mod p), g^y (mod p). 221 o Nonce_S, Nonce_P are random strings generated by the server and 222 the peer as cryptographic challenges. 223 o SharedSecret is the secret created by the Diffie-Hellman 224 algorithm, namely g^(x*y) (mod p). 225 The current protocol extends the basic cryptographic protocol, and 226 the regular successful exchange becomes: 228 Message Server Peer 229 --------- -------- ------ 230 ID/Request ID_S, CryptoProposals -> 232 ID/Response <- ID_P, CryptoSelection 234 Commit/Request Encr(Password, Y_S)) -> 236 Commit/Response <- Encr(Password, Y_P), Prot(Ke, Ki, Nonce_P) 238 Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S -> 240 Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P 242 As shown in the exchange above, the following information elements 243 have been added to the original protocol: identity values for both 244 protocol parties (ID_S, ID_P), negotiation of cryptographic 245 protocols, and signature fields to protect the integrity of the 246 negotiated parameters (Auth_S, Auth_P). In addition the shared 247 secret is not used directly. Note that a few details have been 248 omitted for clarity. 250 4. Packet Formats 252 4.1. EAP-EKE Header 254 The EAP-EKE header consists of the standard EAP header (see Section 4 255 of [RFC3748]), followed an EAP-EKE exchange type. The header has the 256 following structure: 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Code | Identifier | Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | EKE-Exch | Data ... 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 2: EAP-EKE Header 268 The Code, Identifier, Length, and Type fields are all part of the EAP 269 header, and defined in [RFC3748]. The Type field in the EAP header 270 MUST be the value allocated by IANA for EAP-EKE version 1. 272 The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE 273 payload encapsulated in the Data field. This document defines the 274 following values for the EKE-Exch field: 275 o 0x00: Reserved 276 o 0x01: EAP-EKE-ID exchange 277 o 0x02: EAP-EKE-Commit exchange 278 o 0x03: EAP-EKE-Confirm exchange 279 o 0x04: EAP-EKE-Failure message 281 Further values of this EKE-Exch field are available via IANA 282 registration. 284 4.2. EAP-EKE Payloads 286 EAP-EKE payloads all contain the EAP-EKE header and encoded 287 information, which differs for the different exchanges. 289 4.3. EAP-EKE-ID 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | NumProposals | Reserved | Proposal ... 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 ... Proposal | IDType | Identity ... 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 3: EAP-EKE-ID Payload 301 The EAP-EKE-ID payload contains the following fields: 303 NumProposals: 305 The NumProposals field contains the number of Proposal fields 306 subsequently contained in the payload. In the EAP-EKE-ID/Request 307 the NumProposals field MUST NOT be set to zero (0) and in the EAP- 308 EKE-ID/Response message the NumProposals field MUST be set to one 309 (1). The offered proposals in the Request are listed contiguously 310 in priority order, most preferable first. The selected proposal 311 in the Response MUST be fully identical with one of the offered 312 proposals. 314 Proposal: 316 Each proposal consists of four one-octet fields, in this order: 318 Group Description: 320 This field's value is taken from the IANA registry for Diffie- 321 Hellman groups defined in Section 7.4. 323 Encryption: 325 This field's value is taken from the IANA registry for 326 encryption algorithms defined in Section 7.1. 328 PRF: 330 This field's value is taken from the IANA registry for pseudo 331 random functions defined in Section 7.2. 333 MAC: 335 This field's value is taken from the IANA registry for keyed 336 message digest algorithms defined in Section 7.3. 338 IDType: 340 Denotes the Identity type. This is taken from the IANA registry 341 defined in Section 7.5. The server and the peer MAY use different 342 identity types. 344 Identity: 346 The meaning of the Identity field depends on the values of the 347 Code and IDType fields. It is RECOMMENDED that the Identity field 348 be printable. 350 * EAP-EKE-ID/Request: server ID 351 * EAP-EKE-ID/Response: peer ID 352 The length of the Identity field is computed from the Length field 353 in the EAP header. 355 4.4. EAP-EKE-Commit 357 In this exchange both parties send their encrypted ephemeral public 358 key, and the peer also includes a Challenge. In addition, a small 359 amount of protected data can be included, which may be used for 360 channel binding. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | DHComponent ~ 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 ~ ~ 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Commit_P ~ 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 ~ ~ 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | CBValue* ~ 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 ~ ~ 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 4: EAP-EKE-Commit Payload 380 DHComponent: 382 This field contains the password-encrypted Diffie-Hellman public 383 key, see Section 5.1. 385 Commit_P: 387 This field only appears in the response, and contains the 388 encrypted and integrity-protected challenge value sent by the 389 peer. See Section 5.2. 391 CBValue: 393 This structure MAY be included both in the request and in the 394 response, and MAY be repeated multiple times, once per each value 395 transmitted. See Section 4.9. 397 4.5. EAP-EKE-Confirm 399 In this exchange both parties complete the authentication by 400 generating a shared temporary key, authenticating the entire 401 protocol, and generating key material for the EAP consumer protocol. 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Confirm_? ~ 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 ~ ~ 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Auth_? ~ 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 ~ ~ 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 5: EAP-EKE-Confirm Payload 417 Confirm_S/Confirm_P: 419 This field contains the encrypted and integrity-protected response 420 to the other party's challenge, see Section 5.3 and Section 5.4. 422 Auth_S/Auth_P: 424 This field signs the preceding messages, including the Identity 425 and the negotiated fields. This prevents various possible 426 attacks, such as algorithm downgrade attacks. See Section 5.3 and 427 Section 5.4. 429 4.6. EAP-EKE-Failure 431 The EAP-EKE-Failure message format is defined as follows: 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Failure-Code | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 EAP-EKE-Failure Payload 441 The following Failure-Code values are defined: 443 +------------+----------------+-------------------------------------+ 444 | Value | Name | Meaning | 445 +------------+----------------+-------------------------------------+ 446 | 0x00000000 | Reserved | | 447 | 0x00000001 | No Error | This code is used for failure | 448 | | | acknowledgement, see below. | 449 | 0x00000002 | Protocol Error | A failure to parse or understand a | 450 | | | protocol message or one of its | 451 | | | payloads. | 452 | 0x00000003 | Password Not | The password for a particular user | 453 | | Found | could not be located, making | 454 | | | authentication impossible. For | 455 | | | security reasons, implementations | 456 | | | MAY choose to eliminate this error | 457 | | | code and return "Authentication | 458 | | | Failure" also in this case. | 459 | 0x00000004 | Authentication | Failure in the cryptographic | 460 | | Failure | computation most likely caused by | 461 | | | an incorrect password, or an | 462 | | | inappropriate identity type. | 463 | 0x00000005 | Authorization | While the password being used is | 464 | | Failure | correct, the user is not authorized | 465 | | | to connect. | 466 | 0x00000006 | No Proposal | The peer is unwilling to select any | 467 | | Chosen | of the cryptographic proposals | 468 | | | offered by the server. | 469 +------------+----------------+-------------------------------------+ 471 Additional values of this field are available via IANA registration, 472 Section 7.7. 474 When the peer encounters an error situation, it MUST respond with 475 EAP-EKE-Failure. The server MUST send an EAP-Failure message to end 476 the exchange. 478 When the server encounters an error situation, it MUST respond with 479 EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message 480 containing a "No Error" failure code. Then the server MUST send an 481 EAP-Failure message to end the exchange. 483 4.7. Protected Fields 485 Several fields are encrypted and integrity-protected. They are 486 denoted Prot(...). Their general structure is as follows: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Initialization Vector (IV) (optional) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Encrypted Data ~ 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 ~ ~ 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 ~ | Random Padding | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Integrity Check Value (ICV) | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 6: Protected Field Structure 504 The protected field is a concatenation of four octet strings: 506 o An optional IV, required when the encryption algorithm/mode 507 necessitates it, e.g. for CBC encryption. A randomly chosen value 508 whose length is equal to the block length of the encryption 509 algorithm. The sender SHOULD pick this value pseudo-randomly and 510 independently for each protected field. 511 o The encrypted data. 512 o Random padding of the minimal length (possibly zero) required to 513 complete the length of the encrypted data to the encryption 514 algorithm's block size. This field is encrypted along with the 515 preceding data. 516 o ICV, a cryptographic checksum of the encrypted data, including the 517 padding. The checksum is computed over the encrypted, rather than 518 the plaintext, data. Its length is determined by the integrity 519 algorithm negotiated. 521 4.8. Encrypted Fields 523 Two fields are encrypted but not integrity protected. They are 524 denoted Encr(...). Their format is identical to a protected field 525 (Section 4.7), except that the Integrity Check Value is omitted. 527 4.9. Channel Binding Values 529 This protocol allows higher level protocols that are using it to 530 transmit opaque information between the peer and the server. This 531 information is integrity protected but not encrypted, and may be used 532 to ensure that protocol peers are identical at different protocol 533 layers. EAP-EKE is not aware of the transmitted information. The 534 information MUST NOT be used by the consumer protocol until it is 535 verified in the EAP-EKE-Confirm exchange (specifically, it is signed 536 by the Auth_S, Auth_P payloads). Consequently, it MUST NOT be relied 537 upon in case an error occurs at the EAP-EKE level. 539 Each Channel Binding Value is encoded using a simple TLV structure: 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | CBType | Length | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Value ... 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 7: Channel Binding Value 551 CBType: 553 This is the Channel Binding Value's type. This document defines 554 the value 0x0000 as reserved. Other values are left for IANA 555 allocation, Section 7.8. 557 Length: 559 This field is the total length in octets of the structure, 560 including the CBType and Length fields. 562 This facility should be used with care, since EAP-EKE does not 563 provide for message fragmentation. It SHOULD NOT be used to transmit 564 data other than that required to positively identify the protocol 565 peers. 567 5. Protocol Sequence 569 5.1. EAP-EKE-Commit/Request 571 The server computes 573 Y_S = g^x mod N, 575 where 'x' is a randomly chosen number in the range 2 .. N-1. The 576 randomly chosen number is the private key, and the calculated field 577 is the corresponding public key. Each of the peers MUST use a fresh, 578 random value for this field on each run of the protocol. 580 Note: If Elliptic Curve Diffie-Hellman is used, the corresponding 581 additive group operations are to be understood. 583 The server transmits the encrypted field (Section 4.8) 585 DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), Y_S), 587 where the literal string is encoded using ASCII with no zero 588 terminator. See Section 6.1 for the prf+ notation. When using block 589 ciphers, it may be necessary to pad Y_S on the right, to fit the 590 encryption algorithm's block size. In such cases, random padding 591 MUST be used, and this randomness is critical to the security of the 592 protocol. Randomness recommendations can be found in [RFC4086]. 593 When decrypting this field, the real length of Y_S is determined 594 according to the negotiated Diffie Hellman group. 596 If the password needs to be stored on the server, it is RECOMMENDED 597 to store the randomized password value, i.e. prf+(password, ...), as 598 a password-equivalent, rather than the cleartext password. 600 If the password is non-ASCII, it SHOULD be normalized by the sender 601 before the EAP-EKE message is constructed. The normalization method 602 is SASLprep, [RFC4013]. Note that the password is not null- 603 terminated. 605 5.2. EAP-EKE-Commit/Response 607 The peer computes 609 Y_P = g^y mod N 611 and sends 612 DHComponent_P = Encr(prf+(password, "EAP-EKE Password"), Y_P) 614 formatted as an encrypted field (Section 4.8). 616 Both sides calculate 618 SharedSecret = prf(0+, g^(x*y) mod N) 620 where the first argument to "prf" is a string of zero octets whose 621 length is the output size of the base hash algorithm, e.g. 20 octets 622 for HMAC-SHA1; the result is of the same length. This extra 623 application of the pseudo-random function is the "extraction step" of 624 [I-D.krawczyk-hkdf]. Note that the peer needs to compute the 625 SharedSecret value before sending out its response. 627 The encryption key is computed: 629 Ke = prf+(SharedSecret, "EAP-EKE Ke" | ID_S | ID_P) 631 The integrity protection key is computed: 633 Ki = prf+(SharedSecret, "EAP-EKE Ki" | ID_S | ID_P) 635 And the peer generates 637 Commit_P = Prot(Ke, Ki, Nonce_P), 639 where Nonce_P is a randomly generated binary string. Nonce_P has 640 length equal to the block size of the negotiated encryption algorithm 641 for block ciphers, or 32 octets if this algorithm is a stream cipher. 642 The peer sends this value as a protected field (Section 4.7), 643 encrypted using Ke and signed using Ki with the negotiated MAC 644 algorithm. 646 5.3. EAP-EKE-Confirm/Request 648 The server sends: 650 Confirm_S = Prot(Ke, Ki, Nonce_P | Nonce_S), 652 as a protected field, where Nonce_S is a randomly generated string, 653 similar to Nonce_P. 655 It computes: 657 Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | 658 Nonce_S) 660 And sends: 662 Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE- 663 ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response). 665 The messages are included in full, starting with the EAP header, and 666 including any possible future extensions. 668 5.4. EAP-EKE-Confirm/Response 670 The peer computes Ka, and sends: 672 Confirm_P = Prot(Ke, Ki, Nonce_S) 674 as a protected field, and 676 Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/ 677 Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response) 679 5.5. MSK and EMSK 681 Following the last message of the protocol, both sides compute and 682 export the shared keys, each 512 bits in length: 684 MSK = prf+(SharedSecret, "EAP-EKE MSK" | ID_S | ID_P | Nonce_P | 685 Nonce_S) 686 EMSK = prf+(SharedSecret, "EAP-EKE EMSK" | ID_S | ID_P | Nonce_P | 687 Nonce_S) 689 When the RADIUS attributes specified in [RFC2548] are used to 690 transport keying material, then the first 32 bytes of the MSK 691 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE- 692 SEND-KEY. In this case, only 64 bytes of keying material (the MSK) 693 are used. 695 6. Cryptographic Details 697 6.1. Generating Keying Material 699 Keying material is derived as the output of the negotiated prf 700 algorithm. Since the amount of keying material needed may be greater 701 than the size of the output of the prf algorithm, we will use the prf 702 iteratively. We denote by "prf+" the function that outputs a pseudo- 703 random stream based on the inputs to a prf as follows (where | 704 indicates concatenation): 706 prf+ (K, S) = T1 | T2 | T3 | T4 | ... 708 where: 709 T1 = prf(K, S | 0x01) 710 T2 = prf(K, T1 | S | 0x02) 711 T3 = prf(K, T2 | S | 0x03) 712 T4 = prf(K, T3 | S | 0x04) 714 continuing as needed to compute all required keys. The keys are 715 taken from the output string without regard to boundaries (e.g., if 716 the required keys are a 256-bit Advanced Encryption Standard (AES) 717 key and a 160-bit HMAC key, and the prf function generates 160 bits, 718 the AES key will come from T1 and the beginning of T2, while the HMAC 719 key will come from the rest of T2 and the beginning of T3). 721 The constant concatenated to the end of each string feeding the prf 722 is a single octet. prf+ in this document is not defined beyond 255 723 times the size of the prf output. 725 6.2. Diffie-Hellman Groups 727 Many of the commonly used Diffie Hellman groups are inappropriate for 728 use in EKE. Most of these groups use a generator which is not a 729 primitive element of the group. As a result, an attacker running a 730 dictionary attack would be able to learn at least 1 bit of 731 information for each decrypted password guess. 733 Any MODP Diffie Hellman group defined for use in this protocol MUST 734 have the following properties, to ensure that it does not leak a 735 usable amount of information about the password: 736 1. The generator is a primitive element of the group. 737 2. The most significant 64 bits of the prime number are 1. 738 3. The group's order p is a "safe prime", i.e. (p-1)/2 is also 739 prime. 741 The last requirement is related to the strength of the Diffie Hellman 742 algorithm, rather than the password encryption. It also makes it 743 easy to verify that the generator is primitive. 745 We have defined the following groups: 746 o DHGROUP_EKE_14 is defined as: the prime number of Group 14 747 [RFC3526], with the generator 11 (decimal). 748 o Additional groups may be defined by future versions of this 749 document, or through IANA assignment. 751 6.3. Mandatory Algorithms 753 To facilitate interoperability, the following algorithms are 754 mandatory to implement: 756 o ENCR_AES128_CBC (encryption algorithm) 757 o PRF_HMAC_SHA1 (pseudo random function and keyed message digest) 758 o DHGROUP_EKE_14 (DH-group) 760 7. IANA Considerations 762 IANA has allocated the EAP method type XXX, for "EAP-EKE Version 1". 764 This document requests that IANA create the registries described in 765 the following sub-sections. Values (other than private-use ones) can 766 be added or modified in these registries per Specification Required 767 [RFC5226]. 769 7.1. Encryption Algorithm Registry 771 This section defines an IANA registry for encryption algorithms: 773 +-----------------+---------+----------------------------------+ 774 | Name | Value | Definition | 775 +-----------------+---------+----------------------------------+ 776 | Reserved | 0 | | 777 | ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode | 778 | | 2-127 | Available for allocation via IANA| 779 | | 128-255 | Reserved for private use | 780 +-----------------+---------+----------------------------------+ 782 7.2. Pseudo Random Function Registry 784 This section defines an IANA registry for pseudo random function 785 algorithms: 787 +-----------------+---------+-------------------------------------+ 788 | Name | Value | Definition | 789 +-----------------+---------+-------------------------------------+ 790 | Reserved | 0 | | 791 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 792 | PRF_HMAC_SHA256 | 2 | HMAC SHA-256 | 793 | | 3-127 | Available for allocation via IANA | 794 | | 128-255 | Reserved for private use | 795 +-----------------+---------+-------------------------------------+ 797 A pseudo-random function takes two parameters K and S, and must be 798 defined for all lengths of K including zero. 800 7.3. Keyed Message Digest Registry 802 This section defines an IANA registry for keyed message digest 803 algorithms: 805 +-----------------+---------+-------------------------------------+ 806 | Name | Value | Definition | 807 +-----------------+---------+-------------------------------------+ 808 | Reserved | 0 | | 809 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 810 | PRF_HMAC_SHA256 | 2 | HMAC SHA-256 | 811 | | 3-127 | Available for allocation via IANA | 812 | | 128-255 | Reserved for private use | 813 +-----------------+---------+-------------------------------------+ 815 7.4. Diffie-Hellman Group Registry 817 This section defines an IANA registry for Diffie-Hellman groups: 819 +----------------+---------+-------------------------------------------+ 820 | Name | Value | Definition | 821 +----------------+---------+-------------------------------------------+ 822 | Reserved | 0 | | 823 | DHGROUP_EKE_14 | 1 | 2048-bit MODP Group defined in this | 824 | | | document | 825 | | 2-127 | Available for allocation via IANA | 826 | | 128-255 | Reserved for private use | 827 +----------------+---------+-------------------------------------------+ 829 7.5. Identity Type Registry 831 In addition, an identity type registry is defined: 833 +-----------+---------+---------------------------------------------+ 834 | Name | Value | Definition | 835 +-----------+---------+---------------------------------------------+ 836 | Reserved | 0 | | 837 | ID_OPAQUE | 1 | A printable UTF-8 string whose format is | 838 | | | undefined | 839 | ID_NAI | 2 | A Network Access Identifier, as defined in | 840 | | | [RFC4282] (mandatory to implement) | 841 | ID_IPv4 | 3 | An IPv4 address, in binary format | 842 | ID_IPv6 | 4 | An IPv6 address, in binary format | 843 | ID_FQDN | 5 | A fully qualified domain name (mandatory to | 844 | | | implement) | 845 | | 6-127 | Available for allocation via IANA | 846 | | 128-255 | Reserved for private use | 847 +-----------+---------+---------------------------------------------+ 849 7.6. Exchange Registry 851 This section defines an IANA registry for the EAP-EKE Exchange 852 registry, an 8-bit long code. Initial values are defined in 853 Section 4.1. All values up to 0x80 are available for allocation via 854 IANA. The remaining values up to 0xff are available for private use. 856 7.7. Failure-Code Registry 858 This section defines an IANA registry for the Failure-Code registry, 859 a 32-bit long code. Initial values are defined in Section 4.6. All 860 values up to 0xff000000 are available for allocation via IANA. The 861 remaining values up to 0xffffffff are available for private use. 863 7.8. Channel Binding Type Registry 865 This section defines an IANA registry for the Channel Binding Type 866 registry, a 16-bit long code. The value 0x0000 has been defined as 867 Reserved. All other values up to 0xff00 are available for allocation 868 via IANA. The remaining values up to 0xffff are available for 869 private use. 871 8. Security Considerations 873 Any protocol that claims to solve the problem of password- 874 authenticated key exchange must be resistant to active, passive and 875 dictionary attack and have the quality of forward secrecy. These 876 characteristics are discussed further in the following paragraphs. 878 Resistance to Passive Attack A passive attacker is one that merely 879 relays messages back and forth between the peer and server, 880 faithfully, and without modification. The contents of the 881 messages are available for inspection, but that is all. To 882 achieve resistance to passive attack, such an attacker must not be 883 able to obtain any information about the password or anything 884 about the resulting shared secret from watching repeated runs of 885 the protocol. Even if a passive attacker is able to learn the 886 password, she will not be able to determine any information about 887 the resulting secret shared by the peer and server. 888 Resistance to Active Attack An active attacker is able to modify, 889 add, delete, and replay messages sent between protocol 890 participants. For this protocol to be resistant to active attack, 891 the attacker must not be able to obtain any information about the 892 password or the shared secret by using any of its capabilities. 893 In addition, the attacker must not be able to fool a protocol 894 participant into thinking that the protocol completed 895 successfully. It is always possible for an active attacker to 896 deny delivery of a message critical in completing the exchange. 897 This is no different than dropping all messages and is not an 898 attack against the protocol. 899 Resistance to Dictionary Attack For this protocol to be resistant to 900 dictionary attack any advantage an adversary can gain must be 901 directly related to the number of interactions she makes with an 902 honest protocol participant and not through computation. The 903 adversary will not be able to obtain any information about the 904 password except whether a single guess from a single protocol run 905 is correct or incorrect. 906 Forward Secrecy Compromise of the password must not provide any 907 information about the secrets generated by earlier runs of the 908 protocol. 910 [RFC3748] requires that documents describing new EAP methods clearly 911 articulate the security properties of the method. In addition, for 912 use with wireless LANs, [RFC4017] mandates and recommends several of 913 these. The claims are: 914 1. Mechanism: password. 915 2. Claims: 916 * Mutual authentication: the peer and server both authenticate 917 each other by proving possession of a shared password. This 918 is REQUIRED by [RFC4017]. 919 * Forward secrecy: compromise of the password does not reveal 920 the secret keys (MSK and EMSK) from earlier runs of the 921 protocol. 922 * Replay protection: an attacker is unable to replay messages 923 from a previous exchange either to learn the password or a key 924 derived by the exchange. Similarly the attacker is unable to 925 induce either the peer or server to believe the exchange has 926 successfully completed when it hasn't. 927 * Key derivation: a shared secret is derived by performing a 928 group operation in a finite cyclic group (e.g. exponentiation) 929 using secret data contributed by both the peer and server. An 930 MSK and EMSK are derived from that shared secret. This is 931 REQUIRED by [RFC4017]. 932 * Dictionary attack resistance: an attacker can only make one 933 password guess per active attack, and the protocol is designed 934 so that the attacker does not gain any confirmation of her 935 guess by observing the decrypted Y_x value (see below). The 936 advantage she can gain is through interaction not through 937 computation. This is REQUIRED by [RFC4017]. 938 * Session independence: this protocol is resistant to active and 939 passive attacks and does not enable compromise of subsequent 940 or prior MSKs or EMSKs from either passive or active attacks. 941 * Denial of Service resistance: it is possible for an attacker 942 to cause a server to allocate state and consume CPU. Such an 943 attack is gated, though, by the requirement that the attacker 944 first obtain connectivity through a lower-layer protocol (e.g. 945 802.11 authentication followed by 802.11 association, or 802.3 946 "link-up") and respond to two EAP messages: the EAP-ID/Request 947 and the EAP-EKE-ID/Request. 948 * Man-in-the-Middle Attack resistance: this exchange is 949 resistant to active attack, which is a requirement for 950 launching a man-in-the-middle attack. This is REQUIRED by 951 [RFC4017]. 952 * Shared state equivalence: upon completion of EAP-EKE the peer 953 and server both agree on MSK, EMSK. The peer has 954 authenticated the server based on the Server_ID and the server 955 has authenticated the peer based on the Peer_ID. This is due 956 to the fact that Peer_ID, Server_ID, and the generated shared 957 secret are all combined to make the authentication element 958 which must be shared between the peer and server for the 959 exchange to complete. This is REQUIRED by [RFC4017]. 960 * Fragmentation: this protocol does not define a technique for 961 fragmentation and reassembly. 962 * Resistance to "Denning-Sacco" attack: learning keys 963 distributed from an earlier run of the protocol, such as the 964 MSK or EMSK, will not help an adversary learn the password. 965 3. Key strength: the strength of the resulting key depends on the 966 finite cyclic group chosen. Sufficient key strength is REQUIRED 967 by [RFC4017]. 968 4. Key hierarchy: MSKs and EMSKs are derived from the secret values 969 generated during the protocol run, using a negotiated pseudo- 970 random function. 971 5. Vulnerabilities (note that none of these are REQUIRED by 972 [RFC4017]): 974 * Protected ciphersuite negotiation: the ciphersuite proposal 975 made by the server is not protected from tampering by an 976 active attacker. However if a proposal was modified by an 977 active attacker it would result in a failure to confirm the 978 message sent by the other party, since the proposal is bound 979 by each side into its Confirm message, and the protocol would 980 fail as a result. Note that this assumes that none of the 981 proposed ciphersuites enables an attacker to perform real-time 982 cryptanalysis. 983 * Confidentiality: none of the messages sent in this protocol 984 are encrypted. 985 * Integrity protection: all messages in this protocol are 986 integrity protected. 987 * Channel binding: this protocol enables the exchange of 988 integrity-protected channel information that can be compared 989 with values communicated via out-of-band mechanisms. 990 * Fast reconnect: this protocol does not provide a fast 991 reconnect capability. 992 * Cryptographic binding: this protocol is not a tunneled EAP 993 method and therefore has no cryptographic information to bind. 994 * Identity protection: the EAP-EKE-ID exchange is not protected. 995 An attacker will see the server's identity in the EAP-EKE-ID/ 996 Request and see the peer's identity in EAP-EKE-ID/ Response. 997 However see Section 8.4. 999 8.1. Cryptographic Analysis 1001 When analyzing the Commit exchange, it should be noted that the base 1002 security assumptions are different from "normal" cryptology. 1003 Normally, we assume that the key has strong security properties, and 1004 that the data may have little. Here, we assume that the key has weak 1005 security properties (the attacker may have a list of possible keys), 1006 and hence we need to ensure that the data has strong properties 1007 (indistinguishable from random). This difference may mean that 1008 conventional wisdom in cryptology might not apply in this case. This 1009 also imposes severe constraints on the protocol, e.g. the mandatory 1010 use of random padding, and the need to define specific finite groups. 1012 8.2. Diffie Hellman Group Considerations 1014 It is fundamental to the dictionary attack resistance that the Diffie 1015 Hellman public values Y_S and Y_P are indistinguishable from a random 1016 string. If this condition is not met, then a passive attacker can do 1017 trial-decryption of the encrypted DHComponent_P, DHComponent_S values 1018 based on a password guess, and if they decrypt to a value which in 1019 not a valid public value, they know that the password guess was 1020 incorrect. 1022 For MODP groups, Section 6.2 gives conditions on the group to make 1023 sure that this criterion is met. For other groups (for example, 1024 Elliptic Curve groups), some other means of ensuring this must be 1025 employed. The standard way of expressing Elliptic Curve public 1026 values does not meet this criterion, as a valid Elliptic Curve X 1027 coordinate can be distinguished from a random string with probability 1028 approximately 0.5. 1030 A future version of this document might introduce a group 1031 representation, and/or a slight modification of the password 1032 encryption scheme, so that Elliptic Curve groups can be accommodated. 1033 [BR02] presents several alternative solutions for this problem. 1035 8.3. Resistance to Active Attacks 1037 An attacker, impersonating either the peer or the server, can always 1038 try to enumerate all possible passwords, for example by using a 1039 dictionary. To counter this likely attack vector, both peer and 1040 server MUST implement rate-limiting mechanisms. 1042 8.4. Identity Protection, Anonymity and Pseudonymity 1044 By default, the EAP-EKE-ID exchange is unprotected, and an 1045 eavesdropper can observe both parties' identities. However the 1046 parties may prefer to use a temporary identity at this stage in order 1047 to hide the true identity from the attacker. A similar technique is 1048 widely used when authenticating GSM subscribers. Note that in this 1049 respect EAP-EKE differs from tunneled methods, which typically 1050 provide unconditional identity protection to one of the peers by 1051 encrypting the identity exchange (but reveal information in the other 1052 peer's certificate). 1054 9. Acknowledgements 1056 Much of this document was unashamedly picked from 1057 [I-D.harkins-emu-eap-pwd] and [I-D.ietf-pppext-eap-srp-03], and we 1058 would like to acknowledge the authors of these documents: Dan 1059 Harkins, Glen Zorn, James Carlson, Bernard Aboba and Henry Haverinen. 1060 We would like to thank David Jacobson and Steve Bellovin for their 1061 useful comments. Lidar Herooty and Idan Ofrat implemented this 1062 protocol and helped us improve it by asking the right questions, and 1063 we would like to thank them both. 1065 10. References 1066 10.1. Normative References 1068 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1069 Hashing for Message Authentication", RFC 2104, 1070 February 1997. 1072 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1073 Requirement Levels", BCP 14, RFC 2119, March 1997. 1075 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1076 RFC 2548, March 1999. 1078 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1079 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1080 RFC 3526, May 2003. 1082 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1083 Levkowetz, "Extensible Authentication Protocol (EAP)", 1084 RFC 3748, June 2004. 1086 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1087 and Passwords", RFC 4013, February 2005. 1089 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1090 Network Access Identifier", RFC 4282, December 2005. 1092 10.2. Informative References 1094 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 1095 Password-Based Protocols Secure Against Dictionary 1096 Attacks", Proc. IEEE Symp. on Research in Security and 1097 Privacy , May 1992. 1099 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 1100 Exchange: A Password-Based Protocol Secure against 1101 Dictionary Attacks and Password File Compromise", Proc. 1102 1st ACM Conference on Computer and Communication 1103 Security , 1993. 1105 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 1106 Password Authenticated Key Exchange Using Diffie-Hellman", 1107 Advances in Cryptology, EUROCRYPT 2000 , 2000. 1109 [BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite 1110 Domains", Proc. of the RSA Cryptographer's Track (RSA CT 1111 '02), LNCS 2271 , 2002. 1113 [I-D.harkins-emu-eap-pwd] 1114 Harkins, D. and G. Zorn, "EAP Authentication Using Only A 1115 Password", draft-harkins-emu-eap-pwd-12 (work in 1116 progress), October 2009. 1118 [I-D.ietf-pppext-eap-srp-03] 1119 Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 1120 Authentication Protocol", draft-ietf-pppext-eap-srp-03 1121 (work in progress), July 2001. 1123 [I-D.krawczyk-hkdf] 1124 Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1125 Key Derivation Function (HKDF)", draft-krawczyk-hkdf-00 1126 (work in progress), June 2009. 1128 [JAB96] Jablon, D., "Strong Password-Only Authenticated Key 1129 Exchange", ACM Computer Communications Review Volume 1, 1130 Issue 5, October 1996. 1132 [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary 1133 Attacks Without Encrypting Public Keys", Proc. of the 1134 Security Protocols Workshop LNCS 1361, 1997. 1136 [PA97] Patel, S., "Number Theoretic Attacks On Secure Password 1137 Schemes", Proceedings of the 1997 IEEE Symposium on 1138 Security and Privacy , 1997. 1140 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1141 Authentication Protocol (EAP) Method Requirements for 1142 Wireless LANs", RFC 4017, March 2005. 1144 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1145 Requirements for Security", BCP 106, RFC 4086, June 2005. 1147 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1148 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1149 May 2008. 1151 Appendix A. Change Log 1153 Note to RFC Editor: please remove this section before publication. 1155 A.1. -04 1157 Changed the intended document status to Informational. 1159 A.2. -03 1161 Added a provision for channel binding. 1163 Clarified the notation for protected vs. encrypted fields. 1165 Explained how pseudonymity can be provided. 1167 Implementations need not implement the "password not found" failure. 1169 Eliminated the Design Options appendix. 1171 A.3. -02 1173 Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes. 1175 Eliminated protected failures: they are too rarely useful. 1177 Added the "extraction step" of HKDF. 1179 Removed the check for g^x != 0, since this can never happen for an 1180 honest peer, and otherwise requires an active password-guessing 1181 attacker, against which other protections are required. Added a 1182 related subsection about rate limiting. 1184 Added an Exchange Registry to the IANA Considerations. 1186 A general structure for protected (and merely encrypted) fields, 1187 which clarifies the protocol and also adds explicit integrity 1188 protection for the encrypted nonces, as recommended by [BM92]. 1190 A.4. -01 1192 Revised following comments raised on the CFRG mailing list. In 1193 particular, added security considerations and a new DH group 1194 definition, to resolve the vulnerability in case the group's 1195 generator is not a primitive element. 1197 A.5. -00 1199 Initial version. 1201 Authors' Addresses 1203 Yaron Sheffer 1204 Check Point Software Technologies Ltd. 1205 5 Hasolelim St. 1206 Tel Aviv 67897 1207 Israel 1209 Email: yaronf@checkpoint.com 1211 Glen Zorn 1212 Network Zen 1213 1310 East Thomas Street 1214 #306 1215 Seattle, Washington 98102 1216 USA 1218 Phone: +1 (206) 377-9035 1219 Email: gwz@net-zen.net 1221 Hannes Tschofenig 1222 Nokia Siemens Networks 1223 Linnoitustie 6 1224 Espoo 02600 1225 Finland 1227 Phone: +358 (50) 4871445 1228 Email: Hannes.Tschofenig@gmx.net 1229 URI: http://www.tschofenig.priv.at 1231 Scott Fluhrer 1232 Cisco Systems. 1233 1414 Massachusetts Ave. 1234 Boxborough, MA 01719 1235 USA 1237 Email: sfluhrer@cisco.com