idnits 2.17.1 draft-harkins-emu-eap-pwd-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, 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 (April 12, 2010) is 5118 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: 5 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: October 14, 2010 Network Zen 6 April 12, 2010 8 EAP Authentication Using Only A Password 9 draft-harkins-emu-eap-pwd-14 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 October 14, 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 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 Abstract 58 This memo describes an Extensible Authentication Protocol (EAP) 59 method, EAP-pwd, which uses a shared password for authentication. 60 The password may be a low-entropy one and may be drawn from some set 61 of possible passwords, like a dictionary, which is available to an 62 attacker. The underlying key exchange is resistant to active attack, 63 passive attack and dictionary attack. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.2. Keyword Definitions . . . . . . . . . . . . . . . . . . . 4 70 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.3.1. Resistance to Passive Attack . . . . . . . . . . . . . 4 72 1.3.2. Resistance to Active Attack . . . . . . . . . . . . . 5 73 1.3.3. Resistance to Dictionary Attack . . . . . . . . . . . 5 74 1.3.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . 5 75 2. Specification of EAP-pwd . . . . . . . . . . . . . . . . . . . 5 76 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 7 78 2.2.1. Finite Field Cryptography . . . . . . . . . . . . . . 7 79 2.2.2. Elliptic Curve Cryptography . . . . . . . . . . . . . 8 80 2.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 81 2.4. Instantiating the Random Function . . . . . . . . . . . . 9 82 2.5. Key Derivation Function . . . . . . . . . . . . . . . . . 10 83 2.6. Random Numbers . . . . . . . . . . . . . . . . . . . . . . 10 84 2.7. Representation and Processing of Input Strings . . . . . . 11 85 2.7.1. Identity Strings . . . . . . . . . . . . . . . . . . . 11 86 2.7.2. Passwords . . . . . . . . . . . . . . . . . . . . . . 11 87 2.8. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 2.8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12 89 2.8.2. Message Flows . . . . . . . . . . . . . . . . . . . . 12 90 2.8.3. Fixing the Password Element . . . . . . . . . . . . . 14 91 2.8.3.1. ECC Operation for PWE . . . . . . . . . . . . . . 14 92 2.8.3.2. FFC Operation for pwe . . . . . . . . . . . . . . 15 93 2.8.4. Message Construction . . . . . . . . . . . . . . . . . 16 94 2.8.4.1. ECC Groups . . . . . . . . . . . . . . . . . . . . 16 95 2.8.4.2. FFC Groups . . . . . . . . . . . . . . . . . . . . 17 96 2.8.5. Message Processing . . . . . . . . . . . . . . . . . . 18 97 2.8.5.1. EAP-pwd-ID Exchange . . . . . . . . . . . . . . . 18 98 2.8.5.2. EAP-pwd-Commit Exchange . . . . . . . . . . . . . 20 99 2.8.5.3. EAP-pwd-Confirm Exchange . . . . . . . . . . . . . 21 100 2.9. Management of EAP-pwd Keys . . . . . . . . . . . . . . . . 22 101 2.10. Mandatory-to-Implement Parameters . . . . . . . . . . . . 23 102 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 23 103 3.1. EAP-pwd Header . . . . . . . . . . . . . . . . . . . . . . 23 104 3.2. EAP-pwd Payloads . . . . . . . . . . . . . . . . . . . . . 25 105 3.2.1. EAP-pwd-ID . . . . . . . . . . . . . . . . . . . . . . 25 106 3.2.2. EAP-pwd-Commit . . . . . . . . . . . . . . . . . . . . 26 107 3.2.3. EAP-pwd-Confirm . . . . . . . . . . . . . . . . . . . 27 108 3.3. Representation of Group Elements and Scalars . . . . . . . 28 109 3.3.1. Elements in FFC Groups . . . . . . . . . . . . . . . . 28 110 3.3.2. Elements in ECC Groups . . . . . . . . . . . . . . . . 28 111 3.3.3. Scalars . . . . . . . . . . . . . . . . . . . . . . . 28 112 4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 29 113 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 114 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31 115 6.1. Resistance to Passive Attack . . . . . . . . . . . . . . . 31 116 6.2. Resistance to Active Attack . . . . . . . . . . . . . . . 32 117 6.3. Resistance to Dictionary Attack . . . . . . . . . . . . . 32 118 6.4. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 34 119 6.5. Group Strength . . . . . . . . . . . . . . . . . . . . . . 34 120 6.6. Random Functions . . . . . . . . . . . . . . . . . . . . . 34 121 7. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 35 122 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 123 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 124 9.1. Normative References . . . . . . . . . . . . . . . . . . . 38 125 9.2. Informative References . . . . . . . . . . . . . . . . . . 39 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 128 1. Introduction 130 1.1. Background 132 The predominant access method for the Internet today is that of a 133 human using a username and password to authenticate to a computer 134 enforcing access control. Proof of knowledge of the password 135 authenticates the human and computer. 137 Typically these passwords are not stored on a user's computer for 138 security reasons and must be entered each time the human desires 139 network access. Therefore the passwords must be ones that can be 140 repeatedly entered by a human with a low probability of error. They 141 will likely not possess high-entropy and it may be assumed that an 142 adversary with access to a dictionary will have the ability to guess 143 a user's password. It is therefore desirable to have a robust 144 authentication method that is secure even when used with a weak 145 password in the presence of a strong adversary. 147 EAP-pwd is an EAP method that addresses the problem of password-based 148 authenticated key exchange-- using a possibly weak password for 149 authentication to derive an authenticated and cryptographically 150 strong shared secret. This problem was first described by Bellovin 151 and Merritt in [BM92] and [BM93]. There have been a number of 152 subsequent suggestions ([JAB96], [LUC97], [BMP00], and others) for 153 password-based authenticated key exchanges. 155 1.2. Keyword Definitions 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 1.3. Requirements 163 Any protocol that claims to solve the problem of password- 164 authenticated key exchange must be resistant to active, passive and 165 dictionary attack and have the quality of forward secrecy. These 166 characteristics are discussed further in the following sections. 168 1.3.1. Resistance to Passive Attack 170 A passive, or benign, attacker is one that merely relays messages 171 back and forth between the peer and server, faithfully, and without 172 modification. The contents of the messages are available for 173 inspection, but that is all. To achieve resistance to passive 174 attack, such an attacker must not be able to obtain any information 175 about the password or anything about the resulting shared secret from 176 watching repeated runs of the protocol. Even if a passive attacker 177 is able to learn the password, she will not be able to determine any 178 information about the resulting secret shared by the peer and server. 180 1.3.2. Resistance to Active Attack 182 An active attacker is able to modify, add, delete, and replay 183 messages sent between protocol participants. For this protocol to be 184 resistant to active attack, the attacker must not be able to obtain 185 any information about the password or the shared secret by using any 186 of its capabilities. In addition, the attacker must not be able to 187 fool a protocol participant into thinking that the protocol completed 188 successfully. 190 It is always possible for an active attacker to deny delivery of a 191 message critical in completing the exchange. This is no different 192 than dropping all messages and is not an attack against the protocol. 194 1.3.3. Resistance to Dictionary Attack 196 For this protocol to be resistant to dictionary attack any advantage 197 an adversary can gain must be directly related to the number of 198 interactions she makes with an honest protocol participant and not 199 through computation. The adversary will not be able to obtain any 200 information about the password except whether a single guess from a 201 single protocol run is correct or incorrect. 203 1.3.4. Forward Secrecy 205 Compromise of the password must not provide any information about the 206 secrets generated by earlier runs of the protocol. 208 2. Specification of EAP-pwd 210 2.1. Notation 212 The following notation is used in this memo: 214 peer-ID 215 The peer's identity, the peer NAI [RFC4282]. 217 server-ID 218 A string that identifies the server to the peer. 220 password 221 The password shared between the peer and server. 223 y = H(x) 224 The binary string x is given to a function H which produces a 225 fixed-length output y. 227 a | b 228 denotes concatenation of string a with string b. 230 [a]b 231 indicates a string consisting of the single bit "a" repeated "b" 232 times. 234 x mod y 235 indicates the remainder of division of x by y. The result will 236 be between 0 and y. 238 g^x mod p 239 indicates multiplication of the value "g" with itself "x" times, 240 modulo the value "p". 242 inv(Q) 243 indicates the inverse of an element, Q, from a finite field. 245 len(x) 246 indicates the length in bits of the string x. 248 chop(x, y) 249 is reduction of string x, being at least y bits in length, to y 250 bits. 252 PRF(x,y) 253 is a pseudo-random function that takes a key, x, and variable- 254 length data, y, and produces a fixed-length output that cannot be 255 distinguished (with a significant advantage) from a random 256 source. 258 LSB(x) 259 returns the least-significant bit of the bitstring "x". 261 CipherSuite 262 an encoding of a group to use with EAP-pwd, the definition of 263 function H, and a PRF, in that order. 265 MSK 266 The Master Session Key exported by EAP-pwd. This is a high- 267 entropy secret 512 bits in length. 269 EMSK 270 The Extended Master Session Key exported by EAP-pwd. This is a 271 high-entropy secret 512 bits in length. 273 2.2. Discrete Logarithm Cryptography 275 This protocol uses discrete logarithm cryptography to achieve 276 authentication and key agreement (see [SP800-56A]). Each party to 277 the exchange derives ephemeral keys with respect to a particular set 278 of domain parameters (referred to here as a "group"). A group can be 279 based on Finite Field Cryptography (FFC) or Elliptic Curve 280 Cryptography (ECC). 282 2.2.1. Finite Field Cryptography 284 Domain parameters for the FFC groups used by EAP-pwd include: 286 o A prime, p, determining a prime field GF(p), the integers modulo 287 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 288 group of non-zero elements in GF(p). The group operation for FFC 289 groups is multiplication modulo p. 291 o An element, G, in GF(p)* which serves as a generator for the FFC 292 group. G is chosen such that its multiplicative order is a 293 sufficiently large prime divisor of ((p-1)/2). 295 o A prime, r, which is the multiplicative order of G, and thus also 296 the size of the cryptographic subgroup of GF(p)* that is generated 297 by G. 299 An integer scalar, x, acts on an FFC group element, Y, via 300 exponentiation modulo p-- Y^x mod p. 302 The inverse function for an FFC group is defined such that the 303 product of an element and its inverse modulo the group prime equals 304 one (1). In other words, 306 (q * inv(q)) mod p = 1 308 EAP-pwd uses an IANA registry for the definition of groups. Some FFC 309 groups in this registry are based on safe primes and the order is not 310 included in the domain parameters. In this case only, the order, r, 311 MUST be computed as the prime minus one divided by two-- (p-1)/2. If 312 the definition of the group includes an order in its domain 313 parameters, that value MUST be used in this exchange when an order is 314 called for. If an FFC group definition does not have an order in its 315 domain parameters and it is not based on a safe prime it MUST NOT be 316 used with EAP-pwd. 318 2.2.2. Elliptic Curve Cryptography 320 Domain parameters for the ECC groups used by EAP-pwd include: 322 o A prime, p, determining a prime field GF(p). The cryptographic 323 group will be a subgroup of the full elliptic curve group which 324 consists points on an elliptic curve-- elements from GF(p) that 325 satisfy the curve's equation-- together with the "point at 326 infinity" that serves as the identity element. The group 327 operation for ECC groups is addition of points on the elliptic 328 curve. 330 o Elements a and b from GF(p) that define the curve's equation. The 331 point (x,y) in GF(p) x GF(p) is on the elliptic curve if and only 332 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 334 o A point, G, on the elliptic curve, which serves as a generator for 335 the ECC group. G is chosen such that its order, with respect to 336 elliptic curve addition, is a sufficiently large prime. 338 o A prime, r, which is the order of G, and thus is also the size of 339 the cryptographic subgroup that is generated by G. 341 o A co-factor, f, defined by the requirement that the size of the 342 full elliptic curve group (including the "point at infinity") is 343 the product of f and r. 345 An integer scalar, x, acts on an ECC group element, Y, via repetitive 346 addition (Y is added to itself x times), also called point 347 multiplication-- x * Y. 349 The inverse function for an ECC group is defined such that the sum of 350 an element and its inverse is the "point at infinity" (the identity 351 for elliptic curve point addition). In other words, 353 Q + inv(Q) = "O" 355 Only ECC groups over GF(p) can be used by EAP-pwd. ECC groups over 356 GF(2^m) SHALL NOT be used by EAP-pwd. While such groups exist in the 357 IANA registry used by EAP-pwd their use in EAP-pwd is not defined. 358 In addition, ECC groups with a co-factor greater than one (1) SHALL 359 NOT be used by EAP-pwd. At the time of publication, no such groups 360 existed in the IANA registry used by EAP-pwd. 362 2.3. Assumptions 364 In order to see how the protocol addresses the requirements above 365 (see Section 1.3) it is necessary to state some assumptions under 366 which the protocol can be evaluated. They are: 368 1. Function H maps a binary string of indeterminate length onto a 369 fixed binary string that is x bits in length. 371 H: {0,1}^* --> {0,1}^x 373 2. Function H is a "random oracle" (see [RANDOR]). Given knowledge 374 of the input to H an adversary is unable to distinguish the 375 output of H from a random data source. 377 3. Function H is a one-way function. Given the output of H it is 378 computationally infeasible for an adversary to determine the 379 input. 381 4. For any given input to function H each of the 2^x possible 382 outputs are equally probable. 384 5. The discrete logarithm problem for the chosen group is hard. 385 That is, given g, p and y = g^x mod p it is computationally 386 infeasible to determine x. Similarly for an ECC group given the 387 curve definition, a generator G, and Y = x * G it is 388 computationally infeasible to determine x. 390 6. There exists a pool of passwords from which the password shared 391 by the peer and server is drawn. This pool can consist of words 392 from a dictionary, for example. Each password in this pool has 393 an equal probability of being the shared password. All potential 394 attackers have access to this pool of passwords. 396 2.4. Instantiating the Random Function 398 The protocol described in this memo uses a random function, H. As 399 noted in Section 2.3 this is a "random oracle" as defined in 400 [RANDOR]. At first glance one may view this as a hash function. As 401 noted in [RANDOR], though, hash functions are too structured to be 402 used directly as a random oracle. But they can be used to 403 instantiate the random oracle. 405 The random function, H, in this memo is instantiated by HMAC-SHA256 406 (see [RFC4634]) with a key whose length is 32 octets and whose value 407 is zero. In other words, 408 H(x) = HMAC-SHA-256([0]32, x) 410 2.5. Key Derivation Function 412 The keys output by this protocol, MSK and EMSK, are each 512 bits in 413 length. The shared secret that results from the successful 414 termination of this protocol is only 256 bits. Therefore it is 415 necessary to stretch the shared secret using a key derivation 416 function (KDF). 418 The KDF used in this protocol has a counter-mode with feed-back 419 construction using a generic pseudo-random function (PRF), according 420 to [SP800-108]. The specific value of the PRF is specified along 421 with the random function and group when the server sends the first 422 EAP-pwd packet to the peer. 424 The KDF takes a key to stretch, a label to bind into the key, and an 425 indication of the desired length of the output in bits. It uses two 426 internal variables, i and L, each of which is 16-bits in length and 427 is represented in network order. Algorithmically it is: 429 KDF(key, label, length) { 430 i = 1 431 L = length 432 K(1) = PRF(key, i | label | L) 433 res = K(1) 434 while (len(res) < length) 435 do 436 i = i + 1 437 K(i) = PRF(key, K(i-1) | i | label | L) 438 res = res | K(i) 439 done 440 return chop(res, length) 441 } 443 Figure 1: Key Derivation Function 445 2.6. Random Numbers 447 The security of EAP-pwd relies upon each side, the peer and server, 448 producing quality secret random numbers. A poor random number chosen 449 by either side in a single exchange can compromise the shared secret 450 from that exchange and open up the possibility of dictionary attack. 452 Producing quality random numbers without specialized hardware entails 453 using a cryptographic mixing function (like a strong hash function) 454 to distill entropy from multiple, uncorrelated sources of information 455 and events. A very good discussion of this can be found in 457 [RFC4086]. 459 2.7. Representation and Processing of Input Strings 461 2.7.1. Identity Strings 463 The strings representing the server identity and peer identity MUST 464 follow the requirements of [RFC4282] for Network Access Identifiers. 465 This ensures a canonical representation of identities by both ends of 466 the conversation prior to their use in EAP-pwd. 468 2.7.2. Passwords 470 EAP-pwd requires passwords be input as binary strings. For the 471 protocol to successfully terminate each side must produce identical 472 binary strings from the password. This imposes processing 473 requirements on a password prior to its use. 475 Three techniques for password pre-processing exist for EAP-pwd: 477 o None: The input password string SHALL be treated as an ASCII 478 string or a hexadecimal string with no treatment or normalization 479 performed. The output SHALL be the binary representation of the 480 input string. 482 o RFC2759: The input password string SHALL be processed to produce 483 the output PasswordHashHash, as defined in [RFC2759], including 484 any approved errata to [RFC2759]. This technique is useful when 485 the server does not have access to the plaintext password. 487 o SASLprep: The input password string is processed according to the 488 rules of the [RFC4013] profile of [RFC3454]. A password SHALL be 489 considered a "stored string" per [RFC3454] and unassigned code 490 points are therefore prohibited. The output SHALL be the binary 491 representation of the processed UTF-8 character string. 492 Prohibited output and unassigned codepoints encountered in 493 SASLprep pre-processing SHALL cause a failure of pre-processing 494 and the output SHALL NOT be used with EAP-pwd. 496 Changing a password is out-of-scope of EAP-pwd but due to the 497 ambiguities in the way internationalized character strings are 498 handled it SHOULD be done using SASLprep ensure a canonical 499 representation of the new password is stored on the server and 500 subsequent invocations of EAP-pwd SHOULD use SASLprep to ensure that 501 the client generates an identical binary string from the input 502 password. 504 2.8. Protocol 506 2.8.1. Overview 508 EAP is a two-party protocol spoken between an EAP peer and an 509 authenticator. For scaling purposes the functionality of the 510 authenticator that speaks EAP is frequently broken out into a stand- 511 alone EAP server. In this case the EAP peer communicates with an EAP 512 server through the authenticator with the authenticator merely being 513 a passthrough. 515 An EAP method defines the specific authentication protocol being used 516 by EAP. This memo defines a particular method and therefore defines 517 the messages sent between the EAP server (or the "EAP server" 518 functionality in an authenticator if it is not broken out) and the 519 EAP peer for the purpose of authentication and key derivation. 521 2.8.2. Message Flows 523 EAP-pwd defines three message exchanges, an Identity exchange, a 524 Commit exchange and a Confirm exchange. A successful authentication 525 is shown in Figure 2. 527 The peer and server use the Identity exchange to discover each 528 other's identities and to agree upon a ciphersuite to use in the 529 subsequent exchanges; in addition, the EAP Server uses the EAP-pwd- 530 ID/Request message to inform the client of any password preprocessing 531 that may be required. In the Commit exchange the peer and server 532 exchange information to generate a shared key and also to bind each 533 other to a particular guess of the password. In the Confirm exchange 534 the peer and server prove liveness and knowledge of the password by 535 generating and verifying verification data. 537 +--------+ +--------+ 538 | | EAP-pwd-ID/Request | | 539 | EAP |<------------------------------------| EAP | 540 | peer | | server | 541 | | EAP-pwd-ID/Response | | 542 | |------------------------------------>| | 543 | | | | 544 | | EAP-pwd-Commit/Request | | 545 | |<------------------------------------| | 546 | | | | 547 | | EAP-pwd-Commit/Response | | 548 | |------------------------------------>| | 549 | | | | 550 | | EAP-pwd-Confirm/Request | | 551 | |<------------------------------------| | 552 | | | | 553 | | EAP-pwd-Confirm/Response | | 554 | |------------------------------------>| | 555 | | | | 556 | | EAP-Success | | 557 | |<------------------------------------| | 558 +--------+ +--------+ 560 Figure 2: A Successful EAP-pwd Exchange 562 The components of the EAP-pwd-* messages are as follows: 564 EAP-pwd-ID/Request 565 Ciphersuite, Token, Password Processing Method, Server_ID 567 EAP-pwd-ID/Response 568 Ciphersuite, Token, Password Processing Method, Peer_ID 570 EAP-pwd-Commit/Request 571 Scalar_S, Element_S 573 EAP-pwd-Commit/Response 574 Scalar_P, Element_P 576 EAP-pwd-Confirm/Request 577 Confirm_S 579 EAP-pwd-Confirm/Response 580 Confirm_P 582 2.8.3. Fixing the Password Element 584 Once the EAP-pwd-ID exchange is completed the peer and server use 585 each other's identities and the agreed upon ciphersuite to fix an 586 element in the negotiatied group called the Password Element (PWE or 587 pwe, for an element in an ECC group or an FFC group, respectively). 588 The resulting element must be selected in a deterministic fashion 589 using the password but must result in selection of an element that 590 will not leak any information on the password to an attacker. From 591 the point-of-view of an attacker who does not know the password, the 592 Password Element will be a random element in the negotiated group. 594 To properly fix the Password Element both parties must have a common 595 view of the string "password". Therefore, if a password 596 preprocessing algorithm was negotiated during the EAP-pwd-ID exchange 597 the client MUST perform the specified password pre-processing prior 598 to fixing the Password Element. 600 Fixing the Password Element involves an iterative hunting-and-pecking 601 technique using the prime from the negotiated group's domain 602 parameter set and an ECC- or FFC-specific operation depending on the 603 negotiated group. 605 First, an 8-bit counter is set to the value one (1). Then, the 606 agreed upon random function is used to generate a password seed from 607 the identities and the anti-clogging token from the EAP-pwd-ID 608 exchange (see Section 2.8.5.1): 610 pwd-seed = H(token | peer-ID | server-ID | password | counter) 612 Then, the pwd-seed is expanded using the KDF from the agreed-upon 613 Ciphersuite out to the length of the prime: 615 pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) 617 If the pwd-value is greater than or equal to the prime, p, the 618 counter is incremented, and a new pwd-seed is generated and the 619 hunting-and-pecking continues. If pwd-value is less than the prime, 620 p, it is passed to the group-specific operation to select the 621 Password Element or fail. If the group-specific operation fails, the 622 counter is incremeneted, a new pwd-seed is generated and the hunting- 623 and-pecking continues. This process continues until the group- 624 specific operation returns the Password Element. 626 2.8.3.1. ECC Operation for PWE 628 The group-specific operation for ECC groups uses pwd-value, pwd-seed, 629 and the equation for the curve to produce the Password Element. 631 First, pwd-value is used directly as the x-coordinate, x, with the 632 equation for the elliptic curve, with parameters a and b from the 633 domain parameter set of the curve, to solve for a y-coordinate, y. 634 If there is no solution to the quadratic equation this operation 635 fails and the hunting-and-pecking process continues. If a solution 636 is found then an ambiguity exists as there are technically two 637 solutions to the equation and pwd-seed is used to unambiguously 638 select one of them. If the low-order bit of pwd-seed is equal to the 639 low-order bit of y then a candidate PWE is defined as the point (x, 640 y); if the low-order bit of pwd-seed differs from the low-order bit 641 of y then a candidate PWE is defined as the point (x, p - y), where p 642 is the prime over which the curve is defined. The candidate PWE 643 becomes PWE and the hunting and pecking terminates successfully. 645 Algorithmically, the process looks like this: 647 found = 0 648 counter = 1 649 do { 650 pwd-seed = H(token | peer-ID | server-ID | password | counter) 651 pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) 652 if (pwd-value < p) 653 then 654 x = pwd-value 655 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 656 then 657 if (LSB(y) == LSB(pwd-seed)) 658 then 659 PWE = (x,y) 660 else 661 PWE = (x, p-y) 662 fi 663 found = 1 664 fi 665 fi 666 counter = counter + 1 667 } while (found == 0) 669 Figure 3: Fixing PWE for ECC Groups 671 2.8.3.2. FFC Operation for pwe 673 The group-specific operation for FFC groups takes pwd-value, and the 674 the prime, p, and order, r, from the group's domain parameter set 675 (see Section 2.2.1 when the order is not part of the defined domain 676 parameter set) to directly produce a candidate Password Element, pwe, 677 by exponentiating the pwd-value to the value ((p-1)/r) modulo the 678 prime. If the result is result is greater than one (1) the candidate 679 pwe becomes pwe and the hunting and pecking terminates successfully. 681 Algorithmically, the process looks like this: 683 found = 0 684 counter = 1 685 do { 686 pwd-seed = H(token | peer-ID | server-ID | password | counter) 687 pwd-value = KDF(pwd-seed, "EAP-pwd Hunting And Pecking", len(p)) 688 if (pwd-value < p) 689 then 690 pwe = pwd-value ^ ((p-1)/r) mod p 691 if (pwe > 1) 692 then 693 found = 1 694 fi 695 fi 696 counter = counter + 1 697 } while (found == 0) 699 Figure 4: Fixing PWE for FFC Groups 701 2.8.4. Message Construction 703 After the EAP-pwd Identity exchange the construction of the 704 components of subsequent messages depends on the type of group from 705 the ciphersuite (ECC or FFC). This section provides an overview of 706 the authenticated key exchange. For a complete description of 707 message generation and processing see Section 2.8.5.2 and 708 Section 2.8.5.3. 710 2.8.4.1. ECC Groups 712 Using the mapping function F() defined in Section 2.2.2 and the group 713 order r: 715 Server: EAP-pwd-Commit/Request 716 - choose two random numbers, 1 < s_rand, s_mask < r 717 - compute Scalar_S = (s_rand + s_mask) mod r 718 - compute Element_S = inv(s_mask * PWE) 720 Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request 722 Peer: EAP-pwd-Commit/Response 723 - choose two random numbers, 1 < p_rand, p_mask < r 724 - compute Scalar_P = (p_rand + p_mask) mod r 725 - compute Element_P = inv(p_mask * PWE) 727 Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response 729 Server: EAP-pwd-Confirm/Request 730 - compute KS = (s_rand * (Scalar_P * PWE + Element_P)) 731 - compute ks = F(KS) 732 - compute Confirm_S = H(ks | Element_S | Scalar_S | 733 Element_P | Scalar_P | Ciphersuite) 735 Confirm_S is used to construct EAP-pwd-Confirm/Request 737 Peer: EAP-pwd-Confirm/Response 738 - compute KP = (p_rand * (Scalar_S * PWE + Element_S)), 739 - compute kp = F(KP) 740 - compute Confirm_P = H(kp | Element_P | Scalar_P | 741 Element_S | Scalar_S | Ciphersuite) 743 Confirm_P is used to construct EAP-pwd-Confirm/Response 745 The EAP Server computes the shared secret as: 746 MK = H(ks | Confirm_P | Confirm_S) 748 The EAP Peer computes the shared secret as: 749 MK = H(kp | Confirm_P | Confirm_S) 751 The MSK and EMSK are derived from MK per Section 2.9. 753 2.8.4.2. FFC Groups 755 There is no mapping function, F(), required for an FFC group. Using 756 the order, r, for the group (see Section 2.2.1 when the order is not 757 part of the defined domain parameters): 759 Server: EAP-pwd-Commit/Request 760 - choose two random numbers, 1 < s_rand, s_mask < r 761 - compute Scalar_S = (s_rand + s_mask) mod r 762 - compute Element_S = inv(pwe^s_mask mod p) 764 Element_S and Scalar_S are used to construct EAP-pwd-Commit/Request 766 Peer: EAP-pwd-Commit/Response 767 - choose random two numbers, 1 < p_rand, p_mask < r 768 - compute Scalar_P = (p_rand + p_mask) mod r 769 - compute Element_P = inv(pwe^p_mask mod p) 771 Element_P and Scalar_P are used to construct EAP-pwd-Commit/Response 773 Server: EAP-pwd-Confirm/Request 774 - compute ks = ((pwe^Scalar_P mod p) * Element_P)^s_rand mod p 775 - compute Confirm_S = H(ks | Element_S | Scalar_S | 776 Element_P | Scalar_P | Ciphersuite) 778 Confirm_S is used to construct EAP-pwd-Confirm/Request 780 Peer: EAP-pwd-Confirm/Response 781 - compute kp = ((pwe^Scalar_S mod p) * Element_S)^p_rand mod p 782 - compute Confirm_P = H(kp | Element_P | Scalar_P | 783 Element_S | Scalar_S | Ciphersuite) 785 Confirm_P is used to construct EAP-pwd-Confirm/Request 787 The EAP Server computes the shared secret as: 788 MK = H(ks | Confirm_P | Confirm_S) 790 The EAP Peer computes the shared secet as: 791 MK = H(kp | Confirm_P | Confirm_S) 793 The MSK and EMSK derived from MK per Section 2.9. 795 2.8.5. Message Processing 797 2.8.5.1. EAP-pwd-ID Exchange 799 Although EAP provides an Identity method to determine the identity of 800 the peer, the value in the Identity Response may have been truncated 801 or obfuscated to provide privacy or decorated for routing purposes 802 [RFC3748], making it inappropriate for usage by the EAP-pwd method. 803 Therefore, the EAP-pwd-ID exchange is defined for the purpose of 804 exchanging identities between the peer and server. 806 The EAP-pwd-ID/Request contains the following quantities: 808 o a ciphersuite 810 o a representation of the server's identity per Section 2.7.1 812 o an anti-clogging token 814 o a password pre-processing method 816 The ciphersuite specifies the finite cyclic group, random function 817 and PRF selected by the server for use in the subsequent 818 authentication exchange. 820 The value of the anti-clogging token MUST be unpredictable and SHOULD 821 NOT be from a source of random entropy. The purpose of the anti- 822 clogging token is to provide the server an assurance that the peer 823 constructing the EAP-pwd-ID/Response is genuine and not part of a 824 flooding attack. 826 A password pre-processing method is communicated to ensure 827 interoperability by producing a canonical representation of the 828 password string between the peer and server (see Section 2.7.2). 830 The EAP-pwd-ID/Request is constructed according to Section 3.2.1 and 831 is transmitted to the peer. 833 Upon receipt of an EAP-pwd-ID/Request, the peer determines whether 834 the ciphersuite and pre-processing method are acceptable. If not, 835 the peer MUST respond with an EAP-NAK. If acceptable, the peer 836 responds to the EAP-pwd-ID/Request, constructed according to 837 Section 3.2.1, that acknowledges the Ciphersuite, token, and pre- 838 processing method and then adds its identity. After sending the EAP- 839 pwd-ID/Response, the peer has the identity of the server (from the 840 Request), its own identity (it encoded in the Response), a password 841 preprocessing algorithm, and it can compute the Password Element as 842 specified in Section 2.8.3. The Password Element is stored in state 843 allocated for this exchange. 845 The EAP-pwd-ID/Response acknowledges the Ciphersuite from the 846 Request, acknowledges the anti-clogging token from the Request 847 providing a demonstration of "liveness" on the part of the peer, and 848 contains the identity of the peer. Upon receipt of the Response, the 849 server verifies that the Ciphersuite acknowledged by the peer is the 850 same as that sent in the Request and that the anti-clogging token 851 added by the peer in the Response is the same as the one the server 852 sent in the Request. If Ciphersuites or anti-clogging tokens differ, 853 the server MUST respond with an EAP-Failure message. If the anti- 854 clogging tokens are the same the server knows the peer is an active 855 participant in the exchange. If the Ciphersuites are the same, the 856 server now knows its own identity (it encoded in the Request) and the 857 peer's identity (from the Response) and can compute the Password 858 Element according to Section 2.8.3. The server stores the Password 859 Element in state it has allocated for this exchange. The server then 860 initiates an EAP-pwd-Commit exchange. 862 2.8.5.2. EAP-pwd-Commit Exchange 864 The server begins the EAP-pwd-Confirm exchange by choosing two random 865 numbers, s_rand and s_mask, between 1 and r (where r is described in 866 Section 2.1 according to the group established in Section 2.8.5.1) 867 such that their sum modulo r is greater than one (1). It then 868 computes Element_S and Scalar_S as defined in Section 2.8.4 and 869 constructs an EAP-pwd-Commit/Request according to Section 3.2.2. 870 Element_S and Scalar_S are added to the state allocated for this 871 exchange and the EAP-pwd-Commit/Request is transmitted to the peer. 873 Upon receipt of the EAP-pwd-Commit/Request, the peer validates the 874 length of the entire payload based upon the expected lengths of 875 Element_S and Scalar_S (which are fixed according to the length of 876 the agreed-upon group). If the length is incorrect, the peer MUST 877 terminate the exchange. If the length is correct, Element_S and 878 Scalar_S are extracted from the EAP-pwd-Commit/Request. Scalar_S is 879 then checked to ensure it is between 1 and r, exclusive. If it is 880 not the peer MUST terminate the exchange. If it is, Element_S MUST 881 be validated depending on the type of group-- Element validation for 882 FFC groups is described in Section 2.8.5.2.1 and Element validation 883 for ECC groups is described in Section 2.8.5.2.2. If validation is 884 successful the peer chooses two random numbers, p_rand and p_mask, 885 between 1 and r (where r is described in Section 2.1 according to the 886 group established in Section 2.8.5.1) such that their sum modulo r is 887 greater than one (1), and computes Element_P and Scalar_P. Next, the 888 peer computes kp from p_rand, Element_S, Scalar_S and the Password 889 Element according to Section 2.8.4. If kp is the the "identity 890 element"-- the point at infinity for an ECC group or the value one 891 (1) for an FFC group-- the peer MUST terminate the exchange. If not, 892 the peer uses Element_P and Scalar_P to construct an EAP-pwd-Commit/ 893 Response according to Section 3.2.2 and transmits the EAP-pwd-Commit/ 894 Response to the server. 896 Upon receipt of the EAP-pwd-Commit/Response, the server validates the 897 length of the entire payload based upon the expected lengths of 898 Element_P and Scalar_P (which are fixed according to the agreed-upon 899 group). If the length is incorrect, the server MUST respond with an 900 EAP-Failure message and it MUST terminate the exchange and free up 901 any state allocated. If the length is correct, Scalar_P and 902 Element_P are extracted from the EAP-pwd-Commit/Response and compared 903 to Scalar_S and Element_S. If Scalar_P equals Scalar_S and Element_P 904 equals Element_S it indicates a reflection attack and the server MUST 905 respond with an EAP-failure and terminate the exchange. If they 906 differ, Scalar_P is checked to ensure it is between 1 and r, 907 exclusive. If not the server MUST respond with an EAP-failure and 908 terminate the exchange. If it is, Element_P is verified depending on 909 the type of group-- Element validation for FFC groups is described in 910 Section 2.8.5.2.1 and Element validation for ECC groups is described 911 in Section 2.8.5.2.2. If validation is successful the server 912 computes ks from s_rand, Element_P, Scalar_P and the Password Element 913 according to Section 2.8.4. If ks is the "identity element"-- the 914 point at infinity for an ECC group or the value one (1) for an FFC 915 group-- the server MUST respond with an EAP-failure and terminate the 916 exchange. Otherwise, the server initiates an EAP-pwd-Confirm 917 exchange. 919 2.8.5.2.1. Element Validation for FFC Groups 921 A received FFC Element is valid if: 1) it is between one (1) and the 922 prime, p, exclusive; and 2) if modular exponentiation of the Element 923 by the group order, r, equals one (1). If either of these conditions 924 are not true the received Element is invalid. 926 2.8.5.2.2. Element Validation for ECC Groups 928 Validating a received ECC Element involves: 1) checking whether the 929 two coordinates, x and y, are both greater than zero (0) and less 930 than the prime defining the underlying field; and 2) checking whether 931 the x- and y-coordinates satisfy the equation of the curve (that is, 932 that they produce a valid point on the curve that is not the point- 933 at-infinity). If either of these conditions are not met the received 934 Element is invalid, otherwise the Element is valid. 936 2.8.5.3. EAP-pwd-Confirm Exchange 938 The server computes Confirm_S according to Section 2.8.4 and 939 constructs an EAP-pwd-Confirm/Request according to Section 3.2.3 and 940 sends the EAP-pwd-Confirm/Request to the peer. 942 Upon receipt of an EAP-pwd-Confirm/Request, the peer validates the 943 length of the entire payload based upon the expected length of 944 Confirm_S (whose length is fixed by the agreed-upon random function). 945 If the length is incorrect, the peer MUST terminate the exchange and 946 free up any state allocated. If the length is correct, the peer 947 verifies that Confirm_S is the value it expects based on the value of 948 kp. If the value of Confirm_S is incorrect, the peer MUST terminate 949 the exchange and free up any state allocated. If the value of 950 Confirm_S is correct, the peer computes Confirm_P, constructs an EAP- 951 pwd-Confirm/Response according to Section 3.2.3 and sends it off to 952 the server. The peer then computes MK (according to Section 2.8.4) 953 and the MSK and EMSK (according to Section 2.9) and stores these keys 954 in state allocated for this exchange. The peer SHOULD export the MSK 955 and EMSK at this time in anticipation of a secure association 956 protocol by the lower-layer to create session keys. Alternately, the 957 peer can wait until an EAP-success message from the server before 958 exporting the MSK and EMSK. 960 Upon receipt of an EAP-pwd-Confirm/Response, the server validates the 961 length of the entire payload based upon the expected length of 962 Confirm_P (whose length is fixed by the agreed-upon random function). 963 If the length is incorrect, the server MUST respond with an EAP- 964 Failure message and it MUST terminate the exchange and free up any 965 state allocated. If the length is correct, the server verifies that 966 Confirm_P is the value it expects based on the value of ks. If the 967 value of Confirm_P is incorrect, the server MUST respond with an EAP- 968 Failure message. If the value of Confirm_P is correct, the server 969 computes MK (according to Section 2.8.4) and the MSK and EMSK 970 (according to Section 2.9). It exports the MSK and EMSK and responds 971 with an EAP-success message. The server SHOULD free up state 972 allocated for this exchange. 974 2.9. Management of EAP-pwd Keys 976 [RFC5247] recommends each EAP method define how to construct a 977 Method-ID and Session-ID to identify a particular EAP session between 978 a peer and server. This information is constructed thusly: 980 Method-ID = H(Ciphersuite | Scalar_P | Scalar_S) 982 Session-ID = Type-Code | Method-ID 984 where Ciphersuite, Scalar_P and Scalar_S are from the specific 985 exchange being identified; H is the random function specified in the 986 Ciphersuite; and, Type-Code is the code assigned for EAP-pwd, TBD, 987 represented as a single octet. 989 The authenticated key exchange of EAP-pwd generates a shared and 990 authenticated key, MK. The size of MK is dependent on the random 991 function, H, asserted in the Ciphersuite. EAP-pwd must export two 992 512-bit keys, MSK and EMSK. Regardless of the value of len(MK) 993 implementations MUST invoke the KDF defined in Section 2.5 to 994 construct the MSK and EMSK. The MSK and EMSK are derived thusly: 996 MSK | EMSK = KDF(MK, Session-ID, 1024) 998 [RFC4962] mentions the importance of naming keys, particularly when 999 key caching is being used. To facilitate such an important 1000 optimization, names are assigned thusly: 1002 o EMSK-name = Session-ID | 'E' | 'M'| 'S' | 'K' 1004 o MSK-name = Session-ID | 'M'| 'S' | 'K' 1006 where 'E' is a single octet of value 0x45, 'M' is a single octet of 1007 value 0x4d, 'S' is a single octet of value 0x53, and 'K' is a single 1008 octet of value 0x4b. 1010 This naming scheme allows for key management applications to quickly 1011 and accurately identify keys for a particular session or all keys of 1012 a particular type. 1014 2.10. Mandatory-to-Implement Parameters 1016 For the purposes of interoperability, compliant EAP-pwd 1017 implementations SHALL support the following parameters: 1019 o Diffie-Hellman Group: group 19 defined in [RFC5114] 1021 o Random Function: defined in Section 2.4 1023 o PRF: HMAC-SHA256 defined in [RFC4634] 1025 o Password Pre-Processing: none 1027 3. Packet Formats 1029 3.1. EAP-pwd Header 1031 The EAP-pwd header has the following structure: 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Code | Identifier | Length | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Type |L|M| PWD-Exch | Total-Length | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Data... 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 Figure 5: EAP-pwd Header 1045 Code 1047 Either 1 (for Request) or 2 (for Response); see [RFC3748]. 1049 Identifier 1051 The Identifier field is one octet and aids in matching responses 1052 with requests. The Identifier field MUST be changed on each 1053 Request packet. 1055 Length 1057 The Length field is two octets and indicates the length of the EAP 1058 packet including the Code, Identifier, Length, Type, and Data 1059 fields. Octets outside the range of the Length field should be 1060 treated as Data Link Layer padding and MUST be ignored on 1061 reception. 1063 Type 1065 TBD - EAP-pwd 1067 L and M bits 1069 The L bit (Length included) is set to indicate the presence of the 1070 two-octet Total-Length field, and MUST be set for the first 1071 fragment of a fragmented EAP-pwd message or set of messages. 1073 The M bit (more fragments) is set on all but the last fragment. 1075 PWD-Exch 1077 The PWD-Exch field identifies the type of EAP-pwd payload 1078 encapsulated in the Data field. This document defines the 1079 following values for the PWD-Exch field: 1081 * 0x00 : Reserved 1083 * 0x01 : EAP-pwd-ID exchange 1085 * 0x02 : EAP-pwd-Commit exchange 1087 * 0x03 : EAP-pwd-Confirm exchange 1089 All other values of the PWD-Exch field are reserved to IANA. 1091 Total-Length 1093 The Total-Length field is two octets in length, and is present 1094 only if the L bit is set. This field provides the total length of 1095 the EAP-pwd message or set of messages that is being fragmented. 1097 3.2. EAP-pwd Payloads 1099 EAP-pwd payloads all contain the EAP-pwd header and encoded 1100 information. Encoded information is comprised of sequences of data. 1101 Payloads in the EAP-pwd-ID exchange also include a ciphersuite 1102 statement indicating what finite cyclic group to use, what 1103 cryptographic primitive to use for H, and what PRF to use for 1104 deriving keys. 1106 3.2.1. EAP-pwd-ID 1108 The Group Description, Random Function, and PRF together, and in that 1109 order, comprise the Ciphersuite included in the calculation of the 1110 peer's and server's confirm messages. 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Group Description | Random Func'n | PRF | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Token | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Prep | Identity... 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 Figure 6: EAP-pwd-ID Payload 1124 The Group Description field value is taken from the IANA registry for 1125 "Group Description" created by IKE [RFC2409]. 1127 This document defines the following value for the Random Function 1128 field: 1130 o 0x01 : Function defined in this memo in Section 2.4 1132 The value 0x00 is reserved for private use between mutually 1133 consenting parties. All other values of the Random Function field 1134 are reserved to IANA. 1136 The PRF field has the following value: 1138 o 0x01 : HMAC-SHA256 [RFC4634] 1140 The value 0x00 is reserved for private use between mutually 1141 consenting parties. All other values of the PRF field are reserved 1142 to IANA. 1144 The Token field contains an unpredictable value assigned by the 1145 server in an EAP-pwd-ID/Request and acknowledged by the peer in an 1146 EAP-pwd-ID/Response (see Section 2.8.5). 1148 The Prep field represents the password pre-processing technique (see 1149 Section 2.7.2) to be used by the client prior to generating the 1150 password seed (see Section 2.8.3). This document defines the 1151 following values for the Prep field: 1153 o 0x00 : None 1155 o 0x01 : RFC2759 1157 o 0x02 : SASLprep 1159 All other values of the Prep field are reserved to IANA. 1161 The Identity field depends on the value of PWD-Exch. 1163 o EAP-pwd-ID/Request : Server_ID 1165 o EAP-pwd-ID/Response : Peer_ID 1167 The length of the identity is computed from the Length field in the 1168 EAP header. 1170 3.2.2. EAP-pwd-Commit 1171 0 1 2 3 1172 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 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | | 1175 ~ Element ~ 1176 | | 1177 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | | | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ 1180 | | 1181 ~ Scalar +-+-+-+-+-+-+-+-+ 1182 | | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 Figure 7: EAP-pwd-Commit Payload 1187 The Element and Scalar fields depend on the value of PWD-Exch. 1189 o EAP-pwd-Commit/Request : Element_S, Scalar_S 1191 o EAP-pwd-Commit/Response : Element_P, Scalar_P 1193 The Element is encoded according to Section 3.3. The length of the 1194 Element is inferred by the finite cyclic group from the agreed-upon 1195 Ciphersuite. The length of the scalar can then be computed from the 1196 Length in the EAP header. 1198 3.2.3. EAP-pwd-Confirm 1200 0 1 2 3 1201 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 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | | 1204 ~ Confirm ~ 1205 | | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 Figure 8: EAP-pwd-Confirm Payload 1210 The Confirm field depends on the value of PWD-Exch. 1212 o EAP-pwd-Confirm/Request : Confirm_S 1214 o EAP-pwd-Confirm/Response : Confirm_P 1216 The length of the Confirm field computed from the Length in the EAP 1217 header. 1219 3.3. Representation of Group Elements and Scalars 1221 Payloads in the EAP-pwd-Commit exchange contain elements from the 1222 agreed-upon finite cyclic cryptographic group (either an FCC group or 1223 an ECC group). To ensure interoperability field elements and scalars 1224 MUST be represented in payloads in accordance with the requirements 1225 described below. 1227 3.3.1. Elements in FFC Groups 1229 Elements in an FFC group MUST be represented (in binary form) as 1230 unsigned integers that are strictly less than the prime, p, from the 1231 group's domain parameter set. The binary representation of each 1232 group element MUST have a bit length equal to the bit length of the 1233 binary representation of p. This length requirement is enforced, if 1234 necessary, by prepending the binary representation of the integer 1235 with zeros until the required length is achieved. 1237 3.3.2. Elements in ECC Groups 1239 Elements in an ECC group are points on the agreed-upon elliptic 1240 curve. Each such element MUST be represented by the concatenation of 1241 two components, an x-coordinate and a y-coordinate. 1243 Each of the two components, the x-coordinate and the y-coordinate, 1244 MUST be represented (in binary form) as an unsigned integer that is 1245 strictly less than the prime, p, from the group's domain parameter 1246 set. The binary representation of each component MUST have a bit 1247 length equal to the bit length of the binary representation of p. 1248 This length requirement is enforced, if necessary, by prepending the 1249 binary representation of the integer with zeros until the required 1250 length is achieved. 1252 Since the field element is represented in a payload by the 1253 x-coordinate followed by the y-coordinate it follows, then, that the 1254 length of the element in the payload MUST be twice the bit length of 1255 p. In other words, "compressed representation" is not used. 1257 3.3.3. Scalars 1259 Scalars MUST be represented (in binary form) as unsigned integers 1260 that are strictly less than r, the order of the generator of the 1261 agreed-upon cryptographic group. The binary representation of each 1262 scalar MUST have a bit length equal to the bit length of the binary 1263 representation of r. This requirement is enforced, if necessary, by 1264 prepending the binary representation of the integer with zeros until 1265 the required length is achieved. 1267 4. Fragmentation 1269 EAP [RFC3748] is a request-response protocol. The server sends 1270 requests and the peer responds. These request and response messages 1271 are assumed to be limited to at most 1020 bytes. Messages in EAP-pwd 1272 can be larger than 1020 bytes and therefore require support for 1273 fragmentation and reassembly. 1275 Implementations MUST establish a fragmentation threshold that 1276 indicates the maximum size of an EAP-pwd payload. When an 1277 implementation knows the maximum transmission unit (MTU) of its 1278 lower-layer, it SHOULD calculate the fragmentation threshold from 1279 that value. In lieu of knowledge of the lower-layer's MTU the 1280 fragmentation threshold MUST be set to 1020 bytes. 1282 Since EAP is a simple ACK-NAK protocol, fragmentation support can be 1283 added in a simple manner. In EAP, fragments that are lost or damaged 1284 in transit will be retransmitted, and since sequencing information is 1285 provided by the Identifier field in EAP, there is no need for a 1286 fragment offset field as is provided in IPv4. 1288 EAP-pwd fragmentation support is provided through addition of flags 1289 within the EAP-Response and EAP-Request packets, as well as a Total- 1290 Length field of two octets. Flags include the Length included (L) 1291 and More fragments (M) bits. The L flag is set to indicate the 1292 presence of the two octet Total-Length field, and MUST be set for the 1293 first fragment of a fragmented EAP-pwd message or set of messages. 1294 The M flag is set on all but the last fragment. The Total-Length 1295 field is two octets, and provides the total length of the EAP-pwd 1296 message or set of messages that is being fragmented; this simplifies 1297 buffer allocation. 1299 When an EAP-pwd peer receives an EAP-Request packet with the M bit 1300 set, it MUST respond with an EAP-Response with EAP-Type=EAP-pwd and 1301 no data. This serves as a fragment ACK. The EAP server MUST wait 1302 until it receives the EAP-Response before sending another fragment. 1303 In order to prevent errors in processing of fragments, the EAP server 1304 MUST increment the Identifier field for each fragment contained 1305 within an EAP-Request, and the peer MUST include this Identifier 1306 value in the fragment ACK contained within the EAP-Response. 1307 Retransmitted fragments will contain the same Identifier value. 1309 Similarly, when the EAP server receives an EAP-Response with the M 1310 bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-pwd 1311 and no data. This serves as a fragment ACK. The EAP peer MUST wait 1312 until it receives the EAP-Request before sending another fragment. 1313 In order to prevent errors in the processing of fragments, the EAP 1314 server MUST increment the Identifier value for each fragment ACK 1315 contained within an EAP-Request, and the peer MUST include this 1316 Identifier value in the subsequent fragment contained within an EAP- 1317 Response. 1319 5. IANA Considerations 1321 This memo contains new numberspaces to be managed by IANA. The 1322 policies used to allocate numbers are described in [RFC5226]. This 1323 memo requires IANA to allocate a new EAP method type for EAP-pwd. 1324 The placeholders indicated by "TBD" above-- sections Section 2.9 and 1325 Section 3.1-- shall be replaced by the new EAP method type upon 1326 assignment by IANA. 1328 This memo also requires IANA to create new registries for PWD-Exch 1329 messages, random functions, PRFs, and password pre-processing methods 1330 and to add the message numbers, random function, PRF, and pre- 1331 processing methods specified in this memo to those registries, 1332 respectively. 1334 The following is the initial PWD-Exch message registry layout: 1336 o 0x00 : Reserved 1338 o 0x01 : EAP-pwd-ID exchange 1340 o 0x02 : EAP-pwd-Commit exchange 1342 o 0x03 : EAP-pwd-Confirm exchange 1344 The PWD-Exch field is 6 bits long. The value 0x00 is reserved. All 1345 other values are available through assignment by IANA. IANA is 1346 instructed to assign values based on "IETF Review" (see [RFC5226]). 1348 The following is the initial Random Function registry layout: 1350 o 0x00 : Private Use 1352 o 0x01 : Function defined in this memo in Section 2.4 1354 The Random Function field is 8 bits long. The value 0x00 is for 1355 Private Use between mutually consenting parties. All other values 1356 are available through assignment by IANA. IANA is instructed to 1357 assign values based on "Specification Required" (see [RFC5226]). The 1358 Designated Expert performing the necessary review MUST ensure the 1359 random function has been cryptographically vetted. 1361 The following is the initial PRF registry layout: 1363 o 0x00 : Private Use 1365 o 0x01 : HMAC-SHA256 as defined in [RFC4634] 1367 The PRF field is 8 bits long. The value 0x00 is for Private Use 1368 between mutually consenting parties. All other values are available 1369 through assignment by IANA. IANA is instructed to assign values 1370 based on "IETF Review" (see [RFC5226]). 1372 The following is the initial layout for the password preprocessing 1373 method registry: 1375 o 0x00 : None 1377 o 0x01 : RFC2759 1379 o 0x02 : SASLprep 1381 The Prep field is 8 bits long and all other values are available 1382 through assignment by IANA. IANA is instructed to assign values 1383 based on "Specification Required" (see [RFC5226]). 1385 6. Security Considerations 1387 In Section 1.3 several security properties were presented that 1388 motivated the design of this protocol. This section will address how 1389 well they are met. 1391 6.1. Resistance to Passive Attack 1393 A passive attacker will see Scalar_P, Element_P, Scalar_S, and 1394 Element_S. She can guess at passwords to compute the password element 1395 but will not know s_rand or p_rand and therefore will not be able to 1396 compute MK. 1398 The secret random value of the peer (server) is effectively hidden by 1399 adding p_mask (s_mask) to p_rand (s_rand) modulo the order of the 1400 group. If the order is "r", then there are approximately "r" 1401 distinct pairs of numbers that will sum to the value Scalar_P 1402 (Scalar_S). Attempting to guess the particular pair is just as 1403 difficult as guessing the secret random value p_rand (s_rand), the 1404 probability of a guess is 1/(r - i) after "i" guesses and for a large 1405 value of r this exhaustive search technique is computationally 1406 infeasible. An attacker would do better by determining the discrete 1407 logarithm of Element_P (Element_S) using an algorithm like Baby-Step 1408 giant-step (see [APPCRY]), which runs on the order of the square root 1409 of r group operations (e.g. a group with order 2^160 that would be 1410 2^80 exponentiations or point multiplications). Based on the 1411 assumptions made on the finite cyclic group made in Section 2.3 that 1412 is also computationally infeasible. 1414 6.2. Resistance to Active Attack 1416 An active attacker can launch her attack after an honest server has 1417 sent EAP-pwd-Commit/Request to an honest peer. This would result in 1418 the peer sending EAP-pwd-Commit/Response. In this case the active 1419 attack has been reduced to that of a passive attacker since p_rand 1420 and s_rand will remain unknown. The active attacker could forge a 1421 value of Confirm_P (Confirm_S) and send it to the EAP server (EAP 1422 peer) in the hope that it will be accepted but due to the assumptions 1423 on H made in Section 2.3 that is computationally infeasible. 1425 The active attacker can launch her attack by forging EAP-pwd-Commit/ 1426 Request and sending it to the peer. This will result in the peer 1427 responding with EAP-pwd-Commit/Response. The attacker can then 1428 attempt to compute ks but since she doesn't know the password this is 1429 infeasible. It can be shown that an attack by receiving EAP-pwd- 1430 Commit/Request from an honest server and forging EAP-pwd-Commit/ 1431 Response is an identical attack with equal infeasibility. 1433 6.3. Resistance to Dictionary Attack 1435 An active attacker can wait until an honest server sends EAP-pwd- 1436 Commit/Request and then forge EAP-pwd-Commit/Response and send it to 1437 the server. The server will respond with EAP-pwd-Confirm/Request. 1438 Now the attacker can attempt to launch a dictionary attack. She can 1439 guess at potential passwords, compute the password element and 1440 compute kp using her p_rand, Scalar_S and Element_S from the EAP-pwd- 1441 Commit/Request and the candidate password element from her guess. 1442 She will know if her guess is correct when she is able to verify 1443 Confirm_S in EAP-pwd-Confirm/Request. 1445 But the attacker committed to a password guess with her forged EAP- 1446 pwd-Commit/Response when she computed Element_P. That value was used 1447 by the server in his computation of ks which was used when he 1448 constructed Confirm_S in EAP-pwd-Confirm/Request. Any guess of the 1449 password that differs from the one used in the forged EAP-pwd-Commit/ 1450 Response could not be verified as correct since the attacker has no 1451 way of knowing whether it is correct. She is able to make one guess 1452 and one guess only per attack. This means that any advantage she can 1453 gain-- guess a password, if it fails exclude it from the pool of 1454 possible passwords and try again-- is solely through interaction with 1455 an honest protocol peer. 1457 The attacker can commit to the guess with the forged EAP-pwd-Commit/ 1458 Response and then run through the dictionary, computing the password 1459 element and ks using her forged Scalar_P and Element_P. She will know 1460 she is correct if she can compute the same value for Confirm_S that 1461 the server produced in EAP-pwd-Confirm/Request. But this requires 1462 the attacker to know s_rand which we noted, above, was not possible. 1464 The password element PWE/pwe is chosen using a method described in 1465 Section 2.8.3. Since this is an element in the group there exists a 1466 scalar value, q, such that: 1468 PWE = q * G, for an ECC group 1470 pwe = g^q mod p, for an FFC group 1472 Knowledge of q can be used to launch a dictionary attack. For the 1473 sake of brevity, the attack will be demonstrated assuming an ECC 1474 group. The attack works thusly: 1476 The attacker waits until an honest server sends EAP-pwd-Commit/ 1477 Request. The attacker then generates a random Scalar_P and a random 1478 p_mask and computes Element_P = p_mask * G. The attacker sends the 1479 bogus Scalar_P and Element_P to the server and obtains Confirm_S in 1480 return. Note that the server is unable to detect that Element_P was 1481 calculated incorrectly. 1483 The attacker now knows that: 1485 KS = (Scalar_P * q + p_mask) * s_rand * G 1487 and 1489 s_rand * G = Scalar_P * G - ((1/q) mod r * -Element_P) 1491 Since Scalar_P, p_mask, G, and Element_P are all known the attacker 1492 can run through the dictionary, making a password guess, computing 1493 PWE using the technique in Section 2.8.3, determine q, and then use 1494 the equations above to compute KS and see if it can verify Confirm_S. 1495 But to determine q for a candidate PWE the attacker needs to perform 1496 a discrete logarithm which was assumed to be computationally 1497 infeasible in Section 2.3. Therefore this attack is also infeasible. 1499 The best advantage an attacker can gain in a single active attack is 1500 to determine whether a single guess at the password was correct. 1501 Therefore her advantage is solely through interaction and not 1502 computation, which is the definition for resistance to dictionary 1503 attack. 1505 Resistance to dictionary attack means that the attacker must launch 1506 an active attack to make a single guess at the password. If the size 1507 of the dictionary from which the password was extracted was D, and 1508 each password in the dictionary has an equal probability of being 1509 chosen, then the probability of success after a single guess is 1/D. 1510 After X guesses, and removal of failed guesses from the pool of 1511 possible passwords, the probability becomes 1/(D-X). As X grows so 1512 does the probability of success. Therefore it is possible for an 1513 attacker to determine the password through repeated brute-force, 1514 active, guessing attacks. This protocol does not presume to be 1515 secure against this and implementations SHOULD ensure the size of D 1516 is sufficiently large to prevent this attack. Implementations SHOULD 1517 also take countermeasures, for instance refusing authentication 1518 attempts for a certain amount of time, after the number of failed 1519 authentication attempts reaches a certain threshold. No such 1520 threshold or amount of time is recommended in this memo. 1522 6.4. Forward Secrecy 1524 The MSK and EMSK are extracted from MK which is derived from doing 1525 group operations with s_rand, p_rand, and the password element. The 1526 peer and server choose random values with each run of the protocol. 1527 So even if an attacker is able to learn the password, she will not 1528 know the random values used by either the peer or server from an 1529 earlier run and will therefore be unable to determine MK, or the MSK 1530 or EMSK. This is the definition of Forward Secrecy. 1532 6.5. Group Strength 1534 The strength of the shared secret, MK, derived in Section 2.8.4 1535 depends on the effort needed to solve the discrete logarithm problem 1536 in the chosen group. [RFC3766] has a good discussion on the strength 1537 estimates of symmetric keys derived from discrete logarithm 1538 cryptography. 1540 The mandatory-to-implement group defined in this memo is group 19, a 1541 group from [RFC5114] based on Elliptic Curve Cryptography (see 1542 Section 2.2.2) with a prime bit length of 256. This group was chosen 1543 because the current best estimate of a symmetric key derived using 1544 this group is 128 bits which is the typical length of a key for the 1545 Advanced Encryption Standard ([FIPS-197]). While it is possible to 1546 obtain a equivalent measure of strength using a group based on Finite 1547 Field Cryptography (see Section 2.2.1), it would require a much 1548 larger prime and be more memory and compute intensive. 1550 6.6. Random Functions 1552 The protocol described in this memo uses a function referred to as a 1553 "random oracle" (as defined in [RANDOR]). A significant amount of 1554 care must be taken to instantiate a random oracle out of handy 1555 cryptographic primitives. The random oracle used here is based the 1556 notion of a "Randomness Extractor" from [KDF]. 1558 This protocol can use any properly instantiated random oracle. To 1559 ensure that any new value for H will use a properly instantiated 1560 random oracle IANA has been instructed (in Section 5) to only 1561 allocate values from the Random Function registry after being vetted 1562 by an expert. 1564 A few of the defined groups that can be used with this protocol have 1565 a security estimate (see Section 6.5) less than 128 bits, many do not 1566 though, and to prevent the random function from being the gating 1567 factor (or a target for attack) any new random function MUST map its 1568 input to a target of at least 128 bits and SHOULD map its input to a 1569 target of at least 256 bits. 1571 7. Security Claims 1573 [RFC3748] requires that documents describing new EAP methods clearly 1574 articulate the security properties of the method. In addition, for 1575 use with wireless LANs [RFC4017] mandates and recommends several of 1576 these. The claims are: 1578 a. mechanism: password. 1580 b. claims: 1582 * mutual authentication: the peer and server both authenticate 1583 each other by proving possession of a shared password. This 1584 is REQUIRED by [RFC4017]. 1586 * forward secrecy: compromise of the password does not reveal 1587 the secret keys-- MK, MSK, or EMSK-- from earlier runs of the 1588 protocol. 1590 * replay protection: an attacker is unable to replay messages 1591 from a previous exchange either learn the password or a key 1592 derived by the exchange. Similarly the attacker is unable to 1593 induce either the peer or server to believe the exchange has 1594 successfully completed when it hasn't. Reflection attacks 1595 are foiled because the server ensures that the scalar and 1596 element supplied by the peer do not equal its own. 1598 * key derivation: keys are derived by performing a group 1599 operation in a finite cyclic group (e.g. exponentiation) 1600 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. See Section 6.5. This is REQUIRED 1656 by [RFC4017]. 1658 d. key hierarchy: MSKs and EMSKs are derived from the MK using the 1659 KDF defined in Section 2.5 as described in Section 2.8.4. 1661 e. vulnerabilities (note that none of these are REQUIRED by 1662 [RFC4017]): 1664 * protected ciphersuite negotiation: the ciphersuite offer made 1665 by the server is not protected from tampering by an active 1666 attacker. Downgrade attacks are prevented, though, since 1667 this is not a "negotiation" with a list of acceptable 1668 ciphersuites. If a Ciphersuite was modified by an active 1669 attacker it would result in a failure to confirm the message 1670 sent by the other party, since the Ciphersuite is bound by 1671 each side into its confirm message, and the protocol would 1672 fail as a result. 1674 * confidentiality: none of the messages sent in this protocol 1675 are encrypted. 1677 * integrity protection: messages in the EAP-pwd-Commit exchange 1678 are not integrity protected. 1680 * channel binding: this protocol does not enable the exchange 1681 of integrity-protected channel information that can be 1682 compared with values communicated via out-of-band mechanisms. 1684 * fast reconnect: this protocol does not provide a fast 1685 reconnect capability. 1687 * cryptographic binding: this protocol is not a tunneled EAP 1688 method and therefore has no cryptographic information to 1689 bind. 1691 * identity protection: the EAP-pwd-ID exchange is not 1692 protected. An attacker will see the server's identity in the 1693 EAP-pwd-ID/Request and see the peer's identity in EAP-pwd-ID/ 1694 Response. 1696 8. Acknowledgements 1698 The authors would like to thank Scott Fluhrer for discovering the 1699 "password as exponent" attack that was possible in the initial 1700 version of this memo and for his very helpful suggestions on the 1701 techniques for fixing the PWE/pwe to prevent it. The authors would 1702 also like to thank Hideyuki Suzuki for his insight in discovering an 1703 attack against a previous version of the underlying key exchange 1704 protocol. Special thanks to Lily Chen for helpful discussions on 1705 hashing into an elliptic curve and to Jin-Meng Ho for suggesting the 1706 countermeasures to protect against a small sub-group attack. Rich 1707 Davis suggested the defensive checks to Commit messages and his 1708 various comments greatly improved the quality of this memo and the 1709 underlying key exchange on which it is based. Scott Kelly suggested 1710 adding the anti-clogging token to the ID exchange to prevent 1711 distributed denial of service attacks. Dorothy Stanley provided 1712 valuable suggestions to improve the quality of this memo. The 1713 fragmentation method used was taken from [RFC5216]. 1715 9. References 1717 9.1. Normative References 1719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1720 Requirement Levels", BCP 14, RFC 2119, March 1997. 1722 [RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 1723 RFC 2759, January 2000. 1725 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1726 Internationalized Strings ("stringprep")", RFC 3454, 1727 December 2002. 1729 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1730 Levkowetz, "Extensible Authentication Protocol (EAP)", 1731 RFC 3748, June 2004. 1733 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1734 and Passwords", RFC 4013, February 2005. 1736 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1737 Network Access Identifier", RFC 4282, December 2005. 1739 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1740 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1742 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1743 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1744 May 2008. 1746 [SP800-108] 1747 Chen, L., "Recommendations for Key Derivation Using 1748 Pseudorandom Functions", NIST Special Publication 800-108, 1749 April 2008. 1751 [SP800-56A] 1752 Barker, E., Johnson, D., and M. Smid, "Recommendations for 1753 Pair-Wise Key Establishment Schemes Using Discrete 1754 Logarithm Cryptography", NIST Special Publication 800-56A, 1755 March 2007. 1757 9.2. Informative References 1759 [APPCRY] Menezes, A., van Oorshot, P., and S. Vanstone, "Handbook 1760 of Applied Cryptography", CRC Press Series on Discrete 1761 Mathematics and Its Applications, 1996. 1763 [BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: 1764 Password-Based Protocols Secure Against Dictionary 1765 Attack", Proceedings of the IEEE Symposium on Security and 1766 Privacy, Oakland, 1992. 1768 [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted Key 1769 Exchange: A Password-Based Protocol Secure against 1770 Dictionary Attacks and Password File Compromise", 1771 Proceedings of the 1st ACM Conference on Computer and 1772 Communication Security, ACM Press, 1993. 1774 [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably Secure 1775 Password Authenticated Key Exchange Using Diffie-Hellman", 1776 Proceedings of Eurocrypt 2000, LNCS 1807 Springer-Verlag, 1777 2000. 1779 [FIPS-197] 1780 Sam, U., "The Advanced Encryption Standard", Federal 1781 Information Processing Standard 197, November 2001. 1783 [JAB96] Jablon, D., "Strong Password-Only Authenticated Key 1784 Exchange", ACM SIGCOMM Computer Communication 1785 Review Volume 1, Issue 5, October 1996. 1787 [KDF] Krawczyk, H., "On Extract-then-Expand Key Derivation 1788 Functions and an HMAC-based KDF", March 2008, 1789 . 1791 [LUC97] Lucks, S., "Open Key Exchange: How to Defeat Dictionary 1792 Attacks Without Encrypting Public Keys", Proceedings of 1793 the Security Protocols Workshop, LNCS 1361. Springer- 1794 Verlag, 1997. 1796 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 1797 A Paradigm for Designing Efficient Protocols", Proceedings 1798 of the 1st ACM Conference on Computer and Communication 1799 Security, ACM Press, 1993, 1800 . 1802 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1803 (IKE)", RFC 2409, November 1998. 1805 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 1806 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 1807 RFC 3766, April 2004. 1809 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1810 Authentication Protocol (EAP) Method Requirements for 1811 Wireless LANs", RFC 4017, March 2005. 1813 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1814 Requirements for Security", BCP 106, RFC 4086, June 2005. 1816 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1817 Authorization, and Accounting (AAA) Key Management", 1818 BCP 132, RFC 4962, July 2007. 1820 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 1821 Groups for Use with IETF Standards", RFC 5114, 1822 January 2008. 1824 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1825 Authentication Protocol", RFC 5216, March 2008. 1827 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1828 Authentication Protocol (EAP) Key Management Framework", 1829 RFC 5247, August 2008. 1831 Authors' Addresses 1833 Dan Harkins 1834 Aruba Networks 1835 1322 Crossman Avenue 1836 Sunnyvale, CA 94089-1113 1837 United States of America 1839 Email: dharkins@arubanetworks.com 1841 Glen Zorn 1842 Network Zen 1843 1310 East Thomas Street 1844 #306 1845 Seattle, Washington 98102 1846 USA 1848 Phone: +1 (206) 377-9035 1849 Email: gwz@net-zen.net