idnits 2.17.1 draft-irtf-cfrg-dragonfly-03.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 (February 3, 2014) is 3729 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 February 3, 2014 5 Expires: August 7, 2014 7 Dragonfly Key Exchange 8 draft-irtf-cfrg-dragonfly-03 10 Abstract 12 This document specifies a key exchange using discrete logarithm 13 cryptography 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 August 7, 2014. 37 Copyright Notice 39 Copyright (c) 2014 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. Discrete Logarithm Cryptography . . . . . . . . . . . . . . . 4 60 2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . . . 5 61 2.2. Finite Field Cryptography . . . . . . . . . . . . . . . . 6 62 3. The Dragonfly Key Exchange . . . . . . . . . . . . . . . . . . 7 63 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2. Derivation of the Password Element . . . . . . . . . . . . 9 65 3.2.1. Hunting and Pecking with ECC Groups . . . . . . . . . 10 66 3.2.2. Hunting and Pecking with MODP Groups . . . . . . . . . 12 67 3.3. The Commit Exchange . . . . . . . . . . . . . . . . . . . 13 68 3.4. The Confirm Exchange . . . . . . . . . . . . . . . . . . . 14 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 lgr(a,b) 120 takes "a" and a prime, b and returns the legendre symbol (a/b). 122 min(a,b) 123 returns the lexicographical minimum of strings a and b, or zero 124 (0) if a equals b. 126 max(a,b) 127 returns the lexicographical maximum of strings a and b, or zero 128 (0) if a equals b. 130 The convention for this memo to represent an element in a finite 131 cyclic group is to use an upper-case letter or acronym, while a 132 scalar is indicated with a lower-case letter or acronym. An element 133 that represents a point on an elliptic curve has an implied composite 134 nature-- i.e. it has both an x- and y-coordinate. 136 1.2.2. Resistance to Dictionary Attack 138 Resistance to dictionary attack means that any advantage an adversary 139 can gain must be directly related to the number of interactions she 140 makes with an honest protocol participant and not through 141 computation. The adversary will not be able to obtain any 142 information about the password except whether a single guess from a 143 protocol run is correct or incorrect. 145 2. Discrete Logarithm Cryptography 147 Dragonfly uses discrete logarithm cryptography to achieve 148 authentication and key agreement (see [SP800-56A]). Each party to 149 the exchange derives ephemeral keys with respect to a particular set 150 of domain parameters (referred to here as a "group"). A group can be 151 based on Finite Field Cryptography (FFC) or Elliptic Curve 152 Cryptography (ECC). 154 Three operations are defined for both types of groups: 156 o "scalar operation"-- takes a scalar and an element in the group 157 to produce another element-- Z = scalar-op(x, Y). 159 o "element operation"-- takes two elements in the group to produce 160 a third-- Z = element-op(X, Y). 162 o "inverse operation"-- takes an element and returns another 163 element such that the element operation on the two produces the 164 identity element of the group-- Y = inverse(X). 166 2.1. Elliptic Curve Cryptography 168 Domain parameters for the ECC groups used by Dragonfly are: 170 o A prime, p, determining a prime field GF(p). The cryptographic 171 group will be a subgroup of the full elliptic curve group that 172 consists of points on an elliptic curve -- elements from GF(p) 173 that satisfy the curve's equation -- together with the "point at 174 infinity" that serves as the identity element. The group 175 operation for ECC groups is addition of points on the elliptic 176 curve. 178 o Elements a and b from GF(p) that define the curve's equation. The 179 point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only 180 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 182 o A point, G, on the elliptic curve, which serves as a generator for 183 the ECC group. G is chosen such that its order, with respect to 184 elliptic curve addition, is a sufficiently large prime. 186 o A prime, q, which is the order of G, and thus is also the size of 187 the cryptographic subgroup that is generated by G. 189 An (x,y) pair is a valid ECC element if: 1) the x- and y-coordinates 190 are both greater than zero (0) and less than the prime defining the 191 underlying field; and, 2) the x- and y-coordinates satisfy the 192 equation for the curve and produce a valid point on the curve that is 193 not the point at infinity. If either one of those conditions do not 194 hold the (x,y) pair is not a valid element. 196 The scalar operation is addition of a point on the curve with itself 197 a number of times. The point Y is multiplied x-times to produce 198 another point Z: 200 Z = scalar-op(x, Y) = x*Y 202 The element operation is addition of two points on the curve. Points 203 X and Y are summed to produce another point Z: 205 Z = element-op(X, Y) = X + Y 207 The inverse function is defined such that the sum of an element and 208 its inverse is "0", the point-at-infinity of an elliptic curve group: 210 R + inverse(R) = "0" 212 Elliptic curve groups require a mapping function, q = F(Q), to 213 convert a group element to an integer. The mapping function used in 214 this memo returns the x-coordinate of the point it is passed. 216 scalar-op(x, Y) can be viewed as x iterations of element-op() by 217 defining: 219 Y = scalar-op(1, Y) 221 Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1 223 A definition of how to add two points on an elliptic curve (i.e. 224 element-op(X, Y)) can be found in [RFC6090]. 226 Note: There is another elliptic curve domain parameter, a co-factor, 227 h, that is defined by the requirement that the size of the full 228 elliptic curve group (including "0") be the product of h and q. 229 Elliptic curve groups used with Dragonfly authentication MUST have a 230 co-factor of one (1). 232 2.2. Finite Field Cryptography 234 Domain parameters for the FFC groups used in Dragonfly are: 236 o A prime, p, determining a prime field GF(p), the integers modulo 237 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 238 group of non-zero elements in GF(p). The group operation for FFC 239 groups is multiplication modulo p. 241 o An element, G, in GF(p)* which serves as a generator for the FFC 242 group. G is chosen such that its multiplicative order is a 243 sufficiently large prime divisor of ((p-1)/2). 245 o A prime, q, which is the multiplicative order of G, and thus also 246 the size of the cryptographic subgroup of GF(p)* that is generated 247 by G. 249 A number is a valid element in an FFC group if: 1) it is between one 250 (1) and one (1) less than the the prime, p, exclusive (i.e. 1 < 251 element < p-1); and, 2) if modular exponentiation of the element by 252 the group order, q, equals one (1). If either one of those 253 conditions do not hold the number is not a valid element. 255 The scalar operation is exponentiation of a generator modulo a prime. 256 An element Y is taken to the x-th power modulo the prime returning 257 another element, Z: 259 Z = scalar-op(x, Y) = Y^x mod p 261 The element operation is modular multiplication. Two elements, X and 262 Y, are multiplied modulo the prime returning another element, Z: 264 Z = element-op(X, Y) = (X * Y) mod p 266 The inverse function for a MODP group is defined such that the 267 product of an element and its inverse modulo the group prime equals 268 one (1). In other words, 270 (R * inverse(R)) mod p = 1 272 3. The Dragonfly Key Exchange 274 There are two parties to the Dragonfly exchange named, for 275 convenience and by convention, Alice and Bob. The two parties have a 276 shared password that was established in an out-of-band mechanism and 277 they both agree to use a particular domain parameter set (either ECC 278 or FFC). In the Dragonfly exchange both Alice and Bob share an 279 identical view of the shared password-- i.e. it is not "augmented", 280 where one side holds a password and the other side holds a non- 281 invertable verifier. This allows Dragonfly to be used in traditional 282 client-server protocols and also in peer-to-peer applications in 283 which there are not fixed roles and either party may initiate the 284 exchange (and both parties may implement it simultaneously). 286 Prior to beginning the Dragonfly exchange, the two peers MUST derive 287 a secret element in the chosen domain parameter set. Two "hunting- 288 and-pecking" techniques to determine a secret element, one for ECC 289 and one for FFC, are described in Section 3.2 but any secure, 290 determinstic method that is agreed up on can be used. For instance, 291 the technique described in [hash2ec] can be used for ECC groups. 293 The Dragonfly exchange consists of two message exchanges, a "Commit 294 Exchange" in which both sides commit to a single guess of the 295 password, and a "Confirm Exchange" in which both sides confirm 296 knowledge of the password. A side effect of running the Dragonfly 297 exchange is an authenticated, shared, and secret key whose 298 cryptographic strength is set by the agreed-upon group. 300 Dragonfly uses a random function, H(), a mapping function, F(), and a 301 key derivation function, KDF(). 303 3.1. Assumptions 305 The Dragonfly protocol achieves security under some basic 306 assumptions: 308 1. Function H is a "random oracle" (see [RANDOR]) that maps a binary 309 string of indeterminate length onto a fixed binary string that is 310 x bits in length. 312 H: {0,1}^* --> {0,1}^x 314 Given knowledge of the input to H, an adversary is unable to 315 distinguish the output of H from a random data source. 317 2. Function F is a mapping function that takes an element in a group 318 and returns an integer. For ECC groups function F() returns the 319 x-coordinate of the element (which is a point on the elliptic 320 curve), for FFC groups function F() is the identity function 321 (since all elements in an FFC group are already integers less 322 than the prime): 324 ECC: x = F(P), where P=(x,y) 326 FFC: x = F(x) 328 3. Function KDF is a key derivation function (see, for instance, 329 [SP800-108]) that takes a key to stretch, k, a label to bind to 330 the key, label, and an indication of the desired output, n: 332 stretch = KDF-n(k, label) 334 so that len(stretch) equals n. 336 4. The discrete logarithm problem for the chosen group is hard. 337 That is, given G, P, and Y = G^x mod p, it is computationally 338 infeasible to determine x. Similarly, for an ECC group given the 339 curve definition, a generator G, and Y = x * G, it is 340 computationally infeasible to determine x. 342 5. There exists a pool of passwords from which the password shared 343 by the two peers is drawn. This pool can consist of words from a 344 dictionary, for example. Each password in this pool has an equal 345 probability of being the shared password. All potential 346 attackers have access to this pool of passwords. 348 6. The peers have to ability to produce quality random numbers. 350 3.2. Derivation of the Password Element 352 Prior to beginning the exchange of information, the peers MUST derive 353 a secret element, called the Password Element (PE), in the group 354 defined by the chosen domain parameter set. From the point-of-view 355 of an attacker who does not know the password, PE will be a random 356 element in the negotiated group. Two examples are described here for 357 completeness but any method of deterministically mapping a secret 358 string into an element in a selected group can be used, for instance 359 the technique in [hash2ec] for ECC groups. If a different technique 360 than the ones described here is used, the secret string SHOULD 361 include the identities of the peers. 363 To fix PE, both peers MUST have a common view of the password. If 364 there is any password processing necessary, for example to support 365 internationalization, the processed password is then used as the 366 shared credential. If either side wants to store a salted version of 367 the password it will be necessary to convey the salt to the other 368 side prior to commensing the exchange and the salted password is then 369 used as the shared credential. 371 Note: only one party would be able to maintain a salted password and 372 this would require that the Dragonfly key exchange be used in a 373 protocol that has strict roles for client (that always initiates) and 374 server (that always responds). Due to the symmetric nature of 375 Dragonfly salting passwords does not prevent an impersonation attack 376 after compromise of a database of salted passwords. 378 The determinstic process to select the PE begins with choosing a 379 secret seed and then performing a group-specific hunting-and-pecking 380 technique-- one for FFC groups and another for ECC groups. 382 To thwart side channel attacks which attempt to determine the number 383 of iterations of the "hunting-and-pecking" loop are used to find PE 384 for a given password, a security parameter, k, is used that ensures 385 that at least k iterations are always performed. The probability 386 that one requires more than "n" iterations of the "hunting-and- 387 pecking" loop to find an ECC PE is roughly (q/2p)^n and to find an 388 FFC PE is roughly (q/p)^n, both of which rapidly approach zero (0) as 389 "n" increases. The security parameter, k, SHOULD be set sufficiently 390 large such that the probability that finding PE would take more than 391 k iterations is sufficiently small (see Section 6). 393 First, an 8-bit counter is set to one (1) and a secret base is 394 computed using the negotiated one-way function with the identities of 395 the two participants, Alice and Bob, the secret password and the 396 counter: 398 base = H((max(Alice,Bob) | min(Alice,Bob) | password | counter) 400 The base is then stretched using the technique from section B.5.1 of 401 [FIPS186-3]. The key derivation function, KDF, is used to produce a 402 bitstream whose length is equal to the length of the prime from the 403 group's domain parameter set plus the constant sixty-four (64) to 404 derive a temporary value, and the temporary value is moularly reduced 405 to produce a seed: 407 n = len(p) + 64 409 temp = KDF-n(base, "Dragonfly Hunting and Pecking") 411 seed = (temp mod (p - 1)) + 1 413 The string bound to the derived temporary value is for illustrative 414 purposes only. Implementations of the Dragonfly key exchange SHOULD 415 use a usage specific label with the KDF. 417 Note: the base is stretched to 64 more bits than are needed so that 418 the bias from the modular reduction is not so apparent. 420 The seed is then passed to the group-specific hunting and pecking 421 technique. 423 If the protocol performing the Dragonfly exchange has the ability to 424 exchange random nonces those SHOULD be added to the computation of 425 base to ensure that each run of the protocol produces a different PE. 427 3.2.1. Hunting and Pecking with ECC Groups 429 The ECC specific hunting and pecking technique entails looping until 430 a valid point on the elliptic curve has been found. The seed is used 431 as an x-coordinate with the equation of the curve to check whether 432 x^3 + a*x + b is a quadratic residue modulo p. If it is not, then 433 the counter is incremented, a new base and new seed are generated and 434 the hunting and pecking continues. If it is a quadratic residue 435 modulo p, then the x-coordinate is assigned the value of seed and the 436 current base is stored. When the hunting-and-pecking loop 437 terminates, the x-coordinate is used with the equation of the curve 438 to solve for a y-coordinate. An ambiguity exists since two values 439 for the y-coordinate would be valid and the low-order bit of the 440 stored base is used to unambiguously determine the correct 441 y-coordinate. The resulting (x,y) pair becomes the Password Element, 442 PE. 444 Algorithmically, the process looks like this: 446 found = 0 447 counter = 1 448 n = len(p) + 64 449 do { 450 base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter) 451 temp = KDF-n(base, "Dragonfly Hunting And Pecking") 452 seed = (temp mod (p - 1)) + 1 453 if ( (seed^3 + a*seed + b) is a quadratic residue mod p) 454 then 455 if ( found == 0 ) 456 then 457 x = seed 458 save = base 459 found = 1 460 fi 461 fi 462 counter = counter + 1 463 } while ((found == 0) || (counter <= k)) 464 y = sqrt(x^3 + ax + b) 465 if ( lsb(y) == lsb(save) ) 466 then 467 PE = (x,y) 468 else 469 PE = (x,p-y) 470 fi 472 Figure 1: Fixing PE for ECC Groups 474 Checking whether a value is a quadradic residue modulo a prime can 475 leak information about that value in a side-channel attack. 476 Therefore, it is RECOMMENDED that the technique used to determine if 477 the value is a quadratic residue modulo p blind the value with a 478 random number so that the blinded value can take on all numbers 479 between 1 and p-1 with equal probability while not changing its 480 quadratic residuosity. Determining the quadratic residue in a 481 fashion that resists leakage of information is handled by flipping a 482 coin and multiplying the blinded value by either a random quadratic 483 residue or a random quadratic nonresidue and checking whether the 484 multiplied value is a quadradic residue or a quadradic nonresidue 485 modulo p, respectively. The random residue and nonresidue can be 486 calculated prior to hunting-and-pecking by calculating the legendre 487 symbol on random values until they are found:: 489 do { 490 qr = random() mod p 491 } while ( lgr(qr, p) != 1) 493 do { 494 qnr = random() mod p 495 } while ( lgr(qnr, p) != -1) 497 Algorithmically, the masking technique to find out whether a value is 498 a quadratic residue or not looks like this: 500 is_quadratic_residue (val, p) { 501 r = (random() mod (p - 1)) + 1 502 num = (val * r * r) mod p 503 if ( lsb(r) == 1 ) 504 num = (num * qr) mod p 505 if ( lgr(num, p) == 1) 506 then 507 return TRUE 508 fi 509 else 510 num = (num * qnr) mod p 511 if ( lgr(num, p) == -1) 512 then 513 return TRUE 514 fi 515 fi 516 return FALSE 517 } 519 3.2.2. Hunting and Pecking with MODP Groups 521 The MODP specific hunting and pecking technique entails finding a 522 random element which, when used as a generator, will create a group 523 with the same order as the group created by the generator from the 524 domain parameter set. The secret generator is found by 525 exponentiating the seed to the value ((p-1)/q), where p is the prime 526 and q is the order from the domain parameter set. If that value is 527 greater than one (1) it becomes PE, otherwise the counter is 528 incremented, a new base and seed are generated, and the hunting and 529 pecking continues. 531 Algorithmically, the process looks like this: 533 found = 0 534 counter = 1 535 n = len(p) + 64 536 do { 537 base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter) 538 temp = KDF-n(seed, "Dragonfly Hunting And Pecking") 539 seed = (temp mod (p - 1)) + 1 540 temp = seed ^ ((p-1)/q) mod p 541 if (temp > 1) 542 then 543 if (not found) 544 PE = temp 545 found = 1 546 fi 547 fi 548 counter = counter + 1 549 } while ((found == 0) || (counter <= k)) 551 Figure 2: Fixing PE for MODP Groups 553 3.3. The Commit Exchange 555 In the Commit Exchange both sides commit to a single guess of the 556 password. The peers generate a scalar and an element, exchange them 557 with each other, and process the other's scalar and element to 558 generate a common and shared secret. 560 First each peer generates two random numbers, private and mask. 561 These two secrets, the Password Element, and the order from the 562 selected domain parameter set are then used to construct the scalar 563 and element: 565 scalar = (private + mask) modulo q 567 Element = inverse(scalar-op(mask, PE)) 569 If the scalar is less than two (2), the private and mask MUST be 570 thrown away and new values generated. Once a valid scalar and 571 Element are generated, the mask is no longer needed and MUST be 572 irretrievably destroyed. 574 The peers exchange their scalar and Element and check the peer's 575 scalar and Element, deemed peer-scalar and Peer-Element. If the peer 576 has sent an identical scalar and Element-- i.e. if scalar equals 577 peer-scalar and Element equals Peer-Element-- it is sign of a 578 reflection attack and the exchange MUST be aborted. If the values 579 differ, peer-scalar and Peer-Element must be validated. For the 580 peer-scalar to be valid, it MUST be between 1 and q exclusive. 582 Validation of the Peer-Element depends on the type of cryptosystem-- 583 validation of an (x,y) pair as an ECC element is specified in 584 Section 2.1 and validation of a number as an FFC element is specified 585 in Section 2.2. If either the peer-scalar or Peer-Element fail 586 validation then the exchange MUST be terminated and authentication 587 fails. If both the peer-scalar and Peer-Element are valid, they are 588 used with the Password Element to derive a shared secret, ss: 590 ss = F(scalar-op(private, 591 element-op(peer-Element, 592 scalar-op(peer-scalar, PE)))) 594 To enforce key separation and crypto hygiene, the shared secret is 595 stretched into two subkeys, a key confirmation key, kck, and a master 596 key, mk. Each of the subkeys SHOULD be at least the length of the 597 prime used in the selected group. 599 kck | mk = KDF-n(ss, "Dragonfly Key Derivation") 601 where n = len(p)*2. 603 3.4. The Confirm Exchange 605 In the Confirm Exchange both sides confirm that they derived the same 606 secret, and therefore, are in possession of the same password. 608 The Commit Exchange consists of an exchange of data that is the 609 output of the random function, H(), the key confirmation key, and the 610 two scalars and two elements exchanged in the Commit Exchange. The 611 order of the scalars and elements are, scalars before elements, and 612 sender's value before recipient's value. So from each peer's 613 perspective, it would generate: 615 confirm = H(kck | scalar | peer-scalar | 616 Element | Peer-Element) 618 The two peers exchange these confirmations and verify the correctness 619 of the other peer's confirmation that they receive. If the other 620 peer's confirmation is valid, authentication succeeds; if the other 621 peer's confirmation is not valid, authentication fails. 623 If authentication fails, all ephemeral state created as part of the 624 particular run of the Dragonfly exchange MUST be irretrievabley 625 destroyed. If authentication does not fail, mk can be exported as an 626 authenticated and secret key that can be used by another protocol, 627 for instance IPsec, to protect other data. 629 4. Acknowledgements 631 The author would like to thank Kevin Igoe and David McGrew, chairmen 632 of the Crypto Forum Research Group (CFRG) for agreeing to accept this 633 memo as a CFRG work item. Additional thanks go to Scott Fluhrer and 634 Hideyuki Suzuki for discovering attacks against earlier versions of 635 this key exchange and suggesting fixes to address them. Lily Chen 636 provided helpful discussions on hashing into an elliptic curve. Rich 637 Davis suggested the validation steps used on received elements to 638 prevent a small sub-group attack. Dylan Clarke and Feng Hao 639 discovered a dictionary attack against Dragonfly if those checks are 640 not made and a group with a small sub-group is used. 642 The blinding scheme to prevent side-channel attacks when determining 643 whether a value is a quadratic residue modulo a prime was suggested 644 by Scott Fluhrer. Kevin Igoe suggested addition of the security 645 parameter k to hide the amount of time taken hunting-and-pecking for 646 the password element. 648 5. IANA Considerations 650 This memo includes no request to IANA. 652 6. Security Considerations 654 The Dragonfly exchange requires both participants to have an 655 identical representation of the password. Salting of the password 656 merely generates a new credential-- the salted password-- which must 657 be identically represented on both sides. If an adversary is able to 658 gain access to the database of salted passwords, she would be able to 659 impersonate one side to the other, even if she was unable to 660 determine the underlying, unsalted, password. 662 Resistance to dictionary attack means that an adversary must launch 663 an active attack to make a single guess at the password. If the size 664 of the dictionary from which the password was extracted was "d", and 665 each password in the dictionary has an equal probability of being 666 chosen, then the probability of success after a single guess is 1/d. 667 After "x" guesses, and removal of failed guesses from the pool of 668 possible passwords, the probability becomes 1/(d-x). As "x" grows, 669 so does the probability of success. Therefore, it is possible for an 670 adversary to determine the password through repeated brute-force, 671 active, guessing attacks. Users of the Dragonfly key exchange SHOULD 672 ensure that the size of the pool from which the password was drawn, 673 "d", is sufficiently large to make this attack preventable. 674 Implementations of Dragonfly SHOULD support countermeasures to deal 675 with this attack-- for instance, by refusing authentication attempts 676 for a certain amount of time, after the number of failed 677 authentication attempts reaches a certain threshold. No such 678 threshold or amount of time is recommended in this memo. 680 Due to the problems with using groups that contain a small sub-group, 681 it is RECOMMENDED that implementations of Dragonfly not allow for the 682 specification of a group's domain parameter set in-line but instead 683 use a common repository in which to pass an identifier to a domain 684 parameter set whose strength has been rigourously proven and that 685 does not have small sub-groups. If a group's domain parameter set is 686 passed in-line, it SHOULD NOT be used with Dragonfly unless it 687 directly matches a known good group. 689 It is RECOMMENDED that an implementation set the security parameter, 690 k, to a value of at least forty (40) which will put the probability 691 that more than forty iterations are needed in the order of one in one 692 trillion (1:1,000,000,000,000). 694 7. References 696 7.1. Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 7.2. Informative References 703 [FIPS186-3] 704 National Institute of Standards and Technology, "Digital 705 Signature Standard (DSS)", Federal Information Processing 706 Standards Publication 186-3. 708 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 709 A Paradigm for Designing Efficient Protocols", Proceedings 710 of the 1st ACM Conference on Computer and Communication 711 Security, ACM Press, 1993, 712 . 714 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 715 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 716 RFC 5433, February 2009. 718 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 719 "Internet Key Exchange Protocol Version 2 (IKEv2)", 720 RFC 5996, September 2010. 722 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 723 Curve Cryptography Algorithms", RFC 6090, February 2011. 725 [SP800-108] 726 Chen, L., "Recommendations for Key Derivation Using 727 Pseudorandom Functions", NIST Special Publication 800-108, 728 April 2008. 730 [SP800-56A] 731 Barker, E., Johnson, D., and M. Smid, "Recommendations for 732 Pair-Wise Key Establishment Schemes Using Discrete 733 Logarithm Cryptography", NIST Special Publication 800-56A, 734 March 2007. 736 [hash2ec] Coron, J-B. and T. Icart, "An indifferentiable hash 737 function into elliptic curves", Cryptology ePrint 738 Archive Report 2009/340, 2009. 740 Author's Address 742 Dan Harkins (editor) 743 Aruba Networks 744 1322 Crossman Avenue 745 Sunnyvale, CA 94089-1113 746 United States of America 748 Email: dharkins@arubanetworks.com