idnits 2.17.1 draft-harkins-emu-eap-pwd-13.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. 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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (February 23, 2010) is 5174 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harkins 3 Internet-Draft Aruba Networks 4 Intended status: Informational G. Zorn 5 Expires: August 27, 2010 Network Zen 6 February 23, 2010 8 EAP Authentication Using Only A Password 9 draft-harkins-emu-eap-pwd-13 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 27, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 51 in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This memo describes an Extensible Authentication Protocol (EAP) 58 method, EAP-pwd, which uses a shared password for authentication. 59 The password may be a low-entropy one and may be drawn from some set 60 of possible passwords, like a dictionary, which is available to an 61 attacker. The underlying key exchange is resistant to active attack, 62 passive attack and dictionary attack. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Keyword Definitions . . . . . . . . . . . . . . . . . . . 4 69 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.3.1. Resistance to Passive Attack . . . . . . . . . . . . . 4 71 1.3.2. Resistance to Active Attack . . . . . . . . . . . . . 5 72 1.3.3. Resistance to Dictionary Attack . . . . . . . . . . . 5 73 1.3.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . 5 74 2. Specification of EAP-pwd . . . . . . . . . . . . . . . . . . . 5 75 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 2.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 7 77 2.2.1. Finite Field Cryptography . . . . . . . . . . . . . . 7 78 2.2.2. Elliptic Curve Cryptography . . . . . . . . . . . . . 8 79 2.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 80 2.4. Instantiating the Random Function . . . . . . . . . . . . 9 81 2.5. Key Derivation Function . . . . . . . . . . . . . . . . . 10 82 2.6. Random Numbers . . . . . . . . . . . . . . . . . . . . . . 10 83 2.7. Representation and Processing of Input Strings . . . . . . 11 84 2.7.1. Identity Strings . . . . . . . . . . . . . . . . . . . 11 85 2.7.2. Passwords . . . . . . . . . . . . . . . . . . . . . . 11 86 2.8. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 2.8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12 88 2.8.2. Message Flows . . . . . . . . . . . . . . . . . . . . 12 89 2.8.3. Fixing the Password Element . . . . . . . . . . . . . 14 90 2.8.3.1. ECC Operation for PWE . . . . . . . . . . . . . . 14 91 2.8.3.2. FFC Operation for pwe . . . . . . . . . . . . . . 16 92 2.8.4. Message Construction . . . . . . . . . . . . . . . . . 17 93 2.8.4.1. ECC Groups . . . . . . . . . . . . . . . . . . . . 17 94 2.8.4.2. FFC Groups . . . . . . . . . . . . . . . . . . . . 18 95 2.8.5. Message Processing . . . . . . . . . . . . . . . . . . 19 96 2.8.5.1. EAP-pwd-ID Exchange . . . . . . . . . . . . . . . 19 97 2.8.5.2. EAP-pwd-Commit Exchange . . . . . . . . . . . . . 21 98 2.8.5.3. EAP-pwd-Confirm Exchange . . . . . . . . . . . . . 22 99 2.9. Management of EAP-pwd Keys . . . . . . . . . . . . . . . . 23 100 2.10. Mandatory-to-Implement Parameters . . . . . . . . . . . . 24 101 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 24 102 3.1. EAP-pwd Header . . . . . . . . . . . . . . . . . . . . . . 24 103 3.2. EAP-pwd Payloads . . . . . . . . . . . . . . . . . . . . . 26 104 3.2.1. EAP-pwd-ID . . . . . . . . . . . . . . . . . . . . . . 26 105 3.2.2. EAP-pwd-Commit . . . . . . . . . . . . . . . . . . . . 27 106 3.2.3. EAP-pwd-Confirm . . . . . . . . . . . . . . . . . . . 28 107 3.3. Representation of Group Elements and Scalars . . . . . . . 29 108 3.3.1. Elements in FFC Groups . . . . . . . . . . . . . . . . 29 109 3.3.2. Elements in ECC Groups . . . . . . . . . . . . . . . . 29 110 3.3.3. Scalars . . . . . . . . . . . . . . . . . . . . . . . 29 111 4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 30 112 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 113 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 114 6.1. Resistance to Passive Attack . . . . . . . . . . . . . . . 32 115 6.2. Resistance to Active Attack . . . . . . . . . . . . . . . 33 116 6.3. Resistance to Dictionary Attack . . . . . . . . . . . . . 33 117 6.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 35 118 6.5. Random Functions . . . . . . . . . . . . . . . . . . . . . 35 119 7. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 36 120 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 121 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 122 9.1. Normative References . . . . . . . . . . . . . . . . . . . 39 123 9.2. Informative References . . . . . . . . . . . . . . . . . . 40 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 126 1. Introduction 128 1.1. Background 130 The predominant access method for the Internet today is that of a 131 human using a username and password to authenticate to a computer 132 enforcing access control. Proof of knowledge of the password 133 authenticates the human and computer. 135 Typically these passwords are not stored on a user's computer for 136 security reasons and must be entered each time the human desires 137 network access. Therefore the passwords must be ones that can be 138 repeatedly entered by a human with a low probability of error. They 139 will likely not possess high-entropy and it may be assumed that an 140 adversary with access to a dictionary will have the ability to guess 141 a user's password. It is therefore desirable to have a robust 142 authentication method that is secure even when used with a weak 143 password in the presence of a strong adversary. 145 EAP-pwd is an EAP method that addresses the problem of password-based 146 authenticated key exchange-- using a possibly weak password for 147 authentication to derive an authenticated and cryptographically 148 strong shared secret. This problem was first described by Bellovin 149 and Merritt in [BM92] and [BM93]. There have been a number of 150 subsequent suggestions ([JAB96], [LUC97], [BMP00], and others) for 151 password-based authenticated key exchanges. 153 1.2. Keyword Definitions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 1.3. Requirements 161 Any protocol that claims to solve the problem of password- 162 authenticated key exchange must be resistant to active, passive and 163 dictionary attack and have the quality of forward secrecy. These 164 characteristics are discussed further in the following sections. 166 1.3.1. Resistance to Passive Attack 168 A passive, or benign, attacker is one that merely relays messages 169 back and forth between the peer and server, faithfully, and without 170 modification. The contents of the messages are available for 171 inspection, but that is all. To achieve resistance to passive 172 attack, such an attacker must not be able to obtain any information 173 about the password or anything about the resulting shared secret from 174 watching repeated runs of the protocol. Even if a passive attacker 175 is able to learn the password, she will not be able to determine any 176 information about the resulting secret shared by the peer and server. 178 1.3.2. Resistance to Active Attack 180 An active attacker is able to modify, add, delete, and replay 181 messages sent between protocol participants. For this protocol to be 182 resistant to active attack, the attacker must not be able to obtain 183 any information about the password or the shared secret by using any 184 of its capabilities. In addition, the attacker must not be able to 185 fool a protocol participant into thinking that the protocol completed 186 successfully. 188 It is always possible for an active attacker to deny delivery of a 189 message critical in completing the exchange. This is no different 190 than dropping all messages and is not an attack against the protocol. 192 1.3.3. Resistance to Dictionary Attack 194 For this protocol to be resistant to dictionary attack any advantage 195 an adversary can gain must be directly related to the number of 196 interactions she makes with an honest protocol participant and not 197 through computation. The adversary will not be able to obtain any 198 information about the password except whether a single guess from a 199 single protocol run is correct or incorrect. 201 1.3.4. Forward Secrecy 203 Compromise of the password must not provide any information about the 204 secrets generated by earlier runs of the protocol. 206 2. Specification of EAP-pwd 208 2.1. Notation 210 The following notation is used in this memo: 212 peer-ID 213 The peer's identity, the peer NAI [RFC4282]. 215 server-ID 216 A string that identifies the server to the peer. 218 password 219 The password shared between the peer and server. 221 y = H(x) 222 The binary string x is given to a function H which produces a 223 fixed-length output y. 225 a | b 226 denotes concatenation of string a with string b. 228 [a]b 229 indicates a string consisting of the single bit "a" repeated "b" 230 times. 232 x mod y 233 indicates the remainder of division of x by y. The result will 234 be between 0 and y. 236 g^x mod p 237 indicates multiplication of the value "g" with itself "x" times, 238 modulo the value "p". 240 inv(Q) 241 indicates the inverse of an element, Q, from a finite field. 243 len(x) 244 indicates the length in bits of the string x. 246 chop(x, y) 247 is reduction of string x, being at least y bits in length, to y 248 bits. 250 PRF(x,y) 251 is a pseudo-random function that takes a key, x, and variable- 252 length data, y, and produces a fixed-length output that cannot be 253 distinguished (with a significant advantage) from a random 254 source. 256 LSB(x) 257 returns the least-significant bit of the bitstring "x". 259 CipherSuite 260 an encoding of a group to use with EAP-pwd, the definition of 261 function H, and a PRF, in that order. 263 MSK 264 The Master Session Key exported by EAP-pwd. This is a high- 265 entropy secret 512 bits in length. 267 EMSK 268 The Extended Master Session Key exported by EAP-pwd. This is a 269 high-entropy secret 512 bits in length. 271 2.2. Discrete Logarithm Cryptography 273 This protocol uses Discrete Logarithm Cryptography to achieve 274 authentication and key agreement (see [SP800-56A]). Each party to 275 the exchange derives ephemeral public and private keys with respect 276 to a particular set of domain parameters (referred to here as a 277 "group"). A group can be based on Finite Field Cryptography (FFC) or 278 Elliptic Curve Cryptography (ECC). 280 2.2.1. Finite Field Cryptography 282 Domain parameters for the FFC groups used by EAP-pwd include: 284 o A prime, p, determining a prime field GF(p), the integers modulo 285 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 286 group of non-zero elements in GF(p). The group operation for FFC 287 groups is multiplication modulo p. 289 o An element, G, in GF(p)* which serves as a generator for the FFC 290 group. G is chosen such that its multiplicative order is a 291 sufficiently large prime divisor of ((p-1)/2). 293 o A prime, r, which is the multiplicative order of G, and thus also 294 the size of the cryptographic subgroup of GF(p)* that is generated 295 by G. 297 An integer scalar, x, acts on an FFC group element, Y, via 298 exponentiation modulo p-- Y^x mod p. 300 The inverse function for an FFC group is defined such that the 301 product of an element and its inverse modulo the group prime equals 302 one (1). In other words, 304 (q * inv(q)) mod p = 1 306 EAP-pwd uses an IANA registry for the definition of groups. Some FFC 307 groups in this registry are based on safe primes and the order is not 308 included in the domain parameters. In this case only, the order, r, 309 MUST be computed as the prime minus one divided by two-- (p-1)/2. If 310 the definition of the group includes an order in its domain 311 parameters, that value MUST be used in this exchange when an order is 312 called for. If an FFC group definition does not have an order in its 313 domain parameters and it is not based on a safe prime it MUST NOT be 314 used with EAP-pwd. 316 2.2.2. Elliptic Curve Cryptography 318 Domain parameters for the ECC groups used by EAP-pwd include: 320 o A prime, p, determining a prime field GF(p). The cryptographic 321 group will be a subgroup of the full elliptic curve group which 322 consists points on an elliptic curve-- elements from GF(p) that 323 satisfy the curve's equation-- together with the "point at 324 infinity" that serves as the identity element. The group 325 operation for ECC groups is addition of points on the elliptic 326 curve. 328 o Elements a and b from GF(p) that define the curve's equation. The 329 point (x,y) in GF(p) x GF(p) is on the elliptic curve if and only 330 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 332 o A point, G, on the elliptic curve, which serves as a generator for 333 the ECC group. G is chosen such that its order, with respect to 334 elliptic curve addition, is a sufficiently large prime. 336 o A prime, r, which is the order of G, and thus is also the size of 337 the cryptographic subgroup that is generated by G. 339 o A co-factor, f, defined by the requirement that the size of the 340 full elliptic curve group (including the "point at infinity") is 341 the product of f and r. 343 An integer scalar, x, acts on an ECC group element, Y, via repetitive 344 addition: Y is added to itself x times. 346 The inverse function for an ECC group is defined such that the sum of 347 an element and its inverse is the "point at infinity" (the identity 348 for elliptic curve point addition). In other words, 350 Q + inv(Q) = "O" 352 Only ECC groups over GF(p) can be used by EAP-pwd. ECC groups over 353 GF(2^m) SHALL NOT be used by EAP-pwd. While such groups exist in the 354 IANA registry used by EAP-pwd their use in EAP-pwd is not defined. 356 2.3. Assumptions 358 In order to see how the protocol addresses the requirements above 359 (see Section 1.3) it is necessary to state some assumptions under 360 which the protocol can be evaluated. They are: 362 1. Function H maps a binary string of indeterminate length onto a 363 fixed binary string that is x bits in length. 365 H: {0,1}^* --> {0,1}^x 367 2. Function H is a "random oracle" (see [RANDOR]). Given knowledge 368 of the input to H an adversary is unable to distinguish the 369 output of H from a random data source. 371 3. Function H is a one-way function. Given the output of H it is 372 computationally infeasible for an adversary to determine the 373 input. 375 4. For any given input to function H each of the 2^x possible 376 outputs are equally probable. 378 5. The discrete logarithm problem for the chosen group is hard. 379 That is, given g, p and y = g^x mod p it is computationally 380 infeasible to determine x. Similarly for an ECC group given the 381 curve definition, a generator G, and Y = x * G it is 382 computationally infeasible to determine x. 384 6. There exists a pool of passwords from which the password shared 385 by the peer and server is drawn. This pool can consist of words 386 from a dictionary, for example. Each password in this pool has 387 an equal probability of being the shared password. All potential 388 attackers have access to this pool of passwords. 390 2.4. Instantiating the Random Function 392 The protocol described in this memo uses a random function, H. As 393 noted in Section 2.3 this is a "random oracle" as defined in 394 [RANDOR]. At first glance one may view this as a hash function. As 395 noted in [RANDOR], though, hash functions are too structured to be 396 used directly as a random oracle. But they can be used to 397 instantiate the random oracle. 399 The random function, H, in this memo is instantiated by HMAC-SHA256 400 (see [RFC4634]) with a key whose length is 32 octets and whose value 401 is zero. In other words, 402 H(x) = HMAC-SHA-256([0]32, x) 404 2.5. Key Derivation Function 406 The keys output by this protocol, MSK and EMSK, are each 512 bits in 407 length. The shared secret that results from the successful 408 termination of this protocol is only 256 bits. Therefore it is 409 necessary to stretch the shared secret using a key derivation 410 function (KDF). 412 The KDF used in this protocol has a counter-mode with feed-back 413 construction using a generic pseudo-random function (PRF), according 414 to [SP800-108]. The specific value of the PRF is specified along 415 with the random function and group when the server sends the first 416 EAP-pwd packet to the peer. 418 The KDF takes a key to stretch, a label to bind into the key, and an 419 indication of the desired length of the output in bits. It uses two 420 internal variables, i and L, each of which is 16-bits in length and 421 is represented in network order. Algorithmically it is: 423 KDF(key, label, length) { 424 i = 1 425 L = length 426 K(1) = PRF(key, i | label | L) 427 res = K(1) 428 while (len(res) < length) 429 do 430 i = i + 1 431 K(i) = PRF(key, K(i-1) | i | label | L) 432 res = res | K(i) 433 done 434 return chop(res, length) 435 } 437 Figure 1: Key Derivation Function 439 2.6. Random Numbers 441 The security of EAP-pwd relies upon each side, the peer and server, 442 producing quality secret random numbers. A poor random number chosen 443 by either side in a single exchange can compromise the shared secret 444 from that exchange and open up the possibility of dictionary attack. 446 Producing quality random numbers without specialized hardware entails 447 using a cryptographic mixing function (like a strong hash function) 448 to distill entropy from multiple, uncorrelated sources of information 449 and events. A very good discussion of this can be found in 451 [RFC4086]. 453 2.7. Representation and Processing of Input Strings 455 2.7.1. Identity Strings 457 The strings representing the server identity and peer identity MUST 458 follow the requirements of [RFC4282] for Network Access Identifiers. 459 This ensures a canonical representation of identities by both ends of 460 the conversation prior to their use in EAP-pwd. 462 2.7.2. Passwords 464 EAP-pwd requires passwords be input as binary strings. For the 465 protocol to successfully terminate each side must produce identical 466 binary strings from the password. This imposes processing 467 requirements on a password prior to its use. 469 Three techniques for password pre-processing exist for EAP-pwd: 471 o None: The input password string SHALL be treated as an ASCII 472 string or a hexidecimal string with no treatment or normalization 473 performed. The output SHALL be the binary representation of the 474 input string. 476 o RFC2759: The input password string SHALL be processed to produce 477 the output PasswordHashHash, as defined in [RFC2759], including 478 any approved errata to [RFC2759]. This technique is useful when 479 the server does not have access to the plaintext password. 481 o SASLprep: The input password string is processed according to the 482 rules of the [RFC4013] profile of [RFC3454]. A password SHALL be 483 considered a "stored string" per [RFC3454] and unassigned code 484 points are therefore prohibited. The output SHALL be the binary 485 representation of the processed UTF-8 character string. 486 Prohibited output and unassigned codepoints encountered in 487 SASLprep pre-processing SHALL cause a failure of pre-processing 488 and the output SHALL NOT be used with EAP-pwd. 490 Changing a password is out-of-scope of EAP-pwd but due to the 491 ambiguities in the way internationalized character strings are 492 handled it SHOULD be done using SASLprep ensure a canonical 493 representation of the new password is stored on the server and 494 subsequent invocations of EAP-pwd SHOULD use SASLprep to ensure that 495 the client generates an identical binary string from the input 496 password. 498 2.8. Protocol 500 2.8.1. Overview 502 EAP is a two-party protocol spoken between an EAP peer and an 503 authenticator. For scaling purposes the functionality of the 504 authenticator that speaks EAP is frequently broken out into a stand- 505 alone EAP server. In this case the EAP peer communicates with an EAP 506 server through the authenticator with the authenticator merely being 507 a passthrough. 509 An EAP method defines the specific authentication protocol being used 510 by EAP. This memo defines a particular method and therefore defines 511 the messages sent between the EAP server (or the "EAP server" 512 functionality in an authenticator if it is not broken out) and the 513 EAP peer for the purpose of authentication and key derivation. 515 2.8.2. Message Flows 517 EAP-pwd defines three message exchanges, an Identity exchange, a 518 Commit exchange and a Confirm exchange. A successful authentication 519 is shown in Figure 2. 521 The peer and server use the Identity exchange to discover each 522 other's identities and to agree upon a ciphersuite to use in the 523 subsequent exchanges; in addition, the EAP Server uses the EAP-pwd- 524 ID/Request message to inform the client of any password preprocessing 525 that may be required. In the Commit exchange the peer and server 526 exchange information to generate a shared key and also to bind each 527 other to a particular guess of the password. In the Confirm exchange 528 the peer and server prove liveness and knowledge of the password by 529 generating and verifying verification data. 531 +--------+ +--------+ 532 | | EAP-pwd-ID/Request | | 533 | EAP |<------------------------------------| EAP | 534 | peer | | server | 535 | | EAP-pwd-ID/Response | | 536 | |------------------------------------>| | 537 | | | | 538 | | EAP-pwd-Commit/Request | | 539 | |<------------------------------------| | 540 | | | | 541 | | EAP-pwd-Commit/Response | | 542 | |------------------------------------>| | 543 | | | | 544 | | EAP-pwd-Confirm/Request | | 545 | |<------------------------------------| | 546 | | | | 547 | | EAP-pwd-Confirm/Response | | 548 | |------------------------------------>| | 549 | | | | 550 | | EAP-Success | | 551 | |<------------------------------------| | 552 +--------+ +--------+ 554 Figure 2: A Successful EAP-pwd Exchange 556 The components of the EAP-pwd-* messages are as follows: 558 EAP-pwd-ID/Request 559 Ciphersuite, Token, Password Processing Method, Server_ID 561 EAP-pwd-ID/Response 562 Ciphersuite, Token, Password Processing Method, Peer_ID 564 EAP-pwd-Commit/Request 565 Scalar_S, Element_S 567 EAP-pwd-Commit/Response 568 Scalar_P, Element_P 570 EAP-pwd-Confirm/Request 571 Confirm_S 573 EAP-pwd-Confirm/Response 574 Confirm_P 576 2.8.3. Fixing the Password Element 578 Once the EAP-pwd-ID exchange is completed the peer and server use 579 each other's identities and the agreed upon ciphersuite to fix an 580 element in the negotiatied group called the Password Element (PWE or 581 pwe, for an element in an ECC group or an FFC group, respectively). 582 The resulting element must be selected in a deterministic fashion 583 using the password but must result in selection of an element that 584 will not leak any information on the password to an attacker. From 585 the point-of-view of an attacker who does not know the password, PWE 586 will be a random element. 588 To properly fix the Password Element both parties must have a common 589 view of the string "password". Therefore, if a password 590 preprocessing algorithm was negotiated during the EAP-pwd-ID exchange 591 the client MUST perform the specified password pre-processing prior 592 to fixing the Password Element. 594 Fixing the Password Element involves an iterative hunting-and-pecking 595 technique using the prime from the negotiated group's domain 596 parameter set and an ECC- or FFC-specific operation depending on the 597 negotiated group. 599 First, an 8-bit counter is set to the value one (1). Then, the 600 agreed upon random function is used to generate a password seed from 601 the identities and the anti-clogging token from the EAP-pwd-ID 602 exchange (see Section 2.8.5.1): 604 pwd-seed = H(token | peer-ID | server-ID | password | counter) 606 Then, the pwd-seed is expanded using the KDF from the agreed-upon 607 Ciphersuite out to the length of the prime: 609 pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) 611 If the pwd-value is greater than or equal to the prime, p, the 612 counter is incremented, and a new pwd-seed is generated and the 613 hunting-and-pecking continues. If pwd-value is less than the prime, 614 p, it is passed to the group-specific operation to select the 615 Password Element or fail. If the group-specific operation fails, the 616 counter is incremeneted, a new pwd-seed is generated and the hunting- 617 and-pecking continues. 619 2.8.3.1. ECC Operation for PWE 621 The group-specific operation for ECC groups uses pwd-value, pwd-seed, 622 and the equation for the curve to produce the Password Element. 623 First, pwd-value is used directly as the x-coordinate, x, with the 624 equation for the elliptic curve, with parameters a and b from the 625 domain parameter set of the curve, to solve for a y-coordinate, y. 626 If there is no solution to the quadratic equation this operation 627 fails and the hunting-and-pecking process continues. If a solution 628 is found then an ambiguity exists as there are technically two 629 solutions to the equation and pwd-seed is used to unambiguously 630 select one of them. If the low-order bit of pwd-seed is equal to the 631 low-order bit of y then a candidate PWE is defined as the point (x, 632 y); if the low-order bit of pwd-seed differs from the low-order bit 633 of y then a candidate PWE is defined as the point (x, p - y), where p 634 is the prime over which the curve is defined. If the co-factor 635 equals 1 then the candidate PWE becomes the PWE and hunting and 636 pecking terminates successfully. If the co-factor of the curve is 637 not equal to one, the candidate PWE is multiplied by the co-factor to 638 produce another candidate PWE. If this candidate PWE is equal to the 639 point-at-infinity then this operation fails and the hunting-and- 640 pecking process continues. If it does not equal the point-at- 641 infinity the candidate PWE becomes the PWE and hunting and pecking 642 terminates successfully. 644 Algorithmically, the process looks like this: 646 found = 0 647 counter = 1 648 do { 649 pwd-seed = H(token | peer-ID | server-ID | password | counter) 650 pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) 651 if (pwd-value < p) 652 then 653 x = pwd-value 654 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 655 then 656 if (LSB(y) == LSB(pwd-seed)) 657 then 658 PWE = (x,y) 659 else 660 PWE = (x, p-y) 661 fi 662 if (f == 1) 663 then 664 found = 1 665 else 666 PWE = f*PWE 667 if (PWE != "O") 668 then 669 found = 1 670 fi 671 fi 672 fi 673 fi 674 counter = counter + 1 675 } while (found == 0) 677 Figure 3: Fixing PWE for ECC Groups 679 2.8.3.2. FFC Operation for pwe 681 The group-specific operation for FFC groups takes pwd-value, and the 682 the prime, p, and order, r, from the group's domain parameter set 683 (see Section 2.2.1 when the order is not part of the defined domain 684 parameter set) to directly produce the Password Element, pwe, by 685 exponentiating the pwd-value to the value ((p-1)/r) modulo the prime. 687 Algorithmically, the process looks like this: 689 found = 0 690 counter = 1 691 do { 692 pwd-seed = H(token | peer-ID | server-ID | password | counter) 693 pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) 694 if (pwd-value < p) 695 then 696 pwe = pwd-value ^ ((p-1)/r) mod p 697 if (pwe > 1) 698 then 699 found = 1 700 fi 701 fi 702 counter = counter + 1 703 } while (found == 0) 705 Figure 4: Fixing PWE for FFC Groups 707 2.8.4. Message Construction 709 After the EAP-pwd Identity exchange the construction of the 710 components of subsequent messages depends on the type of group from 711 the ciphersuite (ECC or FFC). This section provides an overview of 712 the authenticated key exchange. For a complete description of 713 message generation and processing see Section 2.8.5.2 and 714 Section 2.8.5.3. 716 2.8.4.1. ECC Groups 718 Using the mapping function F() defined in Section 2.2.2 and the group 719 order r: 721 Server: EAP-pwd-Commit/Request 722 - choose two random numbers, 1 < s_rand, s_mask < r 723 - compute Scalar_S = (s_rand + s_mask) mod r 724 - compute Element_S = inv(s_mask * PWE) 726 Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request 728 Peer: EAP-pwd-Commit/Response 729 - choose two random numbers, 1 < p_rand, p_mask < r 730 - compute Scalar_P = (p_rand + p_mask) mod r 731 - compute Element_P = inv(p_mask * PWE) 733 Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response 735 Server: EAP-pwd-Confirm/Request 736 - compute KS = (s_rand * (Scalar_P * PWE + Element_P)) 737 - if f > 1, KS = f * KS 738 - compute ks = F(KS) 739 - compute Confirm_S = H(ks | Element_S | Scalar_S | 740 Element_P | Scalar_P | Ciphersuite) 742 Confirm_S is used to construct EAP-pwd-Confirm/Request 744 Peer: EAP-pwd-Confirm/Response 745 - compute KP = (p_rand * (Scalar_S * PWE + Element_S)), 746 - if f > 1, KP = f * KP 747 - compute kp = F(KP) 748 - compute Confirm_P = H(kp | Element_P | Scalar_P | 749 Element_S | Scalar_S | Ciphersuite) 751 Confirm_P is used to construct EAP-pwd-Confirm/Response 753 The EAP Server computes the shared secret as: 754 MK = H(ks | Confirm_P | Confirm_S) 756 The EAP Peer computes the shared secret as: 757 MK = H(kp | Confirm_P | Confirm_S) 759 The MSK and EMSK are derived from MK per Section 2.9. 761 2.8.4.2. FFC Groups 763 There is no mapping function, F(), required for an FFC group. Using 764 the order, r, for the group (see Section 2.2.1 when the order is not 765 part of the defined domain parameters): 767 Server: EAP-pwd-Commit/Request 768 - choose two random numbers, 1 < s_rand, s_mask < r 769 - compute Scalar_S = (s_rand + s_mask) mod r 770 - compute Element_S = inv(pwe^s_mask mod p) 772 Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request 774 Peer: EAP-pwd-Commit/Response 775 - choose random two numbers, 1 < p_rand, p_mask < r 776 - compute Scalar_P = (p_rand + p_mask) mod r 777 - compute Element_P = inv(pwe^p_mask mod p) 779 Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response 781 Server: EAP-pwd-Confirm/Request 782 - compute ks = ((pwe^Scalar_P mod p) * Element_P)^s_rand mod p 783 - compute Confirm_S = H(ks | Element_S | Scalar_S | 784 Element_P | Scalar_P | Ciphersuite) 786 Confirm_S is used to construct EAP-pwd-Confirm/Request 788 Peer: EAP-pwd-Confirm/Response 789 - compute kp = ((pwe^Scalar_S mod p) * Element_S)^p_rand mod p 790 - compute Confirm_P = H(kp | Element_P | Scalar_P | 791 Element_S | Scalar_S | Ciphersuite) 793 Confirm_P is used to construct EAP-pwd-Confirm/Request 795 The EAP Server computes the shared secret as: 796 MK = H(ks | Confirm_P | Confirm_S) 798 The EAP Peer computes the shared secet as: 799 MK = H(kp | Confirm_P | Confirm_S) 801 The MSK and EMSK derived from MK per Section 2.9. 803 2.8.5. Message Processing 805 2.8.5.1. EAP-pwd-ID Exchange 807 Although EAP provides an Identity method to determine the identity of 808 the peer, the value in the Identity Response may have been truncated 809 or obfuscated to provide privacy or decorated for routing purposes 810 [RFC3748], making it inappropriate for usage by the EAP-pwd method. 811 Therefore, the EAP-pwd-ID exchange is defined for the purpose of 812 exchanging identities between the peer and server. 814 The EAP-pwd-ID/Request contains the following quantities: 816 o a ciphersuite 818 o a representation of the server's identity per Section 2.7.1 820 o an anti-clogging token 822 o a password pre-processing method 824 The ciphersuite specifies the finite cyclic group, random function 825 and PRF selected by the server for use in the subsequent 826 authentication exchange. 828 The value of the anti-clogging token MUST be unpredictable and SHOULD 829 NOT be from a source of random entropy. The purpose of the anti- 830 clogging token is to provide the server an assurance that the peer 831 constructing the EAP-pwd-ID/Response is genuine and not part of a 832 flooding attack. 834 A password pre-processing method is communicated to ensure 835 interoperability by producing a canonical representation of the 836 password string between the peer and server (see Section 2.7.2). 838 The EAP-pwd-ID/Request is constructed according to Section 3.2.1 and 839 is transmitted to the peer. 841 Upon receipt of an EAP-pwd-ID/Request, the peer determines whether 842 the ciphersuite and pre-processing method are acceptable. If not, 843 the peer MUST respond with an EAP-NAK. If acceptable, the peer 844 responds to the EAP-pwd-ID/Request, constructed according to 845 Section 3.2.1, that acknowledges the Ciphersuite, token, and pre- 846 processing method and then adds its identity. After sending the EAP- 847 pwd-ID/Response, the peer has the identity of the server (from the 848 Request), its own identity (it encoded in the Response), a password 849 preprocessing algorithm, and it can compute the password element as 850 specified in Section 2.8.3. The password element is stored in state 851 allocated for this exchange. 853 The EAP-pwd-ID/Response acknowledges the Ciphersuite from the 854 Request, acknowledges the anti-clogging token from the Request 855 providing a demonstration of "liveness" on the part of the peer, and 856 contains the identity of the peer. Upon receipt of the Response, the 857 server verifies that the Ciphersuite acknowledged by the peer is the 858 same as that sent in the Request and that the token added by the peer 859 in the Response is the same as the one the server sent in the 860 Request. If Ciphersuites or tokens differ, the server MUST respond 861 with an EAP-Failure message. If the Ciphersuites are the same, the 862 server now knows its own identity (it encoded in the Request) and the 863 peer's identity (from the Response) and can compute the password 864 element according to Section 2.8.3. The server stores the password 865 element in state it has allocated for this exchange. The server then 866 initiates an EAP-pwd-Commit exchange. 868 2.8.5.2. EAP-pwd-Commit Exchange 870 The server begins the EAP-pwd-Confirm exchange by choosing two random 871 numbers, s_rand and s_mask, between 1 and r (where r is described in 872 Section 2.1 according to the group established in Section 2.8.5.1) 873 such that their sum modulo r is greater than one (1). It then 874 computes Element_S and Scalar_S as defined in Section 2.8.4 and 875 constructs an EAP-pwd-Commit/Request according to Section 3.2.2. 876 Element_S and Scalar_S are added to the state allocated for this 877 exchange and the EAP-pwd-Commit/Request is transmitted to the peer. 879 Upon receipt of the EAP-pwd-Commit/Request, the peer validates the 880 length of the entire payload based upon the expected lengths of 881 Element_S and Scalar_S (which are fixed according to the length of 882 the agreed-upon group). If the length is incorrect, the peer MUST 883 terminate the exchange. If the length is correct, Element_S and 884 Scalar_S are extracted from the EAP-pwd-Commit/Request. Scalar_S is 885 then checked to ensure it is between 1 and r, exclusive. If it is 886 not the peer MUST terminate the exchange. If it is, Element_S MUST 887 be validated depending on the type of group-- Element validation for 888 FFC groups is described in Section 2.8.5.2.1 and Element validation 889 for ECC groups is described in Section 2.8.5.2.2. If validation is 890 successful the peer chooses two random numbers, p_rand and p_mask, 891 between 1 and r (where r is described in Section 2.1 according to the 892 group established in Section 2.8.5.1) such that their sum modulo r is 893 greater than one (1), and computes Element_P and Scalar_P. Next, the 894 peer computes kp from p_rand, Element_S, Scalar_S and the password 895 element according to Section 2.8.4. If kp is the the "identity 896 element"-- the point at infinity for an ECC group or the value one 897 (1) for an FFC group-- the peer MUST terminate the exchange. If not, 898 the peer uses Element_P and Scalar_P to construct an EAP-pwd-Commit/ 899 Response according to Section 3.2.2 and transmits the EAP-pwd-Commit/ 900 Response to the server. 902 Upon receipt of the EAP-pwd-Commit/Response, the server validates the 903 length of the entire payload based upon the expected lengths of 904 Element_P and Scalar_P (which are fixed according to the agreed-upon 905 group). If the length is incorrect, the server MUST respond with an 906 EAP-Failure message and it MUST terminate the exchange and free up 907 any state allocated. If the length is correct, Scalar_P and 908 Element_P are extracted from the EAP-pwd-Commit/Response and compared 909 to Scalar_S and Element_S. If Scalar_P equals Scalar_S and Element_P 910 equals Element_S it indicates a reflection attack and the server MUST 911 respond with an EAP-failure and terminate the exchange. If they 912 differ Scalar_P is checked to ensure it is between 1 and r, 913 exclusive. If not the server MUST respond with an EAP-failure and 914 terminate the exchange. If it is, Element_P is verified depending on 915 the type of group-- Element validation for FFC groups is described in 916 Section 2.8.5.2.1 and Element validation for ECC groups is described 917 in Section 2.8.5.2.2. If validation is successful the server 918 computes ks from s_rand, Element_P, Scalar_P and the password element 919 according to Section 2.8.4. If ks is the "identity element"-- the 920 point at infinity for an ECC group or the value one (1) for an FFC 921 group-- the server MUST respond with an EAP-failure and terminate the 922 exchange. Otherwise, the server initiates an EAP-pwd-Confirm 923 exchange. 925 2.8.5.2.1. Element Validation for FFC Groups 927 A received FFC Element is valid if: 1) it is between one (1) and the 928 prime, p, exclusive; and 2) if modular exponentiation of the Element 929 by the group order, r, equals one (1). If either of these conditions 930 are not true the received Element is invalid. 932 2.8.5.2.2. Element Validation for ECC Groups 934 Validating a received ECC Element involves: 1) checking whether the 935 two coordinates, x and y, are both greater than zero (0) and less 936 than the prime defining the underlying field; and 2) checking whether 937 the x- and y-coordinates satisfy the equation of the curve (that is, 938 that they produce a valid point on the curve that is not the point- 939 at-infinity). If either of these conditions are not met the received 940 Element is invalid, otherwise the co-factor multiplication test MUST 941 be performed. 943 If the co-factor of the group, f, equals one (1) and both checks 1) 944 and 2) above have been successfully completed then the Element is 945 valid. If the co-factor is greater than one (1), a scalar 946 multiplication of the received Element and the co-factor is 947 performed. If the result, f * Element, is "O" (the point-at- 948 infinity) then the received Element is invalid, otherwise the 949 received Element is declared to be valid. Note: the received Element 950 is not modified; the product of f and the Element is thrown away 951 after performing this check. 953 2.8.5.3. EAP-pwd-Confirm Exchange 955 The server computes Confirm_S according to Section 2.8.4 and 956 constructs an EAP-pwd-Confirm/Request according to Section 3.2.3 and 957 sends the EAP-pwd-Confirm/Request to the peer. 959 Upon receipt of an EAP-pwd-Confirm/Request, the peer validates the 960 length of the entire payload based upon the expected length of 961 Confirm_S (whose length is fixed by the agreed-upon random function). 962 If the length is incorrect, the peer MUST terminate the exchange and 963 free up any state allocated. If the length is correct, the peer 964 verifies that Confirm_S is the value it expects based on the value of 965 kp. If the value of Confirm_S is incorrect, the peer MUST terminate 966 the exchange and free up any state allocated. If the value of 967 Confirm_S is correct, the peer computes Confirm_P, constructs an EAP- 968 pwd-Confirm/Response according to Section 3.2.3 and sends it off to 969 the server. The peer then computes MK (according to Section 2.8.4) 970 and the MSK and EMSK (according to Section 2.9) and stores these keys 971 in state allocated for this exchange. The peer SHOULD export the MSK 972 and EMSK at this time in anticipation of a secure association 973 protocol by the lower-layer to create session keys. Alternately, the 974 peer can wait until an EAP-success message from the server before 975 exporting the MSK and EMSK. 977 Upon receipt of an EAP-pwd-Confirm/Response, the server validates the 978 length of the entire payload based upon the expected length of 979 Confirm_P (whose length is fixed by the agreed-upon random function). 980 If the length is incorrect, the server MUST respond with an EAP- 981 Failure message and it MUST terminate the exchange and free up any 982 state allocated. If the length is correct, the server verifies that 983 Confirm_P is the value it expects based on the value of ks. If the 984 value of Confirm_P is incorrect, the server MUST respond with an EAP- 985 Failure message. If the value of Confirm_P is correct, the server 986 computes MK (according to Section 2.8.4) and the MSK and EMSK 987 (according to Section 2.9). It exports the MSK and EMSK and responds 988 with an EAP-success message. The server SHOULD free up state 989 allocated for this exchange. 991 2.9. Management of EAP-pwd Keys 993 [RFC5247] recommends each EAP method define how to construct a 994 Method-ID and Session-ID to identify a particular EAP session between 995 a peer and server. This information is constructed thusly: 997 Method-ID = H(Ciphersuite | Scalar_P | Scalar_S) 999 Session-ID = Type-Code | Method-ID 1001 where Ciphersuite, Scalar_P and Scalar_S are from the specific 1002 exchange being identified; H is the random function specified in the 1003 Ciphersuite; and, Type-Code is the code assigned for EAP-pwd, TBD, 1004 represented as a single octet. 1006 The authenticated key exchange of EAP-pwd generates a shared and 1007 authenticated key, MK. The size of MK is dependent on the random 1008 function, H, asserted in the Ciphersuite. EAP-pwd must export two 1009 512-bit keys, MSK and EMSK. Regardless of the value of len(MK) 1010 implementations MUST invoke the KDF defined in Section 2.5 to 1011 construct the MSK and EMSK. The MSK and EMSK are derived thusly: 1013 MSK | EMSK = KDF(MK, Session-ID, 1024) 1015 [RFC4962] mentions the importance of naming keys, particularly when 1016 key caching is being used. To facilitate such an important 1017 optimization, names are assigned thusly: 1019 o EMSK-name = Session-ID | 'E' | 'M'| 'S' | 'K' 1021 o MSK-name = Session-ID | 'M'| 'S' | 'K' 1023 where 'E' is a single octet of value 0x45, 'M' is a single octet of 1024 value 0x4d, 'S' is a single octet of value 0x53, and 'K' is a single 1025 octet of value 0x4b. 1027 This naming scheme allows for key management applications to quickly 1028 and accurately identify keys for a particular session or all keys of 1029 a particular type. 1031 2.10. Mandatory-to-Implement Parameters 1033 For the purposes of interoperability, compliant EAP-pwd 1034 implementations SHALL support the following parameters: 1036 o Diffie-Hellman Group: groups 14 and 19 1038 o Random Function: defined in Section 2.4 1040 o PRF: HMAC-SHA256 defined in [RFC4634] 1042 o Password Pre-Processing: none 1044 3. Packet Formats 1046 3.1. EAP-pwd Header 1048 The EAP-pwd header has the following structure: 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Code | Identifier | Length | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Type |L|M| PWD-Exch | Total-Length | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Data... 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 Figure 5: EAP-pwd Header 1062 Code 1064 Either 1 (for Request) or 2 (for Response); see [RFC3748]. 1066 Identifier 1068 The Identifier field is one octet and aids in matching responses 1069 with requests. The Identifier field MUST be changed on each 1070 Request packet. 1072 Length 1074 The Length field is two octets and indicates the length of the EAP 1075 packet including the Code, Identifier, Length, Type, and Data 1076 fields. Octets outside the range of the Length field should be 1077 treated as Data Link Layer padding and MUST be ignored on 1078 reception. 1080 Type 1082 TBD - EAP-pwd 1084 L and M bits 1086 The L bit (Length included) is set to indicate the presence of the 1087 two-octet Total-Length field, and MUST be set for the first 1088 fragment of a fragmented EAP-pwd message or set of messages. 1090 The M bit (more fragments) is set on all but the last fragment. 1092 PWD-Exch 1094 The PWD-Exch field identifies the type of EAP-pwd payload 1095 encapsulated in the Data field. This document defines the 1096 following values for the PWD-Exch field: 1098 * 0x00 : Reserved 1100 * 0x01 : EAP-pwd-ID exchange 1102 * 0x02 : EAP-pwd-Commit exchange 1104 * 0x03 : EAP-pwd-Confirm exchange 1106 All other values of the PWD-Exch field are reserved to IANA. 1108 Total-Length 1110 The Total-Length field is two octets in length, and is present 1111 only if the L bit is set. This field provides the total length of 1112 the EAP-pwd message or set of messages that is being fragmented. 1114 3.2. EAP-pwd Payloads 1116 EAP-pwd payloads all contain the EAP-pwd header and encoded 1117 information. Encoded information is comprised of sequences of data. 1118 Payloads in the EAP-pwd-ID exchange also include a ciphersuite 1119 statement indicating what finite cyclic group to use, what 1120 cryptographic primitive to use for H, and what PRF to use for 1121 deriving keys. 1123 3.2.1. EAP-pwd-ID 1125 The Group Description, Random Function, and PRF together, and in that 1126 order, comprise the Ciphersuite included in the calculation of the 1127 peer's and server's confirm messages. 1129 0 1 2 3 1130 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 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Group Description | Random Func'n | PRF | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Token | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Prep | Identity... 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 Figure 6: EAP-pwd-ID Payload 1141 The Group Description field value is taken from the IANA registry for 1142 "Group Description" created by IKE [RFC2409]. 1144 This document defines the following value for the Random Function 1145 field: 1147 o 0x01 : Function defined in this memo in Section 2.4 1149 The value 0x00 is reserved for private use between mutually 1150 consenting parties. All other values of the Random Function field 1151 are reserved to IANA. 1153 The PRF field has the following value: 1155 o 0x01 : HMAC-SHA256 [RFC4634] 1157 The value 0x00 is reserved for private use between mutually 1158 consenting parties. All other values of the PRF field are reserved 1159 to IANA. 1161 The Token field contains an unpredictable value assigned by the 1162 server in an EAP-pwd-ID/Request and acknowledged by the peer in an 1163 EAP-pwd-ID/Response (see Section 2.8.5). 1165 The Prep field represents the password pre-processing technique (see 1166 Section 2.7.2) to be used by the client prior to generating the 1167 password seed (see Section 2.8.3). This document defines the 1168 following values for the Prep field: 1170 o 0x00 : None 1172 o 0x01 : RFC2759 1174 o 0x02 : SASLprep 1176 All other values of the Prep field are reserved to IANA. 1178 The Identity field depends on the value of PWD-Exch. 1180 o EAP-pwd-ID/Request : Server_ID 1182 o EAP-pwd-ID/Response : Peer_ID 1184 The length of the identity is computed from the Length field in the 1185 EAP header. 1187 3.2.2. EAP-pwd-Commit 1188 0 1 2 3 1189 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 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | | 1192 ~ Element ~ 1193 | | 1194 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | | | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 1197 | | 1198 ~ Scalar +-+-+-+-+-+-+-+-+ 1199 | | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 Figure 7: EAP-pwd-Commit Payload 1204 The Element and Scalar fields depend on the value of PWD-Exch. 1206 o EAP-pwd-Commit/Request : Element_S, Scalar_S 1208 o EAP-pwd-Commit/Response : Element_P, Scalar_P 1210 The Element is encoded according to Section 3.3. The length of the 1211 Element is inferred by the finite cyclic group from the agreed-upon 1212 Ciphersuite. The length of the scalar can then be computed from the 1213 Length in the EAP header. 1215 3.2.3. EAP-pwd-Confirm 1217 0 1 2 3 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | | 1221 ~ Confirm ~ 1222 | | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Figure 8: EAP-pwd-Confirm Payload 1227 The Confirm field depends on the value of PWD-Exch. 1229 o EAP-pwd-Confirm/Request : Confirm_S 1231 o EAP-pwd-Confirm/Response : Confirm_P 1233 The length of the Confirm field computed from the Length in the EAP 1234 header. 1236 3.3. Representation of Group Elements and Scalars 1238 Payloads in the EAP-pwd-Commit exchange contain elements from the 1239 agreed-upon finite cyclic cryptographic group (either an FCC group or 1240 an ECC group). To ensure interoperability field elements and scalars 1241 MUST be represented in payloads in accordance with the requirements 1242 described below. 1244 3.3.1. Elements in FFC Groups 1246 Elements in an FFC group MUST be represented (in binary form) as 1247 unsigned integers that are strictly less than the prime, p, from the 1248 group's domain parameter set. The binary representation of each 1249 group element MUST have a bit length equal to the bit length of the 1250 binary representation of p. This length requirement is enforced, if 1251 necessary, by prepending the binary representation of the integer 1252 with zeros until the required length is achieved. 1254 3.3.2. Elements in ECC Groups 1256 Elements in an ECC group are points on the agreed-upon elliptic 1257 curve. Each such element MUST be represented by the concatenation of 1258 two components, an x-coordinate and a y-coordinate. 1260 Each of the two components, the x-coordinate and the y-coordinate, 1261 MUST be represented (in binary form) as an unsigned integer that is 1262 strictly less than the prime, p, from the group's domain parameter 1263 set. The binary representation of each component MUST have a bit 1264 length equal to the bit length of the binary representation of p. 1265 This length requirement is enforced, if necessary, by prepending the 1266 binary representation of the integer with zeros until the required 1267 length is achieved. 1269 Since the field element is represented in a payload by the 1270 x-coordinate followed by the y-coordinate it follows, then, that the 1271 length of the element in the payload MUST be twice the bit length of 1272 p. 1274 3.3.3. Scalars 1276 Scalars MUST be represented (in binary form) as unsigned integers 1277 that are strictly less than r, the order of the generator of the 1278 agreed-upon cryptographic group. The binary representation of each 1279 scalar MUST have a bit length equal to the bit length of the binary 1280 representation of r. This requirement is enforced, if necessary, by 1281 prepending the binary representation of the integer with zeros until 1282 the required length is achieved. 1284 4. Fragmentation 1286 EAP [RFC3748] is a request-response protocol. The server sends 1287 requests and the peer responds. These request and response messages 1288 are assumed to be limited to at most 1020 bytes. Messages in EAP-pwd 1289 can be larger than 1020 bytes and therefore require support for 1290 fragmentation and reassembly. 1292 Implementations MUST establish a fragmentation threshold that 1293 indicates the maximum size of an EAP-pwd payload. When an 1294 implementation knows the maximum transmission unit (MTU) of its 1295 lower-layer, it SHOULD calculate the fragmentation threshold from 1296 that value. In lieu of knowledge of the lower-layer's MTU the 1297 fragmentation threshold MUST be set to 1020 bytes. 1299 Since EAP is a simple ACK-NAK protocol, fragmentation support can be 1300 added in a simple manner. In EAP, fragments that are lost or damaged 1301 in transit will be retransmitted, and since sequencing information is 1302 provided by the Identifier field in EAP, there is no need for a 1303 fragment offset field as is provided in IPv4. 1305 EAP-pwd fragmentation support is provided through addition of flags 1306 within the EAP-Response and EAP-Request packets, as well as a Total- 1307 Length field of two octets. Flags include the Length included (L) 1308 and More fragments (M) bits. The L flag is set to indicate the 1309 presence of the two octet Total-Length field, and MUST be set for the 1310 first fragment of a fragmented EAP-pwd message or set of messages. 1311 The M flag is set on all but the last fragment. The Total-Length 1312 field is two octets, and provides the total length of the EAP-pwd 1313 message or set of messages that is being fragmented; this simplifies 1314 buffer allocation. 1316 When an EAP-pwd peer receives an EAP-Request packet with the M bit 1317 set, it MUST respond with an EAP-Response with EAP-Type=EAP-pwd and 1318 no data. This serves as a fragment ACK. The EAP server MUST wait 1319 until it receives the EAP-Response before sending another fragment. 1320 In order to prevent errors in processing of fragments, the EAP server 1321 MUST increment the Identifier field for each fragment contained 1322 within an EAP-Request, and the peer MUST include this Identifier 1323 value in the fragment ACK contained within the EAP-Response. 1324 Retransmitted fragments will contain the same Identifier value. 1326 Similarly, when the EAP server receives an EAP-Response with the M 1327 bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-pwd 1328 and no data. This serves as a fragment ACK. The EAP peer MUST wait 1329 until it receives the EAP-Request before sending another fragment. 1330 In order to prevent errors in the processing of fragments, the EAP 1331 server MUST increment the Identifier value for each fragment ACK 1332 contained within an EAP-Request, and the peer MUST include this 1333 Identifier value in the subsequent fragment contained within an EAP- 1334 Response. 1336 5. IANA Considerations 1338 This memo contains new numberspaces to be managed by IANA. The 1339 policies used to allocate numbers are described in [RFC5226]. This 1340 memo requires IANA to allocate a new EAP method type for EAP-pwd. 1341 The placeholders indicated by "TBD" above-- sections Section 2.9 and 1342 Section 3.1-- shall be replaced by the new EAP method type upon 1343 assignment by IANA. 1345 This memo also requires IANA to create new registries for PWD-Exch 1346 messages, random functions, PRFs, and password pre-processing methods 1347 and to add the message numbers, random function, PRF, and pre- 1348 processing methods specified in this memo to those registries, 1349 respectively. 1351 The following is the initial PWD-Exch message registry layout: 1353 o 0x00 : Reserved 1355 o 0x01 : EAP-pwd-ID exchange 1357 o 0x02 : EAP-pwd-Commit exchange 1359 o 0x03 : EAP-pwd-Confirm exchange 1361 The PWD-Exch field is 6 bits long. The value 0x00 is reserved. All 1362 other values are available through assignment by IANA. IANA is 1363 instructed to assign values based on "IETF Review" (see [RFC5226]). 1365 The following is the initial Random Function registry layout: 1367 o 0x00 : Private Use 1369 o 0x01 : Function defined in this memo in Section 2.4 1371 The Random Function field is 8 bits long. The value 0x00 is for 1372 Private Use between mutually consenting parties. All other values 1373 are available through assignment by IANA. IANA is instructed to 1374 assign values based on "Specification Required" (see [RFC5226]). The 1375 Designated Expert performing the necessary review MUST ensure the 1376 random function has been cryptographically vetted. 1378 The following is the initial PRF registry layout: 1380 o 0x00 : Private Use 1382 o 0x01 : HMAC-SHA256 as defined in [RFC4634] 1384 The PRF field is 8 bits long. The value 0x00 is for Private Use 1385 between mutually consenting parties. All other values are available 1386 through assignment by IANA. IANA is instructed to assign values 1387 based on "IETF Review" (see [RFC5226]). 1389 The following is the initial layout for the password preprocessing 1390 method registry: 1392 o 0x00 : None 1394 o 0x01 : RFC2759 1396 o 0x02 : SASLprep 1398 The Prep field is 8 bits long and all other values are available 1399 through assignment by IANA. IANA is instructed to assign values 1400 based on "Specification Required" (see [RFC5226]). 1402 6. Security Considerations 1404 In Section 1.3 several security properties were presented that 1405 motivated the design of this protocol. This section will address how 1406 well they are met. 1408 6.1. Resistance to Passive Attack 1410 A passive attacker will see Scalar_P, Element_P, Scalar_S, and 1411 Element_S. She can guess at passwords to compute the password element 1412 but will not know s_rand or p_rand and therefore will not be able to 1413 compute MK. 1415 The secret random value of the peer (server) is effectively hidden by 1416 adding p_mask (s_mask) to p_rand (s_rand) modulo the order of the 1417 group. If the order is "r", then there are approximately "r" 1418 distinct pairs of numbers that will sum to the value Scalar_P 1419 (Scalar_S). Attempting to guess the particular pair is just as 1420 difficult as guessing the secret random value p_rand (s_rand), the 1421 probability of a guess is 1/(r - i) after "i" guesses and for a large 1422 value of r this exhaustive search technique is computationally 1423 infeasible. An attacker would do better by determining the discrete 1424 logarithm of Element_P (Element_S) using an algorithm like Baby-Step 1425 giant-step (see [APPCRY]), which runs on the order of the square root 1426 of r group operations (e.g. a group with order 2^160 that would be 1427 2^80 exponentiations or point multiplications). Based on the 1428 assumptions made on the finite cyclic group made in Section 2.3 that 1429 is also computationally infeasible. 1431 6.2. Resistance to Active Attack 1433 An active attacker can launch her attack after an honest server has 1434 sent EAP-pwd-Commit/Request to an honest peer. This would result in 1435 the peer sending EAP-pwd-Commit/Response. In this case the active 1436 attack has been reduced to that of a passive attacker since p_rand 1437 and s_rand will remain unknown. The active attacker could forge a 1438 value of Confirm_P (Confirm_S) and send it to the EAP server (EAP 1439 peer) in the hope that it will be accepted but due to the assumptions 1440 on H made in Section 2.3 that is computationally infeasible. 1442 The active attacker can launch her attack by forging EAP-pwd-Commit/ 1443 Request and sending it to the peer. This will result in the peer 1444 responding with EAP-pwd-Commit/Response. The attacker can then 1445 attempt to compute ks but since she doesn't know the password this is 1446 infeasible. It can be shown that an attack by receiving EAP-pwd- 1447 Commit/Request from an honest server and forging EAP-pwd-Commit/ 1448 Response is an identical attack with equal infeasibility. 1450 6.3. Resistance to Dictionary Attack 1452 An active attacker can wait until an honest server sends EAP-pwd- 1453 Commit/Request and then forge EAP-pwd-Commit/Response and send it to 1454 the server. The server will respond with EAP-pwd-Confirm/Request. 1455 Now the attacker can attempt to launch a dictionary attack. She can 1456 guess at potential passwords, compute the password element and 1457 compute kp using her p_rand, Scalar_S and Element_S from the EAP-pwd- 1458 Commit/Request and the candidate password element from her guess. 1459 She will know if her guess is correct when she is able to verify 1460 Confirm_S in EAP-pwd-Confirm/Request. 1462 But the attacker committed to a password guess with her forged EAP- 1463 pwd-Commit/Response when she computed Element_P. That value was used 1464 by the server in his computation of ks which was used when he 1465 constructed Confirm_S in EAP-pwd-Confirm/Request. Any guess of the 1466 password that differs from the one used in the forged EAP-pwd-Commit/ 1467 Response could not be verified as correct since the attacker has no 1468 way of knowing whether it is correct. She is able to make one guess 1469 and one guess only per attack. This means that any advantage she can 1470 gain-- guess a password, if it fails exclude it from the pool of 1471 possible passwords and try again-- is solely through interaction with 1472 an honest protocol peer. 1474 The attacker can commit to the guess with the forged EAP-pwd-Commit/ 1475 Response and then run through the dictionary, computing the password 1476 element and ks using her forged Scalar_P and Element_P. She will know 1477 she is correct if she can compute the same value for Confirm_S that 1478 the server produced in EAP-pwd-Confirm/Request. But this requires 1479 the attacker to know s_rand which we noted, above, was not possible. 1481 The password element PWE/pwe is chosen using a method described in 1482 Section 2.8.3. Since this is an element in the group there exists a 1483 scalar value, q, such that: 1485 PWE = q * G, for an ECC group 1487 pwe = g^q mod p, for an FFC group 1489 Knowledge of q can be used to launch a dictionary attack. For the 1490 sake of brevity, the attack will be demonstrated assuming an ECC 1491 group. The attack works thusly: 1493 The attacker waits until an honest server sends EAP-pwd-Commit/ 1494 Request. The attacker then generates a random Scalar_P and a random 1495 p_mask and computes Element_P = p_mask * G. The attacker sends the 1496 bogus Scalar_P and Element_P to the server and obtains Confirm_S in 1497 return. Note that the server is unable to detect that Element_P was 1498 calculated incorrectly. 1500 The attacker now knows that: 1502 KS = (Scalar_P * q + p_mask) * s_rand * G 1504 and 1506 s_rand * G = Scalar_P * G - ((1/q) mod r * -Element_P) 1508 Since Scalar_P, p_mask, G, and Element_P are all known the attacker 1509 can run through the dictionary, making a password guess, computing 1510 PWE using the technique in Section 2.8.3, determine q, and then use 1511 the equations above to compute KS and see if it can verify Confirm_S. 1512 But to determine q for a candidate PWE the attacker needs to perform 1513 a discrete logarithm which was assumed to be computationally 1514 infeasible in Section 2.3. Therefore this attack is also infeasible. 1516 The best advantage an attacker can gain in a single active attack is 1517 to determine whether a single guess at the password was correct. 1518 Therefore her advantage is solely through interaction and not 1519 computation, which is the definition for resistance to dictionary 1520 attack. 1522 Resistance to dictionary attack means that the attacker must launch 1523 an active attack to make a single guess at the password. If the size 1524 of the dictionary from which the password was extracted was D, and 1525 each password in the dictionary has an equal probability of being 1526 chosen, then the probability of success after a single guess is 1/D. 1527 After X guesses, and removal of failed guesses from the pool of 1528 possible passwords, the probability becomes 1/(D-X). As X grows so 1529 does the probability of success. Therefore it is possible for an 1530 attacker to determine the password through repeated brute-force, 1531 active, guessing attacks. This protocol does not presume to be 1532 secure against this and implementations SHOULD ensure the size of D 1533 is sufficiently large to prevent this attack. Implementations SHOULD 1534 also take countermeasures, for instance refusing authentication 1535 attempts for a certain amount of time, after the number of failed 1536 authentication attempts reaches a certain threshold. No such 1537 threshold or amount of time is recommended in this memo. 1539 6.4. Forward Secrecy 1541 The MSK and EMSK are extracted from MK which is derived from doing 1542 group operations with s_rand, p_rand, and the password element. The 1543 peer and server choose random values with each run of the protocol. 1544 So even if an attacker is able to learn the password, she will not 1545 know the random values used by either the peer or server from an 1546 earlier run and will therefore be unable to determine MK, or the MSK 1547 or EMSK. This is the definition of Forward Secrecy. 1549 6.5. Random Functions 1551 The protocol described in this memo uses a function referred to as a 1552 "random oracle" (as defined in [RANDOR]). A significant amount of 1553 care must be taken to instantiate a random oracle out of handy 1554 cryptographic primitives. The random oracle used here is based the 1555 notion of a "Randomness Extractor" from [KDF]. 1557 This protocol can use any properly instantiated random oracle. To 1558 ensure that any new value for H will use a properly instantiated 1559 random oracle IANA has been instructed (in Section 5) to only 1560 allocate values from the Random Function registry after being vetted 1561 by an expert. 1563 The security of this protocol depends on the finite cyclic group used 1564 and the infeasibility of performing a discrete logarithm. A few of 1565 the defined groups that can be used with this protocol have a 1566 security estimate less than 128 bits, many do not though, and to 1567 prevent the random function from being the gating factor (or a target 1568 for attack) any new random function MUST map its input to a target of 1569 at least 128 bits and SHOULD map its input to a target of at least 1570 256 bits. 1572 7. Security Claims 1574 [RFC3748] requires that documents describing new EAP methods clearly 1575 articulate the security properties of the method. In addition, for 1576 use with wireless LANs [RFC4017] mandates and recommends several of 1577 these. The claims are: 1579 a. mechanism: password. 1581 b. claims: 1583 * mutual authentication: the peer and server both authenticate 1584 each other by proving possession of a shared password. This 1585 is REQUIRED by [RFC4017]. 1587 * forward secrecy: compromise of the password does not reveal 1588 the secret keys-- MK, MSK, or EMSK-- from earlier runs of the 1589 protocol. 1591 * replay protection: an attacker is unable to replay messages 1592 from a previous exchange either learn the password or a key 1593 derived by the exchange. Similarly the attacker is unable to 1594 induce either the peer or server to believe the exchange has 1595 successfully completed when it hasn't. Reflection attacks 1596 are foiled because the server ensures that the scalar and 1597 element supplied by the peer do not equal its own. 1599 * key derivation: keys are derived by performing a group 1600 operation in a finite cyclic group (e.g. exponentiation) 1601 using secret data contributed by both the peer and server. 1602 An MSK and EMSK are derived from that shared secret. This is 1603 REQUIRED by [RFC4017] 1605 * dictionary attack resistance: this protocol is resistant to 1606 dictionary attack because an attacker can only make one 1607 password guess per active attack. The advantage gained by an 1608 attacker is through interaction not through computation. 1609 This is REQUIRED by [RFC4017]. 1611 * session independence: this protocol is resistant to active 1612 and passive attack and does not enable compromise of 1613 subsequent or prior MSKs or EMSKs from either passive or 1614 active attack. 1616 * Denial of Service Resistance: it is possible for an attacker 1617 to cause a server to allocate state and consume CPU 1618 generating Scalar_S and Element_S. Such an attack is gated, 1619 though, by the requirement that the attacker first obtain 1620 connectivity through a lower-layer protocol (e.g. 802.11 1621 authentication followed by 802.11 association, or 802.3 1622 "link-up") and respond to two EAP messages--the EAP-ID/ 1623 Request and the EAP-pwd-ID/Request. The EAP-pwd-ID exchange 1624 further includes an anti-clogging token that provides a level 1625 of assurance to the server that the peer is, at least, 1626 performing a rudimentary amount of processing and not merely 1627 spraying packets. This prevents distributed denial of 1628 service attacks and also requires the attacker to announce, 1629 and commit to, a lower-layer identity (such as a MAC 1630 address). 1632 * Man-in-the-Middle Attack Resistance: this exchange is 1633 resistant to active attack, which is a requirement for 1634 launching a man-in-the-middle attack. This is REQUIRED by 1635 [RFC4017]. 1637 * shared state equivalence: upon completion of EAP-pwd the peer 1638 and server both agree on MK, MSK, EMSK, Method-ID, and 1639 Session-ID. The peer has authenticated the server based on 1640 the Server-ID and the server has authenticated the peer based 1641 on the Peer-ID. This is due to the fact that Peer-ID, 1642 Server-ID, and the shared password are all combined to make 1643 the password element which must be shared between the peer 1644 and server for the exchange to complete. This is REQUIRED by 1645 [RFC4017]. 1647 * fragmentation: this protocol defines a technique for 1648 fragmentation and reassembly in Section 4. 1650 * resistance to "Denning-Sacco" attack: learning keys 1651 distributed from an earlier run of the protocol, such as the 1652 MSK or EMSK, will not help an adversary learn the password. 1654 c. key strength: the strength of the resulting key depends on the 1655 finite cyclic group chosen. For example, [RFC5114] defines new 1656 groups available for use with this protocol. Using groups from 1657 [RFC5114] the strength can vary from 80 bits (for the 1024-bit 1658 MODP with 160-bit Prime Subgroup) to 256 bits (for the 521-bit 1659 Random ECP Group). Other groups can be defined and the strength 1660 of those groups depends on their definition. This is REQUIRED by 1661 [RFC4017]. 1663 d. key hierarchy: MSKs and EMSKs are derived from the MK using the 1664 KDF defined in Section 2.5 as described in Section 2.8.4. 1666 e. vulnerabilities (note that none of these are REQUIRED by 1667 [RFC4017]): 1669 * protected ciphersuite negotiation: the ciphersuite offer made 1670 by the server is not protected from tampering by an active 1671 attacker. Downgrade attacks are prevented, though, since 1672 this is not a "negotiation" with a list of acceptable 1673 ciphersuites. If a Ciphersuite was modified by an active 1674 attacker it would result in a failure to confirm the message 1675 sent by the other party, since the Ciphersuite is bound by 1676 each side into its confirm message, and the protocol would 1677 fail as a result. 1679 * confidentiality: none of the messages sent in this protocol 1680 are encrypted. 1682 * integrity protection: messages in the EAP-pwd-Commit exchange 1683 are not integrity protected. 1685 * channel binding: this protocol does not enable the exchange 1686 of integrity-protected channel information that can be 1687 compared with values communicated via out-of-band mechanisms. 1689 * fast reconnect: this protocol does not provide a fast 1690 reconnect capability. 1692 * cryptographic binding: this protocol is not a tunneled EAP 1693 method and therefore has no cryptographic information to 1694 bind. 1696 * identity protection: the EAP-pwd-ID exchange is not 1697 protected. An attacker will see the server's identity in the 1698 EAP-pwd-ID/Request and see the peer's identity in EAP-pwd-ID/ 1699 Response. 1701 8. Acknowledgements 1703 The authors would like to thank Scott Fluhrer for discovering the 1704 "password as exponent" attack that was possible in the initial 1705 version of this memo and for his very helpful suggestions on the 1706 techniques for fixing the PWE/pwe to prevent it. The authors would 1707 also like to thank Hideyuki Suzuki for his insight in discovering an 1708 attack against a previous version of the underlying key exchange 1709 protocol. Special thanks to Lily Chen for helpful discussions on 1710 hashing into an elliptic curve and to Jin-Meng Ho for suggesting the 1711 countermeasures to protect against a small sub-group attack. Rich 1712 Davis suggested the defensive checks to Commit messages and his 1713 various comments greatly improved the quality of this memo and the 1714 underlying key exchange on which it is based. Scott Kelly suggested 1715 adding the anti-clogging token to the ID exchange to prevent 1716 distributed denial of service attacks. Dorothy Stanley provided 1717 valuable suggestions to improve the quality of this memo. The 1718 fragmentation method used was taken from [RFC5216]. 1720 9. References 1722 9.1. Normative References 1724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1725 Requirement Levels", BCP 14, RFC 2119, March 1997. 1727 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1728 RFC 2759, January 2000. 1730 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1731 Internationalized Strings ("stringprep")", RFC 3454, 1732 December 2002. 1734 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1735 Levkowetz, "Extensible Authentication Protocol (EAP)", 1736 RFC 3748, June 2004. 1738 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1739 and Passwords", RFC 4013, February 2005. 1741 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1742 Network Access Identifier", RFC 4282, December 2005. 1744 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1745 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1747 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1748 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1749 May 2008. 1751 [SP800-108] 1752 Chen, L., "Recommendations for Key Derivation Using 1753 Pseudorandom Functions", NIST Special Publication 800-108, 1754 April 2008. 1756 [SP800-56A] 1757 Barker, E., Johnson, D., and M. Smid, "Recommendations for 1758 Pair-Wise Key Establishment Schemes Using Discrete 1759 Logarithm Cryptography", NIST Special Publication 800-56A, 1760 March 2007. 1762 9.2. Informative References 1764 [APPCRY] Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook 1765 of Applied Cryptography", CRC Press Series on Discrete 1766 Mathematics and Its Applications, 1996. 1768 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 1769 Password-Based Protocols Secure Against Dictionary 1770 Attack", Proceedings of the IEEE Symposium on Security and 1771 Privacy, Oakland, 1992. 1773 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 1774 Exchange: A Password-Based Protocol Secure against 1775 Dictionary Attacks and Password File Compromise", 1776 Proceedings of the 1st ACM Conference on Computer and 1777 Communication Security, ACM Press, 1993. 1779 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 1780 Password Authenticated Key Exchange Using Diffie-Hellman", 1781 Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 1782 2000. 1784 [JAB96] Jablon, D., "Strong Password-Only Authenticated Key 1785 Exchange", ACM SIGCOMM Computer Communication 1786 Review Volume 1, Issue 5, October 1996. 1788 [KDF] Krawczyk, H., "On Extract-then-Expand Key Derivation 1789 Functions and an HMAC-based KDF", March 2008, 1790 . 1792 [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary 1793 Attacks Without Encrypting Public Keys", Proceedings of 1794 the Security Protocols Workshop, LNCS 1361. Springer- 1795 Verlag, 1997. 1797 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 1798 A Paradigm for Designing Efficient Protocols", Proceedings 1799 of the 1st ACM Conference on Computer and Communication 1800 Security, ACM Press, 1993, 1801 . 1803 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1804 (IKE)", RFC 2409, November 1998. 1806 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1807 Authentication Protocol (EAP) Method Requirements for 1808 Wireless LANs", RFC 4017, March 2005. 1810 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1811 Requirements for Security", BCP 106, RFC 4086, June 2005. 1813 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1814 Authorization, and Accounting (AAA) Key Management", 1815 BCP 132, RFC 4962, July 2007. 1817 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 1818 Groups for Use with IETF Standards", RFC 5114, 1819 January 2008. 1821 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1822 Authentication Protocol", RFC 5216, March 2008. 1824 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1825 Authentication Protocol (EAP) Key Management Framework", 1826 RFC 5247, August 2008. 1828 Authors' Addresses 1830 Dan Harkins 1831 Aruba Networks 1832 1322 Crossman Avenue 1833 Sunnyvale, CA 94089-1113 1834 United States of America 1836 Email: dharkins@arubanetworks.com 1838 Glen Zorn 1839 Network Zen 1840 1310 East Thomas Street 1841 #306 1842 Seattle, Washington 98102 1843 USA 1845 Phone: +1 (206) 377-9035 1846 Email: gwz@net-zen.net