idnits 2.17.1 draft-sheffer-emu-eap-eke-06.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 date (April 21, 2010) is 5090 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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: October 23, 2010 Network Zen 6 H. Tschofenig 7 Nokia Siemens Networks 8 S. Fluhrer 9 Cisco 10 April 21, 2010 12 An EAP Authentication Method Based on the EKE Protocol 13 draft-sheffer-emu-eap-eke-06 15 Abstract 17 The Extensible Authentication Protocol (EAP) describes a framework 18 that allows the use of multiple authentication mechanisms. This 19 document defines an authentication mechanism for EAP called EAP-EKE, 20 based on the Encrypted Key Exchange (EKE) protocol. This method 21 provides mutual authentication through the use of a short, easy to 22 remember password. Compared with other common authentication 23 methods, EAP-EKE is not susceptible to dictionary attacks. Neither 24 does it require the availability of public-key certificates. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). 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 October 23, 2010. 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 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 8 67 4.2.1. The EAP-EKE-ID Payload . . . . . . . . . . . . . . . . 8 68 4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 9 69 4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11 70 4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 11 71 4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13 72 4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14 73 4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14 74 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 15 75 5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 15 76 5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 16 77 5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 17 78 5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 17 79 5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 18 80 6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 18 81 6.1. Generating Keying Material . . . . . . . . . . . . . . . . 18 82 6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 19 83 6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 19 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 25 87 8.2. Diffie Hellman Group Considerations . . . . . . . . . . . 25 88 8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 26 89 8.4. Identity Protection, Anonymity and Pseudonymity . . . . . 26 90 8.5. Long Term Storage of Passwords . . . . . . . . . . . . . . 26 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 95 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 98 1. Introduction 100 The predominant access method for the Internet today is that of a 101 human using a username and password to authenticate to a computer 102 enforcing access control. Proof of knowledge of the password 103 authenticates the human to the computer. 105 Typically, these passwords are not stored on a user's computer for 106 security reasons and must be entered each time the human desires 107 network access. Therefore, the passwords must be ones that can be 108 repeatedly entered by a human with a low probability of error. They 109 will likely not possess high entropy and it may be assumed that an 110 adversary with access to a dictionary will have the ability to guess 111 a user's password. It is therefore desirable to have a robust 112 authentication method that is secure even when used with a weak 113 password in the presence of a strong adversary. 115 EAP-EKE is an EAP method [RFC3748] that addresses the problem of 116 password-based authenticated key exchange, using a possibly weak 117 password for authentication and to derive an authenticated and 118 cryptographically strong shared secret. This problem was first 119 described by Bellovin and Merritt in [BM92] and [BM93]. 120 Subsequently, a number of other solution approaches have been 121 proposed, for example [JAB96], [LUC97], [BMP00], and others. 123 This proposal is based on the original Encrypted Key Exchange (EKE) 124 proposal, as described in [BM92]. Some of the variants of the 125 original EKE have been attacked, see e.g. [PA97], and improvements 126 have been proposed. None of these subsequent improvements have been 127 incorporated into the current protocol. However, we have used only 128 the subset of [BM92] (namely the variant described in Section 3.1 of 129 the paper) which has withstood the test of time and is believed 130 secure as of this writing. 132 2. Terminology 134 This document uses Encr(Ke, ...) to denote encrypted information, and 135 Prot(Ke, Ki, ...) to denote encrypted and integrity protected 136 information. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Protocol 144 EAP is a two-party protocol spoken between an EAP peer and an EAP 145 server (also known as "authenticator"). An EAP method defines the 146 specific authentication protocol being used by EAP. This memo 147 defines a particular method and therefore defines the messages sent 148 between the EAP server and the EAP peer for the purpose of 149 authentication and key derivation. 151 3.1. Message Flows 153 A successful run of EAP-EKE consists of three message exchanges: an 154 Identity exchange, a Commit exchange and a Confirm exchange. This is 155 shown in Figure 1. 157 The peer and server use the EAP-EKE Identity exchange to learn each 158 other's identities and to agree upon a ciphersuite to use in the 159 subsequent exchanges. In the Commit exchange the peer and server 160 exchange information to generate a shared key and also to bind each 161 other to a particular guess of the password. In the Confirm exchange 162 the peer and server prove liveness and knowledge of the password by 163 generating and verifying verification data. 165 +--------+ +--------+ 166 | | EAP-EKE-ID/Request | | 167 | EAP |<------------------------------------| EAP | 168 | peer | | server | 169 | (P) | EAP-EKE-ID/Response | (S) | 170 | |------------------------------------>| | 171 | | | | 172 | | EAP-EKE-Commit/Request | | 173 | |<------------------------------------| | 174 | | | | 175 | | EAP-EKE-Commit/Response | | 176 | |------------------------------------>| | 177 | | | | 178 | | EAP-EKE-Confirm/Request | | 179 | |<------------------------------------| | 180 | | | | 181 | | EAP-EKE-Confirm/Response | | 182 | |------------------------------------>| | 183 | | | | 184 | | EAP-Success | | 185 | |<------------------------------------| | 186 +--------+ +--------+ 187 Figure 1: A Successful EAP-EKE Exchange 189 Schematically, the original exchange as described in [BM92] (and with 190 the roles reversed) is: 192 Server Peer 193 ------ ---- 195 Encr(Password, y_s) -> 197 <- Encr(Password, y_p), Encr(SharedSecret, Nonce_P) 199 Encr(SharedSecret, Nonce_S | Nonce_P) -> 201 <- Encr(SharedSecret, Nonce_S) 203 Where: 204 o Password is a typically short string, shared between the server 205 and the peer. In other words, the same password is used to 206 authenticate the server to the peer, and vice versa. 207 o y_s and y_p are the server's and respectively, the peer's, 208 ephemeral public key, i.e. y_s = g ^ x_s (mod p) and y_p = g ^ x_p 209 (mod p). 210 o Nonce_S, Nonce_P are random strings generated by the server and 211 the peer as cryptographic challenges. 212 o SharedSecret is the secret created by the Diffie-Hellman 213 algorithm, namely SharedSecret = g^(x_s * x_p) (mod p). This 214 value is calculated by the server as: SharedSecret = y_p ^ x_s 215 (mod p), and by the peer as: SharedSecret = y_s ^ x_p (mod p). 216 The current protocol extends the basic cryptographic protocol, and 217 the regular successful exchange becomes: 219 Message Server Peer 220 --------- -------- ------ 221 ID/Request ID_S, CryptoProposals -> 223 ID/Response <- ID_P, CryptoSelection 225 Commit/Request Encr(Password, y_s) -> 227 Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P) 229 Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S -> 231 Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P 232 Section 5 explains how the various cryptographic values are derived. 234 As shown in the exchange above, the following information elements 235 have been added to the original protocol: identity values for both 236 protocol parties (ID_S, ID_P), negotiation of cryptographic 237 protocols, and signature fields to protect the integrity of the 238 negotiated parameters (Auth_S, Auth_P). In addition the shared 239 secret is not used directly. A few details have been omitted for 240 brevity. 242 4. Message Formats 244 EAP-EKE defined a small number of message types, each message 245 consisting of a header followed by a payload. This section defines 246 the header, several payload formats, as well as the format of 247 specific fields within the payloads. 249 4.1. EAP-EKE Header 251 The EAP-EKE header consists of the standard EAP header (see Section 4 252 of [RFC3748]), followed an EAP-EKE exchange type. The header has the 253 following structure: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Code | Identifier | Length | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | EKE-Exch | Data ... 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 2: EAP-EKE Header 265 The Code, Identifier, Length, and Type fields are all part of the EAP 266 header as defined in [RFC3748]. The Type field in the EAP header is 267 [TBD by IANA] for EAP-EKE version 1. [Note to RFC Editor: insert the 268 IANA-allocated value here.] 270 The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE 271 payload encapsulated in the Data field. This document defines the 272 following values for the EKE-Exch field: 273 o 0x00: Reserved 274 o 0x01: EAP-EKE-ID exchange 275 o 0x02: EAP-EKE-Commit exchange 276 o 0x03: EAP-EKE-Confirm exchange 277 o 0x04: EAP-EKE-Failure message 279 Further values of this EKE-Exch field are available via IANA 280 registration (Section 7.7). 282 4.2. EAP-EKE Payloads 284 EAP-EKE messages all contain the EAP-EKE header and information 285 encoded in a single payload, which differs for the different 286 exchanges. 288 4.2.1. The EAP-EKE-ID Payload 290 0 1 2 3 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | NumProposals | Reserved | Proposal ... 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 ... Proposal | IDType | Identity ... 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 3: EAP-EKE-ID Payload 300 The EAP-EKE-ID payload contains the following fields: 302 NumProposals: 304 The NumProposals field contains the number of Proposal fields 305 subsequently contained in the payload. In the EAP-EKE-ID/Request 306 the NumProposals field MUST NOT be set to zero (0) and in the EAP- 307 EKE-ID/Response message the NumProposals field MUST be set to one 308 (1). The offered proposals in the Request are listed contiguously 309 in priority order, most preferable first. The selected proposal 310 in the Response MUST be fully identical with one of the offered 311 proposals. 313 Proposal: 315 Each proposal consists of four one-octet fields, in this order: 317 Group Description: 319 This field's value is taken from the IANA registry for Diffie- 320 Hellman groups defined in Section 7.1. 322 Encryption: 324 This field's value is taken from the IANA registry for 325 encryption algorithms defined in Section 7.2. 327 PRF: 329 This field's value is taken from the IANA registry for pseudo 330 random functions defined in Section 7.3. 332 MAC: 334 This field's value is taken from the IANA registry for keyed 335 message digest algorithms defined in Section 7.4. 337 Reserved: 339 This field MUST be sent as zero, and MUST be ignored by the 340 recipient. 342 IDType: 344 Denotes the Identity Type. This is taken from the IANA registry 345 defined in Section 7.5. The server and the peer MAY use different 346 identity types. All implementations MUST be able to receive two 347 identity types: ID_NAI and ID_FQDN. 349 Identity: 351 The meaning of the Identity field depends on the values of the 352 Code and IDType fields. 353 * EAP-EKE-ID/Request: server ID 354 * EAP-EKE-ID/Response: peer ID 355 The length of the Identity field is computed from the Length field 356 in the EAP header. Specifically, its length is 357 eap_header_length - 9 - 4 * number_of_proposals. 358 This field, like all other fields in this specification, MUST be 359 octet-aligned. 361 4.2.2. The EAP-EKE-Commit Payload 363 This payload allows both parties send their encrypted ephemeral 364 public key, with the peer also including a Challenge. 366 In addition, a small amount of data can be included by the server 367 and/or the peer, and used for channel binding. This data is sent 368 here unprotected, but is verified later, when it is signed by the 369 Auth_S/Auth_P payloads of the EAP-EKE-Confirm exchange. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | DHComponent_S/DHComponent_P ~ 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 ~ ~ 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Commit_P ~ 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 ~ ~ 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | CBValue* ~ 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 ~ ~ 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Figure 4: EAP-EKE-Commit Payload 389 DHComponent_S/DHComponent_P: 391 This field contains the password-encrypted Diffie-Hellman public 392 key, see Section 5.1. Its size is determined by the group and the 393 encryption algorithm. 395 Commit_P: 397 This field only appears in the response, and contains the 398 encrypted and integrity-protected challenge value sent by the 399 peer. The field's size is determined by the encryption and MAC 400 algorithms being used, since this protocol mandates a fixed nonce 401 size for a given choice of algorithms. See Section 5.2. 403 CBValue: 405 This structure MAY be included both in the request and in the 406 response, and MAY be repeated multiple times, once per each value 407 transmitted. See Section 4.5. Each structure contains its own 408 length. 410 4.2.3. The EAP-EKE-Confirm Payload 412 Using this payload, both parties complete the authentication by 413 generating a shared temporary key, authenticating the entire 414 protocol, and generating key material for the EAP consumer protocol. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Confirm_S/Confirm_P ~ 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 ~ ~ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Auth_S/Auth_P ~ 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 ~ ~ 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 5: EAP-EKE-Confirm Payload 430 Confirm_S/Confirm_P: 432 This field contains the encrypted and integrity-protected response 433 to the other party's challenge, see Section 5.3 and Section 5.4. 434 Similarly to the Commit_P field, this field's size is determined 435 by the encryption and MAC algorithms. 437 Auth_S/Auth_P: 439 This field signs the preceding messages, including the Identity 440 and the negotiated fields. This prevents various possible 441 attacks, such as algorithm downgrade attacks. See Section 5.3 and 442 Section 5.4. The size is determined by the pseudo-random function 443 negotiated. 445 4.2.4. The EAP-EKE-Failure Payload 447 The EAP-EKE-Failure payload format is defined as follows: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Failure-Code | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 EAP-EKE-Failure Payload 457 The payload's size is always exactly 4 octets. 459 The following Failure-Code values are defined: 461 +------------+----------------+-------------------------------------+ 462 | Value | Name | Meaning | 463 +------------+----------------+-------------------------------------+ 464 | 0x00000000 | Reserved | | 465 | 0x00000001 | No Error | This code is used for failure | 466 | | | acknowledgement, see below. | 467 | 0x00000002 | Protocol Error | A failure to parse or understand a | 468 | | | protocol message or one of its | 469 | | | payloads. | 470 | 0x00000003 | Password Not | A password could not be located for | 471 | | Found | the identity presented by the other | 472 | | | protocol party, making | 473 | | | authentication impossible. For | 474 | | | security reasons, implementations | 475 | | | MAY choose to eliminate this error | 476 | | | code and return "Authentication | 477 | | | Failure" also in this case. | 478 | 0x00000004 | Authentication | Failure in the cryptographic | 479 | | Failure | computation most likely caused by | 480 | | | an incorrect password, or an | 481 | | | inappropriate identity type. | 482 | 0x00000005 | Authorization | While the password being used is | 483 | | Failure | correct, the user is not authorized | 484 | | | to connect. | 485 | 0x00000006 | No Proposal | The peer is unwilling to select any | 486 | | Chosen | of the cryptographic proposals | 487 | | | offered by the server. | 488 +------------+----------------+-------------------------------------+ 490 Additional values of this field are available via IANA registration, 491 see Section 7.8. 493 When the peer encounters an error situation, it MUST respond with 494 EAP-EKE-Failure. The server MUST reply with an EAP-Failure message 495 to end the exchange. 497 When the server encounters an error situation, it MUST respond with 498 EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message 499 containing a "No Error" failure code. Then the server MUST send an 500 EAP-Failure message to end the exchange. 502 4.3. Protected Fields 504 Several fields are encrypted and integrity-protected. They are 505 denoted Prot(...). Their general structure is as follows: 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Initialization Vector (IV) (optional) | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Encrypted Data ~ 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 ~ ~ 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 ~ | Random Padding | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Integrity Check Value (ICV) | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 6: Protected Field Structure 523 The protected field is a concatenation of three octet strings: 525 o An optional IV, required when the encryption algorithm/mode 526 necessitates it, e.g. for CBC encryption. The content and size of 527 this field are determined by the selected encryption algorithm. 528 In the case of CBC encryption, this field is a random octet string 529 having the same size as the algorithm's block size. 530 o The original data, followed if necessary by random padding. This 531 padding has the minimal length (possibly zero) required to 532 complete the length of the encrypted data to the encryption 533 algorithm's block size. The original data and the padding are 534 encrypted together. 535 o ICV, a cryptographic checksum (MAC) of the encrypted data, 536 including the padding. The checksum is computed over the 537 encrypted, rather than the plaintext, data. Its length is 538 determined by the MAC algorithm negotiated. 540 We note that because of the requirement for an explicit ICV, this 541 specification does not support authenticated encryption algorithms. 542 Such algorithms may be added by a future extension. 544 4.4. Encrypted Fields 546 Two fields are encrypted but not integrity protected. They are 547 denoted Encr(...). Their format is identical to a protected field 548 (Section 4.3), except that the Integrity Check Value is omitted. 550 4.5. Channel Binding Values 552 This protocol allows higher level protocols that are using it to 553 transmit opaque information between the peer and the server. This 554 information is integrity protected but not encrypted, and may be used 555 to ensure that protocol participants are identical at different 556 protocol layers. EAP-EKE neither validates nor makes any use of the 557 transmitted information. The information MUST NOT be used by the 558 consumer protocol until it is verified in the EAP-EKE-Confirm 559 exchange (specifically, it is integrity protected by the Auth_S, 560 Auth_P payloads). Consequently, it MUST NOT be relied upon in case 561 an error occurs at the EAP-EKE level. 563 An unknown Channel Binding Value SHOULD be ignored by the recipient. 565 Some implementations may require certain values to be present, and 566 will abort the protocol if they are not. Such policy is out of scope 567 of the current protocol. 569 Each Channel Binding Value is encoded using a simple TLV structure: 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | CBType | Length | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Value ... 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 7: Channel Binding Value 581 CBType: 583 This is the Channel Binding Value's type. This document defines 584 the value 0x0000 as reserved. Other values are available for IANA 585 allocation, see Section 7.6. 587 Length: 589 This field is the total length in octets of the structure, 590 including the CBType and Length fields. 592 This facility should be used with care, since EAP-EKE does not 593 provide for message fragmentation. EAP-EKE is not a tunneled method, 594 and should not be used as a generic transport; specifically, 595 implementors should refrain from using the Channel Binding facility 596 to transmit posture information, in the sense of [RFC5209]. 598 5. Protocol Sequence 600 This section describes the sequence of messages for the Commit and 601 Confirm exchanges, and lists the cryptographic operations performed 602 by the server and the peer. 604 5.1. EAP-EKE-Commit/Request 606 The server computes 608 y_s = g ^ x_s (mod p), 610 where x_s is a randomly chosen number in the range 2 .. p-1. The 611 randomly chosen number is the ephemeral private key, and the 612 calculated value is the corresponding ephemeral public key. The 613 server and the peer MUST both use a fresh, random value for x_s and 614 the corresponding x_p on each run of the protocol. 616 Note: If Elliptic Curve Diffie-Hellman is used, the corresponding 617 additive group operations are to be employed instead of 618 exponentiation. 620 The server transmits the encrypted field (Section 4.4) 622 DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), y_s), 624 where the literal string is encoded using ASCII with no zero 625 terminator. See Section 6.1 for the prf+ notation. When using block 626 ciphers, it may be necessary to pad y_s on the right, to fit the 627 encryption algorithm's block size. In such cases, random padding 628 MUST be used, and this randomness is critical to the security of the 629 protocol. Randomness recommendations can be found in [RFC4086]. 630 When decrypting this field, the real length of y_s is determined 631 according to the negotiated Diffie Hellman group. 633 If the password needs to be stored on the server, it is RECOMMENDED 634 to store the randomized password value, i.e. prf+(password, ...), as 635 a password-equivalent, rather than the cleartext password. See also 636 Section 8.5. 638 If the password is non-ASCII, it SHOULD be normalized by the sender 639 before the EAP-EKE message is constructed. The normalization method 640 is SASLprep, [RFC4013]. Note that the password is not null- 641 terminated. 643 5.2. EAP-EKE-Commit/Response 645 The peer computes 647 y_p = g ^ x_p (mod p) 649 and sends 651 DHComponent_P = Encr(prf+(password, "EAP-EKE Password"), y_p) 653 formatted as an encrypted field (Section 4.4). 655 Both sides calculate 657 SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p)) 659 If an HMAC-based pseudo-random function is used, the first argument 660 to "prf" is a string of zero octets whose length is the output size 661 of the base hash algorithm, e.g. 20 octets for HMAC-SHA1; the result 662 is of the same length. If a non HMAC-based prf is used, the 663 algorithm should specify its preferred input length (to be used as 664 the length of the string of zeros) and its preferred output length. 665 This extra application of the pseudo-random function is the 666 "extraction step" of [I-D.krawczyk-hkdf]. Note that the peer needs 667 to compute the SharedSecret value before sending out its response. 669 The encryption and integrity protection keys are computed: 671 Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P) 673 And the peer generates 675 Commit_P = Prot(Ke, Ki, Nonce_P), 677 where Nonce_P is a randomly generated binary string. The length of 678 Nonce_P MUST be the maximum of 128 bits, and half the key size of the 679 negotiated prf (rounded up to the next octet if necessary). The peer 680 sends this value as a protected field (Section 4.3), encrypted using 681 Ke and integrity protected using Ki with the negotiated encryptiom 682 and MAC algorithm. 684 The server MUST verify the correct integrity protection of the 685 received nonce, and MUST abort the protocol if it is incorrect, with 686 an "Authentication Failure" code. 688 5.3. EAP-EKE-Confirm/Request 690 The server constructs: 692 Confirm_S = Prot(Ke, Ki, Nonce_P | Nonce_S), 694 as a protected field, where Nonce_S is a randomly generated string, 695 of the same size as Nonce_P. 697 It computes: 699 Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | 700 Nonce_S) 702 And constructs: 704 Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE- 705 ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response). 707 The messages are included in full, starting with the EAP header, and 708 including any possible future extensions. 710 The server now sends a message that contains the two payloads. 712 The peer MUST verify the correct integrity protection of the received 713 nonces and the correctness of the Auth_S value, and MUST abort the 714 protocol if either is incorrect, with an "Authentication Failure" 715 code. 717 5.4. EAP-EKE-Confirm/Response 719 The peer computes Ka, and sends: 721 Confirm_P = Prot(Ke, Ki, Nonce_S) 723 as a protected field, and 725 Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/ 726 Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response) 728 The server MUST verify the correct integrity protection of the 729 received nonce and the correctness of the Auth_P value, and MUST 730 abort the protocol if either is incorrect, with an "Authentication 731 Failure" code. 733 5.5. MSK and EMSK 735 Following the last message of the protocol, both sides compute and 736 export the shared keys, each 512 bits in length: 738 MSK = prf+(SharedSecret, "EAP-EKE MSK" | ID_S | ID_P | Nonce_P | 739 Nonce_S) 740 EMSK = prf+(SharedSecret, "EAP-EKE EMSK" | ID_S | ID_P | Nonce_P | 741 Nonce_S) 743 When the RADIUS attributes specified in [RFC2548] are used to 744 transport keying material, then the first 32 bytes of the MSK 745 correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE- 746 SEND-KEY. In this case, only 64 bytes of keying material (the MSK) 747 are used. 749 At this point, both protocol participants MUST discard all 750 intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke, 751 Ki, Ka, SharedSecret. Similarly, both parties MUST immediately 752 discard these values whenever the protocol terminates with a failure 753 code or as a result of timeout. 755 6. Cryptographic Details 757 6.1. Generating Keying Material 759 Keying material is derived as the output of the negotiated pseudo- 760 random function (prf) algorithm. Since the amount of keying material 761 needed may be greater than the size of the output of the prf 762 algorithm, we will use the prf iteratively. We denote by "prf+" the 763 function that outputs a pseudo-random stream based on the inputs to a 764 prf as follows (where | indicates concatenation): 766 prf+ (K, S) = T1 | T2 | T3 | T4 | ... 768 where: 769 T1 = prf(K, S | 0x01) 770 T2 = prf(K, T1 | S | 0x02) 771 T3 = prf(K, T2 | S | 0x03) 772 T4 = prf(K, T3 | S | 0x04) 774 continuing as needed to compute all required keys. The keys are 775 taken from the output string without regard to boundaries (e.g., if 776 the required keys are a 256-bit Advanced Encryption Standard (AES) 777 key and a 160-bit HMAC key, and the prf function generates 160 bits, 778 the AES key will come from T1 and the beginning of T2, while the HMAC 779 key will come from the rest of T2 and the beginning of T3). 781 The constant concatenated to the end of each string feeding the prf 782 is a single octet. prf+ in this document is not defined beyond 255 783 times the size of the prf output. 785 6.2. Diffie-Hellman Groups 787 Many of the commonly used Diffie Hellman groups are inappropriate for 788 use in EKE. Most of these groups use a generator which is not a 789 primitive element of the group. As a result, an attacker running a 790 dictionary attack would be able to learn at least 1 bit of 791 information for each decrypted password guess. 793 Any MODP Diffie Hellman group defined for use in this protocol MUST 794 have the following properties, to ensure that it does not leak a 795 usable amount of information about the password: 796 1. The generator is a primitive element of the group. 797 2. The most significant 64 bits of the prime number are 1. 798 3. The group's order p is a "safe prime", i.e. (p-1)/2 is also 799 prime. 801 The last requirement is related to the strength of the Diffie Hellman 802 algorithm, rather than the password encryption. It also makes it 803 easy to verify that the generator is primitive. 805 Suitable groups are defined in Section 7.1. 807 6.3. Mandatory Algorithms 809 To facilitate interoperability, the following algorithms are 810 mandatory to implement: 812 o ENCR_AES128_CBC (encryption algorithm) 813 o PRF_HMAC_SHA1 (pseudo random function) 814 o MAC_HMAC_SHA1 (keyed message digest) 815 o DHGROUP_EKE_14 (DH-group) 817 7. IANA Considerations 819 IANA shall allocate (has allocated) the EAP method type TBD, for 820 "EAP-EKE Version 1". [Note to RFC Editor: insert the IANA-allocated 821 value here.] 823 This document requests that IANA create the registries described in 824 the following sub-sections. Values (other than private-use ones) can 825 be added to these registries per Specification Required [RFC5226], 826 with two exceptions: the Exchange and Failure Code registries can 827 only be extended per RFC Required [RFC5226]. 829 7.1. Diffie-Hellman Group Registry 831 This section defines an IANA registry for Diffie-Hellman groups. 833 This table defines the initial contents of this registry. The Value 834 column is used when negotiating the group. Additional groups may be 835 defined through IANA allocation. Any future specification that 836 defines a non-MODP group MUST specify its use within EAP-EKE and MUST 837 demonstrate the group's security in this context. 839 +----------------+--------+---------+-------------------------------+ 840 | Name | Length | Value | Description | 841 +----------------+--------+---------+-------------------------------+ 842 | Reserved | | 0 | | 843 | DHGROUP_EKE_2 | 1024 | 1 | The prime number of Group 2 | 844 | | | | [RFC4306], with the generator | 845 | | | | 5 (decimal) | 846 | DHGROUP_EKE_5 | 1536 | 2 | The prime number of Group 5 | 847 | | | | [RFC3526], g=31 | 848 | DHGROUP_EKE_14 | 2048 | 3 | The prime number of Group 14 | 849 | | | | [RFC3526], g=11 | 850 | DHGROUP_EKE_15 | 3072 | 4 | The prime number of Group 15 | 851 | | | | [RFC3526], g=5 | 852 | DHGROUP_EKE_16 | 4096 | 5 | The prime number of Group 16 | 853 | | | | [RFC3526], g=5 | 854 | Available for | | 6-127 | | 855 | allocation via | | | | 856 | IANA | | | | 857 | Reserved for | | 128-255 | | 858 | private use | | | | 859 +----------------+--------+---------+-------------------------------+ 861 7.2. Encryption Algorithm Registry 863 This section defines an IANA registry for encryption algorithms: 865 +-----------------+---------+----------------------------------+ 866 | Name | Value | Definition | 867 +-----------------+---------+----------------------------------+ 868 | Reserved | 0 | | 869 | ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode | 870 | | 2-127 | Available for allocation via IANA| 871 | | 128-255 | Reserved for private use | 872 +-----------------+---------+----------------------------------+ 874 7.3. Pseudo Random Function Registry 876 This section defines an IANA registry for pseudo random function 877 algorithms: 879 +-----------------+---------+-------------------------------------+ 880 | Name | Value | Definition | 881 +-----------------+---------+-------------------------------------+ 882 | Reserved | 0 | | 883 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 884 | PRF_HMAC_SHA256 | 2 | HMAC SHA-256 | 885 | | 3-127 | Available for allocation via IANA | 886 | | 128-255 | Reserved for private use | 887 +-----------------+---------+-------------------------------------+ 889 A pseudo-random function takes two parameters K and S, and must be 890 defined for all lengths of K between 0 and 65,535 bits (inclusive). 892 7.4. Keyed Message Digest (MAC) Registry 894 This section defines an IANA registry for keyed message digest 895 algorithms: 897 +-----------------+---------+-------------------------------------+ 898 | Name | Value | Definition | 899 +-----------------+---------+-------------------------------------+ 900 | Reserved | 0 | | 901 | MAC_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 902 | MAC_HMAC_SHA256 | 2 | HMAC SHA-256 | 903 | | 3-127 | Available for allocation via IANA | 904 | | 128-255 | Reserved for private use | 905 +-----------------+---------+-------------------------------------+ 907 7.5. Identity Type Registry 909 In addition, an identity type registry is defined: 911 +-----------+---------+---------------------------------------------+ 912 | Name | Value | Definition | 913 +-----------+---------+---------------------------------------------+ 914 | Reserved | 0 | | 915 | ID_OPAQUE | 1 | A printable UTF-8 string whose format is | 916 | | | undefined | 917 | ID_NAI | 2 | A Network Access Identifier, as defined in | 918 | | | [RFC4282] | 919 | ID_IPv4 | 3 | An IPv4 address, in binary format | 920 | ID_IPv6 | 4 | An IPv6 address, in binary format | 921 | ID_FQDN | 5 | A fully qualified domain name | 922 | | 6-127 | Available for allocation via IANA | 923 | | 128-255 | Reserved for private use | 924 +-----------+---------+---------------------------------------------+ 926 7.6. Channel Binding Type Registry 928 This section defines an IANA registry for the Channel Binding Type 929 registry, a 16-bit long code. The value 0x0000 has been defined as 930 Reserved. All other values up to 0xff00 are available for allocation 931 via IANA. The remaining values up to 0xffff are available for 932 private use. 934 7.7. Exchange Registry 936 This section defines an IANA registry for the EAP-EKE Exchange 937 registry, an 8-bit long code. Initial values are defined in 938 Section 4.1. All values up to 0x80 are available for allocation via 939 IANA. The remaining values up to 0xff are available for private use. 941 7.8. Failure-Code Registry 943 This section defines an IANA registry for the Failure-Code registry, 944 a 32-bit long code. Initial values are defined in Section 4.2.4. 945 All values up to 0xff000000 are available for allocation via IANA. 946 The remaining values up to 0xffffffff are available for private use. 948 8. Security Considerations 950 Any protocol that claims to solve the problem of password- 951 authenticated key exchange must be resistant to active, passive and 952 dictionary attack and have the quality of forward secrecy. These 953 characteristics are discussed further in the following paragraphs. 955 Resistance to Passive Attack A passive attacker is one that merely 956 relays messages back and forth between the peer and server, 957 faithfully, and without modification. The contents of the 958 messages are available for inspection, but that is all. To 959 achieve resistance to passive attack, such an attacker must not be 960 able to obtain any information about the password or anything 961 about the resulting shared secret from watching repeated runs of 962 the protocol. Even if a passive attacker is able to learn the 963 password, she will not be able to determine any information about 964 the resulting secret shared by the peer and server. 965 Resistance to Active Attack An active attacker is able to modify, 966 add, delete, and replay messages sent between protocol 967 participants. For this protocol to be resistant to active attack, 968 the attacker must not be able to obtain any information about the 969 password or the shared secret by using any of its capabilities. 970 In addition, the attacker must not be able to fool a protocol 971 participant into thinking that the protocol completed 972 successfully. It is always possible for an active attacker to 973 deny delivery of a message critical in completing the exchange. 974 This is no different than dropping all messages and is not an 975 attack against the protocol. 976 Resistance to Dictionary Attack For this protocol to be resistant to 977 dictionary attack any advantage an adversary can gain must be 978 directly related to the number of interactions she makes with an 979 honest protocol participant and not through computation. The 980 adversary will not be able to obtain any information about the 981 password except whether a single guess from a single protocol run 982 is correct or incorrect. 983 Forward Secrecy Compromise of the password must not provide any 984 information about the secrets generated by earlier runs of the 985 protocol. 987 [RFC3748] requires that documents describing new EAP methods clearly 988 articulate the security properties of the method. In addition, for 989 use with wireless LANs, [RFC4017] mandates and recommends several of 990 these. The claims are: 991 1. Mechanism: password. 992 2. Claims: 993 * Mutual authentication: the peer and server both authenticate 994 each other by proving possession of a shared password. This 995 is REQUIRED by [RFC4017]. 996 * Forward secrecy: compromise of the password does not reveal 997 the secret keys (MSK and EMSK) from earlier runs of the 998 protocol. 999 * Replay protection: an attacker is unable to replay messages 1000 from a previous exchange either to learn the password or a key 1001 derived by the exchange. Similarly the attacker is unable to 1002 induce either the peer or server to believe the exchange has 1003 successfully completed when it hasn't. 1004 * Key derivation: a shared secret is derived by performing a 1005 group operation in a finite cyclic group (e.g. exponentiation) 1006 using secret data contributed by both the peer and server. An 1007 MSK and EMSK are derived from that shared secret. This is 1008 REQUIRED by [RFC4017]. 1009 * Dictionary attack resistance: an attacker can only make one 1010 password guess per active attack, and the protocol is designed 1011 so that the attacker does not gain any confirmation of her 1012 guess by observing the decrypted Y_x value (see below). The 1013 advantage she can gain is through interaction not through 1014 computation. This is REQUIRED by [RFC4017]. 1015 * Session independence: this protocol is resistant to active and 1016 passive attacks and does not enable compromise of subsequent 1017 or prior MSKs or EMSKs from either passive or active attacks. 1018 * Denial of Service resistance: it is possible for an attacker 1019 to cause a server to allocate state and consume CPU. Such an 1020 attack is gated, though, by the requirement that the attacker 1021 first obtain connectivity through a lower-layer protocol (e.g. 1022 802.11 authentication followed by 802.11 association, or 802.3 1023 "link-up") and respond to two EAP messages: the EAP-ID/Request 1024 and the EAP-EKE-ID/Request. 1025 * Man-in-the-Middle Attack resistance: this exchange is 1026 resistant to active attack, which is a requirement for 1027 launching a man-in-the-middle attack. This is REQUIRED by 1028 [RFC4017]. 1029 * Shared state equivalence: upon completion of EAP-EKE the peer 1030 and server both agree on the MSK and EMSK values. The peer 1031 has authenticated the server based on the Server_ID and the 1032 server has authenticated the peer based on the Peer_ID. This 1033 is due to the fact that Peer_ID, Server_ID, and the generated 1034 shared secret are all combined to make the authentication 1035 element which must be shared between the peer and server for 1036 the exchange to complete. This is REQUIRED by [RFC4017]. 1037 * Fragmentation: this protocol does not define a technique for 1038 fragmentation and reassembly. 1039 * Resistance to "Denning-Sacco" attack: learning keys 1040 distributed from an earlier run of the protocol, such as the 1041 MSK or EMSK, will not help an adversary learn the password. 1042 3. Key strength: the strength of the resulting key depends on the 1043 finite cyclic group chosen. Sufficient key strength is REQUIRED 1044 by [RFC4017]. Clearly, "sufficient" strength varies over time, 1045 depending on computation power assumed to be available to 1046 potential attackers. 1047 4. Key hierarchy: MSKs and EMSKs are derived from the secret values 1048 generated during the protocol run, using a negotiated pseudo- 1049 random function. 1051 5. Vulnerabilities (note that none of these are REQUIRED by 1052 [RFC4017]): 1053 * Protected ciphersuite negotiation: the ciphersuite proposal 1054 made by the server is not protected from tampering by an 1055 active attacker. However if a proposal was modified by an 1056 active attacker it would result in a failure to confirm the 1057 message sent by the other party, since the proposal is bound 1058 by each side into its Confirm message, and the protocol would 1059 fail as a result. Note that this assumes that none of the 1060 proposed ciphersuites enables an attacker to perform real-time 1061 cryptanalysis. 1062 * Confidentiality: none of the messages sent in this protocol 1063 are encrypted, though many of the protocol fields are. 1064 * Integrity protection: protocol messages are not directly 1065 integrity protected; however the ID and Commit exchanges are 1066 integrity protected through the Auth payloads exchanged in the 1067 Confirm exchange. 1068 * Channel binding: this protocol enables the exchange of 1069 integrity-protected channel information that can be compared 1070 with values communicated via out-of-band mechanisms. 1071 * Fast reconnect: this protocol does not provide a fast 1072 reconnect capability. 1073 * Cryptographic binding: this protocol is not a tunneled EAP 1074 method and therefore has no cryptographic information to bind. 1075 * Identity protection: the EAP-EKE-ID exchange is not protected. 1076 An attacker will see the server's identity in the EAP-EKE-ID/ 1077 Request and see the peer's identity in EAP-EKE-ID/ Response. 1078 See also Section 8.4. 1080 8.1. Cryptographic Analysis 1082 When analyzing the Commit exchange, it should be noted that the base 1083 security assumptions are different from "normal" cryptology. 1084 Normally, we assume that the key has strong security properties, and 1085 that the data may have little. Here, we assume that the key has weak 1086 security properties (the attacker may have a list of possible keys), 1087 and hence we need to ensure that the data has strong properties 1088 (indistinguishable from random). This difference may mean that 1089 conventional wisdom in cryptology might not apply in this case. This 1090 also imposes severe constraints on the protocol, e.g. the mandatory 1091 use of random padding, and the need to define specific finite groups. 1093 8.2. Diffie Hellman Group Considerations 1095 It is fundamental to the dictionary attack resistance that the Diffie 1096 Hellman public values y_s and y_p are indistinguishable from a random 1097 string. If this condition is not met, then a passive attacker can do 1098 trial-decryption of the encrypted DHComponent_P or DHComponent_S 1099 values based on a password guess, and if they decrypt to a value 1100 which is not a valid public value, they know that the password guess 1101 was incorrect. 1103 For MODP groups, Section 6.2 gives conditions on the group to make 1104 sure that this criterion is met. For other groups (for example, 1105 Elliptic Curve groups), some other means of ensuring this must be 1106 employed. The standard way of expressing Elliptic Curve public 1107 values does not meet this criterion, as a valid Elliptic Curve X 1108 coordinate can be distinguished from a random string with probability 1109 approximately 0.5. 1111 A future document might introduce a group representation, and/or a 1112 slight modification of the password encryption scheme, so that 1113 Elliptic Curve groups can be accommodated. [BR02] presents several 1114 alternative solutions for this problem. 1116 8.3. Resistance to Active Attacks 1118 An attacker, impersonating either the peer or the server, can always 1119 try to enumerate all possible passwords, for example by using a 1120 dictionary. To counter this likely attack vector, both peer and 1121 server MUST implement rate-limiting mechanisms. We note that locking 1122 out the other party after a small number of tries would create a 1123 trivial denial of service opportunity. 1125 8.4. Identity Protection, Anonymity and Pseudonymity 1127 By default, the EAP-EKE-ID exchange is unprotected, and an 1128 eavesdropper can observe both parties' identities. A future 1129 extension of this protocol may support anonymity, e.g. by allowing 1130 the server to send a temporary identity to the peer at the end of the 1131 exchange, so that the peer can use that identity in subsequent 1132 exchanges. 1134 EAP-EKE differs in this respect from tunneled methods, which 1135 typically provide unconditional identity protection to the peer by 1136 encrypting the identity exchange, but reveal information in the 1137 server certificate. It is possible to use EAP-EKE as the inner 1138 menthod in a tunnelled EAP method in order to achieve this level of 1139 identity protection. 1141 8.5. Long Term Storage of Passwords 1143 This document recommends to store a password-equivalent (a hash of 1144 the password) instead of the cleartext password. While this solution 1145 provides a measure of security, there are also tradeoffs related to 1146 algorithm agility: 1148 o Each stored password must identify the pseudo-random function 1149 (prf) that was used to compute the stored value. 1150 o Complex deployments and migration scenarios might necessitate 1151 multiple stored passwords, one per each prf algorithm. 1152 o Changing the prf can require in some cases that the users manually 1153 change their passwords. 1155 9. Acknowledgements 1157 Much of this document was unashamedly picked from 1158 [I-D.harkins-emu-eap-pwd] and [I-D.ietf-pppext-eap-srp-03], and we 1159 would like to acknowledge the authors of these documents: Dan 1160 Harkins, Glen Zorn, James Carlson, Bernard Aboba and Henry Haverinen. 1161 We would like to thank David Jacobson, Steve Bellovin and Russ 1162 Housley for their useful comments. Lidar Herooty and Idan Ofrat 1163 implemented this protocol and helped us improve it by asking the 1164 right questions, and we would like to thank them both. 1166 10. References 1168 10.1. Normative References 1170 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1171 Hashing for Message Authentication", RFC 2104, 1172 February 1997. 1174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1175 Requirement Levels", BCP 14, RFC 2119, March 1997. 1177 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 1178 RFC 2548, March 1999. 1180 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 1181 Diffie-Hellman groups for Internet Key Exchange (IKE)", 1182 RFC 3526, May 2003. 1184 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1185 Levkowetz, "Extensible Authentication Protocol (EAP)", 1186 RFC 3748, June 2004. 1188 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1189 and Passwords", RFC 4013, February 2005. 1191 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1192 Network Access Identifier", RFC 4282, December 2005. 1194 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1195 RFC 4306, December 2005. 1197 10.2. Informative References 1199 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 1200 Password-Based Protocols Secure Against Dictionary 1201 Attacks", Proc. IEEE Symp. on Research in Security and 1202 Privacy , May 1992. 1204 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 1205 Exchange: A Password-Based Protocol Secure against 1206 Dictionary Attacks and Password File Compromise", Proc. 1207 1st ACM Conference on Computer and Communication 1208 Security , 1993. 1210 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 1211 Password Authenticated Key Exchange Using Diffie-Hellman", 1212 Advances in Cryptology, EUROCRYPT 2000 , 2000. 1214 [BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary Finite 1215 Domains", Proc. of the RSA Cryptographer's Track (RSA CT 1216 '02), LNCS 2271 , 2002. 1218 [I-D.harkins-emu-eap-pwd] 1219 Harkins, D. and G. Zorn, "EAP Authentication Using Only A 1220 Password", draft-harkins-emu-eap-pwd-14 (work in 1221 progress), April 2010. 1223 [I-D.ietf-pppext-eap-srp-03] 1224 Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 1225 Authentication Protocol", draft-ietf-pppext-eap-srp-03 1226 (work in progress), July 2001. 1228 [I-D.krawczyk-hkdf] 1229 Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1230 Key Derivation Function (HKDF)", draft-krawczyk-hkdf-01 1231 (work in progress), January 2010. 1233 [JAB96] Jablon, D., "Strong Password-Only Authenticated Key 1234 Exchange", ACM Computer Communications Review Volume 1, 1235 Issue 5, October 1996. 1237 [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary 1238 Attacks Without Encrypting Public Keys", Proc. of the 1239 Security Protocols Workshop LNCS 1361, 1997. 1241 [PA97] Patel, S., "Number Theoretic Attacks On Secure Password 1242 Schemes", Proceedings of the 1997 IEEE Symposium on 1243 Security and Privacy , 1997. 1245 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1246 Authentication Protocol (EAP) Method Requirements for 1247 Wireless LANs", RFC 4017, March 2005. 1249 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1250 Requirements for Security", BCP 106, RFC 4086, June 2005. 1252 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 1253 Tardo, "Network Endpoint Assessment (NEA): Overview and 1254 Requirements", RFC 5209, June 2008. 1256 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1257 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1258 May 2008. 1260 Appendix A. Change Log 1262 Note to RFC Editor: please remove this section before publication. 1264 A.1. -06 1266 Lots of small changes based on Russ's AD review. Clarified 1267 processing of Channel Binding Values, some of which is currently out 1268 of scope. Made a small but non-backward compatible change to the 1269 generation of Ke, Ki. Changed the rules for nonce lengths (however 1270 this results in no change for the currently specified algorithms). 1272 A.2. -05 1274 Revised the Anonymity section. Added more MODP groups. Note that 1275 DHGROUP_EKE_14 was renumbered. 1277 A.3. -04 1279 Changed the intended document status to Informational. 1281 A.4. -03 1283 Added a provision for channel binding. 1285 Clarified the notation for protected vs. encrypted fields. 1287 Explained how pseudonymity can be provided. 1289 Implementations need not implement the "password not found" failure. 1291 Eliminated the Design Options appendix. 1293 A.5. -02 1295 Added text from EAP-SIM re: exporting MSK in RADIUS MPPE attributes. 1297 Eliminated protected failures: they are too rarely useful. 1299 Added the "extraction step" of HKDF. 1301 Removed the check for g^x != 0, since this can never happen for an 1302 honest peer, and otherwise requires an active password-guessing 1303 attacker, against which other protections are required. Added a 1304 related subsection about rate limiting. 1306 Added an Exchange Registry to the IANA Considerations. 1308 A general structure for protected (and merely encrypted) fields, 1309 which clarifies the protocol and also adds explicit integrity 1310 protection for the encrypted nonces, as recommended by [BM92]. 1312 A.6. -01 1314 Revised following comments raised on the CFRG mailing list. In 1315 particular, added security considerations and a new DH group 1316 definition, to resolve the vulnerability in case the group's 1317 generator is not a primitive element. 1319 A.7. -00 1321 Initial version. 1323 Authors' Addresses 1325 Yaron Sheffer 1326 Independent 1328 Email: yaronf.ietf@gmail.com 1329 Glen Zorn 1330 Network Zen 1331 1310 East Thomas Street 1332 #306 1333 Seattle, Washington 98102 1334 USA 1336 Phone: +1 (206) 377-9035 1337 Email: gwz@net-zen.net 1339 Hannes Tschofenig 1340 Nokia Siemens Networks 1341 Linnoitustie 6 1342 Espoo 02600 1343 Finland 1345 Phone: +358 (50) 4871445 1346 Email: Hannes.Tschofenig@gmx.net 1347 URI: http://www.tschofenig.priv.at 1349 Scott Fluhrer 1350 Cisco Systems. 1351 1414 Massachusetts Ave. 1352 Boxborough, MA 01719 1353 USA 1355 Email: sfluhrer@cisco.com