idnits 2.17.1 draft-sheffer-emu-eap-eke-03.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 (November 30, 2009) is 5254 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2548 ** 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: 5 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: Standards Track G. Zorn 5 Expires: June 3, 2010 Network Zen 6 H. Tschofenig 7 Nokia Siemens Networks 8 S. Fluhrer 9 Cisco 10 November 30, 2009 12 An EAP Authentication Method Based on the EKE Protocol 13 draft-sheffer-emu-eap-eke-03 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 June 3, 2010. 49 Copyright Notice 51 Copyright (c) 2009 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 . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 18 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. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 103 A.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 A.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 A.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 108 1. Introduction 110 The predominant access method for the Internet today is that of a 111 human using a username and password to authenticate to a computer 112 enforcing access control. Proof of knowledge of the password 113 authenticates the human to the computer. 115 Typically, these passwords are not stored on a user's computer for 116 security reasons and must be entered each time the human desires 117 network access. Therefore, the passwords must be ones that can be 118 repeatedly entered by a human with a low probability of error. They 119 will likely not possess high entropy and it may be assumed that an 120 adversary with access to a dictionary will have the ability to guess 121 a user's password. It is therefore desirable to have a robust 122 authentication method that is secure even when used with a weak 123 password in the presence of a strong adversary. 125 EAP-EKE is an EAP method [RFC3748] that addresses the problem of 126 password-based authenticated key exchange, using a possibly weak 127 password for authentication and to derive an authenticated and 128 cryptographically strong shared secret. This problem was first 129 described by Bellovin and Merritt in [BM92] and [BM93]. 130 Subsequently, a number of other solution approaches have been 131 proposed, for example [JAB96], [LUC97], [BMP00], and others. 133 This proposal is based on the original Encrypted Key Exchange (EKE) 134 proposal, as described in [BM92]. Some of the variants of the 135 original EKE have been attacked, see e.g. [PA97], and improvements 136 have been proposed. None of these subsequent improvements have been 137 incorporated into the current protocol. However, we have used only 138 the subset of [BM92] (namely the variant described in Section 3.1 of 139 the paper) which has withstood the test of time and is believed 140 secure as of this writing. 142 2. Terminology 144 This document uses Encr(Ke, ...) to denote encrypted information, and 145 Prot(Ke, Ki, ...) to denote encrypted and integrity protected 146 information. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 3. Protocol 154 3.1. Protocol Overview 156 EAP is a two-party protocol spoken between an EAP peer and an EAP 157 server (also known as "authenticator"). An EAP method defines the 158 specific authentication protocol being used by EAP. This memo 159 defines a particular method and therefore defines the messages sent 160 between the EAP server and the EAP peer for the purpose of 161 authentication and key derivation. 163 3.2. Message Flows 165 EAP-EKE defines three message exchanges: an Identity exchange, a 166 Commit exchange and a Confirm exchange. A successful authentication 167 is shown in Figure 1. 169 The peer and server use the EAP-EKE Identity exchange to learn each 170 other's identities and to agree upon a ciphersuite to use in the 171 subsequent exchanges. In the Commit exchange the peer and server 172 exchange information to generate a shared key and also to bind each 173 other to a particular guess of the password. In the Confirm exchange 174 the peer and server prove liveness and knowledge of the password by 175 generating and verifying verification data. 177 +--------+ +--------+ 178 | | EAP-EKE-ID/Request | | 179 | EAP |<------------------------------------| EAP | 180 | peer | | server | 181 | (P) | EAP-EKE-ID/Response | (S) | 182 | |------------------------------------>| | 183 | | | | 184 | | EAP-EKE-Commit/Request | | 185 | |<------------------------------------| | 186 | | | | 187 | | EAP-EKE-Commit/Response | | 188 | |------------------------------------>| | 189 | | | | 190 | | EAP-EKE-Confirm/Request | | 191 | |<------------------------------------| | 192 | | | | 193 | | EAP-EKE-Confirm/Response | | 194 | |------------------------------------>| | 195 | | | | 196 | | EAP-Success | | 197 | |<------------------------------------| | 198 +--------+ +--------+ 200 Figure 1: A Successful EAP-EKE Exchange 202 Schematically, the original exchange as described in [BM92] (and with 203 the roles reversed) is: 205 Server Peer 206 ------ ---- 208 E(Password, Y_S)) -> 210 <- E(Password, Y_P), E(SharedSecret, Nonce_P) 212 E(SharedSecret, Nonce_S | Nonce_P) -> 214 <- E(SharedSecret, Nonce_S) 216 Where: 217 o Y_S and Y_P are the server's (and respectively, the peer's) 218 ephemeral public key, i.e. g^x (mod p), g^y (mod p). 220 o Nonce_S, Nonce_P are random strings generated by the server and 221 the peer as cryptographic challenges. 222 o SharedSecret is the secret created by the Diffie-Hellman 223 algorithm, namely g^(x*y) (mod p). 224 The current protocol extends the basic cryptographic protocol, and 225 the regular successful exchange becomes: 227 Message Server Peer 228 --------- -------- ------ 229 ID/Request ID_S, CryptoProposals -> 231 ID/Response <- ID_P, CryptoSelection 233 Commit/Request Encr(Password, Y_S)) -> 235 Commit/Response <- Encr(Password, Y_P), Prot(Ke, Ki, Nonce_P) 237 Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S -> 239 Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P 241 As shown in the exchange above, the following information elements 242 have been added to the original protocol: identity values for both 243 protocol parties (ID_S, ID_P), negotiation of cryptographic 244 protocols, and signature fields to protect the integrity of the 245 negotiated parameters (Auth_S, Auth_P). In addition the shared 246 secret is not used directly. Note that a few details have been 247 omitted for clarity. 249 4. Packet Formats 251 4.1. EAP-EKE Header 253 The EAP-EKE header consists of the standard EAP header (see Section 4 254 of [RFC3748]), followed an EAP-EKE exchange type. The header has the 255 following structure: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Code | Identifier | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type | EKE-Exch | Data ... 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2: EAP-EKE Header 267 The Code, Identifier, Length, and Type fields are all part of the EAP 268 header, and defined in [RFC3748]. The Type field in the EAP header 269 MUST be the value allocated by IANA for EAP-EKE version 1. 271 The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE 272 payload encapsulated in the Data field. This document defines the 273 following values for the EKE-Exch field: 274 o 0x00: Reserved 275 o 0x01: EAP-EKE-ID exchange 276 o 0x02: EAP-EKE-Commit exchange 277 o 0x03: EAP-EKE-Confirm exchange 278 o 0x04: EAP-EKE-Failure message 280 Further values of this EKE-Exch field are available via IANA 281 registration. 283 4.2. EAP-EKE Payloads 285 EAP-EKE payloads all contain the EAP-EKE header and encoded 286 information, which differs for the different exchanges. 288 4.3. EAP-EKE-ID 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | NumProposals | Reserved | Proposal ... 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 ... Proposal | IDType | Identity ... 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 3: EAP-EKE-ID Payload 300 The EAP-EKE-ID payload contains the following fields: 302 NumProposals: 304 The NumProposals field contains the number of Proposal fields 305 subsequently contained in the payload. In the EAP-EKE-ID/Request 306 the NumProposals field MUST NOT be set to zero (0) and in the EAP- 307 EKE-ID/Response message the NumProposals field MUST be set to one 308 (1). The offered proposals in the Request are listed contiguously 309 in priority order, most preferable first. The selected proposal 310 in the Response MUST be fully identical with one of the offered 311 proposals. 313 Proposal: 315 Each proposal consists of four one-octet fields, in this order: 317 Group Description: 319 This field's value is taken from the IANA registry for Diffie- 320 Hellman groups defined in Section 7.4. 322 Encryption: 324 This field's value is taken from the IANA registry for 325 encryption algorithms defined in Section 7.1. 327 PRF: 329 This field's value is taken from the IANA registry for pseudo 330 random functions defined in Section 7.2. 332 MAC: 334 This field's value is taken from the IANA registry for keyed 335 message digest algorithms defined in Section 7.3. 337 IDType: 339 Denotes the Identity type. This is taken from the IANA registry 340 defined in Section 7. The server and the peer MAY use different 341 identity types. 343 The meaning of the Identity field depends on the values of the Code 344 and IDType fields. It is RECOMMENDED that the Identity field be 345 printable. 347 o EAP-EKE-ID/Request: server ID 348 o EAP-EKE-ID/Response: peer ID 350 To allow for "channel binding", The server SHOULD assert its own 351 identity (e.g. its host name). 353 The length of the Identity field is computed from the Length field in 354 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 preceeding 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. 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. 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 568 5.1. EAP-EKE-Commit/Request 570 The server computes 572 Y_S = g^x mod N, 574 where 'x' is a randomly chosen number in the range 2 .. N-1. The 575 randomly chosen number is the private key, and the calculated field 576 is the corresponding public key. Each of the peers MUST use a fresh, 577 random value for this field on each run of the protocol. 579 Note: If Elliptic Curve Diffie-Hellman is used, the corresponding 580 additive group operations are to be understood. 582 The server transmits the encrypted field (Section 4.8) 584 DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), Y_S), 586 where the literal string is encoded using ASCII with no zero 587 terminator. See Section 6.1 for the prf+ notation. When using block 588 ciphers, it may be necessary to pad Y_S on the right, to fit the 589 encryption algorithm's block size. In such cases, random padding 590 MUST be used, and this randomness is critical to the security of the 591 protocol. Randomness recommendations can be found in [RFC4086]. 592 When decrypting this field, the real length of Y_S is determined 593 according to the negotiated Diffie Hellman group. 595 If the password needs to be stored on the server, it is RECOMMENDED 596 to store the randomized password value, i.e. prf+(password, ...), as 597 a password-equivalent, rather than the cleartext password. 599 If the password is non-ASCII, it SHOULD be normalized by the sender 600 before the EAP-EKE message is constructed. The normalization method 601 is SASLprep, [RFC4013]. Note that the password is not null- 602 terminated. 604 5.2. EAP-EKE-Commit/Response 606 The peer computes 608 Y_P = g^y mod N 610 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: 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: 747 o DHGROUP_EKE_14 is defined as: the prime number of Group 14 748 [RFC3526], with the generator 11 (decimal). 749 o Additional groups may be defined by future versions of this 750 document, or through IANA assignment. 752 6.3. Mandatory Algorithms 754 To facilitate interoperability, the following algorithms are 755 mandatory to implement: 757 o ENCR_AES128_CBC (encryption algorithm) 758 o PRF_HMAC_SHA1 (pseudo random function and keyed message digest) 759 o DHGROUP_EKE_14 (DH-group) 761 7. IANA Considerations 763 IANA has allocated the EAP method type XXX, for "EAP-EKE Version 1". 765 This document requests that IANA create the registries described in 766 the following sub-sections. Values can be added or modified in these 767 registries per Specification Required [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 certicifate). 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. -03 1157 Added a provision for channel binding. 1159 Clarified the notation for protected vs. encrypted fields. 1161 Explained how pseudonymity can be provided. 1163 Implementations need not implement the "password not found" failure. 1165 Eliminated the Design Options appendix. 1167 A.2. -02 1169 Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes. 1171 Eliminated protected failures: they are too rarely useful. 1173 Added the "extraction step" of HKDF. 1175 Removed the check for g^x != 0, since this can never happen for an 1176 honest peer, and otherwise requires an active password-guessing 1177 attacker, against which other protections are required. Added a 1178 related subsection about rate limiting. 1180 Added an Exchange Registry to the IANA Considerations. 1182 A general structure for protected (and merely encrypted) fields, 1183 which clarifies the protocol and also adds explicit integrity 1184 protection for the encrypted nonces, as recommended by [BM92]. 1186 A.3. -01 1188 Revised following comments raised on the CFRG mailing list. In 1189 particular, added security considerations and a new DH group 1190 definition, to resolve the vulnerability in case the group's 1191 generator is not a primitive element. 1193 A.4. -00 1195 Initial version. 1197 Authors' Addresses 1199 Yaron Sheffer 1200 Check Point Software Technologies Ltd. 1201 5 Hasolelim St. 1202 Tel Aviv 67897 1203 Israel 1205 Email: yaronf@checkpoint.com 1206 Glen Zorn 1207 Network Zen 1208 1310 East Thomas Street 1209 #306 1210 Seattle, Washington 98102 1211 USA 1213 Phone: +1 (206) 377-9035 1214 Email: gwz@net-zen.net 1216 Hannes Tschofenig 1217 Nokia Siemens Networks 1218 Linnoitustie 6 1219 Espoo 02600 1220 Finland 1222 Phone: +358 (50) 4871445 1223 Email: Hannes.Tschofenig@gmx.net 1224 URI: http://www.tschofenig.priv.at 1226 Scott Fluhrer 1227 Cisco Systems. 1228 1414 Massachusetts Ave. 1229 Boxborough, MA 01719 1230 USA 1232 Email: sfluhrer@cisco.com