idnits 2.17.1 draft-harkins-tls-dragonfly-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 5, 2016) is 2820 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security D. Harkins, Ed. 3 Internet-Draft HP Enterprise 4 Intended status: Informational August 5, 2016 5 Expires: February 6, 2017 7 Secure Password Ciphersuites for Transport Layer Security (TLS) 8 draft-harkins-tls-dragonfly-00 10 Abstract 12 This memo defines several new ciphersuites for the Transport Layer 13 Security (TLS) protocol to support certificate-less, secure 14 authentication using only a simple, low-entropy, password. The 15 exchange is called TLS-PWD. The ciphersuites are all based on an 16 authentication and key exchange protocol, named "dragonfly", that is 17 resistant to off-line dictionary attack. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 6, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. The Case for Certificate-less Authentication . . . . . . 3 55 1.2. Resistance to Dictionary Attack . . . . . . . . . . . . . 3 56 2. Keyword Definitions . . . . . . . . . . . . . . . . . . . . . 4 57 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 5 60 3.2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . 5 61 3.2.2. Finite Field Cryptography . . . . . . . . . . . . . . 7 62 3.3. Instantiating the Random Function . . . . . . . . . . . . 8 63 3.4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8 65 4. Specification of the TLS-PWD Handshake . . . . . . . . . . . 9 66 4.1. Protecting the Username . . . . . . . . . . . . . . . . . 10 67 4.1.1. Construction of a Protected Username . . . . . . . . 11 68 4.1.2. Recovery of a Protected Username . . . . . . . . . . 12 69 4.2. Fixing the Password Element . . . . . . . . . . . . . . . 13 70 4.2.1. Computing an ECC Password Element . . . . . . . . . . 14 71 4.2.2. Computing an FFC Password Element . . . . . . . . . . 16 72 4.3. Changes to Handshake Message Contents . . . . . . . . . . 17 73 4.3.1. Client Hello Changes . . . . . . . . . . . . . . . . 17 74 4.3.2. Server Key Exchange Changes . . . . . . . . . . . . . 18 75 4.3.2.1. Generation of ServerKeyExchange . . . . . . . . . 19 76 4.3.2.2. Processing of ServerKeyExchange . . . . . . . . . 20 77 4.3.3. Client Key Exchange Changes . . . . . . . . . . . . . 21 78 4.3.3.1. Generation of Client Key Exchange . . . . . . . . 21 79 4.3.3.2. Processing of Client Key Exchange . . . . . . . . 22 80 4.4. Computing the Premaster Secret . . . . . . . . . . . . . 22 81 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . 23 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 9. Human Rights Considerations . . . . . . . . . . . . . . . . . 27 86 10. Implementation Considerations . . . . . . . . . . . . . . . . 28 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 89 11.2. Informative References . . . . . . . . . . . . . . . . . 29 90 Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 30 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 93 1. Background 95 1.1. The Case for Certificate-less Authentication 97 TLS usually uses public key certificates for authentication 98 [RFC5246]. This is problematic in some cases: 100 o Frequently, TLS [RFC5246] is used in devices owned, operated, and 101 provisioned by people who lack competency to properly use 102 certificates and merely want to establish a secure connection 103 using a more natural credential like a simple password. The 104 proliferation of deployments that use a self-signed server 105 certificate in TLS [RFC5246] followed by a PAP-style exchange over 106 the unauthenticated channel underscores this case. 108 o The alternatives to TLS-PWD for employing certificate-less TLS 109 authentication-- using pre-shared keys in an exchange that is 110 susceptible to dictionary attack, or using an SRP exchange that 111 requires users to, a priori, be fixed to a specific finite field 112 cryptorgraphy group for all subsequent connections-- are not 113 acceptable for modern applications that require both security and 114 cryptographic agility. 116 o A password is a more natural credential than a certificate (from 117 early childhood people learn the semantics of a shared secret), so 118 a password-based TLS ciphersuite can be used to protect an HTTP- 119 based certificate enrollment scheme like EST [RFC7030] to parlay a 120 simple password into a certificate for subsequent use with any 121 certificate-based authentication protocol. This addresses a 122 significant "chicken-and-egg" dilemma found with certificate-only 123 use of [RFC5246]. 125 o Some PIN-code readers will transfer the entered PIN to a smart 126 card in clear text. Assuming a hostile environment, this is a bad 127 practice. A password-based TLS ciphersuite can enable the 128 establishment of an authenticated connection between reader and 129 card based on the PIN. 131 1.2. Resistance to Dictionary Attack 133 It is a common misconception that a protocol that authenticates with 134 a shared and secret credential is resistent to dictionary attack if 135 the credential is assumed to be an N-bit uniformly random secret, 136 where N is sufficiently large. The concept of resistence to 137 dictionary attack really has nothing to do with whether that secret 138 can be found in a standard collection of a language's defined words 139 (i.e. a dictionary). It has to do with how an adversary gains an 140 advantage in attacking the protocol. 142 For a protocol to be resistant to dictionary attack any advantage an 143 adversary can gain must be a function of the amount of interactions 144 she makes with an honest protocol participant and not a function of 145 the amount of computation she uses. The adversary will not be able 146 to obtain any information about the password except whether a single 147 guess from a single protocol run which she took part in is correct or 148 incorrect. 150 It is assumed that the attacker has access to a pool of data from 151 which the secret was drawn-- it could be all numbers between 1 and 152 2^N, it could be all defined words in a dictionary. The key is that 153 the attacker cannot do a an attack and then enumerate through the 154 pool trying potential secrets (computation) to see if one is correct. 155 She must do an active attack for each secret she wishes to try 156 (interaction) and the only information she can glean from that attack 157 is whether the secret used with that particular attack is correct or 158 not. 160 2. Keyword Definitions 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 3. Introduction 168 3.1. Notation 170 The following notation is used in this memo: 172 password 173 a secret, and potentially low-entropy word, phrase, code or key 174 used as a credential for authentication. The password is shared 175 between the TLS client and TLS server. 177 y = H(x) 178 a binary string of arbitrary length, x, is given to a function H 179 which produces a fixed-length output, y. 181 a | b 182 denotes concatenation of string a with string b. 184 [a]b 185 indicates a string consisting of the single bit "a" repeated "b" 186 times. 188 x mod y 189 indicates the remainder of division of x by y. The result will 190 be between 0 and y. 192 len(x) 193 indicates the length in bits of the string x. 195 lgr(a,b) 196 takes "a" and a prime, b and returns the legendre symbol (a/b). 198 LSB(x) 199 returns the least-significant bit of the bitstring "x". 201 G.x 202 indicates the x-coordinate of a point, G, on an elliptic curve. 204 3.2. Discrete Logarithm Cryptography 206 The ciphersuites defined in this memo use discrete logarithm 207 cryptography (see [SP800-56A]) to produce an authenticated and shared 208 secret value that is an element in a group defined by a set of domain 209 parameters. The domain parameters can be based on either Finite 210 Field Cryptography (FFC) or Elliptic Curve Cryptography (EEC). 212 TLS [RFC5246] allows for both FFC and ECC domain parameter sets to be 213 conveyed verbosely by the server. This opens up the possibility of a 214 malicious server offering a weak group, or one with a trapdoor, that 215 would lead to a leaking of information during a run of the protocol. 216 Therefore, if explicit domain parameter sets are used with TLS-PWD, 217 they MUST be agreed-upon a priori in an out-of-band fashion. Clients 218 MUST NOT accept explicit domain parameter sets from a server that it 219 has not previously agreed to accept. 221 Elements in a group, either an FFC or EEC group, are indicated using 222 upper-case while scalar values are indicated using lower-case. 224 3.2.1. Elliptic Curve Cryptography 226 The authenticated key exchange defined in this memo uses fundamental 227 algorithms of elliptic curves defined over GF(p) as described in 228 [RFC6090]. 230 Domain parameters for the ECC groups used by this memo are: 232 o A prime, p, determining a prime field GF(p). The cryptographic 233 group will be a subgroup of the full elliptic curve group which 234 consists points on an elliptic curve-- elements from GF(p) that 235 satisfy the curve's equation-- together with the "point at 236 infinity" that serves as the identity element. 238 o Elements a and b from GF(p) that define the curve's equation. The 239 point (x,y) in GF(p) x GF(p) is on the elliptic curve if and only 240 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 242 o A point, G, on the elliptic curve, which serves as a generator for 243 the ECC group. G is chosen such that its order, with respect to 244 elliptic curve addition, is a sufficiently large prime. 246 o A prime, q, which is the order of G, and thus is also the size of 247 the cryptographic subgroup that is generated by G. 249 o A co-factor, f, defined by the requirement that the size of the 250 full elliptic curve group (including the "point at infinity") is 251 the product of f and q. 253 This memo uses the following ECC Functions: 255 o Z = elem-op(X,Y) = X + Y: two points on the curve X and Y, are 256 sumed to produce another point on the curve, Z. This is the group 257 operation for ECC groups. 259 o Z = scalar-op(x,Y) = x * Y: an integer scalar, x, acts on a point 260 on the curve, Y, via repetitive addition (Y is added to itself x 261 times), to produce another EEC element, Z. 263 o Y = inverse(X): a point on the curve, X, has an inverse, Y, which 264 is also a point on the curve, when their sum is the "point at 265 infinity" (the identity for elliptic curve addition). In other 266 words, R + inverse(R) = "0". 268 o z = F(X): the x-coordinate of a point (x, y) on the curve is 269 returned. This is a mapping function to convert a group element 270 into an integer. 272 Only ECC groups over GF(p) can be used with TLS-PWD. ECC groups over 273 GF(2^m) SHALL NOT be used by TLS-PWD. In addition, ECC groups with a 274 co-factor greater than one (1) SHALL NOT be used by TLS-PWD. 276 A composite (x, y) pair can be validated as a point on the elliptic 277 curve by checking whether: 1) both coordinates x and y are greater 278 than zero (0) and less than the prime defining the underlying field; 279 2) the x- and y- coordinates satisfy the equation of the curve; and 280 3) they do not represent the point-at-infinity "0". If any of those 281 conditions are not true the (x, y) pair is not a valid point on the 282 curve. 284 3.2.2. Finite Field Cryptography 286 Domain parameters for the FFC groups used by this memo are: 288 o A prime, p, determining a prime field GF(p), the integers modulo 289 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 290 group of non-zero elements in GF(p). 292 o An element, G, in GF(p)* which serves as a generator for the FFC 293 group. G is chosen such that its multiplicative order is a 294 sufficiently large prime divisor of ((p-1)/2). 296 o A prime, q, which is the multiplicative order of G, and thus also 297 the size of the cryptographic subgroup of GF(p)* that is generated 298 by G. 300 This memo uses the following FFC Functions: 302 o Z = elem-op(X,Y) = (X * Y) mod p: two FFC elements, X and Y, are 303 multiplied modulo the prime, p, to produce another FFC element, Z. 304 This is the group operation for FFC groups. 306 o Z = scalar-op(x,Y) = Y^x mod p: an integer scalar, x, acts on an 307 FFC group element, Y, via exponentiation modulo the prime, p, to 308 produce another FFC element, Z. 310 o Y = inverse(X): a group element, X, has an inverse, Y, when the 311 product of the element and its inverse modulo the prime equals one 312 (1). In other words, (X * inverse(X)) mod p = 1. 314 o z = F(X): is the identity function since an element in an FFC 315 group is already an integer. It is included here for consistency 316 in the specification. 318 Many FFC groups used in IETF protocols are based on safe primes and 319 do not define an order (q). For these groups, the order (q) used in 320 this memo shall be the prime of the group minus one divided by two-- 321 (p-1)/2. 323 An integer can be validated as being an element in an FFC group by 324 checking whether: 1) it is between one (1) and the prime, p, 325 exclusive; and 2) if modular exponentiation of the integer by the 326 group order, q, equals one (1). If either of these conditions are 327 not true the integer is not an element in the group. 329 3.3. Instantiating the Random Function 331 The protocol described in this memo uses a random function, H, which 332 is modeled as a "random oracle". At first glance, one may view this 333 as a hash function. As noted in [RANDOR], though, hash functions are 334 too structured to be used directly as a random oracle. But they can 335 be used to instantiate the random oracle. 337 The random function, H, in this memo is instantiated by using the 338 hash algorithm defined by the particular TLS-PWD ciphersuite in HMAC 339 mode with a key whose length is equal to block size of the hash 340 algorithm and whose value is zero. For example, if the ciphersuite 341 is TLS_ECCPWD_WITH_AES_128_GCM_SHA256 then H will be instantiated 342 with SHA256 as: 344 H(x) = HMAC-SHA256([0]32, x) 346 3.4. Passwords 348 The authenticated key exchange used in TLS-PWD requires each side to 349 have a common view of a shared credential. To protect the server's 350 database of stored passwords, though, the password SHALL be salted 351 and the result, called the base, SHALL be used as the authentication 352 credential. 354 The salting function is defined as: 356 base = HMAC-SHA256(salt, username | password) 358 The password used for generation of the base SHALL be represented as 359 a UTF-8 encoded character string processed according to the rules of 360 the [RFC4013] profile of [RFC3454] and the salt SHALL be a 32 octet 361 random number. The server SHALL store a triplet of the form: 363 { username, base, salt } 365 And the client SHALL generate the base upon receiving the salt from 366 the server. 368 3.5. Assumptions 370 The security properties of the authenticated key exchange defined in 371 this memo are based on a number of assumptions: 373 1. The random function, H, is a "random oracle" as defined in 374 [RANDOR]. 376 2. The discrete logarithm problem for the chosen group is hard. 377 That is, given g, p, and y = g^x mod p, it is computationally 378 infeasible to determine x. Similarly, for an ECC group given the 379 curve definition, a generator G, and Y = x * G, it is 380 computationally infeasible to determine x. 382 3. Quality random numbers with sufficient entropy can be created. 383 This may entail the use of specialized hardware. If such 384 hardware is unavailable a cryptographic mixing function (like a 385 strong hash function) to distill enropy from multiple, 386 uncorrelated sources of information and events may be needed. A 387 very good discussion of this can be found in [RFC4086]. 389 If the server supports username protection (see Section 4.1), it is 390 assumed that the server has chosen a domain parameter set and 391 generated a username-protection keypair. The chosen domain parameter 392 set and public key are assumed to be conveyed to the client at the 393 time the client's username and password were provisioned. 395 4. Specification of the TLS-PWD Handshake 397 The key exchange underlying TLS-PWD is the "dragonfly" PAKE as 398 defined in [RFC7664]. 400 The authenticated key exchange is accomplished by each side deriving 401 a password-based element, PE, in the chosen group, making a 402 "commitment" to a single guess of the password using PE, and 403 generating the Premaster Secret. The ability of each side to produce 404 a valid finished message authenticates itself to the other side. 406 The authenticated key exchange is dropped into the standard TLS 407 message handshake by modifying some of the messages. 409 Client Server 410 -------- -------- 412 Client Hello (name) --------> 414 Server Hello 415 Server Key Exchange (commit) 416 <-------- Server Hello Done 418 Client Key Exchange (commit) 419 [Change cipher spec] 420 Finished --------> 422 [Change cipher spec] 423 <-------- Finished 425 Application Data <-------> Application Data 427 Figure 1 429 4.1. Protecting the Username 431 The client is required to identify herself to the server before the 432 server can look up the appropriate client credential with which to 433 perform the authenticated key exchange. This has negative privacy 434 implicaitons and opens up the client to tracking and increased 435 monitoring. It is therefore useful for the client to be able to 436 protect her username from passive monitors of the exchange and 437 against active attack by a malicious server. TLS-PWD provides such a 438 mechsnism. Support for protected usernames is RECOMMENDED. 440 To enable username protection a server choses a domain parameter set, 441 chooses a random private key, s, such that 1 < s < (q-1), where q is 442 the order of the chosen group, uses scalar-op() with the selected 443 group's generator to generate a public key, S: 445 S = scalar-op(s, G) 447 This keypair SHALL only be used for username protection. For 448 efficiency, the domain parameter set used for userame protection MUST 449 be based on elliptic curve cryptography. Any ECC group that is 450 approprate for TLS-PWD (see Section 3.2.1) is suitable for this 451 purpose but for interoperability, brainpoolP256r1 MUST be supported. 452 The domain parameter set used for username protection does not 453 restrict the choice of domain parameter set used for the underlying 454 key exchange in any way. 456 When the client's username and password are provisioned on the 457 server, the server conveys the chosen group and its public key to the 458 client. This is stored on the client along with the server-specific 459 state (e.g. the hostname) it uses to initiate a TLS-PWD exchange. 460 The server uses the same group and public key with all clients. 462 To protect a username, the client and server perform a static- 463 ephemeral Diffie-Hellman exchange, using compact representation (and 464 therefore compact output, see [RFC6090]). The result of the Diffie- 465 Hellman exchange is passed to HKDF [RFC5869] to create a key- 466 encrypting key suitable for AES-SIV [RFC5297]. The length of the 467 key-encrypting key, l, and the hash function to use with HKDF depends 468 on the length of the prime, p, of the group used to provide username 469 protection: 471 o SHA-256, SIV-128, l=256 bits: when len(p) <= 256 473 o SHA-384, SIV-192, l=384 bits: when 256 < len(p) <= 384 475 o SHA-512, SIV-256, l=512 bits: when len(p) > 384 477 4.1.1. Construction of a Protected Username 479 Prior to initiating a TLS-PWD exchange, the client chooses a random 480 secret, c, such that 1 < c < (q-1), where q is the order of the group 481 from which the server's public key was generated, and uses scalar- 482 op() with the group's generator to create a public key, C. It uses 483 scalar-op() with the server's public key and c to create a shared 484 secret and derives a key-encrypting key, k, using the "salt-less" 485 mode of HKDF [RFC5869]. 487 C = scalar-op(c, G) 489 Z = scalar-op(c, S) 491 k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) 493 Where NULL indicates the salt-free invocation and "" indicates an 494 empty string (i.e. there is no "context" passed to HKDF). 496 The key, k, and the client's username is then passed to SIV-encrypt 497 with no AAD and no nonce to produce an encrypted username, u: 499 u = SIV-encrypt(k, username) 501 Note: the format of the ciphertext output from SIV includes the 502 authenticating synthetic initialization vector. 504 The protected username SHALL be the concatenation of the x-coordinate 505 of the client's public key, C, and the encrypted username, u. The 506 length of the x-coordinate of C MUST be equal to the length of the 507 group's prime, p, pre-pended with zeros, if necessary. The protected 508 username is inserted into the PWD_name extension and the 509 ExtensionType MUST be PWD_protect (see Section 4.3.1). 511 The length of the ciphertext output from SIV, minus the synthetic 512 initialization vector, will be equal to the length of the input 513 plaintext, in this case the username. To further foil traffic 514 analysis, it is RECOMMENDED that clients append a series of NULL 515 bytes to their usernames prior to passing them to SIV-encrypt() and 516 to vary the number of bytes added with each distinct run of TLS-PWD. 518 4.1.2. Recovery of a Protected Username 520 A server that receives a protected username needs to recover the 521 client's username prior to performing the key exchange. To do so, 522 the server computes the client's public key, completes the static- 523 ephemeral Diffie-Hellman exchange, derives the key encrypting key, k, 524 and decrypts the username. 526 The length of the x-coordinate of the client's public key is known 527 (it is the length of the prime from the domain parameter set used to 528 protect usernames) and can easily be separated from the ciphertext in 529 the PWD_name extension in the Client Hello-- the first len(p) bits 530 are the x-coordinate of the client's public key and the remaining 531 bits are the ciphertext. 533 Since compressed representation is used by the client, the server 534 MUST compute the y-coordinate of the client's public key by using the 535 equation of the curve: 537 y^2 = x^3 + ax + b 539 and solving for y. There are two solutions for y but since 540 compressed output is also being used, the selection is irrelevant. 541 The server reconstructs the client's public value, C, from (x, y). 542 If there is no solution for y, or if (x, y) is not a valid point on 543 the elliptic curve (see Section 3.2.1), the server MUST treat the 544 Client Hello as if it did not have a password for a given username 545 (see Section 4.3.1). 547 The server then uses scalar-op() with the reconstructed point C and 548 the private key it uses for protected passwords, s, to generate a 549 shared secret, and derives a key-encrypting key, k, in the same 550 manner as in Section 4.1.1. 552 Z = scalar-op(s, C) 554 k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) 556 The key, k, and the ciphertext portion of the PWD_name extension, u, 557 are passed to SIV-decrypt with no AAD and no nonce to produce the 558 username: 560 username = SIV-decrypt(k, u) 562 If SIV-decrypt returns the symbol FAIL indicating unsuccessful 563 decryption and verification the server MUST treat the ClientHello as 564 if it did not have a password for a given username (see 565 Section 4.3.1). If successful, the server has obtained the client's 566 username and can process it as needed. Any NULL octets added by the 567 client prior to encryption can be easily stripped off of the string 568 that represents the username. 570 4.2. Fixing the Password Element 572 Prior to making a "commitment" both sides must generate a secret 573 element, PE, in the chosen group using the common password-derived 574 base. The server generates PE after it receives the Client Hello and 575 chooses the particular group to use, and the client generates PE upon 576 receipt of the Server Key Exchange. 578 Fixing the password element involves an iterative "hunting and 579 pecking" technique using the prime from the negotiated group's domain 580 parameter set and an ECC- or FFC-specific operation depending on the 581 negotiated group. 583 To thwart side channel attacks which attempt to determine the number 584 of iterations of the "hunting-and-pecking" loop are used to find PE 585 for a given password, a security parameter, m, is used to ensure that 586 at least m iterations are always performed. 588 First, an 8-bit counter is set to the value one (1). Then, H is used 589 to generate a password seed from the a counter, the prime of the 590 selected group, and the base (which is derived from the username, 591 password, and salt): 593 pwd-seed = H(base | counter | p) 595 Then, using the technique from section B.5.1 of [FIPS186-3], the pwd- 596 seed is expanded using the PRF to the length of the prime from the 597 negotiated group's domain parameter set plus a constant sixty-four 598 (64) to produce an intermediate pwd-tmp which is modularly reduced to 599 create pwd-value: 601 n = len(p) + 64 602 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 603 ClientHello.random | ServerHello.random) [0..n]; 604 pwd-value = (pwd-tmp mod (p-1)) + 1 606 The pwd-value is then passed to the group-specific operation which 607 either returns the selected password element or fails. If the group- 608 specific operation fails, the counter is incremented, a new pwd-seed 609 is generated, and the hunting-and-pecking continues. This process 610 continues until the group-specific operation returns the password 611 element. After the password element has been chosen, the base is 612 changed to a random number, the counter is incremented and the 613 hunting-and-pecking continues until the counter is greater than the 614 security parameter, m. 616 The probability that one requires more than n iterations of the 617 "hunting and pecking" loop to find an ECC PE is roughly (q/2p)^n and 618 to find an FFC PE is roughly (q/p)^n, both of which rapidly approach 619 zero (0) as n increases. The security parameter, m, SHOULD be set 620 sufficiently large such that the probability that finding PE would 621 take more than m iterations is sufficiently small (see Section 8). 623 When PE has been discovered, pwd-seed, pwd-tmp, and pwd-value SHALL 624 be irretrievably destroyed. 626 4.2.1. Computing an ECC Password Element 628 The group-specific operation for ECC groups uses pwd-value, pwd-seed, 629 and the equation for the curve to produce PE. First, pwd-value is 630 used directly as the x-coordinate, x, with the equation for the 631 elliptic curve, with parameters a and b from the domain parameter set 632 of the curve, to solve for a y-coordinate, y. If there is no 633 solution to the quadratic equation, this operation fails and the 634 hunting-and-pecking process continues. If a solution is found, then 635 an ambiguity exists as there are technically two solutions to the 636 equation and pwd-seed is used to unambiguously select one of them. 637 If the low-order bit of pwd-seed is equal to the low-order bit of y, 638 then a candidate PE is defined as the point (x, y); if the low-order 639 bit of pwd-seed differs from the low-order bit of y, then a candidate 640 PE is defined as the point (x, p - y), where p is the prime over 641 which the curve is defined. The candidate PE becomes PE, a random 642 number is used instead of the base, and the hunting and pecking 643 continues until it has looped through m iterations. 645 Algorithmically, the process looks like this: 647 found = 0 648 counter = 0 649 base = H(username | password | salt) 650 n = len(p) + 64 651 do { 652 counter = counter + 1 653 seed = H(base | counter | p) 654 tmp = PRF(seed, "TLS-PWD Hunting And Pecking", 655 ClientHello.random | ServerHello.random) [0..n] 656 val = (tmp mod (p-1)) + 1 657 if ( (val^3 + a*val + b) mod p is a quadratic residue) 658 then 659 if (found == 0) 660 then 661 x = val 662 save = seed 663 found = 1 664 base = random() 665 fi 666 fi 667 } while ((found == 0) || (counter <= m)) 668 y = sqrt(x^3 + a*x + b) mod p 669 if ( lsb(y) == lsb(save)) 670 then 671 PE = (x, y) 672 else 673 PE = (x, p-y) 674 fi 676 Figure 2: Fixing PE for ECC Groups 678 Checking whether a value is a quadradic residue modulo a prime can 679 leak information about that value in a side-channel attack. 680 Therefore, it is RECOMMENDED that the technique used to determine if 681 the value is a quadratic residue modulo p first blind the value with 682 a random number so that the blinded value can take on all numbers 683 between 1 and p-1 with equal probability. Determining the quadratic 684 residue in a fashion that resists leakage of information is handled 685 by flipping a coin and multiplying the blinded value by either a 686 random quadratic residue or a random quadratic nonresidue and 687 checking whether the multiplied value is a quadradic residue or a 688 quadradic nonresidue modulo p, respectively. The random residue and 689 nonresidue can be calculated prior to hunting-and-pecking by 690 calculating the legendre symbol on random values until they are 691 found: 693 do { 694 qr = random() 695 } while ( lgr(qr, p) != 1) 697 do { 698 qnr = random() 699 } while ( lgr(qnr, p) != -1) 701 Algorithmically, the masking technique to find out whether a value is 702 a quadratic residue modulo a prime or not looks like this: 704 is_quadratic_residue (val, p) { 705 r = (random() mod (p - 1)) + 1 706 num = (val * r * r) mod p 707 if ( lsb(r) == 1 ) 708 num = (num * qr) mod p 709 if ( lgr(num, p) == 1) 710 then 711 return TRUE 712 fi 713 else 714 num = (num * qnr) mod p 715 if ( lgr(num, p) == -1) 716 then 717 return TRUE 718 fi 719 fi 720 return FALSE 721 } 723 The random quadratic residue and quadratic non-residue (qr and qnr 724 above) can be used for all the hunting-and-pecking loops but the 725 blinding value, r, MUST be chosen randomly for each loop. 727 4.2.2. Computing an FFC Password Element 729 The group-specific operation for FFC groups takes pwd-value, and the 730 prime, p, and order, q, from the group's domain parameter set (see 731 Section 3.2.2 when the order is not part of the defined domain 732 parameter set) to directly produce a candidate password element, by 733 exponentiating the pwd-value to the value ((p-1)/q) modulo the prime. 734 If the result is greater than one (1), the candidate password element 735 becomes PE, and the hunting and pecking terminates successfully. 737 Algorithmically, the process looks like this: 739 found = 0 740 counter = 0 741 base = H(username | password | salt) 742 n = len(p) + 64 743 do { 744 counter = counter + 1 745 pwd-seed = H(base | counter | p) 746 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 747 ClientHello.random | ServerHello.random) [0..n] 748 pwd-value = (pwd-tmp mod (p-1)) + 1 749 PE = pwd-value ^ ((p-1)/q) mod p 750 if (PE > 1) 751 then 752 found = 1 753 base = random() 754 fi 755 } while ((found == 0) || (counter <= m)) 757 Figure 3: Fixing PE for FFC Groups 759 4.3. Changes to Handshake Message Contents 761 4.3.1. Client Hello Changes 763 The client is required to identify herself to the server by adding a 764 either a PWD_protect or PWD_clear extension to the Client Hello 765 message depending on whether the client wishes to protect its 766 username (see Section 4.1) or not, respectively. The PWD_protect and 767 PWD_clear extensions use the standard mechanism defined in [RFC5246]. 768 The "extension data" field of the PWD extension SHALL contain a 769 PWD_name which is used to identify the password shared between the 770 client and server. If username protection is performed, and the 771 ExtensionType is PWD_protect, the contents of the PWD_name SHALL be 772 constructed according to Section 4.1.1). 774 enum { PWD_clear(TBD1), PWD_protect(TBD2) } ExtensionType; 776 opaque PWD_name<1..2^8-1>; 778 An unprotected PWD_name SHALL be UTF-8 encoded character string 779 processed according to the rules of the [RFC4013] profile of 780 [RFC3454] and a protected PWD_name SHALL be a string of bits. 782 A client offering a PWD ciphersuite MUST include one of the PWD_name 783 extensions in her Client Hello. 785 If a server does not have a password for a client identified by the 786 username either extracted from the PWD_name, if unprotected, or 787 recovered using the technique in Section 4.1.2, if protected, or if 788 recovery of a protected username fails, the server SHOULD hide that 789 fact by simulating the protocol-- putting random data in the PWD- 790 specific components of the Server Key Exchange-- and then rejecting 791 the client's finished message with a "bad_record_mac" alert. To 792 properly effect a simulated TLS-PWD exchange, an appropriate delay 793 SHOULD be inserted between receipt of the Client Hello and response 794 of the Server Hello. Alternately, a server MAY choose to terminate 795 the exchange if a password is not found. 797 The server decides on a group to use with the named user (see 798 Section 10 and generates the password element, PE, according to 799 Section 4.2.2. 801 4.3.2. Server Key Exchange Changes 803 The domain parameter set for the selected group MUST be specified in 804 the ServerKeyExchange, either explicitly or, in the case of some 805 elliptic curve groups, by name. In addition to the group 806 specification, the ServerKeyExchange also contains the server's 807 "commitment" in the form of a scalar and element, and the salt which 808 was used to store the user's password. 810 Two new values have been added to the enumerated KeyExchangeAlgorithm 811 to indicate TLS-PWD using finite field cryptography, ff_pwd, and TLS- 812 PWD using elliptic curve cryptography, ec_pwd. 814 enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms; 816 struct { 817 opaque salt<1..2^8-1>; 818 opaque pwd_p<1..2^16-1>; 819 opaque pwd_g<1..2^16-1>; 820 opaque pwd_q<1..2^16-1>; 821 opaque ff_selement<1..2^16-1>; 822 opaque ff_sscalar<1..2^16-1>; 823 } ServerFFPWDParams; 825 struct 826 opaque salt<1..2^8-1>; 827 ECParameters curve_params; 828 ECPoint ec_selement; 829 opaque ec_sscalar<1..2^8-1>; 830 } ServerECPWDParams; 832 struct { 833 select (KeyExchangeAlgorithm) { 834 case ec_pwd: 835 ServerECPWDParams params; 836 case ff_pwd: 837 ServerFFPWDParams params; 838 }; 839 } ServerKeyExchange; 841 4.3.2.1. Generation of ServerKeyExchange 843 The scalar and Element that comprise the server's "commitment" are 844 generated as follows. 846 First two random numbers, called private and mask, between zero and 847 the order of the group (exclusive) are generated. If their sum 848 modulo the order of the group, q, equals zero the numbers must be 849 thrown away and new random numbers generated. If their sum modulo 850 the order of the group, q, is greater than zero the sum becomes the 851 scalar. 853 scalar = (private + mask) mod q 855 The Element is then calculated as the inverse of the group's scalar 856 operation (see the group specific operations in Section 3.2) with the 857 mask and PE. 859 Element = inverse(scalar-op(mask, PE)) 861 After calculation of the scalar and Element the mask SHALL be 862 irretrievably destroyed. 864 4.3.2.1.1. ECC Server Key Exchange 866 EEC domain parameters are specified, either explicitly or named, in 867 the ECParameters component of the EEC-specific ServerKeyExchange as 868 defined in [RFC4492]. The scalar SHALL become the ec_sscalar 869 component and the Element SHALL become the ec_selement of the 870 ServerKeyExchange. If the client requested a specific point format 871 (compressed or uncompressed) with the Support Point Formats Extension 872 (see [RFC4492]) in its Client Hello, the Element MUST be formatted in 873 the ec_selement to conform to that request. If the client offered 874 (an) elliptic curve(s) in its ClientHello using the Supported 875 Elliptic Curves Extension, the server MUST include (one of the) named 876 curve(s) in the ECParameters field in the ServerKeyExchange and the 877 key exchange operations specified in Section 4.3.2.1 MUST use that 878 group. 880 As mentioned in Section 3.2.1, elliptic curves over GF(2^m), so 881 called characteristic-2 curves, and curves with a co-factor greater 882 than one (1) SHALL NOT be used with TLS-PWD. 884 4.3.2.1.2. FFC Server Key Exchange 886 FFC domain parameters sent in the ServerKeyExchange are for the 887 group's prime, generator (which is only used for verification of the 888 group specification), and the order of the group's generator. The 889 scalar SHALL become the ff_sscalar component and the Element SHALL 890 become the ff_selement in the FFC-specific ServerKeyExchange. 892 As mentioned in Section 3.2.2 if the prime is a safe prime and no 893 order is included in the domain parameter set, the order added to the 894 ServerKeyExchange SHALL be the prime minus one divided by two-- 895 (p-1)/2. 897 4.3.2.2. Processing of ServerKeyExchange 899 Upon receipt of the ServerKeyExchange, the client decides whether to 900 support the indicated group or not. If the client used the Supported 901 Elliptic Curves Extension to offer (a) named curve(s) in her 902 ClientHello, the named curve in the ServerKeyExchange MUST be one 903 offered. If the server is explicitly specifying a group, either an 904 FFC or ECC group, the client and server MUST have agreed upon groups 905 prior to beginning the exchange (see Section 3.2) and the client MUST 906 compare each field of the explicit offer to the agreed-upon group(s). 907 Any discrepency SHALL result in the exchange being aborted. 909 If the client decides to support the indicated group the server's 910 "commitment" MUST be validated by ensuring that: 1) the server's 911 scalar value is greater than zero (0) and less than the order of the 912 group, q; and 2) that the Element is valid for the chosen group (see 913 Section 3.2.2 and Section 3.2.1 for how to determine whether an 914 Element is valid for the particular group. Note that if the Element 915 is a compressed point on an elliptic curve it MUST be uncompressed 916 before checking its validity). 918 If the group is acceptable and the server's "commitment" has been 919 successfully validated, the client extracts the salt from the 920 ServerKeyExchange and generates the password element, PE, according 921 to Section 3.4 and Section 4.2.2. If the group is not acceptable or 922 the server's "commitment" failed validation, the eexchange MUST be 923 aborted. 925 4.3.3. Client Key Exchange Changes 927 When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd, 928 the ClientKeyExchange is used to convey the client's "commitment" to 929 the server. It, therefore, contains a scalar and an Element. 931 struct { 932 opaque ff_celement<1..2^16-1>; 933 opaque ff_cscalar<1..2^16-1>; 934 } ClientFFPWDParams; 936 struct 937 ECPoint ec_celement; 938 opaque ec_cscalar<1..2^8-1>; 939 } ClientECPWDParams; 941 struct { 942 select (KeyExchangeAlgorithm) { 943 case ff_pwd: ClientFFPWDParams; 944 case ec_pwd: ClientECPWDParams; 945 } exchange_keys; 946 } ClientKeyExchange; 948 4.3.3.1. Generation of Client Key Exchange 950 The client's scalar and Element are generated in the manner described 951 in Section 4.3.2.1. 953 For an FFC group, the scalar SHALL become the ff_cscalar component 954 and the Element SHALL become the ff_celement in the FFC-specific 955 ClientKeyExchange. 957 For an ECC group, the scalar SHALL become the ec_cscalar component 958 and the ELement SHALL become the ec_celement in the ECC-specific 959 ClientKeyExchange. If the client requested a specific point format 960 (compressed or uncompressed) with the Support Point Formats Extension 961 in its ClientHello, then the Element MUST be formatted in the 962 ec_celement to conform to its initial request. 964 4.3.3.2. Processing of Client Key Exchange 966 Upon receipt of the ClientKeyExchange, the server must validate the 967 client's "commitment" by ensuring that: 1) the client's scalar and 968 element differ from the server's scalar and element; 2) the client's 969 scalar value is greater than zero (0) and less than the order of the 970 group, q; and 3) that the Element is valid for the chosen group (see 971 Section 3.2.2 and Section 3.2.1 for how to determin whether an 972 Element is valid for a particular group. Note that if the Element is 973 a compressed point on an elliptic curve it MUST be uncompressed 974 before checking its validity. If any of these three conditions are 975 not met the server MUST abort the exchange. 977 4.4. Computing the Premaster Secret 979 The client uses the server's scalar and Element, denoted here as 980 ServerKeyExchange.scalar and ServerKeyExchange.Element, and the 981 random private value, denoted here as client.private, she created as 982 part of the generation of her "commit" to compute an intermediate 983 value, z, as indicated: 985 z = F(scalar-op(client.private, 986 element-op(ServerKeyExchange.Element, 987 scalar-op(ServerKeyExchange.scalar, PE)))) 989 With the same notation as above, the server the client's scalar and 990 Element, and his random private value, denoted here as 991 server.private, he created as part of the generation of his "commit" 992 to compute the premaster secret as follows: 994 z = F(scalar-op(server.private, 995 element-op(ClientKeyExchange.Element, 996 scalar-op(ClientKeyExchange.scalar, PE)))) 998 The intermediate value, z, is then used as the premaster secret after 999 any leading bytes of z that contain all zero bits have been stripped 1000 off. 1002 5. Ciphersuite Definition 1004 This memo adds the following ciphersuites: 1006 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 1008 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 1010 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 1012 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 1014 Implementations conforming to this specification MUST support the 1015 TLS_ECCPWD_WITH_AES_128_GCM_SHA256, ciphersuite; they SHOULD support 1016 the remaining ciphersuites. 1018 When negotiated with a version of TLS prior to 1.2, the Pseudo-Random 1019 Function (PRF) from that version is used; otherwise, the PRF is the 1020 TLS PRF [RFC5246] using the hash function indicated by the 1021 ciphersuite. Regardless of the TLS version, the TLS-PWD random 1022 function, H, is always instantiated with the hash algorithm indicated 1023 by the ciphersuite. 1025 For those ciphersuites that use Cipher Block Chaining (CBC) 1026 [SP800-38A] mode, the MAC is HMAC [RFC2104] with the hash function 1027 indicated by the ciphersuite. 1029 6. Acknowledgements 1031 The authenticated key exchange defined here has also been defined for 1032 use in 802.11 networks, as an EAP method, and as an authentication 1033 method for IKE. Each of these specifications has elicited very 1034 helpful comments from a wide collection of people that have allowed 1035 the definition of the authenticated key exchange to be refined and 1036 improved. 1038 The authors would like to thank Scott Fluhrer for discovering the 1039 "password as exponent" attack that was possible in an early version 1040 of this key exchange and for his very helpful suggestions on the 1041 techniques for fixing the PE to prevent it. The authors would also 1042 like to thank Hideyuki Suzuki for his insight in discovering an 1043 attack against a previous version of the underlying key exchange 1044 protocol. Special thanks to Lily Chen for helpful discussions on 1045 hashing into an elliptic curve. Rich Davis suggested the defensive 1046 checks that are part of the processing of the ServerKeyExchange and 1047 ClientKeyExchange messages, and his various comments have greatly 1048 improved the quality of this memo and the underlying key exchange on 1049 which it is based. 1051 Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik, discussed the 1052 possibility of a side-channel attack against the hunting-and-pecking 1053 loop on the TLS mailing list. That discussion prompted the addition 1054 of the security parameter, m, to the hunting-and-pecking loop. Scott 1055 Flurer suggested the blinding technique to test whether a value is a 1056 quadratic residue modulo a prime in a manner that does not leak 1057 information about the value being tested. 1059 7. IANA Considerations 1061 IANA SHALL assign two values for a new TLS extention type from the 1062 TLS ExtensionType Registry defined in [RFC5246] with the name 1063 "pwd_protect" and "pwd_clear". The RFC editor SHALL replace TBD1 and 1064 TBD2 in Section 4.3.1 with the IANA-assigned value for these 1065 extensions. 1067 IANA SHALL assign nine new ciphersuites from the TLS Ciphersuite 1068 Registry defined in [RFC5246] for the following ciphersuites: 1070 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 1072 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 1074 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 1076 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 1078 The RFC editor SHALL replace (TBD, TBD) in all the ciphersuites 1079 defined in Section 5 with the appropriate IANA-assigned values. The 1080 "DTLS-OK" column in the ciphersuite registry SHALL be set to "Y" and 1081 the "IETF Recommended" column SHALL be set to "N" for all 1082 ciphersuites defined in this memo. 1084 8. Security Considerations 1086 A security proof of this key exchange in the random oracle model is 1087 found in [lanskro]. 1089 A passive attacker against this protocol will see the 1090 ServerKeyExchange and the ClientKeyExchange containing the server's 1091 scalar and Element, and the client's scalar and Element, 1092 respectively. The client and server effectively hide their secret 1093 private value by masking it modulo the order of the selected group. 1094 If the order is "q", then there are approximately "q" distinct pairs 1095 of numbers that will sum to the scalar values observed. It is 1096 possible for an attacker to iterate through all such values but for a 1097 large value of "q", this exhaustive search technique is 1098 computationally infeasible. The attacker would have a better chance 1099 in solving the discrete logarithm problem, which we have already 1100 assumed (see Section 3.5) to be an intractable problem. 1102 A passive attacker can take the Element from either the 1103 ServerKeyExchange or the ClientKeyExchange and try to determine the 1104 random "mask" value used in its construction and then recover the 1105 other party's "private" value from the scalar in the same message. 1106 But this requires the attacker to solve the discrete logarithm 1107 problem which we assumed was intractable. 1109 Both the client and the server obtain a shared secret, the premaster 1110 secret, based on a secret group element and the private information 1111 they contributed to the exchange. The secret group element is based 1112 on the password. If they do not share the same password they will be 1113 unable to derive the same secret group element and if they don't 1114 generate the same secret group element they will be unable to 1115 generate the same premaster secret. Seeing a finished message along 1116 with the ServerKeyExchange and ClientKeyExchange will not provide any 1117 additional advantage of attack since it is generated with the 1118 unknowable premaster secret. 1120 An active attacker impersonating the client can induce a server to 1121 send a ServerKeyExchange containing the server's scalar and Element. 1122 It can attempt to generate a ClientKeyExchange and send to the server 1123 but the attacker is required to send a finished message first so the 1124 only information she can obtain in this attack is less than the 1125 information she can obtain from a passive attack, so this particular 1126 active attack is not very fruitful. 1128 An active attacker can impersonate the server and send a forged 1129 ServerKeyExchange after receiving the ClientHello. The attacker then 1130 waits until it receives the ClientKeyExchange and finished message 1131 from the client. Now the attacker can attempt to run through all 1132 possible values of the password, computing PE (see Section 4.2), 1133 computing candidate premaster secrets (see Section 4.4), and 1134 attempting to recreate the client's finished message. 1136 But the attacker committed to a single guess of the password with her 1137 forged ServerKeyExchange. That value was used by the client in her 1138 computation of the premaster secret which was used to produce the 1139 finished message. Any guess of the password which differs from the 1140 one used in the forged ServerKeyExchange would result in each side 1141 using a different PE in the computation of the premaster secret and 1142 therefore the finished message cannot be verified as correct, even if 1143 a subsequent guess, while running through all possible values, was 1144 correct. The attacker gets one guess, and one guess only, per active 1145 attack. 1147 Instead of attempting to guess at the password, an attacker can 1148 attempt to determine PE and then launch an attack. But PE is 1149 determined by the output of the random function, H, which is 1150 indistinguishable from a random source since H is assumed to be a 1151 "random oracle" (Section 3.5). Therefore, each element of the finite 1152 cyclic group will have an equal probability of being the PE. The 1153 probability of guessing PE will be 1/q, where q is the order of the 1154 group. For a large value of "q" this will be computationally 1155 infeasible. 1157 The implications of resistance to dictionary attack are significant. 1158 An implementation can provision a password in a practical and 1159 realistic manner-- i.e. it MAY be a character string and it MAY be 1160 relatively short-- and still maintain security. The nature of the 1161 pool of potential passwords determines the size of the pool, D, and 1162 countermeasures can prevent an attacker from determining the password 1163 in the only possible way: repeated, active, guessing attacks. For 1164 example, a simple four character string using lower-case English 1165 characters, and assuming random selection of those characters, will 1166 result in D of over four hundred thousand. An attacker would need to 1167 mount over one hundred thousand active, guessing attacks (which will 1168 easily be detected) before gaining any significant advantage in 1169 determining the pre-shared key. 1171 Countermeasures to deal with successive active, guessing attacks are 1172 only possible by noticing a certain username is failing repeatedly 1173 over a certain period of time. Attacks which attempt to find a 1174 password for a random user are more difficult to detect. For 1175 instance, if a device uses a serial number as a username and the pool 1176 of potential passwords is sufficiently small, a more effective attack 1177 would be to select a password and try all potential "users" to 1178 disperse the attack and confound countermeasures. It is therefore 1179 RECOMMENDED that implementations of TLS-PWD keep track of the total 1180 number of failed authentications regardless of username in an effort 1181 to detect and thwart this type of attack. 1183 The benefits of resistance to dictionary attack can be lessened by a 1184 client using the same passwords with multiple servers. An attacker 1185 could re-direct a session from one server to the other if the 1186 attacker knew that the intended server stored the same password for 1187 the client as another server. 1189 An adversary that has access to, and a considerable amount of control 1190 over, a client or server could attempt to mount a side-channel attack 1191 to determine the number of times it took for a certain password (plus 1192 client random and server random) to select a password element. Each 1193 such attack could result in a successive paring-down of the size of 1194 the pool of potential passwords, resulting in a manageably small set 1195 from which to launch a series of active attacks to determine the 1196 password. A security parameter, m, is used to normalize the amount 1197 of work necessary to determine the password element (see 1198 Section 4.2). The probability that a password will require more than 1199 m iterations is roughly (q/2p)^m for ECC groups and (q/p)^m for FFC 1200 groups, so it is possible to mitigate side channel attack at the 1201 expense of a constant cost per connection attempt. But if a 1202 particular password requires more than k iterations it will leak k 1203 bits of information to the side-channel attacker, which for some 1204 dictionaries will uniquely identify the password. Therefore, the 1205 security parameter, m, needs to be set with great care. It is 1206 RECOMMENDED that an implementation set the security parameter, m, to 1207 a value of at least forty (40) which will put the probability that 1208 more than forty iterations are needed in the order of one in one 1209 trillion (1:1,000,000,000,000). 1211 The server uses a database of salted passwords. While this will 1212 prevent an adversary who gains access to the database from learning 1213 the client's password, it does not prevent such an adversary from 1214 impersonating the client back to the server. Each side uses the 1215 salted password, called the base, as the authenticaiton credential so 1216 the database of salted passwords MUST be afforded the security of a 1217 database of plaintext passwords. 1219 Authentication is performed by proving knowledge of the password. 1220 Any third party that knows the password shared by the client and 1221 server can impersonate one to the other. 1223 The static-ephemeral Diffie-Hellman exchange used to protect 1224 usernames requires the server to reuse its Diffie-Hellman public key. 1225 To prevent an invalid curve attack, an entity that reuses its Diffie- 1226 Hellman public key needs to check whether the received ephemeral 1227 public key is actually a point on the curve. This is done explicitly 1228 as part of the server's reconstruction of the client's public key out 1229 of only its x-coordinate ("compact representation"). 1231 9. Human Rights Considerations 1233 At the time of publication, there was a growing interest in 1234 considering the human rights impact of IETF (and IRTF) work. As 1235 such, the Human Rights Considerations of TLS-PWD are presented. 1237 The key exchange underlying TLS-PWD uses public key cryptography to 1238 perform authentication and authenticated key exchange. The keys it 1239 produces can be used to establish secure connections between two 1240 people to protect their communication. Implementations of TLS-PWD, 1241 like implementations of other TLS ciphersuites that perform 1242 authentication and authenticted key establishment, are considered 1243 'armaments' or 'munitions' by many governments around the world. 1245 The most fundamental of Human Rights is the right to protect oneself. 1246 The right to keep and bear arms is an example of this right. 1247 Implementations of TLS-PWD can be used as arms, kept and borne, to 1248 defend oneself against all manner of attackers-- criminals, 1249 governments, laywers, etc. TLS-PWD is a powerful tool in the 1250 promotion and defense of Universal Human Rights. 1252 10. Implementation Considerations 1254 The selection of the ciphersuite and selection of the particular 1255 finite cyclic group to use with the ciphersuite are divorced in this 1256 memo but they remain intimately close. 1258 It is RECOMMENDED that implementations take note of the strength 1259 estimates of particular groups and to select a ciphersuite providing 1260 commensurate security with its hash and encryption algorithms. A 1261 ciphersuite whose encryption algorithm has a keylength less than the 1262 strength estimate, or whose hash algorithm has a blocksize that is 1263 less than twice the strength estimate SHOULD NOT be used. 1265 For example, the elliptic curve named brainpoolP256r1 (whose IANA- 1266 assigned number is 26) provides an estimated 128 bits of strength and 1267 would be compatible with an encryption algorithm supporting a key of 1268 that length, and a hash algorithm that has at least a 256-bit 1269 blocksize. Therefore, a suitable ciphersuite to use with 1270 brainpoolP256r1 could be TLS_ECCPWD_WITH_AES_128_GCM_SHA256 (see 1271 Appendix A for an example of such an exchange). 1273 Resistance to dictionary attack means that the attacker must launch 1274 an active attack to make a single guess at the password. If the size 1275 of the pool from which the password was extracted was D, and each 1276 password in the pool has an equal probability of being chosen, then 1277 the probability of success after a single guess is 1/D. After X 1278 guesses, and removal of failed guesses from the pool of possible 1279 passwords, the probability becomes 1/(D-X). As X grows so does the 1280 probability of success. Therefore it is possible for an attacker to 1281 determine the password through repeated brute-force, active, guessing 1282 attacks. Implementations SHOULD take note of this fact and choose an 1283 appropriate pool of potential passwords-- i.e. make D big. 1284 Implementations SHOULD also take countermeasures, for instance 1285 refusing authentication attempts by a particular username for a 1286 certain amount of time, after the number of failed authentication 1287 attempts reaches a certain threshold. No such threshold or amount of 1288 time is recommended in this memo. 1290 11. References 1292 11.1. Normative References 1294 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1295 Hashing for Message Authentication", RFC 2104, DOI 1296 10.17487/RFC2104, February 1997, 1297 . 1299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1300 Requirement Levels", BCP 14, RFC 2119, March 1997. 1302 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1303 Internationalized Strings ("stringprep")", RFC 3454, DOI 1304 10.17487/RFC3454, December 2002, 1305 . 1307 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1308 and Passwords", RFC 4013, DOI 10.17487/RFC4013, February 1309 2005, . 1311 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1312 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1313 RFC5246, August 2008, 1314 . 1316 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 1317 Authenticated Encryption Using the Advanced Encryption 1318 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 1319 2008, . 1321 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1322 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 1323 RFC5869, May 2010, 1324 . 1326 11.2. Informative References 1328 [FIPS186-3] 1329 National Institute of Standards and Technology, "Digital 1330 Signature Standard (DSS)", Federal Information Processing 1331 Standards Publication 186-3, . 1333 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 1334 A Paradigm for Designing Efficient Protocols", Proceedings 1335 of the 1st ACM Conference on Computer and Communication 1336 Security, ACM Press, 1993. 1338 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1339 "Randomness Requirements for Security", BCP 106, RFC 4086, 1340 DOI 10.17487/RFC4086, June 2005, 1341 . 1343 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1344 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1345 for Transport Layer Security (TLS)", RFC 4492, DOI 1346 10.17487/RFC4492, May 2006, 1347 . 1349 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1350 Curve Cryptography Algorithms", RFC 6090, February 2011. 1352 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1353 "Enrollment over Secure Transport", RFC 7030, DOI 1354 10.17487/RFC7030, October 2013, 1355 . 1357 [RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 1358 10.17487/RFC7664, November 2015, 1359 . 1361 [SP800-38A] 1362 National Institute of Standards and Technology, 1363 "Recommendation for Block Cipher Modes of Operation-- 1364 Methods and Techniques", NIST Special Publication 800-38A, 1365 December 2001. 1367 [SP800-56A] 1368 Barker, E., Johnson, D., and M. Smid, "Recommendations for 1369 Pair-Wise Key Establishment Schemes Using Discrete 1370 Logarithm Cryptography", NIST Special Publication 800-56A, 1371 March 2007. 1373 [lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of 1374 the Dragonfly Protocol", Proceedings of 18th International 1375 Information Security Conference (ISC 2015), pp 244-261, 1376 DOI 10.1007/978-3-319-23318-5_14, September 2015. 1378 Appendix A. Example Exchange 1380 (Note: at the time of publication of this memo ciphersuites have 1381 not yet been assigned by IANA and the exchange that follows uses 1382 the private numberspace). 1384 username: fred 1385 password: barney 1386 ---- prior to running TLS-PWD ---- 1388 server generates salt: 1390 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 1391 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 1393 and a base: 1395 6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 1396 c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75 1398 ---- state derived during the TLS-PWD exchange ---- 1400 client and server agree to use brainpoolP256r1 1402 client and server generate PE: 1404 PE.x: 1405 29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 1406 a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6 1408 server private and mask: 1410 private: 1411 21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b 1412 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c 1413 mask: 1414 0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f 1415 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5 1417 client private and mask: 1419 private: 1420 17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f 1421 a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b 1422 mask: 1423 4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88 1424 83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd 1426 both parties generate pre-master secret and master secret 1428 pre-master secret: 1429 01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11 1430 af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4 1431 master secret: 1432 65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1 1433 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f 1434 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad 1436 ---- ssldump output of exchange ---- 1438 New TCP connection #1: Charlene Client <-> Sammy Server 1439 1 1 0.0018 (0.0018) C>SV3.3(173) Handshake 1440 ClientHello 1441 Version 3.3 1442 random[32]= 1443 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 1444 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d 1445 cipher suites 1446 TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV 1447 TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV 1448 Unknown value 0xff 1449 compression methods 1450 NULL 1451 extensions 1452 TLS-PWD unprotected name[5]= 1453 04 66 72 65 64 1454 elliptic curve point format[4]= 1455 03 00 01 02 1456 elliptic curve list[58]= 1457 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 1458 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 1459 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 1460 00 02 00 03 00 0f 00 10 00 11 1461 Packet data[178]= 1462 16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17 1463 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf 1464 a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3 1465 ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65 1466 64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00 1467 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 1468 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 1469 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 1470 03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06 1471 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 1472 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 1473 01 01 1475 1 2 0.0043 (0.0024) S>CV3.3(94) Handshake 1476 ServerHello 1477 Version 3.3 1478 random[32]= 1479 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 1480 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa 1482 session_id[32]= 1483 ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 1484 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 1485 cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV 1486 compressionMethod NULL 1487 extensions 1488 renegotiate[1]= 1489 00 1490 elliptic curve point format[4]= 1491 03 00 01 02 1492 heartbeat[1]= 1493 01 1494 Packet data[99]= 1495 16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43 1496 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 1497 ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08 1498 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 1499 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00 1500 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f 1501 00 01 01 1503 1 3 0.0043 (0.0000) S>CV3.3(141) Handshake 1504 ServerKeyExchange 1505 params 1506 salt[32]= 1507 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 1508 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 1509 EC parameters = 3 1510 curve id = 26 1511 element[65]= 1512 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 1513 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee 1514 f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 1515 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db 1516 e1 1517 scalar[32]= 1518 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a 1519 df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21 1520 Packet data[146]= 1521 16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1 1522 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 1523 47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04 1524 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 1525 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 1526 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 1527 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 1528 00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 1529 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 1530 49 21 1532 1 4 0.0043 (0.0000) S>CV3.3(4) Handshake 1533 ServerHelloDone 1534 Packet data[9]= 1535 16 03 03 00 04 0e 00 00 00 1537 1 5 0.0086 (0.0043) C>SV3.3(104) Handshake 1538 ClientKeyExchange 1539 element[65]= 1540 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 1541 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 1542 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 1543 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd 1544 a0 1545 scalar[32]= 1546 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 1547 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 1548 Packet data[109]= 1549 16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b 1550 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 1551 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd 1552 d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf 1553 e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44 1554 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 1555 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 1557 1 6 0.0086 (0.0000) C>SV3.3(1) ChangeCipherSpec 1558 Packet data[6]= 1559 14 03 03 00 01 01 1561 1 7 0.0086 (0.0000) C>SV3.3(40) Handshake 1562 Packet data[45]= 1563 16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7 1564 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a 1565 0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20 1567 1 8 0.0105 (0.0018) S>CV3.3(1) ChangeCipherSpec 1568 Packet data[6]= 1569 14 03 03 00 01 01 1571 1 9 0.0105 (0.0000) S>CV3.3(40) Handshake 1572 Packet data[45]= 1573 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c 1574 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 1575 a2 21 94 90 12 72 23 18 24 21 c3 60 a4 1577 1 10 0.0107 (0.0002) C>SV3.3(100) application_data 1578 Packet data.... 1580 Author's Address 1582 Dan Harkins (editor) 1583 HP Enterprise 1584 1322 Crossman Avenue 1585 Sunnyvale, CA 94089-1113 1586 United States of America 1588 Email: dharkins@arubanetworks.com