idnits 2.17.1 draft-irtf-cfrg-dragonfly-07.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 (March 31, 2015) is 3285 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 March 31, 2015 5 Expires: October 2, 2015 7 Dragonfly Key Exchange 8 draft-irtf-cfrg-dragonfly-07 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. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 2, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may not be modified, and derivative works of it may not 50 be created, except to format it for publication as an RFC or to 51 translate it into languages other than English. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2.1. Notations . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2.2. Resistance to Dictionary Attack . . . . . . . . . . . 3 60 2. Discrete Logarithm Cryptography . . . . . . . . . . . . . . . 4 61 2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . . . 4 62 2.2. Finite Field Cryptography . . . . . . . . . . . . . . . . 5 63 3. The Dragonfly Key Exchange . . . . . . . . . . . . . . . . . 6 64 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Derivation of the Password Element . . . . . . . . . . . 8 66 3.2.1. Hunting and Pecking with ECC Groups . . . . . . . . . 10 67 3.2.2. Hunting and Pecking with MODP Groups . . . . . . . . 12 68 3.3. The Commit Exchange . . . . . . . . . . . . . . . . . . . 13 69 3.4. The Confirm Exchange . . . . . . . . . . . . . . . . . . 14 70 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 75 7.2. Informative References . . . . . . . . . . . . . . . . . 16 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction 80 Passwords and passphrases are the predominant way of doing 81 authentication in the Internet today. Many protocols that use 82 passwords and passphrases for authentication exchange password- 83 derived data as a proof-of-knowledge of the password (for example, 84 [RFC5996], and [RFC5433]). This opens the exchange up to an off-line 85 dictionary attack where the attacker gleans enough knowledge from 86 either an active or passive attack on the protocol to run through a 87 pool of potential passwords and compute verifiers until it is able to 88 match the password-derived data. 90 This protocol employs discrete logarithm cryptography to perform an 91 efficient exchange in a way that performs mutual authentication using 92 a password but is resistant to an off-line dictionary attack. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 1.2. Definitions 102 1.2.1. Notations 104 The following notations are used in this memo 106 password 107 A shared, secret and potentially low-entropy word, phrase, code 108 or key used as a credential to mutually authenticate the peers. 109 It is not restricted to characters in a human language. 111 a | b 112 denotes concatenation of bit string "a" with bit string "b". 114 len(a) 115 indicates the length in bits of the bit string "a". 117 lsb(a) 118 returns the least-significant bit of the bit string "a". 120 lgr(a,b) 121 takes "a" and a prime, "b" and returns the legendre symbol (a/b). 123 min(a,b) 124 returns the lexicographical minimum of strings "a" and "b", or 125 zero (0) if "a" equals "b". 127 max(a,b) 128 returns the lexicographical maximum of strings "a" and "b", or 129 zero (0) if "a" equals "b". 131 The convention for this memo to represent an element in a finite 132 cyclic group is to use an upper-case letter or acronym, while a 133 scalar is indicated with a lower-case letter or acronym. An element 134 that represents a point on an elliptic curve has an implied composite 135 nature-- i.e. it has both an x- and y-coordinate. 137 1.2.2. Resistance to Dictionary Attack 139 Resistance to dictionary attack means that any advantage an adversary 140 can gain must be directly related to the number of interactions she 141 makes with an honest protocol participant and not through 142 computation. The adversary will not be able to obtain any 143 information about the password except whether a single guess from a 144 protocol run is correct or incorrect. 146 2. Discrete Logarithm Cryptography 148 Dragonfly uses discrete logarithm cryptography to achieve 149 authentication and key agreement (see [SP800-56A]). Each party to 150 the exchange derives ephemeral keys with respect to a particular set 151 of domain parameters (referred to here as a "group"). A group can be 152 based on Finite Field Cryptography (FFC) or Elliptic Curve 153 Cryptography (ECC). 155 Three operations are defined for both types of groups: 157 o "scalar operation"-- takes a scalar and an element in the group to 158 produce another element-- Z = scalar-op(x, Y). 160 o "element operation"-- takes two elements in the group to produce a 161 third-- Z = element-op(X, Y). 163 o "inverse operation"-- takes an element and returns another element 164 such that the element operation on the two produces the identity 165 element of the group-- Y = inverse(X). 167 2.1. Elliptic Curve Cryptography 169 Domain parameters for the ECC groups used by Dragonfly are: 171 o A prime, p, determining a prime field GF(p). The cryptographic 172 group will be a subgroup of the full elliptic curve group that 173 consists of points on an elliptic curve -- elements from GF(p) 174 that satisfy the curve's equation -- together with the "point at 175 infinity" that serves as the identity element. The group 176 operation for ECC groups is addition of points on the elliptic 177 curve. 179 o Elements a and b from GF(p) that define the curve's equation. The 180 point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only 181 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 183 o A point, G, on the elliptic curve, which serves as a generator for 184 the ECC group. G is chosen such that its order, with respect to 185 elliptic curve addition, is a sufficiently large prime. 187 o A prime, q, which is the order of G, and thus is also the size of 188 the cryptographic subgroup that is generated by G. 190 An (x,y) pair is a valid ECC element if: 1) the x- and y-coordinates 191 are both greater than zero (0) and less than the prime defining the 192 underlying field; and, 2) the x- and y-coordinates satisfy the 193 equation for the curve and produce a valid point on the curve that is 194 not the point at infinity. If either one of those conditions do not 195 hold the (x,y) pair is not a valid element. 197 The scalar operation is addition of a point on the curve with itself 198 a number of times. The point Y is multiplied x-times to produce 199 another point Z: 201 Z = scalar-op(x, Y) = x*Y 203 The element operation is addition of two points on the curve. Points 204 X and Y are summed to produce another point Z: 206 Z = element-op(X, Y) = X + Y 208 The inverse function is defined such that the sum of an element and 209 its inverse is "0", the point-at-infinity of an elliptic curve group: 211 R + inverse(R) = "0" 213 Elliptic curve groups require a mapping function, q = F(Q), to 214 convert a group element to an integer. The mapping function used in 215 this memo returns the x-coordinate of the point it is passed. 217 scalar-op(x, Y) can be viewed as x iterations of element-op() by 218 defining: 220 Y = scalar-op(1, Y) 222 Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1 224 A definition of how to add two points on an elliptic curve (i.e. 225 element-op(X, Y)) can be found in [RFC6090]. 227 Note: There is another elliptic curve domain parameter, a co-factor, 228 h, that is defined by the requirement that the size of the full 229 elliptic curve group (including "0") be the product of h and q. 230 Elliptic curve groups used with Dragonfly authentication MUST have a 231 co-factor of one (1). 233 2.2. Finite Field Cryptography 235 Domain parameters for the FFC groups used in Dragonfly are: 237 o A prime, p, determining a prime field GF(p), the integers modulo 238 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 239 group of non-zero elements in GF(p). The group operation for FFC 240 groups is multiplication modulo p. 242 o An element, G, in GF(p)* which serves as a generator for the FFC 243 group. G is chosen such that its multiplicative order is a 244 sufficiently large prime divisor of ((p-1)/2). 246 o A prime, q, which is the multiplicative order of G, and thus also 247 the size of the cryptographic subgroup of GF(p)* that is generated 248 by G. 250 A number is a valid element in an FFC group if: 1) it is between one 251 (1) and one (1) less than the the prime, p, exclusive (i.e. 1 < 252 element < p-1); and, 2) if modular exponentiation of the element by 253 the group order, q, equals one (1). If either one of those 254 conditions do not hold the number is not a valid element. 256 The scalar operation is exponentiation of a generator modulo a prime. 257 An element Y is taken to the x-th power modulo the prime returning 258 another element, Z: 260 Z = scalar-op(x, Y) = Y^x mod p 262 The element operation is modular multiplication. Two elements, X and 263 Y, are multiplied modulo the prime returning another element, Z: 265 Z = element-op(X, Y) = (X * Y) mod p 267 The inverse function for a MODP group is defined such that the 268 product of an element and its inverse modulo the group prime equals 269 one (1). In other words, 271 (R * inverse(R)) mod p = 1 273 3. The Dragonfly Key Exchange 275 There are two parties to the Dragonfly exchange named, for 276 convenience and by convention, Alice and Bob. The two parties have a 277 shared password that was established in an out-of-band mechanism and 278 they both agree to use a particular domain parameter set (either ECC 279 or FFC). In the Dragonfly exchange both Alice and Bob share an 280 identical view of the shared password-- i.e. it is not "augmented", 281 where one side holds a password and the other side holds a non- 282 invertable verifier. This allows Dragonfly to be used in traditional 283 client-server protocols and also in peer-to-peer applications in 284 which there are not fixed roles and either party may initiate the 285 exchange (and both parties may implement it simultaneously). 287 Prior to beginning the Dragonfly exchange, the two peers MUST derive 288 a secret element in the chosen domain parameter set. Two "hunting- 289 and-pecking" techniques to determine a secret element, one for ECC 290 and one for FFC, are described in Section 3.2 but any secure, 291 determinstic method that is agreed up on can be used. For instance, 292 the technique described in [hash2ec] can be used for ECC groups. 294 The Dragonfly exchange consists of two message exchanges, a "Commit 295 Exchange" in which both sides commit to a single guess of the 296 password, and a "Confirm Exchange" in which both sides confirm 297 knowledge of the password. A side effect of running the Dragonfly 298 exchange is an authenticated, shared, and secret key whose 299 cryptographic strength is set by the agreed-upon group. 301 Dragonfly uses a random function, H(), a mapping function, F(), and a 302 key derivation function, KDF(). 304 3.1. Assumptions 306 In order to avoid attacks on the Dragonfly protocol some basic 307 assumptions are made: 309 1. Function H is a "random oracle" (see [RANDOR]) that maps a binary 310 string of indeterminate length onto a fixed binary string that is 311 x bits in length. 313 H: {0,1}^* --> {0,1}^x 315 2. Function F is a mapping function that takes an element in a group 316 and returns an integer. For ECC groups function F() returns the 317 x-coordinate of the element (which is a point on the elliptic 318 curve), for FFC groups function F() is the identity function 319 (since all elements in an FFC group are already integers less 320 than the prime): 322 ECC: x = F(P), where P=(x,y) 324 FFC: x = F(x) 326 3. Function KDF is a key derivation function (see, for instance, 327 [SP800-108]) that takes a key to stretch, k, a label to bind to 328 the key, label, and an indication of the desired output, n: 330 stretch = KDF-n(k, label) 332 so that len(stretch) equals n. 334 4. The discrete logarithm problem for the chosen group is hard. 335 That is, given G, P, and Y = G^x mod p, it is computationally 336 infeasible to determine x. Similarly, for an ECC group given the 337 curve definition, a generator G, and Y = x * G, it is 338 computationally infeasible to determine x. 340 5. There exists a pool of passwords from which the password shared 341 by the two peers is drawn. This pool can consist of words from a 342 dictionary, for example. Each password in this pool has an equal 343 probability of being the shared password. All potential 344 attackers have access to this pool of passwords. 346 6. The peers have the ability to produce quality random numbers. 348 3.2. Derivation of the Password Element 350 Prior to beginning the exchange of information, the peers MUST derive 351 a secret element, called the Password Element (PE), in the group 352 defined by the chosen domain parameter set. From the point-of-view 353 of an attacker who does not know the password, PE will be a random 354 element in the negotiated group. Two examples are described here for 355 completeness but any method of deterministically mapping a secret 356 string into an element in a selected group can be used, for instance 357 the technique in [hash2ec] for ECC groups. If a different technique 358 than the ones described here is used, the secret string SHOULD 359 include the identities of the peers. 361 To fix PE, both peers MUST have a common view of the password. If 362 there is any password processing necessary, for example to support 363 internationalization, the processed password is then used as the 364 shared credential. If either side wants to store a hashed version of 365 the password-- hashing the password with random data called a 366 "salt"-- it will be necessary to convey the salt to the other side 367 prior to commensing the exchange and the hashed password is then used 368 as the shared credential. 370 Note: only one party would be able to maintain a salted password and 371 this would require that the Dragonfly key exchange be used in a 372 protocol that has strict roles for client (that always initiates) and 373 server (that always responds). Due to the symmetric nature of 374 Dragonfly salting passwords does not prevent an impersonation attack 375 after compromise of a database of salted passwords. 377 The determinstic process to select the PE begins with choosing a 378 secret seed and then performing a group-specific hunting-and-pecking 379 technique-- one for FFC groups and another for ECC groups. 381 To thwart side channel attacks which attempt to determine the number 382 of iterations of the "hunting-and-pecking" loop are used to find PE 383 for a given password, a security parameter, k, is used that ensures 384 that at least k iterations are always performed. The probability 385 that one requires more than "n" iterations of the "hunting-and- 386 pecking" loop to find an ECC PE is roughly (q/2p)^n and to find an 387 FFC PE is roughly (q/p)^n, both of which rapidly approach zero (0) as 388 "n" increases. The security parameter, k, SHOULD be set sufficiently 389 large such that the probability that finding PE would take more than 390 k iterations is sufficiently small (see Section 6). 392 First, an 8-bit counter is set to one (1) and a secret base is 393 computed using the negotiated one-way function with the identities of 394 the two participants, Alice and Bob, the secret password and the 395 counter: 397 base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter) 399 The identities are passed to the max() and min() functions to provide 400 the necessary ordering of the inputs to H() while still allowing for 401 a peer-to-peer exchange where both Alice and Bob each view themselves 402 as the "initiator" of the exchange. 404 The base is then stretched using the technique from section B.5.1 of 405 [FIPS186-4]. The key derivation function, KDF, is used to produce a 406 bitstream whose length is equal to the length of the prime from the 407 group's domain parameter set plus the constant sixty-four (64) to 408 derive a temporary value, and the temporary value is moularly reduced 409 to produce a seed: 411 n = len(p) + 64 413 temp = KDF-n(base, "Dragonfly Hunting and Pecking") 415 seed = (temp mod (p - 1)) + 1 417 The string bound to the derived temporary value is for illustrative 418 purposes only. Implementations of the Dragonfly key exchange SHOULD 419 use a usage specific label with the KDF. 421 Note: the base is stretched to 64 more bits than are needed so that 422 the bias from the modular reduction is not so apparent. 424 The seed is then passed to the group-specific hunting and pecking 425 technique. 427 If the protocol performing the Dragonfly exchange has the ability to 428 exchange random nonces those SHOULD be added to the computation of 429 base to ensure that each run of the protocol produces a different PE. 431 3.2.1. Hunting and Pecking with ECC Groups 433 The ECC specific hunting and pecking technique entails looping until 434 a valid point on the elliptic curve has been found. The seed is used 435 as an x-coordinate with the equation of the curve to check whether 436 x^3 + a*x + b is a quadratic residue modulo p. If it is not, then 437 the counter is incremented, a new base and new seed are generated and 438 the hunting and pecking continues. If it is a quadratic residue 439 modulo p, then the x-coordinate is assigned the value of seed and the 440 current base is stored. When the hunting-and-pecking loop 441 terminates, the x-coordinate is used with the equation of the curve 442 to solve for a y-coordinate. An ambiguity exists since two values 443 for the y-coordinate would be valid and the low-order bit of the 444 stored base is used to unambiguously determine the correct 445 y-coordinate. The resulting (x,y) pair becomes the Password Element, 446 PE. 448 Algorithmically, the process looks like this: 450 found = 0 451 counter = 1 452 n = len(p) + 64 453 do { 454 base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter) 455 temp = KDF-n(base, "Dragonfly Hunting And Pecking") 456 seed = (temp mod (p - 1)) + 1 457 if ( (seed^3 + a*seed + b) is a quadratic residue mod p) 458 then 459 if ( found == 0 ) 460 then 461 x = seed 462 save = base 463 found = 1 464 fi 465 fi 466 counter = counter + 1 467 } while ((found == 0) || (counter <= k)) 468 y = sqrt(x^3 + ax + b) 469 if ( lsb(y) == lsb(save) ) 470 then 471 PE = (x,y) 472 else 473 PE = (x,p-y) 474 fi 476 Figure 1: Fixing PE for ECC Groups 478 Checking whether a value is a quadradic residue modulo a prime can 479 leak information about that value in a side-channel attack. 480 Therefore, it is RECOMMENDED that the technique used to determine if 481 the value is a quadratic residue modulo p blind the value with a 482 random number so that the blinded value can take on all numbers 483 between 1 and p-1 with equal probability while not changing its 484 quadratic residuosity. Determining the quadratic residue in a 485 fashion that resists leakage of information is handled by flipping a 486 coin and multiplying the blinded value by either a random quadratic 487 residue or a random quadratic nonresidue and checking whether the 488 multiplied value is a quadradic residue or a quadradic nonresidue 489 modulo p, respectively. The random residue and nonresidue can be 490 calculated prior to hunting-and-pecking by calculating the legendre 491 symbol on random values until they are found: 493 do { 494 qr = random() mod p 495 } while ( lgr(qr, p) != 1) 497 do { 498 qnr = random() mod p 499 } while ( lgr(qnr, p) != -1) 501 Algorithmically, the masking technique to find out whether a value is 502 a quadratic residue or not looks like this: 504 is_quadratic_residue (val, p) { 505 r = (random() mod (p - 1)) + 1 506 num = (val * r * r) mod p 507 if ( lsb(r) == 1 ) 508 num = (num * qr) mod p 509 if ( lgr(num, p) == 1) 510 then 511 return TRUE 512 fi 513 else 514 num = (num * qnr) mod p 515 if ( lgr(num, p) == -1) 516 then 517 return TRUE 518 fi 519 fi 520 return FALSE 521 } 523 3.2.2. Hunting and Pecking with MODP Groups 525 The MODP specific hunting and pecking technique entails finding a 526 random element which, when used as a generator, will create a group 527 with the same order as the group created by the generator from the 528 domain parameter set. The secret generator is found by 529 exponentiating the seed to the value ((p-1)/q), where p is the prime 530 and q is the order from the domain parameter set. If that value is 531 greater than one (1) it becomes PE, otherwise the counter is 532 incremented, a new base and seed are generated, and the hunting and 533 pecking continues. 535 Algorithmically, the process looks like this: 537 found = 0 538 counter = 1 539 n = len(p) + 64 540 do { 541 base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter) 542 temp = KDF-n(seed, "Dragonfly Hunting And Pecking") 543 seed = (temp mod (p - 1)) + 1 544 temp = seed ^ ((p-1)/q) mod p 545 if (temp > 1) 546 then 547 if (not found) 548 PE = temp 549 found = 1 550 fi 551 fi 552 counter = counter + 1 553 } while ((found == 0) || (counter <= k)) 555 Figure 2: Fixing PE for MODP Groups 557 3.3. The Commit Exchange 559 In the Commit Exchange both sides commit to a single guess of the 560 password. The peers generate a scalar and an element, exchange them 561 with each other, and process the other's scalar and element to 562 generate a common and shared secret. 564 First each peer generates two random numbers, private and mask. 565 These two secrets, the Password Element, and the order from the 566 selected domain parameter set are then used to construct the scalar 567 and element: 569 scalar = (private + mask) modulo q 571 Element = inverse(scalar-op(mask, PE)) 573 If the scalar is less than two (2), the private and mask MUST be 574 thrown away and new values generated. Once a valid scalar and 575 Element are generated, the mask is no longer needed and MUST be 576 irretrievably destroyed. 578 The peers exchange their scalar and Element and check the peer's 579 scalar and Element, deemed peer-scalar and Peer-Element. If the peer 580 has sent an identical scalar and Element-- i.e. if scalar equals 581 peer-scalar and Element equals Peer-Element-- it is sign of a 582 reflection attack and the exchange MUST be aborted. If the values 583 differ, peer-scalar and Peer-Element must be validated. For the 584 peer-scalar to be valid, it MUST be between 1 and q exclusive. 586 Validation of the Peer-Element depends on the type of cryptosystem-- 587 validation of an (x,y) pair as an ECC element is specified in 588 Section 2.1 and validation of a number as an FFC element is specified 589 in Section 2.2. If either the peer-scalar or Peer-Element fail 590 validation then the exchange MUST be terminated and authentication 591 fails. If both the peer-scalar and Peer-Element are valid, they are 592 used with the Password Element to derive a shared secret, ss: 594 ss = F(scalar-op(private, 595 element-op(peer-Element, 596 scalar-op(peer-scalar, PE)))) 598 To enforce key separation and crypto hygiene, the shared secret is 599 stretched into two subkeys, a key confirmation key, kck, and a master 600 key, mk. Each of the subkeys SHOULD be at least the length of the 601 prime used in the selected group. 603 kck | mk = KDF-n(ss, "Dragonfly Key Derivation") 605 where n = len(p)*2. 607 3.4. The Confirm Exchange 609 In the Confirm Exchange both sides confirm that they derived the same 610 secret, and therefore, are in possession of the same password. 612 The Commit Exchange consists of an exchange of data that is the 613 output of the random function, H(), the key confirmation key, and the 614 two scalars and two elements exchanged in the Commit Exchange. The 615 order of the scalars and elements are, scalars before elements, and 616 sender's value before recipient's value. So from each peer's 617 perspective, it would generate: 619 confirm = H(kck | scalar | peer-scalar | 620 Element | Peer-Element | ) 622 Where is the identity of the sender of the confirm 623 message. This identity SHALL be that contributed by the sender of 624 the confim message in generation of the base in Section 3.2. 626 The two peers exchange these confirmations and verify the correctness 627 of the other peer's confirmation that they receive. If the other 628 peer's confirmation is valid, authentication succeeds; if the other 629 peer's confirmation is not valid, authentication fails. 631 If authentication fails, all ephemeral state created as part of the 632 particular run of the Dragonfly exchange MUST be irretrievabley 633 destroyed. If authentication does not fail, mk can be exported as an 634 authenticated and secret key that can be used by another protocol, 635 for instance IPsec, to protect other data. 637 4. Acknowledgements 639 The author would like to thank Kevin Igoe and David McGrew, chairmen 640 of the Crypto Forum Research Group (CFRG) for agreeing to accept this 641 memo as a CFRG work item. Additional thanks go to Scott Fluhrer and 642 Hideyuki Suzuki for discovering attacks against earlier versions of 643 this key exchange and suggesting fixes to address them. Lily Chen 644 provided helpful discussions on hashing into an elliptic curve. Rich 645 Davis suggested the validation steps used on received elements to 646 prevent a small sub-group attack. Dylan Clarke and Feng Hao 647 discovered a dictionary attack against Dragonfly if those checks are 648 not made and a group with a small sub-group is used. 650 The blinding scheme to prevent side-channel attacks when determining 651 whether a value is a quadratic residue modulo a prime was suggested 652 by Scott Fluhrer. Kevin Igoe suggested addition of the security 653 parameter k to hide the amount of time taken hunting-and-pecking for 654 the password element. 656 5. IANA Considerations 658 This memo includes no request to IANA. 660 6. Security Considerations 662 The Dragonfly exchange requires both participants to have an 663 identical representation of the password. Salting of the password 664 merely generates a new credential-- the salted password-- which must 665 be identically represented on both sides. If an adversary is able to 666 gain access to the database of salted passwords, she would be able to 667 impersonate one side to the other, even if she was unable to 668 determine the underlying, unsalted, password. 670 Resistance to dictionary attack means that an adversary must launch 671 an active attack to make a single guess at the password. If the size 672 of the dictionary from which the password was extracted was "d", and 673 each password in the dictionary has an equal probability of being 674 chosen, then the probability of success after a single guess is 1/d. 675 After "x" guesses, and removal of failed guesses from the pool of 676 possible passwords, the probability becomes 1/(d-x). As "x" grows, 677 so does the probability of success. Therefore, it is possible for an 678 adversary to determine the password through repeated brute-force, 679 active, guessing attacks. Users of the Dragonfly key exchange SHOULD 680 ensure that the size of the pool from which the password was drawn, 681 "d", is sufficiently large to make this attack preventable. 683 Implementations of Dragonfly SHOULD support countermeasures to deal 684 with this attack-- for instance, by refusing authentication attempts 685 for a certain amount of time, after the number of failed 686 authentication attempts reaches a certain threshold. No such 687 threshold or amount of time is recommended in this memo. 689 Due to the problems with using groups that contain a small sub-group, 690 it is RECOMMENDED that implementations of Dragonfly not allow for the 691 specification of a group's complete domain parameter to be sent in- 692 line but instead use a common repository and to pass an identifier to 693 a domain parameter set whose strength has been rigourously proven and 694 that does not have small sub-groups. If a group's complete domain 695 parameter set is passed in-line, it SHOULD NOT be used with Dragonfly 696 unless it directly matches a known good group. 698 It is RECOMMENDED that an implementation set the security parameter, 699 k, to a value of at least forty (40) which will put the probability 700 that more than forty iterations are needed in the order of one in one 701 trillion (1:1,000,000,000,000). 703 The technique used to obtain the Password Element in Section 3.2.1 704 addresses side-channel attacks in a manner deemed controversial by 705 some reviewers in the CFRG. An alternate method, such as the one 706 defined in [hash2ec], can be used to alleviate concerns. Also, while 707 this key exchange protocol has received cryptanalysis (see 708 [clarkhao]), it does does not have a security proof that accompanies 709 it. 711 7. References 713 7.1. Normative References 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, March 1997. 718 7.2. Informative References 720 [FIPS186-4] 721 National Institute of Standards and Technology, "Digital 722 Signature Standard (DSS)", Federal Information Processing 723 Standards Publication 186-4, 724 . 727 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 728 A Paradigm for Designing Efficient Protocols", Proceedings 729 of the 1st ACM Conference on Computer and Communication 730 Security, ACM Press, 1993, 731 . 733 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 734 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 735 RFC 5433, February 2009. 737 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 738 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 739 5996, September 2010. 741 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 742 Curve Cryptography Algorithms", RFC 6090, February 2011. 744 [SP800-108] 745 Chen, L., "Recommendations for Key Derivation Using 746 Pseudorandom Functions", NIST Special Publication 800-108, 747 April 2008. 749 [SP800-56A] 750 Barker, E., Johnson, D., and M. Smid, "Recommendations for 751 Pair-Wise Key Establishment Schemes Using Discrete 752 Logarithm Cryptography", NIST Special Publication 800-56A, 753 March 2007. 755 [clarkhao] 756 Clarke, D. and F. Hao, "Cryptanalysis of the Dragonfly Key 757 Exchange Protocol", 2013, 758 . 760 [hash2ec] Coron, J-B. and T. Icart, "An indifferentiable hash 761 function into elliptic curves", Cryptology ePrint Archive 762 Report 2009/340, 2009. 764 Author's Address 766 Dan Harkins (editor) 767 Aruba Networks 768 1322 Crossman Avenue 769 Sunnyvale, CA 94089-1113 770 United States of America 772 Email: dharkins@arubanetworks.com