idnits 2.17.1 draft-irtf-cfrg-dragonfly-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 (August 27, 2013) is 3888 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force D. Harkins, Ed. 3 Internet-Draft Aruba Networks 4 Intended status: Informational August 27, 2013 5 Expires: February 28, 2014 7 Dragonfly Key Exchange 8 draft-irtf-cfrg-dragonfly-02 10 Abstract 12 This document specifies a key exchange using discrete logarithm 13 cryptogprahy that is authenticated using a password or passphrase. 14 It is resistant to active attack, passive attack, and off-line 15 dictionary attack. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may not be modified, 21 and derivative works of it may not be created, except to format it 22 for publication as an RFC or to translate it into languages other 23 than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 28, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2.1. Notations . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2.2. Resistance to Dictionary Attack . . . . . . . . . . . 4 59 2. Discete Logarithm Cryptography . . . . . . . . . . . . . . . . 4 60 2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . . . 4 61 2.2. Finite Field Cryptography . . . . . . . . . . . . . . . . 6 62 3. The Dragonfly Key Exchange . . . . . . . . . . . . . . . . . . 7 63 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2. Derviation of the Password Element . . . . . . . . . . . . 8 65 3.2.1. Hunting and Pecking with ECC Groups . . . . . . . . . 10 66 3.2.2. Hunting and Pecking with MODP Groups . . . . . . . . . 11 67 3.3. The Commit Exchange . . . . . . . . . . . . . . . . . . . 11 68 3.4. The Confirm Exchange . . . . . . . . . . . . . . . . . . . 12 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 Passwords and passphrases are the predominant way of doing 80 authentication in the Internet today. Many protocols that use 81 passwords and passphrases for authentication exchange password- 82 derived data as a proof-of-knowledge of the password (for example, 83 [RFC5996], and [RFC5433]). This opens the exchange up to an off-line 84 dictionary attack where the attacker gleans enough knowledge from 85 either an active or passive attack on the protocol to run through a 86 pool of potential passwords and compute verifiers until it is able to 87 match the password-derived data. 89 This protocol employs discrete logarithm cryptography to perform an 90 efficient exchange in a way that performs mutual authentication using 91 a password but is resistant to an off-line dictionary attack. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 1.2. Definitions 101 1.2.1. Notations 103 The following notations are used in this memo 105 password 106 A shared, secret and potentially low-entropy word, phrase, code 107 or key used as a credential to mutually authenticate the peers. 108 It is not restricted to characters in a human language. 110 a | b 111 denotes concatenation of string "a" with string "b". 113 len(a) 114 indicates the length in bits of the string "a". 116 lsb(a) 117 returns the least-significant bit of the bitstring "a". 119 min(a,b) 120 returns the lexicographical minimum of strings a and b, or zero 121 (0) if a equals b. 123 max(a,b) 124 returns the lexicographical maximum of strings a and b, or zero 125 (0) if a equals b. 127 The convention for this memo to represent an element in a finite 128 cyclic group is to use an upper-case letter or acronym, while a 129 scalar is indicated with a lower-case letter or acronym. An element 130 that represents a point on an elliptic curve has an implied composite 131 nature-- i.e. it has both an x- and y-coordinate. 133 1.2.2. Resistance to Dictionary Attack 135 Resistance to dictionary attack means that any advantage an adversary 136 can gain must be directly related to the number of interactions she 137 makes with an honest protocol participant and not through 138 computation. The adversary will not be able to obtain any 139 information about the password except whether a single guess from a 140 protocol run is correct or incorrect. 142 2. Discete Logarithm Cryptography 144 Dragonfly uses discrete logarithm cryptography to achieve 145 authentication and key agreement (see [SP800-56A]). Each party to 146 the exchange derives ephemeral keys with respect to a particular set 147 of domain parameters (referred to here as a "group"). A group can be 148 based on Finite Field Cryptography (FFC) or Elliptic Curve 149 Cryptography (ECC). 151 Three operations are defined for both types of groups: 153 o "scalar operation"-- takes a scalar and an element in the group 154 to produce another element-- Z = scalar-op(x, Y). 156 o "element operation"-- takes two elements in the group to produce 157 a third-- Z = element-op(X, Y). 159 o "inverse operation"-- takes an element and returns another 160 element such that the element operation on the two produces the 161 identity element of the group-- Y = inverse(X). 163 2.1. Elliptic Curve Cryptography 165 Domain parameters for the ECC groups used by dragonfly are: 167 o A prime, p, determining a prime field GF(p). The cryptographic 168 group will be a subgroup of the full elliptic curve group that 169 consists of points on an elliptic curve -- elements from GF(p) 170 that satisfy the curve's equation -- together with the "point at 171 infinity" that serves as the identity element. The group 172 operation for ECC groups is addition of points on the elliptic 173 curve. 175 o Elements a and b from GF(p) that define the curve's equation. The 176 point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only 177 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 179 o A point, G, on the elliptic curve, which serves as a generator for 180 the ECC group. G is chosen such that its order, with respect to 181 elliptic curve addition, is a sufficiently large prime. 183 o A prime, q, which is the order of G, and thus is also the size of 184 the cryptographic subgroup that is generated by G. 186 An (x,y) pair is a valid ECC element if: 1) the x- and y-coordinates 187 are both greater than zero (0) and less than the prime defining the 188 underlying field; and, 2) the x- and y-coordinates satisfy the 189 equation for the curve and produce a valid point on the curve that is 190 not the point at infinity. If either one of those conditions do not 191 hold the (x,y) pair is not a valid element. 193 The scalar operation is multiplication of a point on the curve by 194 itself a number of times. The point Y is multiplied x-times to 195 produce another point Z: 197 Z = scalar-op(x, Y) = x*Y 199 The element operation is addition of two points on the curve. Points 200 X and Y are summed to produce another point Z: 202 Z = element-op(X, Y) = X + Y 204 The inverse function is defined such that the sum of an element and 205 its inverse is "0", the point-at-infinity of an elliptic curve group: 207 R + inverse(R) = "0" 209 Elliptic curve groups require a mapping function, q = F(Q), to 210 convert a group element to an integer. The mapping function used in 211 this memo returns the x-coordinate of the point it is passed. 213 scalar-op(x, Y) can be viewed as x iterations of element-op() by 214 defining: 216 Y = scalar-op(1, Y) 217 Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1 219 A definition of how to add two points on an elliptic curve (i.e. 220 element-op(X, Y)) can be found in [RFC6090]. 222 Note: There is another elliptic curve domain parameter, a co-factor, 223 h, that is defined by the requirement that the size of the full 224 elliptic curve group (including "0") be the product of h and q. 225 Elliptic curve groups used with dragonfly authentication MUST have a 226 co-factor of one (1). 228 2.2. Finite Field Cryptography 230 Domain parameters for the FFC groups used in dragonfly are: 232 o A prime, p, determining a prime field GF(p), the integers modulo 233 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 234 group of non-zero elements in GF(p). The group operation for FFC 235 groups is multiplication modulo p. 237 o An element, G, in GF(p)* which serves as a generator for the FFC 238 group. G is chosen such that its multiplicative order is a 239 sufficiently large prime divisor of ((p-1)/2). 241 o A prime, q, which is the multiplicative order of G, and thus also 242 the size of the cryptographic subgroup of GF(p)* that is generated 243 by G. 245 A number is a valid element in an FFC group if: 1) it is between one 246 (1) and one (1) less than the the prime, p, exclusive (i.e. 1 < 247 element < p-1); and, 2) if modular exponentiation of the element by 248 the group order, q, equals one (1). If either one of those 249 conditions do not hold the number is not a valid element. 251 The scalar operation is exponentiation of a generator modulo a prime. 252 An element Y is taken to the x-th power modulo the prime returning 253 another element, Z: 255 Z = scalar-op(x, Y) = Y^x mod p 257 The element operation is modular multiplication. Two elements, X and 258 Y, are multiplied modulo the prime returning another element, Z: 260 Z = element-op(X, Y) = (X * Y) mod p 262 The inverse function for a MODP group is defined such that the 263 product of an element and its inverse modulo the group prime equals 264 one (1). In other words, 265 (R * inverse(R)) mod p = 1 267 3. The Dragonfly Key Exchange 269 There are two parties to the Dragonfly exchange named, for 270 convenience and by convention, Alice and Bob. The two parties have a 271 shared password that was established in an out-of-band mechanism and 272 they both agree to use a particular domain parameter set (either ECC 273 or FFC). 275 Prior to beginning the Dragonfly exchange, the two peers MUST derive 276 a secret element in the chosen domain parameter set. Two "hunting- 277 and-pecking" techniques to determine a secret element, one for ECC 278 and one for FFC, are described in Section 3.2 but any secure, 279 determinstic method that is agreed up on can be used. For instance, 280 the technique described in [hash2ec] can be used for ECC groups. 282 The Dragonfly exchange consists of two message exchanges, a "Commit 283 Exchange" in which both sides commit to a single guess of the 284 password, and a "Confirm Exchange" in which both sides confirm 285 knowledge of the password. A side effect of running the Dragonfly 286 exchange is an authenticated, shared, and secret key whose 287 cryptographic strength is set by the agreed-upon group. 289 Dragonfly uses a random function, H(), a mapping function, F(), and a 290 key derivation function, KDF(). 292 3.1. Assumptions 294 The Dragonfly protocol achieves security under some basic 295 assumptions: 297 1. Function H is a "random oracle" (see [RANDOR]) that maps a binary 298 string of indeterminate length onto a fixed binary string that is 299 x bits in length. 301 H: {0,1}^* --> {0,1}^x 303 Given knowledge of the input to H, an adversary is unable to 304 distinguish the output of H from a random data source. 306 2. Function F is an injective mapping function that takes an element 307 in a group and returns an integer. For ECC groups function F() 308 returns the x-coordinate of the element (which is a point on the 309 elliptic curve), for FFC groups function F() is the identity 310 function (since all elements in an FFC group are already integers 311 less than the prime): 313 ECC: x = F(P), where P=(x,y) 315 FFC: x = F(x) 317 3. Function KDF is a key derivation function (see, for instance, 318 [SP800-108]) that takes a key to stretch, k, a label to bind to 319 the key, label, and an indication of the desired output, n: 321 stretch = KDF-n(k, label) 323 so that len(stretch) equals n. 325 4. The discrete logarithm problem for the chosen group is hard. 326 That is, given G, P, and Y = G^x mod p, it is computationally 327 infeasible to determine x. Similarly, for an ECC group given the 328 curve definition, a generator G, and Y = x * G, it is 329 computationally infeasible to determine x. 331 5. There exists a pool of passwords from which the password shared 332 by the two peers is drawn. This pool can consist of words from a 333 dictionary, for example. Each password in this pool has an equal 334 probability of being the shared password. All potential 335 attackers have access to this pool of passwords. 337 6. The peers have to ability to produce quality random numbers. 339 3.2. Derviation of the Password Element 341 Prior to beginning the exchange of information, the peers MUST derive 342 a secret element, called the Password Element (PE), in the group 343 defined by the chosen domain parameter set. From the point-of-view 344 of an attacker who does not know the password, PE will be a random 345 element in the negotiated group. Two examples are described here for 346 completeness but any method of deterministically mapping a secret 347 string into an element in a selected group can be used, for instance 348 the technique in [hash2ec] for ECC groups. If a different technique 349 than the ones described here is used, the secret string SHOULD 350 include the identities of the peers. 352 To fix PE, both peers MUST have a common view of the password. If 353 there is any password processing necessary, for example to support 354 internationalization, the processed password is then used as the 355 shared credential. If either side wants to store a salted version of 356 the password it will be necessary to convey the salt to the other 357 side prior to commensing the exchange and the salted password is then 358 used as the shared credential. 360 Note: only one party would be able to maintain a salted password and 361 this would require that the dragonfly key exchange be used in a 362 protocol that has strict roles for client (that always initiates) and 363 server (that always responds). Due to the symmetric nature of 364 dragonfly salting passwords does not prevent an impersonation attack 365 after compromise of a database of salted passwords. 367 The determinstic process to select the PE begins with choosing a 368 secret seed and then performing a group-specific hunting-and-pecking 369 technique-- one for FFC groups and another for ECC groups. 371 To thwart side channel attacks which attempt to determine the number 372 of iterations of the "hunting-and-pecking" loop are used to find PE 373 for a given password, a security parameter, k, is used to ensure that 374 at least k iterations are always performed. The probability that one 375 requires more than "n" iterations of the "hunting-and-pecking" loop 376 to find an ECC PE is roughly (q/2p)^n and to find an FFC PE is 377 roughly (q/p)^n, both of which rapidly approach zero (0) as "n" 378 increases. The security parameter, k, SHOULD be set sufficiently 379 large such that the probability that finding PE would take more than 380 k iterations is sufficiently small (see Section 6). 382 First, an 8-bit counter is set to one (1) and a secret base is 383 computed using the negotiated one-way function with the identities of 384 the two participants, Alice and Bob, the secret password and the 385 counter: 387 base = H((max(Alice,Bob) | min(Alice,Bob) | password | counter) 389 The base is then stretched using the technique from section B.5.1 of 390 [FIPS186-3]. The key derivation function, KDF, is used to produce a 391 bitstream whose length is equal to the length of the prime from the 392 group's domain parameter set plus the constant sixty-four (64) to 393 derive a temporary value, and the temporary value is moularly reduced 394 to produce a seed: 396 n = len(p) + 64 398 temp = KDF-n(base, "Dragonfly Hunting and Pecking") 400 seed = (temp mod (p - 1)) + 1 402 The string bound to the derived temporary value is for illustrative 403 purposes only. Implementations of the dragonfly key exchange SHOULD 404 use a usage specific label with the KDF. 406 Note: the base is stretched to 64 more bits than are needed so that 407 the bias from the modular reduction is not so apparent. 409 The seed is then passed to the group-specific hunting and pecking 410 technique. 412 If the protocol performing the dragonfly exchange has the ability to 413 exchange random nonces those SHOULD be added to the computation of 414 base to ensure that each run of the protocol produces a different PE. 416 3.2.1. Hunting and Pecking with ECC Groups 418 The ECC specific hunting and pecking technique entails looping until 419 a valid point on the elliptic curve has been found. If the seed is 420 not a quadratic residue modulo p, then the counter is incremented, a 421 new base and new seed are generated and the hunting and pecking 422 continues. If the seed is a quadratic residue modulo p, then the 423 seed is used as the x-coordinate with the equation of the curve to 424 solve for a y-coordinate. An ambiguity exists since two values for 425 the y-coordinate would be valid and the low-order bit of the base is 426 used to unambiguously determine the correct y-coordinate. The 427 resulting (x,y) pair becomes the Password Element, PE. 429 Algorithmically, the process looks like this: 431 found = 0 432 counter = 1 433 n = len(p) + 64 434 do { 435 base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter) 436 temp = KDF-n(seed, "Dragonfly Hunting And Pecking") 437 seed = (temp mod (p - 1)) + 1 438 if (seed < p) 439 then 440 x = seed 441 if ( (x^3 + ax + b) is a quadratic residue mod p) 442 then 443 y = sqrt(x^3 + ax + b) 444 if (lsb(y) == lsb(base)) 445 then 446 PE = (x,y) 447 else 448 PE = (x,p-y) 449 fi 450 found = 1 451 fi 452 fi 453 counter = counter + 1 454 } while ((found == 0) || (counter <= k)) 456 Figure 1: Fixing PE for ECC Groups 458 3.2.2. Hunting and Pecking with MODP Groups 460 The MODP specific hunting and pecking technique entails finding a 461 random element which, when used as a generator, will create a group 462 with the same order as the group created by the generator from the 463 domain parameter set. The secret generator is found by 464 exponentiating the seed to the value ((p-1)/q), where p is the prime 465 and q is the order from the domain parameter set. If that value is 466 greater than one (1) it becomes PE, otherwise the counter is 467 incremented, a new base and seed are generated, and the hunting and 468 pecking continues. 470 Algorithmically, the process looks like this: 472 found = 0 473 counter = 1 474 n = len(p) + 64 475 do { 476 base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter) 477 temp = KDF-n(seed, "Dragonfly Hunting And Pecking") 478 seed = (temp mod (p - 1)) + 1 479 if (seed < p) 480 then 481 PE = seed ^ ((p-1)/q) mod p 482 if (PE > 1) 483 then 484 found = 1 485 fi 486 fi 487 counter = counter + 1 488 } while ((found == 0) || (counter <= k)) 490 Figure 2: Fixing PE for MODP Groups 492 3.3. The Commit Exchange 494 In the Commit Exchange both sides commit to a single guess of the 495 password. The peers generate a scalar and an element, exchange them 496 with each other, and process the other's scalar and element to 497 generate a common and shared secret. 499 First each peer generates two random numbers, private and mask. 500 These two secrets, the Password Element, and the order from the 501 selected domain parameter set are then used to construct the scalar 502 and element: 504 scalar = (private + mask) modulo q 505 Element = inverse(scalar-op(mask, PE)) 507 If the scalar is less than two (2), the private and mask MUST be 508 thrown away and new values generated. Once a valid scalar and 509 Element are generated, the mask is no longer needed and MUST be 510 irretrievably destroyed. 512 The peers exchange their scalar and Element and validate the peer's 513 scalar and Element, deemed peer-scalar and Peer-Element. For the 514 peer-scalar to be valid, it MUST be between 1 and q exclusive. 515 Validation of the Peer-Element depends on the type of cryptosystem-- 516 validation of an (x,y) pair as an ECC element is specified in 517 Section 2.1 and validation of a number as an FFC element is specified 518 in Section 2.2. If either the peer-scalar or Peer-Element fail 519 validation then the exchange MUST be terminated and authentication 520 fails. If both the peer-scalar and Peer-Element are valid, they are 521 used with the Password Element to derive a shared secret, ss: 523 ss = F(scalar-op(private, 524 element-op(peer-Element, 525 scalar-op(peer-scalar, PE)))) 527 To enforce key separation and crypto hygiene, the shared secret is 528 stretched into two subkeys, a key confirmation key, kck, and a master 529 key, mk. Each of the subkeys SHOULD be at least the length of the 530 prime used in the selected group. 532 kck | mk = KDF-n(ss, "Dragonfly Key Derivation") 534 where n = len(p)*2. 536 3.4. The Confirm Exchange 538 In the Confirm Exchange both sides confirm that they derived the same 539 secret, and therefore, are in possession of the same password. 541 The Commit Exchange consists of an exchange of data that is the 542 output of the random function, H(), the key confirmation key, and the 543 two scalars and two elements exchanged in the Commit Exchange. The 544 order of the scalars and elements are, scalars before elements, and 545 sender's value before recipient's value. So from each peer's 546 perspective, it would generate: 548 confirm = H(kck | scalar | peer-scalar | 549 Element | Peer-Element) 551 The two peers exchange these confirmations and verify the correctness 552 of the other peer's confirmation that they receive. If the other 553 peer's confirmation is valid, authentication succeeds; if the other 554 peer's confirmation is not valid, authentication fails. 556 If authentication fails, all ephemeral state created as part of the 557 particular run of the dragonfly exchange MUST be irretrievabley 558 destroyed. If authentication does not fail, mk can be exported as an 559 authenticated and secret key that can be used by another protocol, 560 for instance IPsec, to protect other data. 562 4. Acknowledgements 564 The author would like to thank Kevin Igoe and David McGrew, chairmen 565 of the Crypto Forum Research Group (CFRG) for agreeing to accept this 566 memo as a CFRG work item. Additional thanks go to Scott Fluhrer and 567 Hideyuki Suzuki for discovering attacks against earlier versions of 568 this key exchange and suggesting fixes to address them. Lily Chen 569 provided helpful discussions on hashing into an elliptic curve. Rich 570 Davis suggested the validation steps used on received elements. 571 Dylan Clarke and Feng Hao discovered a dictionary attack against 572 dragonfly if a group with a small sub-group is used. Martin Rex, 573 Peter Gutmann, Marsh Ray, Rene Struik and Kevin Igoe discussed the 574 possibility of a side-channel attack against the hunting-and-pecking 575 loop and motivated the addition of the security parameter, k. 577 5. IANA Considerations 579 This memo includes no request to IANA. 581 6. Security Considerations 583 The dragonfly exchange requires both participants to have an 584 identical representation of the password. Salting of the password 585 merely generates a new credential-- the salted password-- which must 586 be identically represented on both sides. If an adversary is able to 587 gain access to the database of salted passwords, she would be able to 588 impersonate one side to the other, even if she was unable to 589 determine the underlying, unsalted, password. 591 Resistance to dictionary attack means that an adversary must launch 592 an active attack to make a single guess at the password. If the size 593 of the dictionary from which the password was extracted was "d", and 594 each password in the dictionary has an equal probability of being 595 chosen, then the probability of success after a single guess is 1/d. 596 After "x" guesses, and removal of failed guesses from the pool of 597 possible passwords, the probability becomes 1/(d-x). As "x" grows, 598 so does the probability of success. Therefore, it is possible for an 599 adversary to determine the password through repeated brute-force, 600 active, guessing attacks. Users of the dragonfly key exchange SHOULD 601 ensure that the size of the pool from which the password was drawn, 602 "d", is sufficiently large to make this attack preventable. 603 Implementations of dragonfly SHOULD support countermeasures to deal 604 with this attack-- for instance, by refusing authentication attempts 605 for a certain amount of time, after the number of failed 606 authentication attempts reaches a certain threshold. No such 607 threshold or amount of time is recommended in this memo. 609 Due to the problems with using groups that contain a small sub-group, 610 it is RECOMMENDED that implementations of Dragonfly not allow for the 611 specification of a group's domain parameter set in-line but instead 612 use a common repository in which to pass an identifier to a domain 613 parameter set whose strength has been rigourously proven and that 614 does not have small sub-groups. If a group's domain parameter set is 615 passed in-line, it SHOULD NOT be used with Dragonfly unless it 616 directly matches a known good group. 618 It is RECOMMENDED that an implementation set the security parameter, 619 k, to a value of at least forty (40) which will put the probability 620 that more than forty iterations are needed in the order of one in one 621 trillion (1:1,000,000,000,000). 623 7. References 625 7.1. Normative References 627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 628 Requirement Levels", BCP 14, RFC 2119, March 1997. 630 7.2. Informative References 632 [FIPS186-3] 633 National Institute of Standards and Technology, "Digital 634 Signature Standard (DSS)", Federal Information Processing 635 Standards Publication 186-3. 637 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 638 A Paradigm for Designing Efficient Protocols", Proceedings 639 of the 1st ACM Conference on Computer and Communication 640 Security, ACM Press, 1993, 641 . 643 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 644 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 645 RFC 5433, February 2009. 647 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 648 "Internet Key Exchange Protocol Version 2 (IKEv2)", 649 RFC 5996, September 2010. 651 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 652 Curve Cryptography Algorithms", RFC 6090, February 2011. 654 [SP800-108] 655 Chen, L., "Recommendations for Key Derivation Using 656 Pseudorandom Functions", NIST Special Publication 800-108, 657 April 2008. 659 [SP800-56A] 660 Barker, E., Johnson, D., and M. Smid, "Recommendations for 661 Pair-Wise Key Establishment Schemes Using Discrete 662 Logarithm Cryptography", NIST Special Publication 800-56A, 663 March 2007. 665 [hash2ec] Coron, J-B. and T. Icart, "An indifferentiable hash 666 function into elliptic curves", Cryptology ePrint 667 Archive Report 2009/340, 2009. 669 Author's Address 671 Dan Harkins (editor) 672 Aruba Networks 673 1322 Crossman Avenue 674 Sunnyvale, CA 94089-1113 675 United States of America 677 Email: dharkins@arubanetworks.com