idnits 2.17.1 draft-sheffer-emu-eap-eke-09.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 (October 10, 2010) is 4940 days in the past. Is this intentional? 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 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: April 13, 2011 Network Zen 6 H. Tschofenig 7 Nokia Siemens Networks 8 S. Fluhrer 9 Cisco 10 October 10, 2010 12 An EAP Authentication Method Based on the EKE Protocol 13 draft-sheffer-emu-eap-eke-09 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 April 13, 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 . . . . . . . . . . . . . . . . . 19 91 5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 19 92 6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 19 93 6.1. Generating Keying Material . . . . . . . . . . . . . . . . 19 94 6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 20 95 6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 20 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 27 99 8.2. Diffie Hellman Group Considerations . . . . . . . . . . . 27 100 8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 28 101 8.4. Identity Protection, Anonymity and Pseudonymity . . . . . 28 102 8.5. Password Processing and Long Term Storage . . . . . . . . 28 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 106 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 107 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 110 1. Introduction 112 The predominant access method for the Internet today is that of a 113 human using a username and password to authenticate to a computer 114 enforcing access control. Proof of knowledge of the password 115 authenticates the human to the computer. 117 Typically, these passwords are not stored on a user's computer for 118 security reasons and must be entered each time the human desires 119 network access. Therefore, the passwords must be ones that can be 120 repeatedly entered by a human with a low probability of error. They 121 will likely not possess high entropy and it may be assumed that an 122 adversary with access to a dictionary will have the ability to guess 123 a user's password. It is therefore desirable to have a robust 124 authentication method that is secure even when used with a weak 125 password in the presence of a strong adversary. 127 EAP-EKE is an EAP method [RFC3748] that addresses the problem of 128 password-based authenticated key exchange, using a possibly weak 129 password for authentication and to derive an authenticated and 130 cryptographically strong shared secret. This problem was first 131 described by Bellovin and Merritt in [BM92] and [BM93]. 132 Subsequently, a number of other solution approaches have been 133 proposed, for example [JAB96], [LUC97], [BMP00], and others. 135 This proposal is based on the original Encrypted Key Exchange (EKE) 136 proposal, as described in [BM92]. Some of the variants of the 137 original EKE have been attacked, see e.g. [PA97], and improvements 138 have been proposed. None of these subsequent improvements have been 139 incorporated into the current protocol. However, we have used only 140 the subset of [BM92] (namely the variant described in Section 3.1 of 141 the paper) which has withstood the test of time and is believed 142 secure as of this writing. 144 2. Terminology 146 This document uses Encr(Ke, ...) to denote encrypted information, and 147 Prot(Ke, Ki, ...) to denote encrypted and integrity protected 148 information. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. Protocol 156 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.1. Message Flows 165 A successful run of EAP-EKE consists of three message exchanges: an 166 Identity exchange, a Commit exchange and a Confirm exchange. This is 167 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 (note that the second 176 message of the Commit exchange already plays an essential part in 177 this liveness proof). 179 +--------+ +--------+ 180 | | EAP-EKE-ID/Request | | 181 | EAP |<------------------------------------| EAP | 182 | peer | | server | 183 | (P) | EAP-EKE-ID/Response | (S) | 184 | |------------------------------------>| | 185 | | | | 186 | | EAP-EKE-Commit/Request | | 187 | |<------------------------------------| | 188 | | | | 189 | | EAP-EKE-Commit/Response | | 190 | |------------------------------------>| | 191 | | | | 192 | | EAP-EKE-Confirm/Request | | 193 | |<------------------------------------| | 194 | | | | 195 | | EAP-EKE-Confirm/Response | | 196 | |------------------------------------>| | 197 | | | | 198 | | EAP-Success | | 199 | |<------------------------------------| | 200 +--------+ +--------+ 202 Figure 1: A Successful EAP-EKE Exchange 204 Schematically, the original exchange as described in [BM92] (and with 205 the roles reversed) is: 207 Server Peer 208 ------ ---- 210 Encr(Password, y_s) -> 212 <- Encr(Password, y_p), Encr(SharedSecret, Nonce_P) 214 Encr(SharedSecret, Nonce_S | Nonce_P) -> 216 <- Encr(SharedSecret, Nonce_S) 218 Where: 219 o Password is a typically short string, shared between the server 220 and the peer. In other words, the same password is used to 221 authenticate the server to the peer, and vice versa. 223 o y_s and y_p are the server's and respectively, the peer's, 224 ephemeral public key, i.e. y_s = g ^ x_s (mod p) and y_p = g ^ x_p 225 (mod p). 226 o Nonce_S, Nonce_P are random strings generated by the server and 227 the peer as cryptographic challenges. 228 o SharedSecret is the secret created by the Diffie-Hellman 229 algorithm, namely SharedSecret = g^(x_s * x_p) (mod p). This 230 value is calculated by the server as: SharedSecret = y_p ^ x_s 231 (mod p), and by the peer as: SharedSecret = y_s ^ x_p (mod p). 232 The current protocol extends the basic cryptographic protocol, and 233 the regular successful exchange becomes: 235 Message Server Peer 236 --------- -------- ------ 237 ID/Request ID_S, CryptoProposals -> 239 ID/Response <- ID_P, CryptoSelection 241 Commit/Request Encr(Password, y_s) -> 243 Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P) 245 Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S -> 247 Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P 249 Where, in addition to the above terminology: 250 o Encr means encryption only, and Prot is encryption with integrity 251 protection. 252 o Ke is an encryption key, Ki an integrity-protection key. 253 Section 5 explains the various cryptographic values and how they are 254 derived. 256 As shown in the exchange above, the following information elements 257 have been added to the original protocol: identity values for both 258 protocol parties (ID_S, ID_P), negotiation of cryptographic 259 protocols, and signature fields to protect the integrity of the 260 negotiated parameters (Auth_S, Auth_P). In addition the shared 261 secret is not used directly. A few details have been omitted for 262 brevity. 264 4. Message Formats 266 EAP-EKE defined a small number of message types, each message 267 consisting of a header followed by a payload. This section defines 268 the header, several payload formats, as well as the format of 269 specific fields within the payloads. 271 As usual, all multi-octet strings MUST be laid out in network byte 272 order. 274 4.1. EAP-EKE Header 276 The EAP-EKE header consists of the standard EAP header (see Section 4 277 of [RFC3748]), followed an EAP-EKE exchange type. The header has the 278 following structure: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Code | Identifier | Length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | EKE-Exch | Data ... 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 2: EAP-EKE Header 290 The Code, Identifier, Length, and Type fields are all part of the EAP 291 header as defined in [RFC3748]. The Type field in the EAP header is 292 [TBD by IANA] for EAP-EKE version 1. [Note to RFC Editor: insert the 293 IANA-allocated value here.] 295 The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE 296 payload encapsulated in the Data field. This document defines the 297 following values for the EKE-Exch field: 298 o 0x00: Reserved 299 o 0x01: EAP-EKE-ID exchange 300 o 0x02: EAP-EKE-Commit exchange 301 o 0x03: EAP-EKE-Confirm exchange 302 o 0x04: EAP-EKE-Failure message 304 Further values of this EKE-Exch field are available via IANA 305 registration (Section 7.7). 307 4.2. EAP-EKE Payloads 309 EAP-EKE messages all contain the EAP-EKE header and information 310 encoded in a single payload, which differs for the different 311 exchanges. 313 4.2.1. The EAP-EKE-ID Payload 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | NumProposals | Reserved | Proposal ... 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 ... Proposal | IDType | Identity ... 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 3: EAP-EKE-ID Payload 325 The EAP-EKE-ID payload contains the following fields: 327 NumProposals: 329 The NumProposals field contains the number of Proposal fields 330 subsequently contained in the payload. In the EAP-EKE-ID/Request 331 the NumProposals field MUST NOT be set to zero (0) and in the EAP- 332 EKE-ID/Response message the NumProposals field MUST be set to one 333 (1). The offered proposals in the Request are listed contiguously 334 in priority order, most preferable first. The selected proposal 335 in the Response MUST be fully identical with one of the offered 336 proposals. 338 Proposal: 340 Each proposal consists of four one-octet fields, in this order: 342 Group Description: 344 This field's value is taken from the IANA registry for Diffie- 345 Hellman groups defined in Section 7.1. 347 Encryption: 349 This field's value is taken from the IANA registry for 350 encryption algorithms defined in Section 7.2. 352 PRF: 354 This field's value is taken from the IANA registry for pseudo 355 random functions defined in Section 7.3. 357 MAC: 359 This field's value is taken from the IANA registry for keyed 360 message digest algorithms defined in Section 7.4. 362 Reserved: 364 This field MUST be sent as zero, and MUST be ignored by the 365 recipient. 367 IDType: 369 Denotes the Identity Type. This is taken from the IANA registry 370 defined in Section 7.5. The server and the peer MAY use different 371 identity types. All implementations MUST be able to receive two 372 identity types: ID_NAI and ID_FQDN. 374 Identity: 376 The meaning of the Identity field depends on the values of the 377 Code and IDType fields. 378 * EAP-EKE-ID/Request: server ID 379 * EAP-EKE-ID/Response: peer ID 380 The length of the Identity field is computed from the Length field 381 in the EAP header. Specifically, its length is 382 eap_header_length - 9 - 4 * number_of_proposals. 383 This field, like all other fields in this specification, MUST be 384 octet-aligned. 386 4.2.2. The EAP-EKE-Commit Payload 388 This payload allows both parties send their encrypted ephemeral 389 public key, with the peer also including a Challenge. 391 In addition, a small amount of data can be included by the server 392 and/or the peer, and used for channel binding. This data is sent 393 here unprotected, but is verified later, when it is signed by the 394 Auth_S/Auth_P payloads of the EAP-EKE-Confirm exchange. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | DHComponent_S/DHComponent_P ~ 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 ~ ~ 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | PNonce_P ~ 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 ~ ~ 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | CBValue (zero or more occurrences) ~ 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 ~ ~ 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Figure 4: EAP-EKE-Commit Payload 414 DHComponent_S/DHComponent_P: 416 This field contains the password-encrypted Diffie-Hellman public 417 key, see Section 5.1. Its size is determined by the group and the 418 encryption algorithm. 420 PNonce_P: 422 This field only appears in the response, and contains the 423 encrypted and integrity-protected challenge value sent by the 424 peer. The field's size is determined by the encryption and MAC 425 algorithms being used, since this protocol mandates a fixed nonce 426 size for a given choice of algorithms. See Section 5.2. 428 CBValue: 430 This structure MAY be included both in the request and in the 431 response, and MAY be repeated multiple times in a single payload. 432 See Section 4.5. Each structure contains its own length. The 433 field is neither encrypted nor integrity protected, instead it is 434 protected by the AUTH payloads in the Confirm exchange. 436 4.2.3. The EAP-EKE-Confirm Payload 438 Using this payload, both parties complete the authentication by 439 generating a shared temporary key, authenticating the entire 440 protocol, and generating key material for the EAP consumer protocol. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | PNonce_PS/PNonce_S ~ 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 ~ ~ 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Auth_S/Auth_P ~ 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 ~ ~ 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 5: EAP-EKE-Confirm Payload 456 PNonce_PS/PNonce_S: 458 This field ("protected nonce") contains the encrypted and 459 integrity-protected response to the other party's challenge, see 460 Section 5.3 and Section 5.4. Similarly to the PNonce_P field, 461 this field's size is determined by the encryption and MAC 462 algorithms. 464 Auth_S/Auth_P: 466 This field signs the preceding messages, including the Identity 467 and the negotiated fields. This prevents various possible 468 attacks, such as algorithm downgrade attacks. See Section 5.3 and 469 Section 5.4. The size is determined by the pseudo-random function 470 negotiated. 472 4.2.4. The EAP-EKE-Failure Payload 474 The EAP-EKE-Failure payload format is defined as follows: 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Failure-Code | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 6: EAP-EKE-Failure Payload 484 The payload's size is always exactly 4 octets. 486 The following Failure-Code values are defined: 488 +------------+----------------+-------------------------------------+ 489 | Value | Name | Meaning | 490 +------------+----------------+-------------------------------------+ 491 | 0x00000000 | Reserved | | 492 | 0x00000001 | No Error | This code is used for failure | 493 | | | acknowledgement, see below. | 494 | 0x00000002 | Protocol Error | A failure to parse or understand a | 495 | | | protocol message or one of its | 496 | | | payloads. | 497 | 0x00000003 | Password Not | A password could not be located for | 498 | | Found | the identity presented by the other | 499 | | | protocol party, making | 500 | | | authentication impossible. For | 501 | | | security reasons, implementations | 502 | | | MAY choose to eliminate this error | 503 | | | code and return "Authentication | 504 | | | Failure" also in this case. | 505 | 0x00000004 | Authentication | Failure in the cryptographic | 506 | | Failure | computation most likely caused by | 507 | | | an incorrect password, or an | 508 | | | inappropriate identity type. | 509 | 0x00000005 | Authorization | While the password being used is | 510 | | Failure | correct, the user is not authorized | 511 | | | to connect. | 512 | 0x00000006 | No Proposal | The peer is unwilling to select any | 513 | | Chosen | of the cryptographic proposals | 514 | | | offered by the server. | 515 +------------+----------------+-------------------------------------+ 517 Additional values of this field are available via IANA registration, 518 see Section 7.8. 520 When the peer encounters an error situation, it MUST respond with 521 EAP-EKE-Failure. The server MUST reply with an EAP-Failure message 522 to end the exchange. 524 When the server encounters an error situation, it MUST respond with 525 EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message 526 containing a "No Error" failure code. Then the server MUST send an 527 EAP-Failure message to end the exchange. 529 4.3. Protected Fields 531 Several fields are encrypted and integrity-protected. They are 532 denoted Prot(...). Their general structure is as follows: 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Initialization Vector (IV) (optional) | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Encrypted Data ~ 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 ~ ~ 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 ~ | Random Padding | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Integrity Check Value (ICV) | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 7: Protected Field Structure 550 The protected field is a concatenation of three octet strings: 552 o An optional IV, required when the encryption algorithm/mode 553 necessitates it, e.g. for CBC encryption. The content and size of 554 this field are determined by the selected encryption algorithm. 555 In the case of CBC encryption, this field is a random octet string 556 having the same size as the algorithm's block size. 557 o The original data, followed if necessary by random padding. This 558 padding has the minimal length (possibly zero) required to 559 complete the length of the encrypted data to the encryption 560 algorithm's block size. The original data and the padding are 561 encrypted together. 562 o ICV, a cryptographic checksum (MAC) of the encrypted data, 563 including the padding. The checksum is computed over the 564 encrypted, rather than the plaintext, data. Its length is 565 determined by the MAC algorithm negotiated. 567 We note that because of the requirement for an explicit ICV, this 568 specification does not support authenticated encryption algorithms. 569 Such algorithms may be added by a future extension. 571 4.4. Encrypted Fields 573 Two fields are encrypted but not integrity protected. They are 574 denoted Encr(...). Their format is identical to a protected field 575 (Section 4.3), except that the Integrity Check Value is omitted. 577 4.5. Channel Binding Values 579 This protocol allows higher level protocols that are using it to 580 transmit opaque information between the peer and the server. This 581 information is integrity protected but not encrypted, and may be used 582 to ensure that protocol participants are identical at different 583 protocol layers. See Sec. 7.15 of [RFC3748] for more on the 584 rationale behind this facility. 586 EAP-EKE neither validates nor makes any use of the transmitted 587 information. The information MUST NOT be used by the consumer 588 protocol until it is verified in the EAP-EKE-Confirm exchange 589 (specifically, it is integrity protected by the Auth_S, Auth_P 590 payloads). Consequently, it MUST NOT be relied upon in case an error 591 occurs at the EAP-EKE level. 593 An unknown Channel Binding Value SHOULD be ignored by the recipient. 595 Some implementations may require certain values to be present, and 596 will abort the protocol if they are not. Such policy is out of scope 597 of the current protocol. 599 Each Channel Binding Value is encoded using a simple TLV structure: 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | CBType | Length | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Value ... 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Figure 8: Channel Binding Value 611 CBType: 613 This is the Channel Binding Value's type. This document defines 614 the value 0x0000 as reserved. Other values are available for IANA 615 allocation, see Section 7.6. 617 Length: 619 This field is the total length in octets of the structure, 620 including the CBType and Length fields. 622 This facility should be used with care, since EAP-EKE does not 623 provide for message fragmentation. EAP-EKE is not a tunneled method, 624 and should not be used as a generic transport; specifically, 625 implementors should refrain from using the Channel Binding facility 626 to transmit posture information, in the sense of [RFC5209]. 628 5. Protocol Sequence 630 This section describes the sequence of messages for the Commit and 631 Confirm exchanges, and lists the cryptographic operations performed 632 by the server and the peer. 634 5.1. EAP-EKE-Commit/Request 636 The server computes 638 y_s = g ^ x_s (mod p), 640 where x_s is a randomly chosen number in the range 2 .. p-1. The 641 randomly chosen number is the ephemeral private key, and the 642 calculated value is the corresponding ephemeral public key. The 643 server and the peer MUST both use a fresh, random value for x_s and 644 the corresponding x_p on each run of the protocol. 646 The server computes and transmits the encrypted field (Section 4.4) 648 temp = prf(0+, password) 649 key = prf+(temp, ID_S | ID_P) 650 DHComponent_S = Encr(key, y_s). 652 See Section 6.1 for the prf+ notation. The first argument to "prf" 653 is a string of zero octets whose length is the output size of the 654 base hash algorithm, e.g. 20 octets for HMAC-SHA1; the result is of 655 the same length. The first output octets of prf+ are used as the 656 encryption key for the negotiated encryption algorithm, according to 657 that algorithm's key length. 659 Since the PRF function is required to be an application of the HMAC 660 operator to a hash function, the above construction implements HKDF 661 as defined in [RFC5869]. 663 When using block ciphers, it may be necessary to pad y_s on the 664 right, to fit the encryption algorithm's block size. In such cases, 665 random padding MUST be used, and this randomness is critical to the 666 security of the protocol. Randomness recommendations can be found in 667 [RFC4086], and see also [NIST.800-90.2007] for additional 668 recommendations on cryptographic-level randomness. When decrypting 669 this field, the real length of y_s is determined according to the 670 negotiated Diffie Hellman group. 672 If the password needs to be stored on the server, it is RECOMMENDED 673 to store a randomized password value as a password-equivalent, rather 674 than the cleartext password. We note that implementations may choose 675 the output of either of the two steps of the password derivation. 676 Using the output of the second step, where the password is salted by 677 the identity values, is more secure; however it may create an 678 operational issue if identities are likely to change. See also 679 Section 8.5. 681 The input password string SHOULD be processed according to the rules 682 of the [RFC4013] profile of [RFC3454]. A password SHOULD be 683 considered a "stored string" per [RFC3454] and unassigned code points 684 are therefore prohibited. The output is the binary representation of 685 the processed UTF-8 [RFC3629] character string. Prohibited output 686 and unassigned codepoints encountered in SASLprep preprocessing 687 SHOULD cause a preprocessing failure and the output SHOULD NOT be 688 used. 690 5.2. EAP-EKE-Commit/Response 692 The peer computes 694 y_p = g ^ x_p (mod p) 696 computes and sends 698 temp = prf(0+, password) 699 key = prf+(temp, ID_S | ID_P) 700 DHComponent_P = Encr(key, y_p) 702 formatted as an encrypted field (Section 4.4). 704 Both sides calculate 706 SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p)) 708 The first argument to "prf" is a string of zero octets whose length 709 is the output size of the base hash algorithm, e.g. 20 octets for 710 HMAC-SHA1; the result is of the same length. This extra application 711 of the pseudo-random function is the "extraction step" of [RFC5869]. 712 Note that the peer needs to compute the SharedSecret value before 713 sending out its response. 715 The encryption and integrity protection keys are computed: 717 Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P) 719 And the peer generates the Protected Nonce: 721 PNonce_P = Prot(Ke, Ki, Nonce_P), 723 where Nonce_P is a randomly generated binary string. The length of 724 Nonce_P MUST be the maximum of 16 octets, and half the key size of 725 the negotiated prf (rounded up to the next octet if necessary). The 726 peer sends this value as a protected field (Section 4.3), encrypted 727 using Ke and integrity protected using Ki with the negotiated 728 encryption and MAC algorithm. 730 The server MUST verify the correct integrity protection of the 731 received nonce, and MUST abort the protocol if it is incorrect, with 732 an "Authentication Failure" code. 734 5.3. EAP-EKE-Confirm/Request 736 The server constructs: 738 PNonce_PS = Prot(Ke, Ki, Nonce_P | Nonce_S), 740 as a protected field, where Nonce_S is a randomly generated string, 741 of the same size as Nonce_P. 743 It computes: 745 Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | 746 Nonce_S) 748 whose length is the preferred key length of the negotiated prf (see 749 Section 5.2). It then constructs: 751 Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE- 752 ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response). 754 The messages are included in full, starting with the EAP header, and 755 including any possible future extensions. 757 This construction of the Auth_S (and Auth_P) value implies that any 758 future extensions MUST NOT be added to the EAP-EKE-Confirm/Request or 759 EAP-EKE-Confirm/Response messages themselves, unless these extensions 760 are integrity-protected in some other manner. 762 The server now sends a message that contains the two payloads. 764 The peer MUST verify the correct integrity protection of the received 765 nonces and the correctness of the Auth_S value, and MUST abort the 766 protocol if either is incorrect, with an "Authentication Failure" 767 code. 769 5.4. EAP-EKE-Confirm/Response 771 The peer computes Ka, and sends: 773 PNonce_S = Prot(Ke, Ki, Nonce_S) 775 as a protected field, and 777 Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/ 778 Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response) 780 The server MUST verify the correct integrity protection of the 781 received nonce and the correctness of the Auth_P value, and MUST 782 abort the protocol if either is incorrect, with an "Authentication 783 Failure" code. 785 5.5. MSK and EMSK 787 Following the last message of the protocol, both sides compute and 788 export the shared keys, each 64 bytes in length: 790 MSK | EMSK = prf+(SharedSecret, "EAP-EKE Exported Keys" | ID_S | 791 ID_P | Nonce_P | Nonce_S) 793 When the RADIUS attributes specified in [RFC2548] are used to 794 transport keying material, then the first 32 bytes of the MSK 795 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE- 796 SEND-KEY. In this case, only 64 bytes of keying material (the MSK) 797 are used. 799 At this point, both protocol participants MUST discard all 800 intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke, 801 Ki, Ka, SharedSecret. Similarly, both parties MUST immediately 802 discard these values whenever the protocol terminates with a failure 803 code or as a result of timeout. 805 6. Cryptographic Details 807 6.1. Generating Keying Material 809 Keying material is derived as the output of the negotiated pseudo- 810 random function (prf) algorithm. Since the amount of keying material 811 needed may be greater than the size of the output of the prf 812 algorithm, we will use the prf iteratively. We denote by "prf+" the 813 function that outputs a pseudo-random stream based on the inputs to a 814 prf as follows (where | indicates concatenation): 816 prf+ (K, S) = T1 | T2 | T3 | T4 | ... 818 where: 819 T1 = prf(K, S | 0x01) 820 T2 = prf(K, T1 | S | 0x02) 821 T3 = prf(K, T2 | S | 0x03) 822 T4 = prf(K, T3 | S | 0x04) 824 continuing as needed to compute all required keys. The keys are 825 taken from the output string without regard to boundaries (e.g., if 826 the required keys are a 256-bit Advanced Encryption Standard (AES) 827 key and a 160-bit HMAC key, and the prf function generates 160 bits, 828 the AES key will come from T1 and the beginning of T2, while the HMAC 829 key will come from the rest of T2 and the beginning of T3). 831 The constant concatenated to the end of each string feeding the prf 832 is a single octet. prf+ in this document is not defined beyond 255 833 times the size of the prf output. 835 6.2. Diffie-Hellman Groups 837 Many of the commonly used Diffie Hellman groups are inappropriate for 838 use in EKE. Most of these groups use a generator which is not a 839 primitive element of the group. As a result, an attacker running a 840 dictionary attack would be able to learn at least 1 bit of 841 information for each decrypted password guess. 843 Any MODP Diffie Hellman group defined for use in this protocol MUST 844 have the following properties, to ensure that it does not leak a 845 usable amount of information about the password: 846 1. The generator is a primitive element of the group. 847 2. The most significant 64 bits of the prime number are 1. 848 3. The group's order p is a "safe prime", i.e. (p-1)/2 is also 849 prime. 851 The last requirement is related to the strength of the Diffie Hellman 852 algorithm, rather than the password encryption. It also makes it 853 easy to verify that the generator is primitive. 855 Suitable groups are defined in Section 7.1. 857 6.3. Mandatory Algorithms 859 To facilitate interoperability, the following algorithms are 860 mandatory to implement: 862 o ENCR_AES128_CBC (encryption algorithm) 863 o PRF_HMAC_SHA1 (pseudo random function) 864 o MAC_HMAC_SHA1 (keyed message digest) 865 o DHGROUP_EKE_14 (DH-group) 867 7. IANA Considerations 869 IANA shall allocate (has allocated) the EAP method type TBD from the 870 range 1-191, for "EAP-EKE Version 1". [Note to RFC Editor: insert 871 the IANA-allocated value here.] 873 This document requests that IANA create the registries described in 874 the following sub-sections. Values (other than private-use ones) can 875 be added to these registries per Specification Required [RFC5226], 876 with two exceptions: the Exchange and Failure Code registries can 877 only be extended per RFC Required [RFC5226]. 879 7.1. Diffie-Hellman Group Registry 881 This section defines an IANA registry for Diffie-Hellman groups. 883 This table defines the initial contents of this registry. The Value 884 column is used when negotiating the group. Additional groups may be 885 defined through IANA allocation. Any future specification that 886 defines a non-MODP group MUST specify its use within EAP-EKE and MUST 887 demonstrate the group's security in this context. 889 +-----------------+---------+---------------------------------------+ 890 | Name | Value | Description | 891 +-----------------+---------+---------------------------------------+ 892 | Reserved | 0 | | 893 | DHGROUP_EKE_2 | 1 | The prime number of the 1024-bit | 894 | | | Group 2 [RFC5996], with the generator | 895 | | | 5 (decimal) | 896 | DHGROUP_EKE_5 | 2 | The prime number of the 1536-bit | 897 | | | Group 5 [RFC3526], g=31 | 898 | DHGROUP_EKE_14 | 3 | The prime number of the 2048-bit | 899 | | | Group 14 [RFC3526], g=11 | 900 | DHGROUP_EKE_15 | 4 | The prime number of the 3072-bit | 901 | | | Group 15 [RFC3526], g=5 | 902 | DHGROUP_EKE_16 | 5 | The prime number of the 4096-bit | 903 | | | Group 16 [RFC3526], g=5 | 904 | Available for | 6-127 | | 905 | allocation via | | | 906 | IANA | | | 907 | Reserved for | 128-255 | | 908 | private use | | | 909 +-----------------+---------+---------------------------------------+ 911 7.2. Encryption Algorithm Registry 913 This section defines an IANA registry for encryption algorithms: 915 +-----------------+---------+-----------------------------------+ 916 | Name | Value | Definition | 917 +-----------------+---------+-----------------------------------+ 918 | Reserved | 0 | | 919 | ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode | 920 | | 2-127 | Available for allocation via IANA | 921 | | 128-255 | Reserved for private use | 922 +-----------------+---------+-----------------------------------+ 924 7.3. Pseudo Random Function Registry 926 This section defines an IANA registry for pseudo random function 927 algorithms: 929 +-------------------+---------+-------------------------------------+ 930 | Name | Value | Definition | 931 +-------------------+---------+-------------------------------------+ 932 | Reserved | 0 | | 933 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 934 | PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] | 935 | | 3-127 | Available for allocation via IANA | 936 | | 128-255 | Reserved for private use | 937 +-------------------+---------+-------------------------------------+ 939 A pseudo-random function takes two parameters K and S (the key and 940 input string respectively), and, to be usable in this protocol, must 941 be defined for all lengths of K between 0 and 65,535 bits 942 (inclusive). 944 Any future pseudo-random function MUST be based on the HMAC 945 construct, since the security of HKDF is only known for such 946 functions. 948 7.4. Keyed Message Digest (MAC) Registry 950 This section defines an IANA registry for keyed message digest 951 algorithms: 953 +-------------------+---------+--------------+----------------------+ 954 | Name | Value | Key Length | Definition | 955 | | | (Octets) | | 956 +-------------------+---------+--------------+----------------------+ 957 | Reserved | 0 | | | 958 | MAC_HMAC_SHA1 | 1 | 20 | HMAC SHA-1, as | 959 | | | | defined in [RFC2104] | 960 | MAC_HMAC_SHA2_256 | 2 | 32 | HMAC SHA-2-256 | 961 | Reserved | 3-127 | | Available for | 962 | | | | allocation via IANA | 963 | Reserved | 128-255 | | Reserved for private | 964 | | | | use | 965 +-------------------+---------+--------------+----------------------+ 967 7.5. Identity Type Registry 969 In addition, an identity type registry is defined: 971 +-----------+---------+---------------------------------------------+ 972 | Name | Value | Definition | 973 +-----------+---------+---------------------------------------------+ 974 | Reserved | 0 | | 975 | ID_OPAQUE | 1 | An opaque octet string | 976 | ID_NAI | 2 | A Network Access Identifier, as defined in | 977 | | | [RFC4282] | 978 | ID_IPv4 | 3 | An IPv4 address, in binary format | 979 | ID_IPv6 | 4 | An IPv6 address, in binary format | 980 | ID_FQDN | 5 | A fully qualified domain name, see note | 981 | | | below | 982 | ID_DN | 6 | An LDAP Distinguished Name formatted as a | 983 | | | string, as defined in [RFC4514] | 984 | | 7-127 | Available for allocation via IANA | 985 | | 128-255 | Reserved for private use | 986 +-----------+---------+---------------------------------------------+ 988 An example of an ID_FQDN is "example.com". The string MUST NOT 989 contain any terminators (e.g., NULL, CR, etc.). All characters in 990 the ID_FQDN are ASCII; for an "internationalized domain name", the 991 syntax is as defined in [RFC5891], for example "xn--tmonesimerkki- 992 bfbb.example.net". 994 7.6. EAP-EKE Channel Binding Type Registry 996 This section defines an IANA registry for the Channel Binding Type 997 registry, a 16-bit long code. The value 0x0000 has been defined as 998 Reserved. All other values up to and including 0xfeff are available 999 for allocation via IANA. The remaining values up to and including 1000 0xffff are available for private use. 1002 7.7. Exchange Registry 1004 This section defines an IANA registry for the EAP-EKE Exchange 1005 registry, an 8-bit long code. Initial values are defined in 1006 Section 4.1. All values up to and including 0x7f are available for 1007 allocation via IANA. The remaining values up to and including 0xff 1008 are available for private use. 1010 7.8. Failure-Code Registry 1012 This section defines an IANA registry for the Failure-Code registry, 1013 a 32-bit long code. Initial values are defined in Section 4.2.4. 1014 All values up to and including 0xfeffffff are available for 1015 allocation via IANA. The remaining values up to and including 1016 0xffffffff are available for private use. 1018 8. Security Considerations 1020 Any protocol that claims to solve the problem of password- 1021 authenticated key exchange must be resistant to active, passive and 1022 dictionary attack and have the quality of forward secrecy. These 1023 characteristics are discussed further in the following paragraphs. 1025 Resistance to Passive Attack A passive attacker is one that merely 1026 relays messages back and forth between the peer and server, 1027 faithfully, and without modification. The contents of the 1028 messages are available for inspection, but that is all. To 1029 achieve resistance to passive attack, such an attacker must not be 1030 able to obtain any information about the password or anything 1031 about the resulting shared secret from watching repeated runs of 1032 the protocol. Even if a passive attacker is able to learn the 1033 password, she will not be able to determine any information about 1034 the resulting secret shared by the peer and server. 1035 Resistance to Active Attack An active attacker is able to modify, 1036 add, delete, and replay messages sent between protocol 1037 participants. For this protocol to be resistant to active attack, 1038 the attacker must not be able to obtain any information about the 1039 password or the shared secret by using any of its capabilities. 1040 In addition, the attacker must not be able to fool a protocol 1041 participant into thinking that the protocol completed 1042 successfully. It is always possible for an active attacker to 1043 deny delivery of a message critical in completing the exchange. 1044 This is no different than dropping all messages and is not an 1045 attack against the protocol. 1047 Resistance to Dictionary Attack For this protocol to be resistant to 1048 dictionary attack any advantage an adversary can gain must be 1049 directly related to the number of interactions she makes with an 1050 honest protocol participant and not through computation. The 1051 adversary will not be able to obtain any information about the 1052 password except whether a single guess from a single protocol run 1053 is correct or incorrect. 1054 Forward Secrecy Compromise of the password must not provide any 1055 information about the secrets generated by earlier runs of the 1056 protocol. 1058 [RFC3748] requires that documents describing new EAP methods clearly 1059 articulate the security properties of the method. In addition, for 1060 use with wireless LANs, [RFC4017] mandates and recommends several of 1061 these. The claims are: 1062 1. Mechanism: password. 1063 2. Claims: 1064 * Mutual authentication: the peer and server both authenticate 1065 each other by proving possession of a shared password. This 1066 is REQUIRED by [RFC4017]. 1067 * Forward secrecy: compromise of the password does not reveal 1068 the secret keys (MSK and EMSK) from earlier runs of the 1069 protocol. 1070 * Replay protection: an attacker is unable to replay messages 1071 from a previous exchange either to learn the password or a key 1072 derived by the exchange. Similarly the attacker is unable to 1073 induce either the peer or server to believe the exchange has 1074 successfully completed when it hasn't. 1075 * Key derivation: a shared secret is derived by performing a 1076 group operation in a finite cyclic group (e.g. exponentiation) 1077 using secret data contributed by both the peer and server. An 1078 MSK and EMSK are derived from that shared secret. This is 1079 REQUIRED by [RFC4017]. 1080 * Dictionary attack resistance: an attacker can only make one 1081 password guess per active attack, and the protocol is designed 1082 so that the attacker does not gain any confirmation of her 1083 guess by observing the decrypted Y_x value (see below). The 1084 advantage she can gain is through interaction not through 1085 computation. This is REQUIRED by [RFC4017]. 1086 * Session independence: this protocol is resistant to active and 1087 passive attacks and does not enable compromise of subsequent 1088 or prior MSKs or EMSKs from either passive or active attacks. 1089 * Denial of Service resistance: it is possible for an attacker 1090 to cause a server to allocate state and consume CPU. Such an 1091 attack is gated, though, by the requirement that the attacker 1092 first obtain connectivity through a lower-layer protocol (e.g. 1093 802.11 authentication followed by 802.11 association, or 802.3 1094 "link-up") and respond to two EAP messages: the EAP-ID/Request 1095 and the EAP-EKE-ID/Request. 1096 * Man-in-the-Middle Attack resistance: this exchange is 1097 resistant to active attack, which is a requirement for 1098 launching a man-in-the-middle attack. This is REQUIRED by 1099 [RFC4017]. 1100 * Shared state equivalence: upon completion of EAP-EKE the peer 1101 and server both agree on the MSK and EMSK values. The peer 1102 has authenticated the server based on the Server_ID and the 1103 server has authenticated the peer based on the Peer_ID. This 1104 is due to the fact that Peer_ID, Server_ID, and the generated 1105 shared secret are all combined to make the authentication 1106 element which must be shared between the peer and server for 1107 the exchange to complete. This is REQUIRED by [RFC4017]. 1108 * Fragmentation: this protocol does not define a technique for 1109 fragmentation and reassembly. 1110 * Resistance to "Denning-Sacco" attack: learning keys 1111 distributed from an earlier run of the protocol, such as the 1112 MSK or EMSK, will not help an adversary learn the password. 1113 3. Key strength: the strength of the resulting key depends on the 1114 finite cyclic group chosen. Sufficient key strength is REQUIRED 1115 by [RFC4017]. Clearly, "sufficient" strength varies over time, 1116 depending on computation power assumed to be available to 1117 potential attackers. 1118 4. Key hierarchy: MSKs and EMSKs are derived from the secret values 1119 generated during the protocol run, using a negotiated pseudo- 1120 random function. 1121 5. Vulnerabilities (note that none of these are REQUIRED by 1122 [RFC4017]): 1123 * Protected ciphersuite negotiation: the ciphersuite proposal 1124 made by the server is not protected from tampering by an 1125 active attacker. However if a proposal was modified by an 1126 active attacker it would result in a failure to confirm the 1127 message sent by the other party, since the proposal is bound 1128 by each side into its Confirm message, and the protocol would 1129 fail as a result. Note that this assumes that none of the 1130 proposed ciphersuites enables an attacker to perform real-time 1131 cryptanalysis. 1132 * Confidentiality: none of the messages sent in this protocol 1133 are encrypted, though many of the protocol fields are. 1134 * Integrity protection: protocol messages are not directly 1135 integrity protected; however the ID and Commit exchanges are 1136 integrity protected through the Auth payloads exchanged in the 1137 Confirm exchange. 1138 * Channel binding: this protocol enables the exchange of 1139 integrity-protected channel information that can be compared 1140 with values communicated via out-of-band mechanisms. 1142 * Fast reconnect: this protocol does not provide a fast 1143 reconnect capability. 1144 * Cryptographic binding: this protocol is not a tunneled EAP 1145 method and therefore has no cryptographic information to bind. 1146 * Identity protection: the EAP-EKE-ID exchange is not protected. 1147 An attacker will see the server's identity in the EAP-EKE-ID/ 1148 Request and see the peer's identity in EAP-EKE-ID/ Response. 1149 See also Section 8.4. 1151 8.1. Cryptographic Analysis 1153 When analyzing the Commit exchange, it should be noted that the base 1154 security assumptions are different from "normal" cryptology. 1155 Normally, we assume that the key has strong security properties, and 1156 that the data may have little. Here, we assume that the key has weak 1157 security properties (the attacker may have a list of possible keys), 1158 and hence we need to ensure that the data has strong properties 1159 (indistinguishable from random). This difference may mean that 1160 conventional wisdom in cryptology might not apply in this case. This 1161 also imposes severe constraints on the protocol, e.g. the mandatory 1162 use of random padding, and the need to define specific finite groups. 1164 8.2. Diffie Hellman Group Considerations 1166 It is fundamental to the dictionary attack resistance that the Diffie 1167 Hellman public values y_s and y_p are indistinguishable from a random 1168 string. If this condition is not met, then a passive attacker can do 1169 trial-decryption of the encrypted DHComponent_P or DHComponent_S 1170 values based on a password guess, and if they decrypt to a value 1171 which is not a valid public value, they know that the password guess 1172 was incorrect. 1174 For MODP groups, Section 6.2 gives conditions on the group to make 1175 sure that this criterion is met. For other groups (for example, 1176 Elliptic Curve groups), some other means of ensuring this must be 1177 employed. The standard way of expressing Elliptic Curve public 1178 values does not meet this criterion, as a valid Elliptic Curve X 1179 coordinate can be distinguished from a random string with probability 1180 approximately 0.5. 1182 A future document might introduce a group representation, and/or a 1183 slight modification of the password encryption scheme, so that 1184 Elliptic Curve groups can be accommodated. [BR02] presents several 1185 alternative solutions for this problem. 1187 8.3. Resistance to Active Attacks 1189 An attacker, impersonating either the peer or the server, can always 1190 try to enumerate all possible passwords, for example by using a 1191 dictionary. To counter this likely attack vector, both peer and 1192 server MUST implement rate-limiting mechanisms. We note that locking 1193 out the other party after a small number of tries would create a 1194 trivial denial of service opportunity. 1196 8.4. Identity Protection, Anonymity and Pseudonymity 1198 By default, the EAP-EKE-ID exchange is unprotected, and an 1199 eavesdropper can observe both parties' identities. A future 1200 extension of this protocol may support anonymity, e.g. by allowing 1201 the server to send a temporary identity to the peer at the end of the 1202 exchange, so that the peer can use that identity in subsequent 1203 exchanges. 1205 EAP-EKE differs in this respect from tunneled methods, which 1206 typically provide unconditional identity protection to the peer by 1207 encrypting the identity exchange, but reveal information in the 1208 server certificate. It is possible to use EAP-EKE as the inner 1209 method in a tunneled EAP method in order to achieve this level of 1210 identity protection. 1212 8.5. Password Processing and Long Term Storage 1214 This document recommends to store a password-equivalent (a hash of 1215 the password) instead of the cleartext password. While this solution 1216 provides a measure of security, there are also tradeoffs related to 1217 algorithm agility: 1218 o Each stored password must identify the hash function that was used 1219 to compute the stored value. 1220 o Complex deployments and migration scenarios might necessitate 1221 multiple stored passwords, one per each algorithm. 1222 o Changing the algorithm can require in some cases that the users 1223 manually change their passwords. 1225 The reader is referred to [RFC3629] for security considerations 1226 related to the parsing and processing of UTF-8 strings. 1228 9. Acknowledgements 1230 Much of this document was unashamedly picked from [RFC5931] and 1231 [I-D.ietf-pppext-eap-srp-03], and we would like to acknowledge the 1232 authors of these documents: Dan Harkins, Glen Zorn, James Carlson, 1233 Bernard Aboba and Henry Haverinen. We would like to thank David 1234 Jacobson, Steve Bellovin, Russ Housley, Brian Weis, Dan Harkins and 1235 Alexey Melnikov for their useful comments. Lidar Herooty and Idan 1236 Ofrat implemented this protocol and helped us improve it by asking 1237 the right questions, and we would like to thank them both. 1239 10. References 1241 10.1. Normative References 1243 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1244 Hashing for Message Authentication", RFC 2104, 1245 February 1997. 1247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1248 Requirement Levels", BCP 14, RFC 2119, March 1997. 1250 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1251 RFC 2548, March 1999. 1253 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1254 Internationalized Strings ("stringprep")", RFC 3454, 1255 December 2002. 1257 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1258 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1259 RFC 3526, May 2003. 1261 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1262 10646", STD 63, RFC 3629, November 2003. 1264 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1265 Levkowetz, "Extensible Authentication Protocol (EAP)", 1266 RFC 3748, June 2004. 1268 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1269 and Passwords", RFC 4013, February 2005. 1271 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1272 Network Access Identifier", RFC 4282, December 2005. 1274 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 1275 (LDAP): String Representation of Distinguished Names", 1276 RFC 4514, June 2006. 1278 [RFC5891] Klensin, J., "Internationalized Domain Names in 1279 Applications (IDNA): Protocol", RFC 5891, August 2010. 1281 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1282 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1283 RFC 5996, September 2010. 1285 [SHA] National Institute of Standards and Technology, U.S. 1286 Department of Commerce, "Secure Hash Standard", NIST FIPS 1287 180-3, October 2008. 1289 10.2. Informative References 1291 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 1292 Password-Based Protocols Secure Against Dictionary 1293 Attacks", Proc. IEEE Symp. on Research in Security and 1294 Privacy , May 1992. 1296 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 1297 Exchange: A Password-Based Protocol Secure against 1298 Dictionary Attacks and Password File Compromise", Proc. 1299 1st ACM Conference on Computer and Communication 1300 Security , 1993. 1302 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 1303 Password Authenticated Key Exchange Using Diffie-Hellman", 1304 Advances in Cryptology, EUROCRYPT 2000 , 2000. 1306 [BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite 1307 Domains", Proc. of the RSA Cryptographer's Track (RSA CT 1308 '02), LNCS 2271 , 2002. 1310 [I-D.ietf-pppext-eap-srp-03] 1311 Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 1312 Authentication Protocol", draft-ietf-pppext-eap-srp-03 1313 (work in progress), July 2001. 1315 [JAB96] Jablon, D., "Strong Password-Only Authenticated Key 1316 Exchange", ACM Computer Communications Review Volume 1, 1317 Issue 5, October 1996. 1319 [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary 1320 Attacks Without Encrypting Public Keys", Proc. of the 1321 Security Protocols Workshop LNCS 1361, 1997. 1323 [NIST.800-90.2007] 1324 National Institute of Standards and Technology, 1325 "Recommendation for Random Number Generation Using 1326 Deterministic Random Bit Generators (Revised)", NIST SP 1327 800-90, March 2007. 1329 [PA97] Patel, S., "Number Theoretic Attacks On Secure Password 1330 Schemes", Proceedings of the 1997 IEEE Symposium on 1331 Security and Privacy , 1997. 1333 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1334 Authentication Protocol (EAP) Method Requirements for 1335 Wireless LANs", RFC 4017, March 2005. 1337 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1338 Requirements for Security", BCP 106, RFC 4086, June 2005. 1340 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1341 Tardo, "Network Endpoint Assessment (NEA): Overview and 1342 Requirements", RFC 5209, June 2008. 1344 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1345 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1346 May 2008. 1348 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1349 Key Derivation Function (HKDF)", RFC 5869, May 2010. 1351 [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication 1352 Protocol (EAP) Authentication Using Only a Password", 1353 RFC 5931, August 2010. 1355 Appendix A. Change Log 1357 Note to RFC Editor: please remove this section before publication. 1359 A.1. -09 1361 Implemented all remaining "discuss" comments. This includes two 1362 changes to the IANA Considerations: clarification of the range where 1363 the EAP method number is to be allocated, and removal of the Length 1364 column from the DH Group registry. 1366 Eliminated the "kmac+" construction, reusing the prf+ notation 1367 instead. Key derivation from the password uses HKDF, and the PRF 1368 function is required to be an HMAC (thanks Dan and Brian!). 1370 Added an identity type for LDAP DNs. 1372 A.2. -08 1374 Implemented Alexey Melnikov's "discuss" comments. 1376 A.3. -07 1378 Implemented IETF LC review comments, primarily from Dan Harkins. 1379 Changed the derivation of an encryption key from the plaintext 1380 password. Changed the derivation of EMSK for efficiency. Clarified 1381 the ranges of IANA allocations, and added a key length column for 1382 keyed MAC algorithms. Renamed some protocol fields for clarity. 1384 A.4. -06 1386 Lots of small changes based on Russ's AD review. Clarified 1387 processing of Channel Binding Values, some of which is currently out 1388 of scope. Made a small but non-backward compatible change to the 1389 generation of Ke, Ki. Changed the rules for nonce lengths (however 1390 this results in no change for the currently specified algorithms). 1392 A.5. -05 1394 Revised the Anonymity section. Added more MODP groups. Note that 1395 DHGROUP_EKE_14 was renumbered. 1397 A.6. -04 1399 Changed the intended document status to Informational. 1401 A.7. -03 1403 Added a provision for channel binding. 1405 Clarified the notation for protected vs. encrypted fields. 1407 Explained how pseudonymity can be provided. 1409 Implementations need not implement the "password not found" failure. 1411 Eliminated the Design Options appendix. 1413 A.8. -02 1415 Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes. 1417 Eliminated protected failures: they are too rarely useful. 1419 Added the "extraction step" of HKDF. 1421 Removed the check for g^x != 0, since this can never happen for an 1422 honest peer, and otherwise requires an active password-guessing 1423 attacker, against which other protections are required. Added a 1424 related subsection about rate limiting. 1426 Added an Exchange Registry to the IANA Considerations. 1428 A general structure for protected (and merely encrypted) fields, 1429 which clarifies the protocol and also adds explicit integrity 1430 protection for the encrypted nonces, as recommended by [BM92]. 1432 A.9. -01 1434 Revised following comments raised on the CFRG mailing list. In 1435 particular, added security considerations and a new DH group 1436 definition, to resolve the vulnerability in case the group's 1437 generator is not a primitive element. 1439 A.10. -00 1441 Initial version. 1443 Authors' Addresses 1445 Yaron Sheffer 1446 Independent 1448 Email: yaronf.ietf@gmail.com 1450 Glen Zorn 1451 Network Zen 1452 227/358 Thanon Sanphawut 1453 Bang Na, Bangkok 10260 1454 Thailand 1456 Phone: +66 (0) 87-040-4617 1457 Email: gwz@net-zen.net 1459 Hannes Tschofenig 1460 Nokia Siemens Networks 1461 Linnoitustie 6 1462 Espoo 02600 1463 Finland 1465 Phone: +358 (50) 4871445 1466 Email: Hannes.Tschofenig@gmx.net 1467 URI: http://www.tschofenig.priv.at 1468 Scott Fluhrer 1469 Cisco Systems. 1470 1414 Massachusetts Ave. 1471 Boxborough, MA 01719 1472 USA 1474 Email: sfluhrer@cisco.com