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