idnits 2.17.1 draft-sheffer-emu-eap-eke-05.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 (March 6, 2010) is 5162 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) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-14) exists of draft-harkins-emu-eap-pwd-13 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 2 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: September 7, 2010 Network Zen 6 H. Tschofenig 7 Nokia Siemens Networks 8 S. Fluhrer 9 Cisco 10 March 6, 2010 12 An EAP Authentication Method Based on the EKE Protocol 13 draft-sheffer-emu-eap-eke-05 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 September 7, 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 . . . . . . . . . . . . . . . . . . . 22 93 8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 24 94 8.2. Diffie Hellman Group Considerations . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . 28 102 A.1. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 103 A.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 A.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 A.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 A.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 A.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 110 1. Introduction 112 The predominant access method for the Internet today is that of a 113 human using a username and password to authenticate to a computer 114 enforcing access control. Proof of knowledge of the password 115 authenticates the human to the computer. 117 Typically, these passwords are not stored on a user's computer for 118 security reasons and must be entered each time the human desires 119 network access. Therefore, the passwords must be ones that can be 120 repeatedly entered by a human with a low probability of error. They 121 will likely not possess high entropy and it may be assumed that an 122 adversary with access to a dictionary will have the ability to guess 123 a user's password. It is therefore desirable to have a robust 124 authentication method that is secure even when used with a weak 125 password in the presence of a strong adversary. 127 EAP-EKE is an EAP method [RFC3748] that addresses the problem of 128 password-based authenticated key exchange, using a possibly weak 129 password for authentication and to derive an authenticated and 130 cryptographically strong shared secret. This problem was first 131 described by Bellovin and Merritt in [BM92] and [BM93]. 132 Subsequently, a number of other solution approaches have been 133 proposed, for example [JAB96], [LUC97], [BMP00], and others. 135 This proposal is based on the original Encrypted Key Exchange (EKE) 136 proposal, as described in [BM92]. Some of the variants of the 137 original EKE have been attacked, see e.g. [PA97], and improvements 138 have been proposed. None of these subsequent improvements have been 139 incorporated into the current protocol. However, we have used only 140 the subset of [BM92] (namely the variant described in Section 3.1 of 141 the paper) which has withstood the test of time and is believed 142 secure as of this writing. 144 2. Terminology 146 This document uses Encr(Ke, ...) to denote encrypted information, and 147 Prot(Ke, Ki, ...) to denote encrypted and integrity protected 148 information. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. Protocol 156 3.1. Protocol Overview 158 EAP is a two-party protocol spoken between an EAP peer and an EAP 159 server (also known as "authenticator"). An EAP method defines the 160 specific authentication protocol being used by EAP. This memo 161 defines a particular method and therefore defines the messages sent 162 between the EAP server and the EAP peer for the purpose of 163 authentication and key derivation. 165 3.2. Message Flows 167 EAP-EKE defines three message exchanges: an Identity exchange, a 168 Commit exchange and a Confirm exchange. A successful authentication 169 is shown in Figure 1. 171 The peer and server use the EAP-EKE Identity exchange to learn each 172 other's identities and to agree upon a ciphersuite to use in the 173 subsequent exchanges. In the Commit exchange the peer and server 174 exchange information to generate a shared key and also to bind each 175 other to a particular guess of the password. In the Confirm exchange 176 the peer and server prove liveness and knowledge of the password by 177 generating and verifying verification data. 179 +--------+ +--------+ 180 | | EAP-EKE-ID/Request | | 181 | EAP |<------------------------------------| EAP | 182 | peer | | server | 183 | (P) | EAP-EKE-ID/Response | (S) | 184 | |------------------------------------>| | 185 | | | | 186 | | EAP-EKE-Commit/Request | | 187 | |<------------------------------------| | 188 | | | | 189 | | EAP-EKE-Commit/Response | | 190 | |------------------------------------>| | 191 | | | | 192 | | EAP-EKE-Confirm/Request | | 193 | |<------------------------------------| | 194 | | | | 195 | | EAP-EKE-Confirm/Response | | 196 | |------------------------------------>| | 197 | | | | 198 | | EAP-Success | | 199 | |<------------------------------------| | 200 +--------+ +--------+ 202 Figure 1: A Successful EAP-EKE Exchange 204 Schematically, the original exchange as described in [BM92] (and with 205 the roles reversed) is: 207 Server Peer 208 ------ ---- 210 E(Password, Y_S)) -> 212 <- E(Password, Y_P), E(SharedSecret, Nonce_P) 214 E(SharedSecret, Nonce_S | Nonce_P) -> 216 <- E(SharedSecret, Nonce_S) 218 Where: 219 o Y_S and Y_P are the server's (and respectively, the peer's) 220 ephemeral public key, i.e. g^x (mod p), g^y (mod p). 222 o Nonce_S, Nonce_P are random strings generated by the server and 223 the peer as cryptographic challenges. 224 o SharedSecret is the secret created by the Diffie-Hellman 225 algorithm, namely g^(x*y) (mod p). 226 The current protocol extends the basic cryptographic protocol, and 227 the regular successful exchange becomes: 229 Message Server Peer 230 --------- -------- ------ 231 ID/Request ID_S, CryptoProposals -> 233 ID/Response <- ID_P, CryptoSelection 235 Commit/Request Encr(Password, Y_S)) -> 237 Commit/Response <- Encr(Password, Y_P), Prot(Ke, Ki, Nonce_P) 239 Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S -> 241 Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P 243 As shown in the exchange above, the following information elements 244 have been added to the original protocol: identity values for both 245 protocol parties (ID_S, ID_P), negotiation of cryptographic 246 protocols, and signature fields to protect the integrity of the 247 negotiated parameters (Auth_S, Auth_P). In addition the shared 248 secret is not used directly. Note that a few details have been 249 omitted for clarity. 251 4. Packet Formats 253 4.1. EAP-EKE Header 255 The EAP-EKE header consists of the standard EAP header (see Section 4 256 of [RFC3748]), followed an EAP-EKE exchange type. The header has the 257 following structure: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Code | Identifier | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | EKE-Exch | Data ... 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2: EAP-EKE Header 269 The Code, Identifier, Length, and Type fields are all part of the EAP 270 header, and defined in [RFC3748]. The Type field in the EAP header 271 MUST be the value allocated by IANA for EAP-EKE version 1. 273 The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE 274 payload encapsulated in the Data field. This document defines the 275 following values for the EKE-Exch field: 276 o 0x00: Reserved 277 o 0x01: EAP-EKE-ID exchange 278 o 0x02: EAP-EKE-Commit exchange 279 o 0x03: EAP-EKE-Confirm exchange 280 o 0x04: EAP-EKE-Failure message 282 Further values of this EKE-Exch field are available via IANA 283 registration. 285 4.2. EAP-EKE Payloads 287 EAP-EKE payloads all contain the EAP-EKE header and encoded 288 information, which differs for the different exchanges. 290 4.3. EAP-EKE-ID 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | NumProposals | Reserved | Proposal ... 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 ... Proposal | IDType | Identity ... 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 3: EAP-EKE-ID Payload 302 The EAP-EKE-ID payload contains the following fields: 304 NumProposals: 306 The NumProposals field contains the number of Proposal fields 307 subsequently contained in the payload. In the EAP-EKE-ID/Request 308 the NumProposals field MUST NOT be set to zero (0) and in the EAP- 309 EKE-ID/Response message the NumProposals field MUST be set to one 310 (1). The offered proposals in the Request are listed contiguously 311 in priority order, most preferable first. The selected proposal 312 in the Response MUST be fully identical with one of the offered 313 proposals. 315 Proposal: 317 Each proposal consists of four one-octet fields, in this order: 319 Group Description: 321 This field's value is taken from the IANA registry for Diffie- 322 Hellman groups defined in Section 7.4. 324 Encryption: 326 This field's value is taken from the IANA registry for 327 encryption algorithms defined in Section 7.1. 329 PRF: 331 This field's value is taken from the IANA registry for pseudo 332 random functions defined in Section 7.2. 334 MAC: 336 This field's value is taken from the IANA registry for keyed 337 message digest algorithms defined in Section 7.3. 339 IDType: 341 Denotes the Identity type. This is taken from the IANA registry 342 defined in Section 7.5. The server and the peer MAY use different 343 identity types. 345 Identity: 347 The meaning of the Identity field depends on the values of the 348 Code and IDType fields. It is RECOMMENDED that the Identity field 349 be printable. 351 * EAP-EKE-ID/Request: server ID 352 * EAP-EKE-ID/Response: peer ID 353 The length of the Identity field is computed from the Length field 354 in the EAP header. 356 4.4. EAP-EKE-Commit 358 In this exchange both parties send their encrypted ephemeral public 359 key, and the peer also includes a Challenge. In addition, a small 360 amount of protected data can be included, which may be used for 361 channel binding. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | DHComponent ~ 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 ~ ~ 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Commit_P ~ 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 ~ ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | CBValue* ~ 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 ~ ~ 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 4: EAP-EKE-Commit Payload 381 DHComponent: 383 This field contains the password-encrypted Diffie-Hellman public 384 key, see Section 5.1. 386 Commit_P: 388 This field only appears in the response, and contains the 389 encrypted and integrity-protected challenge value sent by the 390 peer. See Section 5.2. 392 CBValue: 394 This structure MAY be included both in the request and in the 395 response, and MAY be repeated multiple times, once per each value 396 transmitted. See Section 4.9. 398 4.5. EAP-EKE-Confirm 400 In this exchange both parties complete the authentication by 401 generating a shared temporary key, authenticating the entire 402 protocol, and generating key material for the EAP consumer protocol. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Confirm_? ~ 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 ~ ~ 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Auth_? ~ 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 ~ ~ 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 5: EAP-EKE-Confirm Payload 418 Confirm_S/Confirm_P: 420 This field contains the encrypted and integrity-protected response 421 to the other party's challenge, see Section 5.3 and Section 5.4. 423 Auth_S/Auth_P: 425 This field signs the preceding messages, including the Identity 426 and the negotiated fields. This prevents various possible 427 attacks, such as algorithm downgrade attacks. See Section 5.3 and 428 Section 5.4. 430 4.6. EAP-EKE-Failure 432 The EAP-EKE-Failure message format is defined as follows: 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Failure-Code | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 EAP-EKE-Failure Payload 442 The following Failure-Code values are defined: 444 +------------+----------------+-------------------------------------+ 445 | Value | Name | Meaning | 446 +------------+----------------+-------------------------------------+ 447 | 0x00000000 | Reserved | | 448 | 0x00000001 | No Error | This code is used for failure | 449 | | | acknowledgement, see below. | 450 | 0x00000002 | Protocol Error | A failure to parse or understand a | 451 | | | protocol message or one of its | 452 | | | payloads. | 453 | 0x00000003 | Password Not | The password for a particular user | 454 | | Found | could not be located, making | 455 | | | authentication impossible. For | 456 | | | security reasons, implementations | 457 | | | MAY choose to eliminate this error | 458 | | | code and return "Authentication | 459 | | | Failure" also in this case. | 460 | 0x00000004 | Authentication | Failure in the cryptographic | 461 | | Failure | computation most likely caused by | 462 | | | an incorrect password, or an | 463 | | | inappropriate identity type. | 464 | 0x00000005 | Authorization | While the password being used is | 465 | | Failure | correct, the user is not authorized | 466 | | | to connect. | 467 | 0x00000006 | No Proposal | The peer is unwilling to select any | 468 | | Chosen | of the cryptographic proposals | 469 | | | offered by the server. | 470 +------------+----------------+-------------------------------------+ 472 Additional values of this field are available via IANA registration, 473 Section 7.7. 475 When the peer encounters an error situation, it MUST respond with 476 EAP-EKE-Failure. The server MUST send an EAP-Failure message to end 477 the exchange. 479 When the server encounters an error situation, it MUST respond with 480 EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message 481 containing a "No Error" failure code. Then the server MUST send an 482 EAP-Failure message to end the exchange. 484 4.7. Protected Fields 486 Several fields are encrypted and integrity-protected. They are 487 denoted Prot(...). Their general structure is as follows: 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Initialization Vector (IV) (optional) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Encrypted Data ~ 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 ~ ~ 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 ~ | Random Padding | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Integrity Check Value (ICV) | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Figure 6: Protected Field Structure 505 The protected field is a concatenation of four octet strings: 507 o An optional IV, required when the encryption algorithm/mode 508 necessitates it, e.g. for CBC encryption. A randomly chosen value 509 whose length is equal to the block length of the encryption 510 algorithm. The sender SHOULD pick this value pseudo-randomly and 511 independently for each protected field. 512 o The encrypted data. 513 o Random padding of the minimal length (possibly zero) required to 514 complete the length of the encrypted data to the encryption 515 algorithm's block size. This field is encrypted along with the 516 preceding data. 517 o ICV, a cryptographic checksum of the encrypted data, including the 518 padding. The checksum is computed over the encrypted, rather than 519 the plaintext, data. Its length is determined by the integrity 520 algorithm negotiated. 522 4.8. Encrypted Fields 524 Two fields are encrypted but not integrity protected. They are 525 denoted Encr(...). Their format is identical to a protected field 526 (Section 4.7), except that the Integrity Check Value is omitted. 528 4.9. Channel Binding Values 530 This protocol allows higher level protocols that are using it to 531 transmit opaque information between the peer and the server. This 532 information is integrity protected but not encrypted, and may be used 533 to ensure that protocol peers are identical at different protocol 534 layers. EAP-EKE is not aware of the transmitted information. The 535 information MUST NOT be used by the consumer protocol until it is 536 verified in the EAP-EKE-Confirm exchange (specifically, it is signed 537 by the Auth_S, Auth_P payloads). Consequently, it MUST NOT be relied 538 upon in case an error occurs at the EAP-EKE level. 540 Each Channel Binding Value is encoded using a simple TLV structure: 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | CBType | Length | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Value ... 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 7: Channel Binding Value 552 CBType: 554 This is the Channel Binding Value's type. This document defines 555 the value 0x0000 as reserved. Other values are left for IANA 556 allocation, Section 7.8. 558 Length: 560 This field is the total length in octets of the structure, 561 including the CBType and Length fields. 563 This facility should be used with care, since EAP-EKE does not 564 provide for message fragmentation. It SHOULD NOT be used to transmit 565 data other than that required to positively identify the protocol 566 peers. 568 5. Protocol Sequence 570 5.1. EAP-EKE-Commit/Request 572 The server computes 574 Y_S = g^x mod N, 576 where 'x' is a randomly chosen number in the range 2 .. N-1. The 577 randomly chosen number is the private key, and the calculated field 578 is the corresponding public key. Each of the peers MUST use a fresh, 579 random value for this field on each run of the protocol. 581 Note: If Elliptic Curve Diffie-Hellman is used, the corresponding 582 additive group operations are to be understood. 584 The server transmits the encrypted field (Section 4.8) 586 DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), Y_S), 588 where the literal string is encoded using ASCII with no zero 589 terminator. See Section 6.1 for the prf+ notation. When using block 590 ciphers, it may be necessary to pad Y_S on the right, to fit the 591 encryption algorithm's block size. In such cases, random padding 592 MUST be used, and this randomness is critical to the security of the 593 protocol. Randomness recommendations can be found in [RFC4086]. 594 When decrypting this field, the real length of Y_S is determined 595 according to the negotiated Diffie Hellman group. 597 If the password needs to be stored on the server, it is RECOMMENDED 598 to store the randomized password value, i.e. prf+(password, ...), as 599 a password-equivalent, rather than the cleartext password. 601 If the password is non-ASCII, it SHOULD be normalized by the sender 602 before the EAP-EKE message is constructed. The normalization method 603 is SASLprep, [RFC4013]. Note that the password is not null- 604 terminated. 606 5.2. EAP-EKE-Commit/Response 608 The peer computes 610 Y_P = g^y mod N 612 and sends 613 DHComponent_P = Encr(prf+(password, "EAP-EKE Password"), Y_P) 615 formatted as an encrypted field (Section 4.8). 617 Both sides calculate 619 SharedSecret = prf(0+, g^(x*y) mod N) 621 where the first argument to "prf" is a string of zero octets whose 622 length is the output size of the base hash algorithm, e.g. 20 octets 623 for HMAC-SHA1; the result is of the same length. This extra 624 application of the pseudo-random function is the "extraction step" of 625 [I-D.krawczyk-hkdf]. Note that the peer needs to compute the 626 SharedSecret value before sending out its response. 628 The encryption key is computed: 630 Ke = prf+(SharedSecret, "EAP-EKE Ke" | ID_S | ID_P) 632 The integrity protection key is computed: 634 Ki = prf+(SharedSecret, "EAP-EKE Ki" | ID_S | ID_P) 636 And the peer generates 638 Commit_P = Prot(Ke, Ki, Nonce_P), 640 where Nonce_P is a randomly generated binary string. Nonce_P has 641 length equal to the block size of the negotiated encryption algorithm 642 for block ciphers, or 32 octets if this algorithm is a stream cipher. 643 The peer sends this value as a protected field (Section 4.7), 644 encrypted using Ke and signed using Ki with the negotiated MAC 645 algorithm. 647 5.3. EAP-EKE-Confirm/Request 649 The server sends: 651 Confirm_S = Prot(Ke, Ki, Nonce_P | Nonce_S), 653 as a protected field, where Nonce_S is a randomly generated string, 654 similar to Nonce_P. 656 It computes: 658 Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | 659 Nonce_S) 661 And sends: 663 Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE- 664 ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response). 666 The messages are included in full, starting with the EAP header, and 667 including any possible future extensions. 669 5.4. EAP-EKE-Confirm/Response 671 The peer computes Ka, and sends: 673 Confirm_P = Prot(Ke, Ki, Nonce_S) 675 as a protected field, and 677 Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/ 678 Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response) 680 5.5. MSK and EMSK 682 Following the last message of the protocol, both sides compute and 683 export the shared keys, each 512 bits in length: 685 MSK = prf+(SharedSecret, "EAP-EKE MSK" | ID_S | ID_P | Nonce_P | 686 Nonce_S) 687 EMSK = prf+(SharedSecret, "EAP-EKE EMSK" | ID_S | ID_P | Nonce_P | 688 Nonce_S) 690 When the RADIUS attributes specified in [RFC2548] are used to 691 transport keying material, then the first 32 bytes of the MSK 692 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE- 693 SEND-KEY. In this case, only 64 bytes of keying material (the MSK) 694 are used. 696 6. Cryptographic Details 698 6.1. Generating Keying Material 700 Keying material is derived as the output of the negotiated prf 701 algorithm. Since the amount of keying material needed may be greater 702 than the size of the output of the prf algorithm, we will use the prf 703 iteratively. We denote by "prf+" the function that outputs a pseudo- 704 random stream based on the inputs to a prf as follows (where | 705 indicates concatenation): 707 prf+ (K, S) = T1 | T2 | T3 | T4 | ... 709 where: 710 T1 = prf(K, S | 0x01) 711 T2 = prf(K, T1 | S | 0x02) 712 T3 = prf(K, T2 | S | 0x03) 713 T4 = prf(K, T3 | S | 0x04) 715 continuing as needed to compute all required keys. The keys are 716 taken from the output string without regard to boundaries (e.g., if 717 the required keys are a 256-bit Advanced Encryption Standard (AES) 718 key and a 160-bit HMAC key, and the prf function generates 160 bits, 719 the AES key will come from T1 and the beginning of T2, while the HMAC 720 key will come from the rest of T2 and the beginning of T3). 722 The constant concatenated to the end of each string feeding the prf 723 is a single octet. prf+ in this document is not defined beyond 255 724 times the size of the prf output. 726 6.2. Diffie-Hellman Groups 728 Many of the commonly used Diffie Hellman groups are inappropriate for 729 use in EKE. Most of these groups use a generator which is not a 730 primitive element of the group. As a result, an attacker running a 731 dictionary attack would be able to learn at least 1 bit of 732 information for each decrypted password guess. 734 Any MODP Diffie Hellman group defined for use in this protocol MUST 735 have the following properties, to ensure that it does not leak a 736 usable amount of information about the password: 737 1. The generator is a primitive element of the group. 738 2. The most significant 64 bits of the prime number are 1. 739 3. The group's order p is a "safe prime", i.e. (p-1)/2 is also 740 prime. 742 The last requirement is related to the strength of the Diffie Hellman 743 algorithm, rather than the password encryption. It also makes it 744 easy to verify that the generator is primitive. 746 We have defined the following groups. The Value column is used when 747 negotiating the group. Additional groups may be defined through IANA 748 allocation. Future non-MODP groups require a document to define 749 their interaction with EAP-EKE. 751 +----------------+--------+---------+-------------------------------+ 752 | Name | Length | Value | Description | 753 +----------------+--------+---------+-------------------------------+ 754 | Reserved | | 0 | | 755 | DHGROUP_EKE_2 | 1024 | 1 | The prime number of Group 2 | 756 | | | | [RFC4306], with the generator | 757 | | | | 5 (decimal) | 758 | DHGROUP_EKE_5 | 1536 | 2 | The prime number of Group 5 | 759 | | | | [RFC3526], g=31 | 760 | DHGROUP_EKE_14 | 2048 | 3 | The prime number of Group 14 | 761 | | | | [RFC3526], g=11 | 762 | DHGROUP_EKE_15 | 3072 | 4 | The prime number of Group 15 | 763 | | | | [RFC3526], g=5 | 764 | DHGROUP_EKE_16 | 4096 | 5 | The prime number of Group 16 | 765 | | | | [RFC3526], g=5 | 766 | Available for | | 6-127 | | 767 | allocation via | | | | 768 | IANA | | | | 769 | Reserved for | | 128-255 | | 770 | private use | | | | 771 +----------------+--------+---------+-------------------------------+ 773 6.3. Mandatory Algorithms 775 To facilitate interoperability, the following algorithms are 776 mandatory to implement: 778 o ENCR_AES128_CBC (encryption algorithm) 779 o PRF_HMAC_SHA1 (pseudo random function and keyed message digest) 780 o DHGROUP_EKE_14 (DH-group) 782 7. IANA Considerations 784 IANA has allocated the EAP method type XXX, for "EAP-EKE Version 1". 786 This document requests that IANA create the registries described in 787 the following sub-sections. Values (other than private-use ones) can 788 be added or modified in these registries per Specification Required 789 [RFC5226]. 791 7.1. Encryption Algorithm Registry 793 This section defines an IANA registry for encryption algorithms: 795 +-----------------+---------+----------------------------------+ 796 | Name | Value | Definition | 797 +-----------------+---------+----------------------------------+ 798 | Reserved | 0 | | 799 | ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode | 800 | | 2-127 | Available for allocation via IANA| 801 | | 128-255 | Reserved for private use | 802 +-----------------+---------+----------------------------------+ 804 7.2. Pseudo Random Function Registry 806 This section defines an IANA registry for pseudo random function 807 algorithms: 809 +-----------------+---------+-------------------------------------+ 810 | Name | Value | Definition | 811 +-----------------+---------+-------------------------------------+ 812 | Reserved | 0 | | 813 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 814 | PRF_HMAC_SHA256 | 2 | HMAC SHA-256 | 815 | | 3-127 | Available for allocation via IANA | 816 | | 128-255 | Reserved for private use | 817 +-----------------+---------+-------------------------------------+ 819 A pseudo-random function takes two parameters K and S, and must be 820 defined for all lengths of K including zero. 822 7.3. Keyed Message Digest Registry 824 This section defines an IANA registry for keyed message digest 825 algorithms: 827 +-----------------+---------+-------------------------------------+ 828 | Name | Value | Definition | 829 +-----------------+---------+-------------------------------------+ 830 | Reserved | 0 | | 831 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 832 | PRF_HMAC_SHA256 | 2 | HMAC SHA-256 | 833 | | 3-127 | Available for allocation via IANA | 834 | | 128-255 | Reserved for private use | 835 +-----------------+---------+-------------------------------------+ 837 7.4. Diffie-Hellman Group Registry 839 An IANA registry for Diffie-Hellman groups is defined in Section 6.2. 841 7.5. Identity Type Registry 843 In addition, an identity type registry is defined: 845 +-----------+---------+---------------------------------------------+ 846 | Name | Value | Definition | 847 +-----------+---------+---------------------------------------------+ 848 | Reserved | 0 | | 849 | ID_OPAQUE | 1 | A printable UTF-8 string whose format is | 850 | | | undefined | 851 | ID_NAI | 2 | A Network Access Identifier, as defined in | 852 | | | [RFC4282] (mandatory to implement) | 853 | ID_IPv4 | 3 | An IPv4 address, in binary format | 854 | ID_IPv6 | 4 | An IPv6 address, in binary format | 855 | ID_FQDN | 5 | A fully qualified domain name (mandatory to | 856 | | | implement) | 857 | | 6-127 | Available for allocation via IANA | 858 | | 128-255 | Reserved for private use | 859 +-----------+---------+---------------------------------------------+ 861 7.6. Exchange Registry 863 This section defines an IANA registry for the EAP-EKE Exchange 864 registry, an 8-bit long code. Initial values are defined in 865 Section 4.1. All values up to 0x80 are available for allocation via 866 IANA. The remaining values up to 0xff are available for private use. 868 7.7. Failure-Code Registry 870 This section defines an IANA registry for the Failure-Code registry, 871 a 32-bit long code. Initial values are defined in Section 4.6. All 872 values up to 0xff000000 are available for allocation via IANA. The 873 remaining values up to 0xffffffff are available for private use. 875 7.8. Channel Binding Type Registry 877 This section defines an IANA registry for the Channel Binding Type 878 registry, a 16-bit long code. The value 0x0000 has been defined as 879 Reserved. All other values up to 0xff00 are available for allocation 880 via IANA. The remaining values up to 0xffff are available for 881 private use. 883 8. Security Considerations 885 Any protocol that claims to solve the problem of password- 886 authenticated key exchange must be resistant to active, passive and 887 dictionary attack and have the quality of forward secrecy. These 888 characteristics are discussed further in the following paragraphs. 890 Resistance to Passive Attack A passive attacker is one that merely 891 relays messages back and forth between the peer and server, 892 faithfully, and without modification. The contents of the 893 messages are available for inspection, but that is all. To 894 achieve resistance to passive attack, such an attacker must not be 895 able to obtain any information about the password or anything 896 about the resulting shared secret from watching repeated runs of 897 the protocol. Even if a passive attacker is able to learn the 898 password, she will not be able to determine any information about 899 the resulting secret shared by the peer and server. 900 Resistance to Active Attack An active attacker is able to modify, 901 add, delete, and replay messages sent between protocol 902 participants. For this protocol to be resistant to active attack, 903 the attacker must not be able to obtain any information about the 904 password or the shared secret by using any of its capabilities. 905 In addition, the attacker must not be able to fool a protocol 906 participant into thinking that the protocol completed 907 successfully. It is always possible for an active attacker to 908 deny delivery of a message critical in completing the exchange. 909 This is no different than dropping all messages and is not an 910 attack against the protocol. 911 Resistance to Dictionary Attack For this protocol to be resistant to 912 dictionary attack any advantage an adversary can gain must be 913 directly related to the number of interactions she makes with an 914 honest protocol participant and not through computation. The 915 adversary will not be able to obtain any information about the 916 password except whether a single guess from a single protocol run 917 is correct or incorrect. 918 Forward Secrecy Compromise of the password must not provide any 919 information about the secrets generated by earlier runs of the 920 protocol. 922 [RFC3748] requires that documents describing new EAP methods clearly 923 articulate the security properties of the method. In addition, for 924 use with wireless LANs, [RFC4017] mandates and recommends several of 925 these. The claims are: 926 1. Mechanism: password. 927 2. Claims: 928 * Mutual authentication: the peer and server both authenticate 929 each other by proving possession of a shared password. This 930 is REQUIRED by [RFC4017]. 932 * Forward secrecy: compromise of the password does not reveal 933 the secret keys (MSK and EMSK) from earlier runs of the 934 protocol. 935 * Replay protection: an attacker is unable to replay messages 936 from a previous exchange either to learn the password or a key 937 derived by the exchange. Similarly the attacker is unable to 938 induce either the peer or server to believe the exchange has 939 successfully completed when it hasn't. 940 * Key derivation: a shared secret is derived by performing a 941 group operation in a finite cyclic group (e.g. exponentiation) 942 using secret data contributed by both the peer and server. An 943 MSK and EMSK are derived from that shared secret. This is 944 REQUIRED by [RFC4017]. 945 * Dictionary attack resistance: an attacker can only make one 946 password guess per active attack, and the protocol is designed 947 so that the attacker does not gain any confirmation of her 948 guess by observing the decrypted Y_x value (see below). The 949 advantage she can gain is through interaction not through 950 computation. This is REQUIRED by [RFC4017]. 951 * Session independence: this protocol is resistant to active and 952 passive attacks and does not enable compromise of subsequent 953 or prior MSKs or EMSKs from either passive or active attacks. 954 * Denial of Service resistance: it is possible for an attacker 955 to cause a server to allocate state and consume CPU. Such an 956 attack is gated, though, by the requirement that the attacker 957 first obtain connectivity through a lower-layer protocol (e.g. 958 802.11 authentication followed by 802.11 association, or 802.3 959 "link-up") and respond to two EAP messages: the EAP-ID/Request 960 and the EAP-EKE-ID/Request. 961 * Man-in-the-Middle Attack resistance: this exchange is 962 resistant to active attack, which is a requirement for 963 launching a man-in-the-middle attack. This is REQUIRED by 964 [RFC4017]. 965 * Shared state equivalence: upon completion of EAP-EKE the peer 966 and server both agree on MSK, EMSK. The peer has 967 authenticated the server based on the Server_ID and the server 968 has authenticated the peer based on the Peer_ID. This is due 969 to the fact that Peer_ID, Server_ID, and the generated shared 970 secret are all combined to make the authentication element 971 which must be shared between the peer and server for the 972 exchange to complete. This is REQUIRED by [RFC4017]. 973 * Fragmentation: this protocol does not define a technique for 974 fragmentation and reassembly. 975 * Resistance to "Denning-Sacco" attack: learning keys 976 distributed from an earlier run of the protocol, such as the 977 MSK or EMSK, will not help an adversary learn the password. 979 3. Key strength: the strength of the resulting key depends on the 980 finite cyclic group chosen. Sufficient key strength is REQUIRED 981 by [RFC4017]. 982 4. Key hierarchy: MSKs and EMSKs are derived from the secret values 983 generated during the protocol run, using a negotiated pseudo- 984 random function. 985 5. Vulnerabilities (note that none of these are REQUIRED by 986 [RFC4017]): 987 * Protected ciphersuite negotiation: the ciphersuite proposal 988 made by the server is not protected from tampering by an 989 active attacker. However if a proposal was modified by an 990 active attacker it would result in a failure to confirm the 991 message sent by the other party, since the proposal is bound 992 by each side into its Confirm message, and the protocol would 993 fail as a result. Note that this assumes that none of the 994 proposed ciphersuites enables an attacker to perform real-time 995 cryptanalysis. 996 * Confidentiality: none of the messages sent in this protocol 997 are encrypted. 998 * Integrity protection: all messages in this protocol are 999 integrity protected. 1000 * Channel binding: this protocol enables the exchange of 1001 integrity-protected channel information that can be compared 1002 with values communicated via out-of-band mechanisms. 1003 * Fast reconnect: this protocol does not provide a fast 1004 reconnect capability. 1005 * Cryptographic binding: this protocol is not a tunneled EAP 1006 method and therefore has no cryptographic information to bind. 1007 * Identity protection: the EAP-EKE-ID exchange is not protected. 1008 An attacker will see the server's identity in the EAP-EKE-ID/ 1009 Request and see the peer's identity in EAP-EKE-ID/ Response. 1010 However see Section 8.4. 1012 8.1. Cryptographic Analysis 1014 When analyzing the Commit exchange, it should be noted that the base 1015 security assumptions are different from "normal" cryptology. 1016 Normally, we assume that the key has strong security properties, and 1017 that the data may have little. Here, we assume that the key has weak 1018 security properties (the attacker may have a list of possible keys), 1019 and hence we need to ensure that the data has strong properties 1020 (indistinguishable from random). This difference may mean that 1021 conventional wisdom in cryptology might not apply in this case. This 1022 also imposes severe constraints on the protocol, e.g. the mandatory 1023 use of random padding, and the need to define specific finite groups. 1025 8.2. Diffie Hellman Group Considerations 1027 It is fundamental to the dictionary attack resistance that the Diffie 1028 Hellman public values Y_S and Y_P are indistinguishable from a random 1029 string. If this condition is not met, then a passive attacker can do 1030 trial-decryption of the encrypted DHComponent_P, DHComponent_S values 1031 based on a password guess, and if they decrypt to a value which in 1032 not a valid public value, they know that the password guess was 1033 incorrect. 1035 For MODP groups, Section 6.2 gives conditions on the group to make 1036 sure that this criterion is met. For other groups (for example, 1037 Elliptic Curve groups), some other means of ensuring this must be 1038 employed. The standard way of expressing Elliptic Curve public 1039 values does not meet this criterion, as a valid Elliptic Curve X 1040 coordinate can be distinguished from a random string with probability 1041 approximately 0.5. 1043 A future version of this document might introduce a group 1044 representation, and/or a slight modification of the password 1045 encryption scheme, so that Elliptic Curve groups can be accommodated. 1046 [BR02] presents several alternative solutions for this problem. 1048 8.3. Resistance to Active Attacks 1050 An attacker, impersonating either the peer or the server, can always 1051 try to enumerate all possible passwords, for example by using a 1052 dictionary. To counter this likely attack vector, both peer and 1053 server MUST implement rate-limiting mechanisms. 1055 8.4. Identity Protection, Anonymity and Pseudonymity 1057 By default, the EAP-EKE-ID exchange is unprotected, and an 1058 eavesdropper can observe both parties' identities. A future 1059 extension of this protocol may support anonymity, e.g. by allowing 1060 the server to send a temporary identity to the peer at the end of the 1061 exchange, so that the peer can use that identity in subsequent 1062 exchanges. Note that in this respect EAP-EKE differs from tunneled 1063 methods, which typically provide unconditional identity protection to 1064 the peer by encrypting the identity exchange, but reveal information 1065 in the server certificate. 1067 9. Acknowledgements 1069 Much of this document was unashamedly picked from 1070 [I-D.harkins-emu-eap-pwd] and [I-D.ietf-pppext-eap-srp-03], and we 1071 would like to acknowledge the authors of these documents: Dan 1072 Harkins, Glen Zorn, James Carlson, Bernard Aboba and Henry Haverinen. 1073 We would like to thank David Jacobson and Steve Bellovin for their 1074 useful comments. Lidar Herooty and Idan Ofrat implemented this 1075 protocol and helped us improve it by asking the right questions, and 1076 we would like to thank them both. 1078 10. References 1080 10.1. Normative References 1082 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1083 Hashing for Message Authentication", RFC 2104, 1084 February 1997. 1086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1087 Requirement Levels", BCP 14, RFC 2119, March 1997. 1089 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1090 RFC 2548, March 1999. 1092 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1093 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1094 RFC 3526, May 2003. 1096 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1097 Levkowetz, "Extensible Authentication Protocol (EAP)", 1098 RFC 3748, June 2004. 1100 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1101 and Passwords", RFC 4013, February 2005. 1103 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1104 Network Access Identifier", RFC 4282, December 2005. 1106 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1107 RFC 4306, December 2005. 1109 10.2. Informative References 1111 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 1112 Password-Based Protocols Secure Against Dictionary 1113 Attacks", Proc. IEEE Symp. on Research in Security and 1114 Privacy , May 1992. 1116 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 1117 Exchange: A Password-Based Protocol Secure against 1118 Dictionary Attacks and Password File Compromise", Proc. 1120 1st ACM Conference on Computer and Communication 1121 Security , 1993. 1123 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 1124 Password Authenticated Key Exchange Using Diffie-Hellman", 1125 Advances in Cryptology, EUROCRYPT 2000 , 2000. 1127 [BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite 1128 Domains", Proc. of the RSA Cryptographer's Track (RSA CT 1129 '02), LNCS 2271 , 2002. 1131 [I-D.harkins-emu-eap-pwd] 1132 Harkins, D. and G. Zorn, "EAP Authentication Using Only A 1133 Password", draft-harkins-emu-eap-pwd-13 (work in 1134 progress), February 2010. 1136 [I-D.ietf-pppext-eap-srp-03] 1137 Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 1138 Authentication Protocol", draft-ietf-pppext-eap-srp-03 1139 (work in progress), July 2001. 1141 [I-D.krawczyk-hkdf] 1142 Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1143 Key Derivation Function (HKDF)", draft-krawczyk-hkdf-01 1144 (work in progress), January 2010. 1146 [JAB96] Jablon, D., "Strong Password-Only Authenticated Key 1147 Exchange", ACM Computer Communications Review Volume 1, 1148 Issue 5, October 1996. 1150 [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary 1151 Attacks Without Encrypting Public Keys", Proc. of the 1152 Security Protocols Workshop LNCS 1361, 1997. 1154 [PA97] Patel, S., "Number Theoretic Attacks On Secure Password 1155 Schemes", Proceedings of the 1997 IEEE Symposium on 1156 Security and Privacy , 1997. 1158 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1159 Authentication Protocol (EAP) Method Requirements for 1160 Wireless LANs", RFC 4017, March 2005. 1162 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1163 Requirements for Security", BCP 106, RFC 4086, June 2005. 1165 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1166 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1167 May 2008. 1169 Appendix A. Change Log 1171 Note to RFC Editor: please remove this section before publication. 1173 A.1. -05 1175 Revised the Anonymity section. Added more MODP groups. Note that 1176 DHGROUP_EKE_14 was renumbered. 1178 A.2. -04 1180 Changed the intended document status to Informational. 1182 A.3. -03 1184 Added a provision for channel binding. 1186 Clarified the notation for protected vs. encrypted fields. 1188 Explained how pseudonymity can be provided. 1190 Implementations need not implement the "password not found" failure. 1192 Eliminated the Design Options appendix. 1194 A.4. -02 1196 Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes. 1198 Eliminated protected failures: they are too rarely useful. 1200 Added the "extraction step" of HKDF. 1202 Removed the check for g^x != 0, since this can never happen for an 1203 honest peer, and otherwise requires an active password-guessing 1204 attacker, against which other protections are required. Added a 1205 related subsection about rate limiting. 1207 Added an Exchange Registry to the IANA Considerations. 1209 A general structure for protected (and merely encrypted) fields, 1210 which clarifies the protocol and also adds explicit integrity 1211 protection for the encrypted nonces, as recommended by [BM92]. 1213 A.5. -01 1215 Revised following comments raised on the CFRG mailing list. In 1216 particular, added security considerations and a new DH group 1217 definition, to resolve the vulnerability in case the group's 1218 generator is not a primitive element. 1220 A.6. -00 1222 Initial version. 1224 Authors' Addresses 1226 Yaron Sheffer 1227 Check Point Software Technologies Ltd. 1228 5 Hasolelim St. 1229 Tel Aviv 67897 1230 Israel 1232 Email: yaronf@checkpoint.com 1234 Glen Zorn 1235 Network Zen 1236 1310 East Thomas Street 1237 #306 1238 Seattle, Washington 98102 1239 USA 1241 Phone: +1 (206) 377-9035 1242 Email: gwz@net-zen.net 1244 Hannes Tschofenig 1245 Nokia Siemens Networks 1246 Linnoitustie 6 1247 Espoo 02600 1248 Finland 1250 Phone: +358 (50) 4871445 1251 Email: Hannes.Tschofenig@gmx.net 1252 URI: http://www.tschofenig.priv.at 1253 Scott Fluhrer 1254 Cisco Systems. 1255 1414 Massachusetts Ave. 1256 Boxborough, MA 01719 1257 USA 1259 Email: sfluhrer@cisco.com