idnits 2.17.1 draft-harkins-eap-pwd-prime-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 24, 2019) is 1737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU D. Harkins 3 Internet-Draft HPE 4 Intended status: Informational July 24, 2019 5 Expires: January 25, 2020 7 Improved Extensible Authentication Protocol Using Only a Password 8 draft-harkins-eap-pwd-prime-00.txt 10 Abstract 12 Passwords are a popular form of credential for user authentication. 13 EAP-pwd (RFC 5931) is a popular method of performing secure password 14 authenticaiton. EAP-pwd requires a secret element in a finite cyclic 15 group, unfortunately the technique it uses to derive this secret is 16 open to timing and cache attacks. This improved version, EAP-pwd', 17 uses a different technique to derive the secret element which is 18 resistant to timing and cache attacks. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [1]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 25, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. EAP-pwd' . . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2.1. Secret Element Derivation for ECC . . . . . . . . . . . . 3 63 2.2. Secret Element Derivation for FFC . . . . . . . . . . . . 6 64 2.3. Fixing the Password Element . . . . . . . . . . . . . . . 7 65 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 5. Implementation Considerations . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 7.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 EAP-pwd is a popular EAP method due to the fact that it authenticates 77 without requiring certificates. Large federated networks sometimes 78 have latency issues with numerous fragmented packets going between 79 the EAP client and EAP server, a problem exacerbated by using EAP 80 methods that require certificate-based authentication. EAP-pwd 81 obviates this. 83 The technique used by EAP-pwd to obtain its secret element is 84 susceptible to timing attacks and cache attacks that can partition 85 the dictionary enough to successfully determine the password. Recent 86 work in the Crypto Forum Research Group on constant time techniques 87 to hash a string into a point on an elliptic curve in constant time 88 [2] provides an opportunity to address this. 90 2. EAP-pwd' 92 EAP-pwd' is an EAP method that follows the EAP-pwd specification 93 ([3]) in all respects except for the following: 95 o It uses the Type code TBD-1, not 52 which is used by EAP-pwd. 97 o It derives PWE/pwe as defined in Section 2.1 and Section 2.2 for 98 ECC and FFC groups, respectively, using a different technique than 99 the "hunting and pecking" loop defined in [3]. 101 o it defines three new random functions using HKDF instantiated with 102 SHA-256, SHA-384, and SHA-512. 104 EAP-pwd' MUST be used with one of the random functions defined in 105 this document. 107 The technique used by EAP-pwd' for deriving PWE/pwe can be 108 implemented in constant time and is resistant to the side channel and 109 timing attacks that the hunting-and-pecking loop of [3] is 110 susceptible to. Computing the password element in EAP-pwd' is a two- 111 step process. First, a secret element based on the password is 112 generated using one of the two new techniques, one for ECC and one 113 for FFC. Next the identities of the EAP server and EAP peer are 114 combined with the secret element to create the password element used 115 by the key exchange of [3]. 117 The secret element can be generated at provisioning time or a run- 118 time. Either way, the EAP server will generate the password element 119 prior to generation of an EAP-pwd-Commit/Request and the EAP peer 120 will generate the password element prior to generation of an EAP-pwd- 121 Commit/Response. 123 2.1. Secret Element Derivation for ECC 125 The new technique to hash into an elliptic curve is the "Simplified 126 Shallue-van de Woestijne-Ulas Method" from [2]. The operations to 127 derive the secret element can be implemented in constant time. 129 The Simplified SWU method takes a password as input and generates 2 130 values-- x1 and x2-- at least one of which will be the abscissa of a 131 point on the curve. Since this method does not map its input to the 132 entire curve it is necessary to use a construct from [5] that uses 133 Simplified SWU with two functions that operate as random oracles to 134 produce two different points whose sum is the secret point S: 136 S := SSWU( h1(m) ) + SSWU( h2(m) ) 138 Where m is the message to hash, h1() and h2() are random oracles 139 based on hash functions, '+' is point addition, and SSWU() is the 140 "Simplified SWU" hash-to-curve method. 142 EAP-pwd' uses HKDF ([4]) to instantiate the random oracles. The 143 password and a label is passed to HKDF() to produce a password-seed. 144 The password seed is then reduced modulo the prime to produce the 145 input variable, u, for "Simplified SWU" which generates the first 146 intermediate point. This process is repeated with a different label 147 to produce the second intermediate point. Their sum is S. 149 The particular flavor of HKDF is the random function negotiated by 150 EAP-pwd'. 152 Algorithmically, the process looks like this: 154 simplified_swu(password) { 155 pwd-seed = HKDF(0^n, password, 156 "EAP-pwd' Hash to Element P1", olen(p)) 157 u = (pwd-seed modulo (p - 2)) + 2 159 t = inverse(z^2 * u^4 + z * u^2) 160 x1 = (-b/a) * (1 + t) 161 gx1 = x1^3 + a * x1 + b 162 x2 = z * u^2 * x1 163 gx2 = x2^3 + a * x2 + b 165 l = gx1 is a quadratic residue modulo p 166 v = CSEL(l, gx1, gx2) 167 x = CSEL(l, x1, x2) 168 y = sqrt(v) 170 l = CEQ(LSB(u), LSB(y)) 171 P1 = CSEL(l, (x,y), (x, p-y)) 173 pwd-seed = HKDF(0^n, password, 174 "EAP-pwd' Hash to Element P2", olen(p)) 175 u = (pwd-seed modulo (p - 2)) + 2 177 t = inverse(z^2 * u^4 + z * u^2) 178 x1 = (-b/a) * (1 + t) 179 gx1 = x1^3 + a * x1 + b 180 x2 = z * u^2 * x1 181 gx2 = x2^3 + a * x2 + b 183 l = gx1 is a quadratic residue modulo p 184 v = CSEL(l, gx1, gx2) 185 x = CSEL(l, x1, x2) 186 y = sqrt(v) 188 l = CEQ(LSB(u), LSB(y)) 189 P2 = CSEL(l, (x,y), (x, p-y)) 191 S = P1 + P2 193 output S 194 } 196 Figure 1: Generation of the ECC Secret Point 198 Where: 200 o 0^n is a salt of all zeros whose length equals the length of the 201 digest of the hash function that instantiates HKDF 203 o p is the prime, q is the order, a and b are part of the equation 204 of the curve, and all of these are defined in the domain parameter 205 set of the chosen curve 207 o z is a curve-specific parameter derived according to [2] for the 208 chosen curve 210 o LSB(x) returns the least significant bit of x 212 o CSEL(x,y,z) operates in constant time and returns y if x is true 213 and z otherwise 215 o CEQ(x,y) operates in constant time and returns true if x equals y 216 and false otherwise 218 2.2. Secret Element Derivation for FFC 220 The new technique to hash into an FFC group is similar to the 221 technique used in [3] but it does so without looping thereby 222 obviating a timing attack that can partition the dictionary. 224 EAP-pwd' uses HKDF ([4]) to produce a password value which is 225 exponentiated to produce a new element of the same order as the 226 generator of the group. This new element is output. 228 Algorithmically, the process looks like this: 230 hash_to_ffc(password) { 231 pwd-value = HKDF(0^n, password, 232 "EAP-pwd' Hash To Element", 233 olen(p)) 234 pwd-value = (pwd-value modulo (p - 2)) + 2 236 s = pwd-value^((p-1)/q) modulo p 238 output s 239 } 241 Figure 2: Generation of the FFC Secret Point 243 Where: 245 o 0^n is a salt of all zeros whose length equals the length of the 246 digest of the hash function that instantiates HKDF 248 o p is the prime, and q is the order and are defined in the domain 249 parameter set of the chosen group 251 The secret element, s, is guaranteed to have an order of either 1 or 252 q and the probability that it is 1 is remote enough to ignore. 254 2.3. Fixing the Password Element 256 The secret element derived in Section 2.1 or Section 2.2 is used to 257 fix EAP-pwd's Password Element prior to the generation of the EAP- 258 pwd-Commit/Request by the EAP server and prior to generation of the 259 EAP-pwd-Commit/Response by the EAP peer. To do this, they use the 260 negotiated random function to hash the anti-clogging token from [3] 261 and their identities to the length of the order of the negotiated 262 group. This is interpreted as an integer and reduced such that it is 263 between 1 and the order of the group, exclusive. The secret element 264 is then operated on by this value, point multiplication for ECC and 265 exponentiation for FFC, to produce the Password Element. 267 For ECC groups, this process looks like: 269 fix_PWE(S) { 270 val = HKDF(peer-ID | server-ID, token, "Fixing PWE", olen(p)) 271 val = val modulo (q - 1) + 1 273 PWE = val * S 274 } 276 Figure 3: Generation of PWE 278 Where: p is the prime, and q is the order and are defined in the 279 domain parameter set of the chosen group. 281 For FFC groups, this process looks like: 283 fix_pwe(S) { 284 val = HKDF(peer-ID | server-ID, token, "Fixing pwe", olen(p)) 285 val = val modulo (q - 1) + 1 287 pwe = s^val modulo p 288 } 290 Figure 4: Generation of pwe 292 Where: p is the prime, and q is the order and are defined in the 293 domain parameter set of the chosen group. 295 3. Acknowledgements 297 The author thanks Hugo Krawczyk and Riad Wahby. 299 4. IANA Considerations 301 IANA is insructed to assign a new EAP method type to EAP-pwd' and 302 replace TBD-1 in this document with that value. 304 IANA is instructed to assign values from the Random Function registry 305 of [3] for the following: 307 o TBD-2: HKDF with SHA256 as defined in [4] 309 o TBD-3: HKDF with SHA384 as defined in [4] 311 o TBD-4: HKDF with SHA512 as defined in [4] 313 Replacing TBD-[2-4] with the assigned values. 315 5. Implementation Considerations 317 Implementations SHOULD generate the secret element from Section 2.1 318 and Section 2.2 when the password is provisioned and wait to generate 319 a session-specific password element when the EAP-pwd' protocol 320 begins. 322 Implementations SHOULD offer use a random function that provides 323 commensurate strength for the curve being negotiated. Guidance is as 324 follows based on the length of the curve's prime, len(p): 326 o HKDF-SHA256 when len(p) <= 256 328 o HKDF-SHA384 when 256 < len(p) <= 384 330 o HKDF-SHA512 when 384 < len(p) 332 The technique to generate the secret element on an elliptic curve 333 from Section 2.1 only works on Weierstrass curves with an equation of 334 y^2 = x^3 + a*x + b, with a != 0 and b != 0. A different hash-to- 335 curve technique implementable in constant time will have to be used 336 for other curves. [2] defines curve-specific techniques to obtain a 337 secret element for other curves. In the event that such a technique 338 is used, the random function negotiated SHALL be HKDF based on the 339 hash function defined in the ciphersuite of the particular hash to 340 curve technique. 342 [2] describes useful utility functions that can be used to perform 343 the operations in Figure 1 in constant time. In addition, [7] 344 describes a useful blinding technique that can be used to determine 345 whether number is a quadratic residue modulo a prime in constant 346 time. 348 6. Security Considerations 350 The "hunting and pecking" loop done in [3] leaked information on how 351 many loops it took to determine the password element. This allows an 352 attacker to partition the dictionary by excluding possible passwords 353 which would take a different number of loops. After a frighteningly 354 few such partitionings it becomes possible for the attacker to 355 eliminate enough passwords to feasibly launch active attacks to learn 356 the password. [6] describes cache based attacks and timing attacks 357 that are possible against [3]. 359 The Simplified SWU hash-to-curve method with the Brier construct 360 allows for the password element to be derived in constant time which 361 obviates these attacks. 363 For implementations that cannot become completely constant time (due 364 to, for instance, limitations in a crypto library) it is possible to 365 limit timing attacks by generating the secret element from 366 Section 2.1 and Section 2.2 when the password is provisioned and then 367 generating the password element at run time. 369 7. References 371 7.1. Normative References 373 [1] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997, 375 . 377 [2] Fax-Hernandez, A., Scott, S., Sullivan, N., Wahby, R., and 378 C. Wood, "Hashing to Elliptic Curves", draft-irtf-cfrg- 379 hash-to-curve A work in progress, July 2019. 381 [3] Harkins, D. and G. Zorn, "Extensible Authentication 382 Protocol (EAP) Authentication Using Only a Password", RFC 383 5931, August 2010. 385 [4] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 386 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 387 RFC5869, May 2010, 388 . 390 7.2. Informative References 392 [5] Brier, E., "Efficient Indifferentiable Hashing into 393 Ordinary Elliptic Curves", Advances in Cryptology-- Crypto 394 2010 Springer-Verlag, 2010. 396 [6] Vanhoef, M. and E. Ronen, "Dragonblood: A Security 397 Analysis of WPA3's SAE Handshake", Cryptology ePrint 398 Archive Report 2019, 2019. 400 [7] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 401 10.17487/RFC7664, November 2015, 402 . 404 Author's Address 406 Dan Harkins 407 Hewlett Packard Enterprise 408 3333 Scott boulevard 409 Santa Clara 410 United States of America 412 Email: dharkins@lounge.org