idnits 2.17.1 draft-sheffer-emu-eap-eke-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 25, 2010) is 4993 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 3454 (Obsoleted by RFC 7564) ** 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) -- 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 Independent 4 Intended status: Informational G. Zorn 5 Expires: February 26, 2011 Network Zen 6 H. Tschofenig 7 Nokia Siemens Networks 8 S. Fluhrer 9 Cisco 10 August 25, 2010 12 An EAP Authentication Method Based on the EKE Protocol 13 draft-sheffer-emu-eap-eke-08 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 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). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 26, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 5 76 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 8 78 4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 8 79 4.2.1. The EAP-EKE-ID Payload . . . . . . . . . . . . . . . . 9 80 4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 10 81 4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11 82 4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 12 83 4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13 84 4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14 85 4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14 86 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 16 87 5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 16 88 5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 17 89 5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 18 90 5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 18 91 5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 19 92 6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 19 93 6.1. Deriving a Key from the Password . . . . . . . . . . . . . 19 94 6.2. Generating Keying Material . . . . . . . . . . . . . . . . 20 95 6.3. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 20 96 6.4. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 21 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 99 8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 27 100 8.2. Diffie Hellman Group Considerations . . . . . . . . . . . 27 101 8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 28 102 8.4. Identity Protection, Anonymity and Pseudonymity . . . . . 28 103 8.5. Password Processing and Long Term Storage . . . . . . . . 28 104 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 107 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 108 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 111 1. Introduction 113 The predominant access method for the Internet today is that of a 114 human using a username and password to authenticate to a computer 115 enforcing access control. Proof of knowledge of the password 116 authenticates the human to the computer. 118 Typically, these passwords are not stored on a user's computer for 119 security reasons and must be entered each time the human desires 120 network access. Therefore, the passwords must be ones that can be 121 repeatedly entered by a human with a low probability of error. They 122 will likely not possess high entropy and it may be assumed that an 123 adversary with access to a dictionary will have the ability to guess 124 a user's password. It is therefore desirable to have a robust 125 authentication method that is secure even when used with a weak 126 password in the presence of a strong adversary. 128 EAP-EKE is an EAP method [RFC3748] that addresses the problem of 129 password-based authenticated key exchange, using a possibly weak 130 password for authentication and to derive an authenticated and 131 cryptographically strong shared secret. This problem was first 132 described by Bellovin and Merritt in [BM92] and [BM93]. 133 Subsequently, a number of other solution approaches have been 134 proposed, for example [JAB96], [LUC97], [BMP00], and others. 136 This proposal is based on the original Encrypted Key Exchange (EKE) 137 proposal, as described in [BM92]. Some of the variants of the 138 original EKE have been attacked, see e.g. [PA97], and improvements 139 have been proposed. None of these subsequent improvements have been 140 incorporated into the current protocol. However, we have used only 141 the subset of [BM92] (namely the variant described in Section 3.1 of 142 the paper) which has withstood the test of time and is believed 143 secure as of this writing. 145 2. Terminology 147 This document uses Encr(Ke, ...) to denote encrypted information, and 148 Prot(Ke, Ki, ...) to denote encrypted and integrity protected 149 information. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Protocol 157 EAP is a two-party protocol spoken between an EAP peer and an EAP 158 server (also known as "authenticator"). An EAP method defines the 159 specific authentication protocol being used by EAP. This memo 160 defines a particular method and therefore defines the messages sent 161 between the EAP server and the EAP peer for the purpose of 162 authentication and key derivation. 164 3.1. Message Flows 166 A successful run of EAP-EKE consists of three message exchanges: an 167 Identity exchange, a Commit exchange and a Confirm exchange. This is 168 shown in Figure 1. 170 The peer and server use the EAP-EKE Identity exchange to learn each 171 other's identities and to agree upon a ciphersuite to use in the 172 subsequent exchanges. In the Commit exchange the peer and server 173 exchange information to generate a shared key and also to bind each 174 other to a particular guess of the password. In the Confirm exchange 175 the peer and server prove liveness and knowledge of the password by 176 generating and verifying verification data (note that the second 177 message of the Commit exchange already plays an essential part in 178 this liveness proof). 180 +--------+ +--------+ 181 | | EAP-EKE-ID/Request | | 182 | EAP |<------------------------------------| EAP | 183 | peer | | server | 184 | (P) | EAP-EKE-ID/Response | (S) | 185 | |------------------------------------>| | 186 | | | | 187 | | EAP-EKE-Commit/Request | | 188 | |<------------------------------------| | 189 | | | | 190 | | EAP-EKE-Commit/Response | | 191 | |------------------------------------>| | 192 | | | | 193 | | EAP-EKE-Confirm/Request | | 194 | |<------------------------------------| | 195 | | | | 196 | | EAP-EKE-Confirm/Response | | 197 | |------------------------------------>| | 198 | | | | 199 | | EAP-Success | | 200 | |<------------------------------------| | 201 +--------+ +--------+ 203 Figure 1: A Successful EAP-EKE Exchange 205 Schematically, the original exchange as described in [BM92] (and with 206 the roles reversed) is: 208 Server Peer 209 ------ ---- 211 Encr(Password, y_s) -> 213 <- Encr(Password, y_p), Encr(SharedSecret, Nonce_P) 215 Encr(SharedSecret, Nonce_S | Nonce_P) -> 217 <- Encr(SharedSecret, Nonce_S) 219 Where: 220 o Password is a typically short string, shared between the server 221 and the peer. In other words, the same password is used to 222 authenticate the server to the peer, and vice versa. 224 o y_s and y_p are the server's and respectively, the peer's, 225 ephemeral public key, i.e. y_s = g ^ x_s (mod p) and y_p = g ^ x_p 226 (mod p). 227 o Nonce_S, Nonce_P are random strings generated by the server and 228 the peer as cryptographic challenges. 229 o SharedSecret is the secret created by the Diffie-Hellman 230 algorithm, namely SharedSecret = g^(x_s * x_p) (mod p). This 231 value is calculated by the server as: SharedSecret = y_p ^ x_s 232 (mod p), and by the peer as: SharedSecret = y_s ^ x_p (mod p). 233 The current protocol extends the basic cryptographic protocol, and 234 the regular successful exchange becomes: 236 Message Server Peer 237 --------- -------- ------ 238 ID/Request ID_S, CryptoProposals -> 240 ID/Response <- ID_P, CryptoSelection 242 Commit/Request Encr(Password, y_s) -> 244 Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P) 246 Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S -> 248 Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P 250 Where, in addition to the above terminology: 251 o Encr means encryption only, and Prot is encryption with integrity 252 protection. 253 o Ke is an encryption key, Ki an integrity-protection key. 254 Section 5 explains the various cryptographic values and how they are 255 derived. 257 As shown in the exchange above, the following information elements 258 have been added to the original protocol: identity values for both 259 protocol parties (ID_S, ID_P), negotiation of cryptographic 260 protocols, and signature fields to protect the integrity of the 261 negotiated parameters (Auth_S, Auth_P). In addition the shared 262 secret is not used directly. A few details have been omitted for 263 brevity. 265 4. Message Formats 267 EAP-EKE defined a small number of message types, each message 268 consisting of a header followed by a payload. This section defines 269 the header, several payload formats, as well as the format of 270 specific fields within the payloads. 272 As usual, all multi-octet strings MUST be laid out in network byte 273 order. 275 4.1. EAP-EKE Header 277 The EAP-EKE header consists of the standard EAP header (see Section 4 278 of [RFC3748]), followed an EAP-EKE exchange type. The header has the 279 following structure: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Code | Identifier | Length | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type | EKE-Exch | Data ... 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 2: EAP-EKE Header 291 The Code, Identifier, Length, and Type fields are all part of the EAP 292 header as defined in [RFC3748]. The Type field in the EAP header is 293 [TBD by IANA] for EAP-EKE version 1. [Note to RFC Editor: insert the 294 IANA-allocated value here.] 296 The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE 297 payload encapsulated in the Data field. This document defines the 298 following values for the EKE-Exch field: 299 o 0x00: Reserved 300 o 0x01: EAP-EKE-ID exchange 301 o 0x02: EAP-EKE-Commit exchange 302 o 0x03: EAP-EKE-Confirm exchange 303 o 0x04: EAP-EKE-Failure message 305 Further values of this EKE-Exch field are available via IANA 306 registration (Section 7.7). 308 4.2. EAP-EKE Payloads 310 EAP-EKE messages all contain the EAP-EKE header and information 311 encoded in a single payload, which differs for the different 312 exchanges. 314 4.2.1. The EAP-EKE-ID Payload 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | NumProposals | Reserved | Proposal ... 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 ... Proposal | IDType | Identity ... 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 3: EAP-EKE-ID Payload 326 The EAP-EKE-ID payload contains the following fields: 328 NumProposals: 330 The NumProposals field contains the number of Proposal fields 331 subsequently contained in the payload. In the EAP-EKE-ID/Request 332 the NumProposals field MUST NOT be set to zero (0) and in the EAP- 333 EKE-ID/Response message the NumProposals field MUST be set to one 334 (1). The offered proposals in the Request are listed contiguously 335 in priority order, most preferable first. The selected proposal 336 in the Response MUST be fully identical with one of the offered 337 proposals. 339 Proposal: 341 Each proposal consists of four one-octet fields, in this order: 343 Group Description: 345 This field's value is taken from the IANA registry for Diffie- 346 Hellman groups defined in Section 7.1. 348 Encryption: 350 This field's value is taken from the IANA registry for 351 encryption algorithms defined in Section 7.2. 353 PRF: 355 This field's value is taken from the IANA registry for pseudo 356 random functions defined in Section 7.3. 358 MAC: 360 This field's value is taken from the IANA registry for keyed 361 message digest algorithms defined in Section 7.4. 363 Reserved: 365 This field MUST be sent as zero, and MUST be ignored by the 366 recipient. 368 IDType: 370 Denotes the Identity Type. This is taken from the IANA registry 371 defined in Section 7.5. The server and the peer MAY use different 372 identity types. All implementations MUST be able to receive two 373 identity types: ID_NAI and ID_FQDN. 375 Identity: 377 The meaning of the Identity field depends on the values of the 378 Code and IDType fields. 379 * EAP-EKE-ID/Request: server ID 380 * EAP-EKE-ID/Response: peer ID 381 The length of the Identity field is computed from the Length field 382 in the EAP header. Specifically, its length is 383 eap_header_length - 9 - 4 * number_of_proposals. 384 This field, like all other fields in this specification, MUST be 385 octet-aligned. 387 4.2.2. The EAP-EKE-Commit Payload 389 This payload allows both parties send their encrypted ephemeral 390 public key, with the peer also including a Challenge. 392 In addition, a small amount of data can be included by the server 393 and/or the peer, and used for channel binding. This data is sent 394 here unprotected, but is verified later, when it is signed by the 395 Auth_S/Auth_P payloads of the EAP-EKE-Confirm exchange. 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | DHComponent_S/DHComponent_P ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 ~ ~ 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | PNonce_P ~ 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 ~ ~ 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | CBValue (zero or more occurrences) ~ 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 ~ ~ 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 4: EAP-EKE-Commit Payload 415 DHComponent_S/DHComponent_P: 417 This field contains the password-encrypted Diffie-Hellman public 418 key, see Section 5.1. Its size is determined by the group and the 419 encryption algorithm. 421 PNonce_P: 423 This field only appears in the response, and contains the 424 encrypted and integrity-protected challenge value sent by the 425 peer. The field's size is determined by the encryption and MAC 426 algorithms being used, since this protocol mandates a fixed nonce 427 size for a given choice of algorithms. See Section 5.2. 429 CBValue: 431 This structure MAY be included both in the request and in the 432 response, and MAY be repeated multiple times in a single payload. 433 See Section 4.5. Each structure contains its own length. The 434 field is neither encrypted nor integrity protected, instead it is 435 protected by the AUTH payloads in the Confirm exchange. 437 4.2.3. The EAP-EKE-Confirm Payload 439 Using this payload, both parties complete the authentication by 440 generating a shared temporary key, authenticating the entire 441 protocol, and generating key material for the EAP consumer protocol. 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | PNonce_PS/PNonce_S ~ 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 ~ ~ 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Auth_S/Auth_P ~ 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 ~ ~ 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 5: EAP-EKE-Confirm Payload 457 PNonce_PS/PNonce_S: 459 This field ("protected nonce") contains the encrypted and 460 integrity-protected response to the other party's challenge, see 461 Section 5.3 and Section 5.4. Similarly to the PNonce_P field, 462 this field's size is determined by the encryption and MAC 463 algorithms. 465 Auth_S/Auth_P: 467 This field signs the preceding messages, including the Identity 468 and the negotiated fields. This prevents various possible 469 attacks, such as algorithm downgrade attacks. See Section 5.3 and 470 Section 5.4. The size is determined by the pseudo-random function 471 negotiated. 473 4.2.4. The EAP-EKE-Failure Payload 475 The EAP-EKE-Failure payload format is defined as follows: 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Failure-Code | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 6: EAP-EKE-Failure Payload 485 The payload's size is always exactly 4 octets. 487 The following Failure-Code values are defined: 489 +------------+----------------+-------------------------------------+ 490 | Value | Name | Meaning | 491 +------------+----------------+-------------------------------------+ 492 | 0x00000000 | Reserved | | 493 | 0x00000001 | No Error | This code is used for failure | 494 | | | acknowledgement, see below. | 495 | 0x00000002 | Protocol Error | A failure to parse or understand a | 496 | | | protocol message or one of its | 497 | | | payloads. | 498 | 0x00000003 | Password Not | A password could not be located for | 499 | | Found | the identity presented by the other | 500 | | | protocol party, making | 501 | | | authentication impossible. For | 502 | | | security reasons, implementations | 503 | | | MAY choose to eliminate this error | 504 | | | code and return "Authentication | 505 | | | Failure" also in this case. | 506 | 0x00000004 | Authentication | Failure in the cryptographic | 507 | | Failure | computation most likely caused by | 508 | | | an incorrect password, or an | 509 | | | inappropriate identity type. | 510 | 0x00000005 | Authorization | While the password being used is | 511 | | Failure | correct, the user is not authorized | 512 | | | to connect. | 513 | 0x00000006 | No Proposal | The peer is unwilling to select any | 514 | | Chosen | of the cryptographic proposals | 515 | | | offered by the server. | 516 +------------+----------------+-------------------------------------+ 518 Additional values of this field are available via IANA registration, 519 see Section 7.8. 521 When the peer encounters an error situation, it MUST respond with 522 EAP-EKE-Failure. The server MUST reply with an EAP-Failure message 523 to end the exchange. 525 When the server encounters an error situation, it MUST respond with 526 EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message 527 containing a "No Error" failure code. Then the server MUST send an 528 EAP-Failure message to end the exchange. 530 4.3. Protected Fields 532 Several fields are encrypted and integrity-protected. They are 533 denoted Prot(...). Their general structure is as follows: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Initialization Vector (IV) (optional) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Encrypted Data ~ 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 ~ ~ 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 ~ | Random Padding | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Integrity Check Value (ICV) | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 7: Protected Field Structure 551 The protected field is a concatenation of three octet strings: 553 o An optional IV, required when the encryption algorithm/mode 554 necessitates it, e.g. for CBC encryption. The content and size of 555 this field are determined by the selected encryption algorithm. 556 In the case of CBC encryption, this field is a random octet string 557 having the same size as the algorithm's block size. 558 o The original data, followed if necessary by random padding. This 559 padding has the minimal length (possibly zero) required to 560 complete the length of the encrypted data to the encryption 561 algorithm's block size. The original data and the padding are 562 encrypted together. 563 o ICV, a cryptographic checksum (MAC) of the encrypted data, 564 including the padding. The checksum is computed over the 565 encrypted, rather than the plaintext, data. Its length is 566 determined by the MAC algorithm negotiated. 568 We note that because of the requirement for an explicit ICV, this 569 specification does not support authenticated encryption algorithms. 570 Such algorithms may be added by a future extension. 572 4.4. Encrypted Fields 574 Two fields are encrypted but not integrity protected. They are 575 denoted Encr(...). Their format is identical to a protected field 576 (Section 4.3), except that the Integrity Check Value is omitted. 578 4.5. Channel Binding Values 580 This protocol allows higher level protocols that are using it to 581 transmit opaque information between the peer and the server. This 582 information is integrity protected but not encrypted, and may be used 583 to ensure that protocol participants are identical at different 584 protocol layers. See Sec. 7.15 of [RFC3748] for more on the 585 rationale behind this facility. 587 EAP-EKE neither validates nor makes any use of the transmitted 588 information. The information MUST NOT be used by the consumer 589 protocol until it is verified in the EAP-EKE-Confirm exchange 590 (specifically, it is integrity protected by the Auth_S, Auth_P 591 payloads). Consequently, it MUST NOT be relied upon in case an error 592 occurs at the EAP-EKE level. 594 An unknown Channel Binding Value SHOULD be ignored by the recipient. 596 Some implementations may require certain values to be present, and 597 will abort the protocol if they are not. Such policy is out of scope 598 of the current protocol. 600 Each Channel Binding Value is encoded using a simple TLV structure: 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | CBType | Length | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Value ... 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 Figure 8: Channel Binding Value 612 CBType: 614 This is the Channel Binding Value's type. This document defines 615 the value 0x0000 as reserved. Other values are available for IANA 616 allocation, see Section 7.6. 618 Length: 620 This field is the total length in octets of the structure, 621 including the CBType and Length fields. 623 This facility should be used with care, since EAP-EKE does not 624 provide for message fragmentation. EAP-EKE is not a tunneled method, 625 and should not be used as a generic transport; specifically, 626 implementors should refrain from using the Channel Binding facility 627 to transmit posture information, in the sense of [RFC5209]. 629 5. Protocol Sequence 631 This section describes the sequence of messages for the Commit and 632 Confirm exchanges, and lists the cryptographic operations performed 633 by the server and the peer. 635 5.1. EAP-EKE-Commit/Request 637 The server computes 639 y_s = g ^ x_s (mod p), 641 where x_s is a randomly chosen number in the range 2 .. p-1. The 642 randomly chosen number is the ephemeral private key, and the 643 calculated value is the corresponding ephemeral public key. The 644 server and the peer MUST both use a fresh, random value for x_s and 645 the corresponding x_p on each run of the protocol. 647 The server transmits the encrypted field (Section 4.4) 649 DHComponent_S = Encr(kmac+(password), y_s). 651 See Section 6.1 for the kmac+ notation. The first output octets of 652 kmac+ are used as the encryption key for the negotiated encryption 653 algorithm, according to that algorithm's key length. 655 When using block ciphers, it may be necessary to pad y_s on the 656 right, to fit the encryption algorithm's block size. In such cases, 657 random padding MUST be used, and this randomness is critical to the 658 security of the protocol. Randomness recommendations can be found in 659 [RFC4086], and see also [NIST.800-90.2007] for additional 660 recommendations on cryptographic-level randomness. When decrypting 661 this field, the real length of y_s is determined according to the 662 negotiated Diffie Hellman group. 664 If the password needs to be stored on the server, it is RECOMMENDED 665 to store the randomized password value, i.e. kmac+(password, ...), as 666 a password-equivalent, rather than the cleartext password. See also 667 Section 8.5. 669 The input password string SHOULD be processed according to the rules 670 of the [RFC4013] profile of [RFC3454]. A password SHOULD be 671 considered a "stored string" per [RFC3454] and unassigned code points 672 are therefore prohibited. The output is the binary representation of 673 the processed UTF-8 [RFC3629] character string. Prohibited output 674 and unassigned codepoints encountered in SASLprep preprocessing 675 SHOULD cause a preprocessing failure and the output SHOULD NOT be 676 used. 678 5.2. EAP-EKE-Commit/Response 680 The peer computes 682 y_p = g ^ x_p (mod p) 684 and sends 686 DHComponent_P = Encr(kmac+(password), y_p) 688 formatted as an encrypted field (Section 4.4). 690 Both sides calculate 692 SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p)) 694 If an HMAC-based pseudo-random function is used, the first argument 695 to "prf" is a string of zero octets whose length is the output size 696 of the base hash algorithm, e.g. 20 octets for HMAC-SHA1; the result 697 is of the same length. If a non HMAC-based prf is used, the 698 algorithm should specify its preferred input length (to be used as 699 the length of the string of zeros). This extra application of the 700 pseudo-random function is the "extraction step" of [RFC5869]. Note 701 that the peer needs to compute the SharedSecret value before sending 702 out its response. 704 The encryption and integrity protection keys are computed: 706 Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P) 708 And the peer generates the Protected Nonce: 710 PNonce_P = Prot(Ke, Ki, Nonce_P), 712 where Nonce_P is a randomly generated binary string. The length of 713 Nonce_P MUST be the maximum of 16 octets, and half the key size of 714 the negotiated prf (rounded up to the next octet if necessary). The 715 peer sends this value as a protected field (Section 4.3), encrypted 716 using Ke and integrity protected using Ki with the negotiated 717 encryption and MAC algorithm. 719 The server MUST verify the correct integrity protection of the 720 received nonce, and MUST abort the protocol if it is incorrect, with 721 an "Authentication Failure" code. 723 5.3. EAP-EKE-Confirm/Request 725 The server constructs: 727 PNonce_PS = Prot(Ke, Ki, Nonce_P | Nonce_S), 729 as a protected field, where Nonce_S is a randomly generated string, 730 of the same size as Nonce_P. 732 It computes: 734 Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | 735 Nonce_S) 737 whose length is the preferred key length of the negotiated prf (see 738 Section 5.2). It then constructs: 740 Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE- 741 ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response). 743 The messages are included in full, starting with the EAP header, and 744 including any possible future extensions. 746 This construction of the Auth_S (and Auth_P) value implies that any 747 future extensions MUST NOT be added to the EAP-EKE-Confirm/Request or 748 EAP-EKE-Confirm/Response messages themselves, unless these extensions 749 are integrity-protected in some other manner. 751 The server now sends a message that contains the two payloads. 753 The peer MUST verify the correct integrity protection of the received 754 nonces and the correctness of the Auth_S value, and MUST abort the 755 protocol if either is incorrect, with an "Authentication Failure" 756 code. 758 5.4. EAP-EKE-Confirm/Response 760 The peer computes Ka, and sends: 762 PNonce_S = Prot(Ke, Ki, Nonce_S) 764 as a protected field, and 766 Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/ 767 Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response) 769 The server MUST verify the correct integrity protection of the 770 received nonce and the correctness of the Auth_P value, and MUST 771 abort the protocol if either is incorrect, with an "Authentication 772 Failure" code. 774 5.5. MSK and EMSK 776 Following the last message of the protocol, both sides compute and 777 export the shared keys, each 64 bytes in length: 779 MSK | EMSK = prf+(SharedSecret, "EAP-EKE Exported Keys" | ID_S | 780 ID_P | Nonce_P | Nonce_S) 782 When the RADIUS attributes specified in [RFC2548] are used to 783 transport keying material, then the first 32 bytes of the MSK 784 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE- 785 SEND-KEY. In this case, only 64 bytes of keying material (the MSK) 786 are used. 788 At this point, both protocol participants MUST discard all 789 intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke, 790 Ki, Ka, SharedSecret. Similarly, both parties MUST immediately 791 discard these values whenever the protocol terminates with a failure 792 code or as a result of timeout. 794 6. Cryptographic Details 796 6.1. Deriving a Key from the Password 798 The negotiated keyed MAC algorithm is used as a hash function, to 799 derive a bit string (albeit with low entropy) from the password. If 800 "kmac" is the negotiated algorithm, we define: 802 kmac+(P) = T1 | T2 | ... 804 where each Ti is an application of the keyed MAC with a fixed key: 806 T1 = kmac("S"+, P | 0x01) 807 T2 = kmac("S"+, T1 | P | 0x02) 808 T3 = kmac("S"+, T2 | P | 0x03) 810 The key is a string containing the octet ASCII "S" (0x53) repeated N 811 times, where N is the key length of the algorithm. Similarly to prf+ 812 (Section 6.2), The keys are taken from the output string without 813 regard to boundaries. 815 6.2. Generating Keying Material 817 Keying material is derived as the output of the negotiated pseudo- 818 random function (prf) algorithm. Since the amount of keying material 819 needed may be greater than the size of the output of the prf 820 algorithm, we will use the prf iteratively. We denote by "prf+" the 821 function that outputs a pseudo-random stream based on the inputs to a 822 prf as follows (where | indicates concatenation): 824 prf+ (K, S) = T1 | T2 | T3 | T4 | ... 826 where: 827 T1 = prf(K, S | 0x01) 828 T2 = prf(K, T1 | S | 0x02) 829 T3 = prf(K, T2 | S | 0x03) 830 T4 = prf(K, T3 | S | 0x04) 832 continuing as needed to compute all required keys. The keys are 833 taken from the output string without regard to boundaries (e.g., if 834 the required keys are a 256-bit Advanced Encryption Standard (AES) 835 key and a 160-bit HMAC key, and the prf function generates 160 bits, 836 the AES key will come from T1 and the beginning of T2, while the HMAC 837 key will come from the rest of T2 and the beginning of T3). 839 The constant concatenated to the end of each string feeding the prf 840 is a single octet. prf+ in this document is not defined beyond 255 841 times the size of the prf output. 843 6.3. Diffie-Hellman Groups 845 Many of the commonly used Diffie Hellman groups are inappropriate for 846 use in EKE. Most of these groups use a generator which is not a 847 primitive element of the group. As a result, an attacker running a 848 dictionary attack would be able to learn at least 1 bit of 849 information for each decrypted password guess. 851 Any MODP Diffie Hellman group defined for use in this protocol MUST 852 have the following properties, to ensure that it does not leak a 853 usable amount of information about the password: 854 1. The generator is a primitive element of the group. 855 2. The most significant 64 bits of the prime number are 1. 856 3. The group's order p is a "safe prime", i.e. (p-1)/2 is also 857 prime. 859 The last requirement is related to the strength of the Diffie Hellman 860 algorithm, rather than the password encryption. It also makes it 861 easy to verify that the generator is primitive. 863 Suitable groups are defined in Section 7.1. 865 6.4. Mandatory Algorithms 867 To facilitate interoperability, the following algorithms are 868 mandatory to implement: 870 o ENCR_AES128_CBC (encryption algorithm) 871 o PRF_HMAC_SHA1 (pseudo random function) 872 o MAC_HMAC_SHA1 (keyed message digest) 873 o DHGROUP_EKE_14 (DH-group) 875 7. IANA Considerations 877 IANA shall allocate (has allocated) the EAP method type TBD, for 878 "EAP-EKE Version 1". [Note to RFC Editor: insert the IANA-allocated 879 value here.] 881 This document requests that IANA create the registries described in 882 the following sub-sections. Values (other than private-use ones) can 883 be added to these registries per Specification Required [RFC5226], 884 with two exceptions: the Exchange and Failure Code registries can 885 only be extended per RFC Required [RFC5226]. 887 7.1. Diffie-Hellman Group Registry 889 This section defines an IANA registry for Diffie-Hellman groups. 891 This table defines the initial contents of this registry. The Value 892 column is used when negotiating the group. Additional groups may be 893 defined through IANA allocation. Any future specification that 894 defines a non-MODP group MUST specify its use within EAP-EKE and MUST 895 demonstrate the group's security in this context. 897 +----------------+--------+---------+-------------------------------+ 898 | Name | Length | Value | Description | 899 +----------------+--------+---------+-------------------------------+ 900 | Reserved | | 0 | | 901 | DHGROUP_EKE_2 | 1024 | 1 | The prime number of Group 2 | 902 | | | | [RFC4306], with the generator | 903 | | | | 5 (decimal) | 904 | DHGROUP_EKE_5 | 1536 | 2 | The prime number of Group 5 | 905 | | | | [RFC3526], g=31 | 906 | DHGROUP_EKE_14 | 2048 | 3 | The prime number of Group 14 | 907 | | | | [RFC3526], g=11 | 908 | DHGROUP_EKE_15 | 3072 | 4 | The prime number of Group 15 | 909 | | | | [RFC3526], g=5 | 910 | DHGROUP_EKE_16 | 4096 | 5 | The prime number of Group 16 | 911 | | | | [RFC3526], g=5 | 912 | Available for | | 6-127 | | 913 | allocation via | | | | 914 | IANA | | | | 915 | Reserved for | | 128-255 | | 916 | private use | | | | 917 +----------------+--------+---------+-------------------------------+ 919 7.2. Encryption Algorithm Registry 921 This section defines an IANA registry for encryption algorithms: 923 +-----------------+---------+-----------------------------------+ 924 | Name | Value | Definition | 925 +-----------------+---------+-----------------------------------+ 926 | Reserved | 0 | | 927 | ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode | 928 | | 2-127 | Available for allocation via IANA | 929 | | 128-255 | Reserved for private use | 930 +-----------------+---------+-----------------------------------+ 932 7.3. Pseudo Random Function Registry 934 This section defines an IANA registry for pseudo random function 935 algorithms: 937 +-------------------+---------+-------------------------------------+ 938 | Name | Value | Definition | 939 +-------------------+---------+-------------------------------------+ 940 | Reserved | 0 | | 941 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 942 | PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] | 943 | | 3-127 | Available for allocation via IANA | 944 | | 128-255 | Reserved for private use | 945 +-------------------+---------+-------------------------------------+ 947 A pseudo-random function takes two parameters K and S (the key and 948 input string respectively), and, to be usable in this context, must 949 be defined for all lengths of K between 0 and 65,535 bits 950 (inclusive). 952 7.4. Keyed Message Digest (MAC) Registry 954 This section defines an IANA registry for keyed message digest 955 algorithms: 957 +-------------------+---------+--------------+----------------------+ 958 | Name | Value | Key Length | Definition | 959 | | | (Octets) | | 960 +-------------------+---------+--------------+----------------------+ 961 | Reserved | 0 | | | 962 | MAC_HMAC_SHA1 | 1 | 20 | HMAC SHA-1, as | 963 | | | | defined in [RFC2104] | 964 | MAC_HMAC_SHA2_256 | 2 | 32 | HMAC SHA-2-256 | 965 | Reserved | 3-127 | | Available for | 966 | | | | allocation via IANA | 967 | Reserved | 128-255 | | Reserved for private | 968 | | | | use | 969 +-------------------+---------+--------------+----------------------+ 971 7.5. Identity Type Registry 973 In addition, an identity type registry is defined: 975 +-----------+---------+---------------------------------------------+ 976 | Name | Value | Definition | 977 +-----------+---------+---------------------------------------------+ 978 | Reserved | 0 | | 979 | ID_OPAQUE | 1 | An opaque octet string | 980 | ID_NAI | 2 | A Network Access Identifier, as defined in | 981 | | | [RFC4282] | 982 | ID_IPv4 | 3 | An IPv4 address, in binary format | 983 | ID_IPv6 | 4 | An IPv6 address, in binary format | 984 | ID_FQDN | 5 | A fully qualified domain name, see note | 985 | | | below | 986 | | 6-127 | Available for allocation via IANA | 987 | | 128-255 | Reserved for private use | 988 +-----------+---------+---------------------------------------------+ 990 An example of a ID_FQDN is "example.com". The string MUST NOT 991 contain any terminators (e.g., NULL, CR, etc.). All characters in 992 the ID_FQDN are ASCII; for an "internationalized domain name", the 993 syntax is as defined in [RFC5891], for example "xn--tmonesimerkki- 994 bfbb.example.net". 996 7.6. EAP-EKE Channel Binding Type Registry 998 This section defines an IANA registry for the Channel Binding Type 999 registry, a 16-bit long code. The value 0x0000 has been defined as 1000 Reserved. All other values up to and including 0xfeff are available 1001 for allocation via IANA. The remaining values up to and including 1002 0xffff are available for private use. 1004 7.7. Exchange Registry 1006 This section defines an IANA registry for the EAP-EKE Exchange 1007 registry, an 8-bit long code. Initial values are defined in 1008 Section 4.1. All values up to and including 0x7f are available for 1009 allocation via IANA. The remaining values up to and including 0xff 1010 are available for private use. 1012 7.8. Failure-Code Registry 1014 This section defines an IANA registry for the Failure-Code registry, 1015 a 32-bit long code. Initial values are defined in Section 4.2.4. 1016 All values up to and including 0xfeffffff are available for 1017 allocation via IANA. The remaining values up to and including 1018 0xffffffff are available for private use. 1020 8. Security Considerations 1022 Any protocol that claims to solve the problem of password- 1023 authenticated key exchange must be resistant to active, passive and 1024 dictionary attack and have the quality of forward secrecy. These 1025 characteristics are discussed further in the following paragraphs. 1027 Resistance to Passive Attack A passive attacker is one that merely 1028 relays messages back and forth between the peer and server, 1029 faithfully, and without modification. The contents of the 1030 messages are available for inspection, but that is all. To 1031 achieve resistance to passive attack, such an attacker must not be 1032 able to obtain any information about the password or anything 1033 about the resulting shared secret from watching repeated runs of 1034 the protocol. Even if a passive attacker is able to learn the 1035 password, she will not be able to determine any information about 1036 the resulting secret shared by the peer and server. 1037 Resistance to Active Attack An active attacker is able to modify, 1038 add, delete, and replay messages sent between protocol 1039 participants. For this protocol to be resistant to active attack, 1040 the attacker must not be able to obtain any information about the 1041 password or the shared secret by using any of its capabilities. 1042 In addition, the attacker must not be able to fool a protocol 1043 participant into thinking that the protocol completed 1044 successfully. It is always possible for an active attacker to 1045 deny delivery of a message critical in completing the exchange. 1046 This is no different than dropping all messages and is not an 1047 attack against the protocol. 1049 Resistance to Dictionary Attack For this protocol to be resistant to 1050 dictionary attack any advantage an adversary can gain must be 1051 directly related to the number of interactions she makes with an 1052 honest protocol participant and not through computation. The 1053 adversary will not be able to obtain any information about the 1054 password except whether a single guess from a single protocol run 1055 is correct or incorrect. 1056 Forward Secrecy Compromise of the password must not provide any 1057 information about the secrets generated by earlier runs of the 1058 protocol. 1060 [RFC3748] requires that documents describing new EAP methods clearly 1061 articulate the security properties of the method. In addition, for 1062 use with wireless LANs, [RFC4017] mandates and recommends several of 1063 these. The claims are: 1064 1. Mechanism: password. 1065 2. Claims: 1066 * Mutual authentication: the peer and server both authenticate 1067 each other by proving possession of a shared password. This 1068 is REQUIRED by [RFC4017]. 1069 * Forward secrecy: compromise of the password does not reveal 1070 the secret keys (MSK and EMSK) from earlier runs of the 1071 protocol. 1072 * Replay protection: an attacker is unable to replay messages 1073 from a previous exchange either to learn the password or a key 1074 derived by the exchange. Similarly the attacker is unable to 1075 induce either the peer or server to believe the exchange has 1076 successfully completed when it hasn't. 1077 * Key derivation: a shared secret is derived by performing a 1078 group operation in a finite cyclic group (e.g. exponentiation) 1079 using secret data contributed by both the peer and server. An 1080 MSK and EMSK are derived from that shared secret. This is 1081 REQUIRED by [RFC4017]. 1082 * Dictionary attack resistance: an attacker can only make one 1083 password guess per active attack, and the protocol is designed 1084 so that the attacker does not gain any confirmation of her 1085 guess by observing the decrypted Y_x value (see below). The 1086 advantage she can gain is through interaction not through 1087 computation. This is REQUIRED by [RFC4017]. 1088 * Session independence: this protocol is resistant to active and 1089 passive attacks and does not enable compromise of subsequent 1090 or prior MSKs or EMSKs from either passive or active attacks. 1091 * Denial of Service resistance: it is possible for an attacker 1092 to cause a server to allocate state and consume CPU. Such an 1093 attack is gated, though, by the requirement that the attacker 1094 first obtain connectivity through a lower-layer protocol (e.g. 1095 802.11 authentication followed by 802.11 association, or 802.3 1096 "link-up") and respond to two EAP messages: the EAP-ID/Request 1097 and the EAP-EKE-ID/Request. 1098 * Man-in-the-Middle Attack resistance: this exchange is 1099 resistant to active attack, which is a requirement for 1100 launching a man-in-the-middle attack. This is REQUIRED by 1101 [RFC4017]. 1102 * Shared state equivalence: upon completion of EAP-EKE the peer 1103 and server both agree on the MSK and EMSK values. The peer 1104 has authenticated the server based on the Server_ID and the 1105 server has authenticated the peer based on the Peer_ID. This 1106 is due to the fact that Peer_ID, Server_ID, and the generated 1107 shared secret are all combined to make the authentication 1108 element which must be shared between the peer and server for 1109 the exchange to complete. This is REQUIRED by [RFC4017]. 1110 * Fragmentation: this protocol does not define a technique for 1111 fragmentation and reassembly. 1112 * Resistance to "Denning-Sacco" attack: learning keys 1113 distributed from an earlier run of the protocol, such as the 1114 MSK or EMSK, will not help an adversary learn the password. 1115 3. Key strength: the strength of the resulting key depends on the 1116 finite cyclic group chosen. Sufficient key strength is REQUIRED 1117 by [RFC4017]. Clearly, "sufficient" strength varies over time, 1118 depending on computation power assumed to be available to 1119 potential attackers. 1120 4. Key hierarchy: MSKs and EMSKs are derived from the secret values 1121 generated during the protocol run, using a negotiated pseudo- 1122 random function. 1123 5. Vulnerabilities (note that none of these are REQUIRED by 1124 [RFC4017]): 1125 * Protected ciphersuite negotiation: the ciphersuite proposal 1126 made by the server is not protected from tampering by an 1127 active attacker. However if a proposal was modified by an 1128 active attacker it would result in a failure to confirm the 1129 message sent by the other party, since the proposal is bound 1130 by each side into its Confirm message, and the protocol would 1131 fail as a result. Note that this assumes that none of the 1132 proposed ciphersuites enables an attacker to perform real-time 1133 cryptanalysis. 1134 * Confidentiality: none of the messages sent in this protocol 1135 are encrypted, though many of the protocol fields are. 1136 * Integrity protection: protocol messages are not directly 1137 integrity protected; however the ID and Commit exchanges are 1138 integrity protected through the Auth payloads exchanged in the 1139 Confirm exchange. 1140 * Channel binding: this protocol enables the exchange of 1141 integrity-protected channel information that can be compared 1142 with values communicated via out-of-band mechanisms. 1144 * Fast reconnect: this protocol does not provide a fast 1145 reconnect capability. 1146 * Cryptographic binding: this protocol is not a tunneled EAP 1147 method and therefore has no cryptographic information to bind. 1148 * Identity protection: the EAP-EKE-ID exchange is not protected. 1149 An attacker will see the server's identity in the EAP-EKE-ID/ 1150 Request and see the peer's identity in EAP-EKE-ID/ Response. 1151 See also Section 8.4. 1153 8.1. Cryptographic Analysis 1155 When analyzing the Commit exchange, it should be noted that the base 1156 security assumptions are different from "normal" cryptology. 1157 Normally, we assume that the key has strong security properties, and 1158 that the data may have little. Here, we assume that the key has weak 1159 security properties (the attacker may have a list of possible keys), 1160 and hence we need to ensure that the data has strong properties 1161 (indistinguishable from random). This difference may mean that 1162 conventional wisdom in cryptology might not apply in this case. This 1163 also imposes severe constraints on the protocol, e.g. the mandatory 1164 use of random padding, and the need to define specific finite groups. 1166 8.2. Diffie Hellman Group Considerations 1168 It is fundamental to the dictionary attack resistance that the Diffie 1169 Hellman public values y_s and y_p are indistinguishable from a random 1170 string. If this condition is not met, then a passive attacker can do 1171 trial-decryption of the encrypted DHComponent_P or DHComponent_S 1172 values based on a password guess, and if they decrypt to a value 1173 which is not a valid public value, they know that the password guess 1174 was incorrect. 1176 For MODP groups, Section 6.3 gives conditions on the group to make 1177 sure that this criterion is met. For other groups (for example, 1178 Elliptic Curve groups), some other means of ensuring this must be 1179 employed. The standard way of expressing Elliptic Curve public 1180 values does not meet this criterion, as a valid Elliptic Curve X 1181 coordinate can be distinguished from a random string with probability 1182 approximately 0.5. 1184 A future document might introduce a group representation, and/or a 1185 slight modification of the password encryption scheme, so that 1186 Elliptic Curve groups can be accommodated. [BR02] presents several 1187 alternative solutions for this problem. 1189 8.3. Resistance to Active Attacks 1191 An attacker, impersonating either the peer or the server, can always 1192 try to enumerate all possible passwords, for example by using a 1193 dictionary. To counter this likely attack vector, both peer and 1194 server MUST implement rate-limiting mechanisms. We note that locking 1195 out the other party after a small number of tries would create a 1196 trivial denial of service opportunity. 1198 8.4. Identity Protection, Anonymity and Pseudonymity 1200 By default, the EAP-EKE-ID exchange is unprotected, and an 1201 eavesdropper can observe both parties' identities. A future 1202 extension of this protocol may support anonymity, e.g. by allowing 1203 the server to send a temporary identity to the peer at the end of the 1204 exchange, so that the peer can use that identity in subsequent 1205 exchanges. 1207 EAP-EKE differs in this respect from tunneled methods, which 1208 typically provide unconditional identity protection to the peer by 1209 encrypting the identity exchange, but reveal information in the 1210 server certificate. It is possible to use EAP-EKE as the inner 1211 method in a tunneled EAP method in order to achieve this level of 1212 identity protection. 1214 8.5. Password Processing and Long Term Storage 1216 This document recommends to store a password-equivalent (a hash of 1217 the password) instead of the cleartext password. While this solution 1218 provides a measure of security, there are also tradeoffs related to 1219 algorithm agility: 1220 o Each stored password must identify the hash function that was used 1221 to compute the stored value. 1222 o Complex deployments and migration scenarios might necessitate 1223 multiple stored passwords, one per each algorithm. 1224 o Changing the algorithm can require in some cases that the users 1225 manually change their passwords. 1227 The reader is referred to [RFC3629] for security considerations 1228 related to the parsing and processing of UTF-8 strings. 1230 9. Acknowledgements 1232 Much of this document was unashamedly picked from [RFC5931] and 1233 [I-D.ietf-pppext-eap-srp-03], and we would like to acknowledge the 1234 authors of these documents: Dan Harkins, Glen Zorn, James Carlson, 1235 Bernard Aboba and Henry Haverinen. We would like to thank David 1236 Jacobson, Steve Bellovin, Russ Housley, Brian Weis, Dan Harkins and 1237 Alexey Melnikov for their useful comments. Lidar Herooty and Idan 1238 Ofrat implemented this protocol and helped us improve it by asking 1239 the right questions, and we would like to thank them both. 1241 10. References 1243 10.1. Normative References 1245 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1246 Hashing for Message Authentication", RFC 2104, 1247 February 1997. 1249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1250 Requirement Levels", BCP 14, RFC 2119, March 1997. 1252 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1253 RFC 2548, March 1999. 1255 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1256 Internationalized Strings ("stringprep")", RFC 3454, 1257 December 2002. 1259 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1260 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1261 RFC 3526, May 2003. 1263 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1264 10646", STD 63, RFC 3629, November 2003. 1266 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1267 Levkowetz, "Extensible Authentication Protocol (EAP)", 1268 RFC 3748, June 2004. 1270 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1271 and Passwords", RFC 4013, February 2005. 1273 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1274 Network Access Identifier", RFC 4282, December 2005. 1276 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1277 RFC 4306, December 2005. 1279 [RFC5891] Klensin, J., "Internationalized Domain Names in 1280 Applications (IDNA): Protocol", RFC 5891, August 2010. 1282 [SHA] National Institute of Standards and Technology, U.S. 1284 Department of Commerce, "Secure Hash Standard", NIST FIPS 1285 180-3, October 2008. 1287 10.2. Informative References 1289 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 1290 Password-Based Protocols Secure Against Dictionary 1291 Attacks", Proc. IEEE Symp. on Research in Security and 1292 Privacy , May 1992. 1294 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 1295 Exchange: A Password-Based Protocol Secure against 1296 Dictionary Attacks and Password File Compromise", Proc. 1297 1st ACM Conference on Computer and Communication 1298 Security , 1993. 1300 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 1301 Password Authenticated Key Exchange Using Diffie-Hellman", 1302 Advances in Cryptology, EUROCRYPT 2000 , 2000. 1304 [BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite 1305 Domains", Proc. of the RSA Cryptographer's Track (RSA CT 1306 '02), LNCS 2271 , 2002. 1308 [I-D.ietf-pppext-eap-srp-03] 1309 Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 1310 Authentication Protocol", draft-ietf-pppext-eap-srp-03 1311 (work in progress), July 2001. 1313 [JAB96] Jablon, D., "Strong Password-Only Authenticated Key 1314 Exchange", ACM Computer Communications Review Volume 1, 1315 Issue 5, October 1996. 1317 [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary 1318 Attacks Without Encrypting Public Keys", Proc. of the 1319 Security Protocols Workshop LNCS 1361, 1997. 1321 [NIST.800-90.2007] 1322 National Institute of Standards and Technology, 1323 "Recommendation for Random Number Generation Using 1324 Deterministic Random Bit Generators (Revised)", NIST SP 1325 800-90, March 2007. 1327 [PA97] Patel, S., "Number Theoretic Attacks On Secure Password 1328 Schemes", Proceedings of the 1997 IEEE Symposium on 1329 Security and Privacy , 1997. 1331 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1332 Authentication Protocol (EAP) Method Requirements for 1333 Wireless LANs", RFC 4017, March 2005. 1335 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1336 Requirements for Security", BCP 106, RFC 4086, June 2005. 1338 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1339 Tardo, "Network Endpoint Assessment (NEA): Overview and 1340 Requirements", RFC 5209, June 2008. 1342 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1343 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1344 May 2008. 1346 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1347 Key Derivation Function (HKDF)", RFC 5869, May 2010. 1349 [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication 1350 Protocol (EAP) Authentication Using Only a Password", 1351 RFC 5931, August 2010. 1353 Appendix A. Change Log 1355 Note to RFC Editor: please remove this section before publication. 1357 A.1. -08 1359 Implemented Alexey Melnikov's "discuss" comments. 1361 A.2. -07 1363 Implemented IETF LC review comments, primarily from Dan Harkins. 1364 Changed the derivation of an encryption key from the plaintext 1365 password. Changed the derivation of EMSK for efficiency. Clarified 1366 the ranges of IANA allocations, and added a key length column for 1367 keyed MAC algorithms. Renamed some protocol fields for clarity. 1369 A.3. -06 1371 Lots of small changes based on Russ's AD review. Clarified 1372 processing of Channel Binding Values, some of which is currently out 1373 of scope. Made a small but non-backward compatible change to the 1374 generation of Ke, Ki. Changed the rules for nonce lengths (however 1375 this results in no change for the currently specified algorithms). 1377 A.4. -05 1379 Revised the Anonymity section. Added more MODP groups. Note that 1380 DHGROUP_EKE_14 was renumbered. 1382 A.5. -04 1384 Changed the intended document status to Informational. 1386 A.6. -03 1388 Added a provision for channel binding. 1390 Clarified the notation for protected vs. encrypted fields. 1392 Explained how pseudonymity can be provided. 1394 Implementations need not implement the "password not found" failure. 1396 Eliminated the Design Options appendix. 1398 A.7. -02 1400 Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes. 1402 Eliminated protected failures: they are too rarely useful. 1404 Added the "extraction step" of HKDF. 1406 Removed the check for g^x != 0, since this can never happen for an 1407 honest peer, and otherwise requires an active password-guessing 1408 attacker, against which other protections are required. Added a 1409 related subsection about rate limiting. 1411 Added an Exchange Registry to the IANA Considerations. 1413 A general structure for protected (and merely encrypted) fields, 1414 which clarifies the protocol and also adds explicit integrity 1415 protection for the encrypted nonces, as recommended by [BM92]. 1417 A.8. -01 1419 Revised following comments raised on the CFRG mailing list. In 1420 particular, added security considerations and a new DH group 1421 definition, to resolve the vulnerability in case the group's 1422 generator is not a primitive element. 1424 A.9. -00 1426 Initial version. 1428 Authors' Addresses 1430 Yaron Sheffer 1431 Independent 1433 Email: yaronf.ietf@gmail.com 1435 Glen Zorn 1436 Network Zen 1437 1310 East Thomas Street 1438 #306 1439 Seattle, Washington 98102 1440 USA 1442 Phone: +1 (206) 377-9035 1443 Email: gwz@net-zen.net 1445 Hannes Tschofenig 1446 Nokia Siemens Networks 1447 Linnoitustie 6 1448 Espoo 02600 1449 Finland 1451 Phone: +358 (50) 4871445 1452 Email: Hannes.Tschofenig@gmx.net 1453 URI: http://www.tschofenig.priv.at 1455 Scott Fluhrer 1456 Cisco Systems. 1457 1414 Massachusetts Ave. 1458 Boxborough, MA 01719 1459 USA 1461 Email: sfluhrer@cisco.com