idnits 2.17.1 draft-harkins-tls-dragonfly-02.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 28, 2017) is 2405 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7613 (Obsoleted by RFC 8265) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 28, 2017 5 Expires: March 1, 2018 7 Secure Password Ciphersuites for Transport Layer Security (TLS) 8 draft-harkins-tls-dragonfly-02 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 March 1, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 . . . . . . . . . . . . . . 6 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 . . . . . . . . 21 80 4.4. Computing the Premaster Secret . . . . . . . . . . . . . 22 81 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . 22 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 9. Human Rights Considerations . . . . . . . . . . . . . . . . . 27 86 10. Implementation Considerations . . . . . . . . . . . . . . . . 27 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 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 basic password exchange 106 over 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. This means that the adversary 146 will not be able to obtain any information about the password except 147 whether a single guess from a single protocol run which she took part 148 in is correct or 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 go off-line and enumerate 154 through the pool trying potential secrets (computation) to see if one 155 is correct. She must do an active attack for each secret she wishes 156 to try (interaction) and the only information she can glean from that 157 attack is whether the secret used with that particular attack is 158 correct or 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 (ECC). 212 Elements in a group, either an FFC or ECC group, are indicated using 213 upper-case while scalar values are indicated using lower-case. 215 3.2.1. Elliptic Curve Cryptography 217 The authenticated key exchange defined in this memo uses fundamental 218 algorithms of elliptic curves defined over GF(p) as described in 219 [RFC6090]. Ciphersuites defined in this memo SHALL only use ECC 220 curves based on the Weierstrass equation y^2 = x^3 + a*x + b. 222 Domain parameters for the ECC groups used by this memo are: 224 o A prime, p, determining a prime field GF(p). The cryptographic 225 group will be a subgroup of the full elliptic curve group which 226 consists points on an elliptic curve-- elements from GF(p) that 227 satisfy the curve's equation-- together with the "point at 228 infinity" that serves as the identity element. 230 o Elements a and b from GF(p) that define the curve's equation. The 231 point (x,y) in GF(p) x GF(p) is on the elliptic curve if and only 232 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 234 o A point, G, on the elliptic curve, which serves as a generator for 235 the ECC group. G is chosen such that its order, with respect to 236 elliptic curve addition, is a sufficiently large prime. 238 o A prime, q, which is the order of G, and thus is also the size of 239 the cryptographic subgroup that is generated by G. 241 o A co-factor, f, defined by the requirement that the size of the 242 full elliptic curve group (including the "point at infinity") is 243 the product of f and q. 245 This memo uses the following ECC Functions: 247 o Z = elem-op(X,Y) = X + Y: two points on the curve X and Y, are 248 sumed to produce another point on the curve, Z. This is the group 249 operation for ECC groups. 251 o Z = scalar-op(x,Y) = x * Y: an integer scalar, x, acts on a point 252 on the curve, Y, via repetitive addition (Y is added to itself x 253 times), to produce another EEC element, Z. 255 o Y = inverse(X): a point on the curve, X, has an inverse, Y, which 256 is also a point on the curve, when their sum is the "point at 257 infinity" (the identity for elliptic curve addition). In other 258 words, R + inverse(R) = "0". 260 o z = F(X): the x-coordinate of a point (x, y) on the curve is 261 returned. This is a mapping function to convert a group element 262 into an integer. 264 Only ECC groups over GF(p) can be used with TLS-PWD. ECC groups over 265 GF(2^m) SHALL NOT be used by TLS-PWD. In addition, ECC groups with a 266 co-factor greater than one (1) SHALL NOT be used by TLS-PWD. 268 A composite (x, y) pair can be validated as a point on the elliptic 269 curve by checking whether: 1) both coordinates x and y are greater 270 than zero (0) and less than the prime defining the underlying field; 271 2) the x- and y- coordinates satisfy the equation of the curve; and 272 3) they do not represent the point-at-infinity "0". If any of those 273 conditions are not true the (x, y) pair is not a valid point on the 274 curve. 276 A compliant implementaiton of TLS-PWD SHALL support group twenty- 277 three (23) and SHOULD support group group twenty-four (24) from 278 [named_groups]. 280 3.2.2. Finite Field Cryptography 282 Domain parameters for the FFC groups used by this memo are: 284 o A prime, p, determining a prime field GF(p), the integers modulo 285 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 286 group of non-zero elements in GF(p). 288 o An element, G, in GF(p)* which serves as a generator for the FFC 289 group. G is chosen such that its multiplicative order is a 290 sufficiently large prime divisor of ((p-1)/2). 292 o A prime, q, which is the multiplicative order of G, and thus also 293 the size of the cryptographic subgroup of GF(p)* that is generated 294 by G. 296 This memo uses the following FFC Functions: 298 o Z = elem-op(X,Y) = (X * Y) mod p: two FFC elements, X and Y, are 299 multiplied modulo the prime, p, to produce another FFC element, Z. 300 This is the group operation for FFC groups. 302 o Z = scalar-op(x,Y) = Y^x mod p: an integer scalar, x, acts on an 303 FFC group element, Y, via exponentiation modulo the prime, p, to 304 produce another FFC element, Z. 306 o Y = inverse(X): a group element, X, has an inverse, Y, when the 307 product of the element and its inverse modulo the prime equals one 308 (1). In other words, (X * inverse(X)) mod p = 1. 310 o z = F(X): is the identity function since an element in an FFC 311 group is already an integer. It is included here for consistency 312 in the specification. 314 Many FFC groups used in IETF protocols are based on safe primes and 315 do not define an order (q). For these groups, the order (q) used in 316 this memo shall be the prime of the group minus one divided by two-- 317 (p-1)/2. 319 An integer can be validated as being an element in an FFC group by 320 checking whether: 1) it is between one (1) and the prime, p, 321 exclusive; and 2) if modular exponentiation of the integer by the 322 group order, q, equals one (1). If either of these conditions are 323 not true the integer is not an element in the group. 325 A compliant implementaiton of TLS-PWD SHOULD support group two- 326 hundred fifty-six (256) and group group two-hundred fifty-eight (258) 327 from [named_groups]. 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 OpaqueString profile of [RFC7613] and the salt SHALL be a 32 361 octet 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 defining extensions to 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 and generates an ephemeral public/private keypair. This keypair 442 SHALL only be used for username protection. For efficiency, the 443 domain parameter set used for userame protection MUST be based on 444 elliptic curve cryptography. Any ECC group that is approprate for 445 TLS-PWD (see Section 3.2.1) is suitable for this purpose but for 446 interoperability prime256v1 (aka NIST's p256 curve) MUST be 447 supported. The domain parameter set chosen for username protection 448 is independent of the domain parameter set chosen for the underlying 449 key exchange-- i.e. they need not be the same. 451 When the client's username and password are provisioned on the 452 server, the chosen group and its public key are provisioned on the 453 client. This is stored on the client along with the server-specific 454 state (e.g. the hostname) it uses to initiate a TLS-PWD exchange. 455 The server uses the same group and public key with all clients. 457 To protect a username, the client and server perform a static- 458 ephemeral Diffie-Hellman exchange. Since the y-coordinate is not 459 necessary and eliminating it will reduce message size, compact 460 representation (and therefore compact output, see [RFC6090]) are used 461 in the static-ephemeral Diffie-Hellman exchange. The result of the 462 Diffie-Hellman exchange is passed to HKDF [RFC5869] to create a key- 463 encrypting key suitable for AES-SIV [RFC5297] in its deterministic 464 authenticated encryption mode. The length of the key-encrypting key, 465 l, and the hash function to use with HKDF depends on the length of 466 the prime, p, of the group used to provide username protection: 468 o SHA-256, SIV-128, l=256 bits: when len(p) <= 256 470 o SHA-384, SIV-192, l=384 bits: when 256 < len(p) <= 384 472 o SHA-512, SIV-256, l=512 bits: when len(p) > 384 474 4.1.1. Construction of a Protected Username 476 Prior to initiating a TLS-PWD exchange, the client chooses a random 477 secret, c, such that 1 < c < (q-1), where q is the order of the group 478 from which the server's public key was generated, and uses scalar- 479 op() with the group's generator to create a public key, C. It uses 480 scalar-op() with the server's public key and c to create a shared 481 secret and derives a key-encrypting key, k, using the "salt-less" 482 mode of HKDF [RFC5869]. 484 C = scalar-op(c, G) 486 Z = scalar-op(c, S) 488 k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) 490 Where NULL indicates the salt-free invocation and "" indicates an 491 empty string (i.e. there is no "context" passed to HKDF). 493 The client's username SHALL be represented as a UTF-8 encoded 494 character string processed according to the rules of the OpaqueString 495 profile of [RFC7613]. The output of OpaqueString is then passed with 496 the key, k, to SIV-encrypt with no AAD and no nonce to produce an 497 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 To ensure the username remains confidential, the random secret, c, 512 MUST be generated from a source of random entropy, see section 513 Section 3.5. 515 The length of the ciphertext output from SIV, minus the synthetic 516 initialization vector, will be equal to the length of the input 517 plaintext, in this case the username. To further foil traffic 518 analysis, it is RECOMMENDED that clients append a series of NULL 519 bytes to their usernames prior to passing them to SIV-encrypt() such 520 that the resulting padded length of the username is at least 128 521 octets. 523 4.1.2. Recovery of a Protected Username 525 A server that receives a protected username needs to recover the 526 client's username prior to performing the key exchange. To do so, 527 the server computes the client's public key, completes the static- 528 ephemeral Diffie-Hellman exchange, derives the key encrypting key, k, 529 and decrypts the username. 531 The length of the x-coordinate of the client's public key is known 532 (it is the length of the prime from the domain parameter set used to 533 protect usernames) and can easily be separated from the ciphertext in 534 the PWD_name extension in the Client Hello-- the first len(p) bits 535 are the x-coordinate of the client's public key and the remaining 536 bits are the ciphertext. 538 Since compressed representation is used by the client, the server 539 MUST compute the y-coordinate of the client's public key by using the 540 equation of the curve: 542 y^2 = x^3 + ax + b 544 and solving for y. There are two solutions for y but since 545 compressed output is also being used, the selection is irrelevant. 546 The server reconstructs the client's public value, C, from (x, y). 547 If there is no solution for y, or if (x, y) is not a valid point on 548 the elliptic curve (see Section 3.2.1), the server MUST treat the 549 Client Hello as if it did not have a password for a given username 550 (see Section 4.3.1). 552 The server then uses scalar-op() with the reconstructed point C and 553 the private key it uses for protected passwords, s, to generate a 554 shared secret, and derives a key-encrypting key, k, in the same 555 manner as in Section 4.1.1. 557 Z = scalar-op(s, C) 559 k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) 561 The key, k, and the ciphertext portion of the PWD_name extension, u, 562 are passed to SIV-decrypt with no AAD and no nonce to produce the 563 username: 565 username = SIV-decrypt(k, u) 567 If SIV-decrypt returns the symbol FAIL indicating unsuccessful 568 decryption and verification the server MUST treat the ClientHello as 569 if it did not have a password for a given username (see 570 Section 4.3.1). If successful, the server has obtained the client's 571 username and can process it as needed. Any NULL octets added by the 572 client prior to encryption can be easily stripped off of the string 573 that represents the username. 575 4.2. Fixing the Password Element 577 Prior to making a "commitment" both sides must generate a secret 578 element, PE, in the chosen group using the common password-derived 579 base. The server generates PE after it receives the Client Hello and 580 chooses the particular group to use, and the client generates PE upon 581 receipt of the Server Key Exchange. 583 Fixing the password element involves an iterative "hunting and 584 pecking" technique using the prime from the negotiated group's domain 585 parameter set and an ECC- or FFC-specific operation depending on the 586 negotiated group. 588 To thwart side channel attacks which attempt to determine the number 589 of iterations of the "hunting-and-pecking" loop are used to find PE 590 for a given password, a security parameter, m, is used to ensure that 591 at least m iterations are always performed. 593 First, an 8-bit counter is set to the value one (1). Then, H is used 594 to generate a password seed from the a counter, the prime of the 595 selected group, and the base (which is derived from the username, 596 password, and salt): 598 pwd-seed = H(base | counter | p) 600 Then, using the technique from section B.5.1 of [FIPS186-3], the pwd- 601 seed is expanded using the PRF to the length of the prime from the 602 negotiated group's domain parameter set plus a constant sixty-four 603 (64) to produce an intermediate pwd-tmp which is modularly reduced to 604 create pwd-value: 606 n = len(p) + 64 607 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 608 ClientHello.random | ServerHello.random) [0..n]; 609 pwd-value = (pwd-tmp mod (p-1)) + 1 611 The pwd-value is then passed to the group-specific operation which 612 either returns the selected password element or fails. If the group- 613 specific operation fails, the counter is incremented, a new pwd-seed 614 is generated, and the hunting-and-pecking continues. This process 615 continues until the group-specific operation returns the password 616 element. After the password element has been chosen, the base is 617 changed to a random number, the counter is incremented and the 618 hunting-and-pecking continues until the counter is greater than the 619 security parameter, m. 621 The probability that one requires more than n iterations of the 622 "hunting and pecking" loop to find an ECC PE is roughly (q/2p)^n and 623 to find an FFC PE is roughly (q/p)^n, both of which rapidly approach 624 zero (0) as n increases. The security parameter, m, SHOULD be set 625 sufficiently large such that the probability that finding PE would 626 take more than m iterations is sufficiently small (see Section 8). 628 When PE has been discovered, pwd-seed, pwd-tmp, and pwd-value SHALL 629 be irretrievably destroyed. 631 4.2.1. Computing an ECC Password Element 633 The group-specific operation for ECC groups uses pwd-value, pwd-seed, 634 and the equation for the curve to produce PE. First, pwd-value is 635 used directly as the x-coordinate, x, with the equation for the 636 elliptic curve, with parameters a and b from the domain parameter set 637 of the curve, to solve for a y-coordinate, y. If there is no 638 solution to the quadratic equation, this operation fails and the 639 hunting-and-pecking process continues. If a solution is found, then 640 an ambiguity exists as there are technically two solutions to the 641 equation and pwd-seed is used to unambiguously select one of them. 642 If the low-order bit of pwd-seed is equal to the low-order bit of y, 643 then a candidate PE is defined as the point (x, y); if the low-order 644 bit of pwd-seed differs from the low-order bit of y, then a candidate 645 PE is defined as the point (x, p - y), where p is the prime over 646 which the curve is defined. The candidate PE becomes PE, a random 647 number is used instead of the base, and the hunting and pecking 648 continues until it has looped through m iterations, where m is a 649 suitably large number to prevent side channel attack (see [RFC7664]). 651 Algorithmically, the process looks like this: 653 found = 0 654 counter = 0 655 base = H(username | password | salt) 656 n = len(p) + 64 657 do { 658 counter = counter + 1 659 seed = H(base | counter | p) 660 tmp = PRF(seed, "TLS-PWD Hunting And Pecking", 661 ClientHello.random | ServerHello.random) [0..n] 662 val = (tmp mod (p-1)) + 1 663 if ( (val^3 + a*val + b) mod p is a quadratic residue) 664 then 665 if (found == 0) 666 then 667 x = val 668 save = seed 669 found = 1 670 base = random() 671 fi 672 fi 673 } while ((found == 0) || (counter <= m)) 674 y = sqrt(x^3 + a*x + b) mod p 675 if ( lsb(y) == lsb(save)) 676 then 677 PE = (x, y) 678 else 679 PE = (x, p-y) 680 fi 682 Figure 2: Fixing PE for ECC Groups 684 Checking whether a value is a quadradic residue modulo a prime can 685 leak information about that value in a side-channel attack. 686 Therefore, it is RECOMMENDED that the technique used to determine if 687 the value is a quadratic residue modulo p first blind the value with 688 a random number so that the blinded value can take on all numbers 689 between 1 and p-1 with equal probability. Determining the quadratic 690 residue in a fashion that resists leakage of information is handled 691 by flipping a coin and multiplying the blinded value by either a 692 random quadratic residue or a random quadratic nonresidue and 693 checking whether the multiplied value is a quadradic residue or a 694 quadradic nonresidue modulo p, respectively. The random residue and 695 nonresidue can be calculated prior to hunting-and-pecking by 696 calculating the legendre symbol on random values until they are 697 found: 699 do { 700 qr = random() 701 } while ( lgr(qr, p) != 1) 703 do { 704 qnr = random() 705 } while ( lgr(qnr, p) != -1) 707 Algorithmically, the masking technique to find out whether a value is 708 a quadratic residue modulo a prime or not looks like this: 710 is_quadratic_residue (val, p) { 711 r = (random() mod (p - 1)) + 1 712 num = (val * r * r) mod p 713 if ( lsb(r) == 1 ) 714 num = (num * qr) mod p 715 if ( lgr(num, p) == 1) 716 then 717 return TRUE 718 fi 719 else 720 num = (num * qnr) mod p 721 if ( lgr(num, p) == -1) 722 then 723 return TRUE 724 fi 725 fi 726 return FALSE 727 } 729 The random quadratic residue and quadratic non-residue (qr and qnr 730 above) can be used for all the hunting-and-pecking loops but the 731 blinding value, r, MUST be chosen randomly for each loop. 733 4.2.2. Computing an FFC Password Element 735 The group-specific operation for FFC groups takes pwd-value, and the 736 prime, p, and order, q, from the group's domain parameter set (see 737 Section 3.2.2 when the order is not part of the defined domain 738 parameter set) to directly produce a candidate password element, by 739 exponentiating the pwd-value to the value ((p-1)/q) modulo the prime. 740 If the result is greater than one (1), the candidate password element 741 becomes PE, and the hunting and pecking continues until it has looped 742 through m iterations, where m is a suitably large number to prevent 743 side channel attack (see [RFC7664]). 745 Algorithmically, the process looks like this: 747 found = 0 748 counter = 0 749 base = H(username | password | salt) 750 n = len(p) + 64 751 do { 752 counter = counter + 1 753 pwd-seed = H(base | counter | p) 754 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 755 ClientHello.random | ServerHello.random) [0..n] 756 pwd-value = (pwd-tmp mod (p-1)) + 1 757 PE = pwd-value ^ ((p-1)/q) mod p 758 if (PE > 1) 759 then 760 found = 1 761 base = random() 762 fi 763 } while ((found == 0) || (counter <= m)) 765 Figure 3: Fixing PE for FFC Groups 767 4.3. Changes to Handshake Message Contents 769 4.3.1. Client Hello Changes 771 The client is required to identify herself to the server by adding a 772 either a PWD_protect or PWD_clear extension to the Client Hello 773 message depending on whether the client wishes to protect its 774 username (see Section 4.1) or not, respectively. The PWD_protect and 775 PWD_clear extensions use the standard mechanism defined in [RFC5246]. 776 The "extension data" field of the PWD extension SHALL contain a 777 PWD_name which is used to identify the password shared between the 778 client and server. If username protection is performed, and the 779 ExtensionType is PWD_protect, the contents of the PWD_name SHALL be 780 constructed according to Section 4.1.1). 782 enum { PWD_clear(TBD1), PWD_protect(TBD2) } ExtensionType; 784 opaque PWD_name<1..2^8-1>; 786 An unprotected PWD_name SHALL be UTF-8 encoded character string 787 processed according to the rules of the OpaqueString profile of 788 [RFC7613] and a protected PWD_name SHALL be a string of bits. 790 A client offering a PWD ciphersuite MUST include one of the PWD_name 791 extensions in her Client Hello. 793 If a server does not have a password for a client identified by the 794 username either extracted from the PWD_name, if unprotected, or 795 recovered using the technique in Section 4.1.2, if protected, or if 796 recovery of a protected username fails, the server SHOULD hide that 797 fact by simulating the protocol-- putting random data in the PWD- 798 specific components of the Server Key Exchange-- and then rejecting 799 the client's finished message with a "bad_record_mac" alert. To 800 properly effect a simulated TLS-PWD exchange, an appropriate delay 801 SHOULD be inserted between receipt of the Client Hello and response 802 of the Server Hello. Alternately, a server MAY choose to terminate 803 the exchange if a password is not found. The security impliication 804 of terminating the exchange is to expose to an attacker whether a 805 username is valid or not. 807 The server decides on a group to use with the named user (see 808 Section 10 and generates the password element, PE, according to 809 Section 4.2.2. 811 4.3.2. Server Key Exchange Changes 813 The domain parameter set for the selected group MUST be explicitly 814 specified by name in the ServerKeyExchange. ECC roups are specified 815 using the NamedGroup enumeration of [RFC4492] and FFC groups are 816 specified using the NamedGroup extensions added by [RFC7919] and the 817 registry in [named_groups]. In addition to the group specification, 818 the ServerKeyExchange also contains the server's "commitment" in the 819 form of a scalar and element, and the salt which was used to store 820 the user's password. 822 Two new values have been added to the enumerated KeyExchangeAlgorithm 823 to indicate TLS-PWD using finite field cryptography, ff_pwd, and TLS- 824 PWD using elliptic curve cryptography, ec_pwd. 826 enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms; 828 struct { 829 opaque salt<1..2^8-1>; 830 NamedGroup ff_group; 831 opaque ff_selement<1..2^16-1>; 832 opaque ff_sscalar<1..2^16-1>; 833 } ServerFFPWDParams; 835 struct 836 opaque salt<1..2^8-1>; 837 ECParameters curve_params; 838 ECPoint ec_selement; 839 opaque ec_sscalar<1..2^8-1>; 840 } ServerECPWDParams; 842 struct { 843 select (KeyExchangeAlgorithm) { 844 case ec_pwd: 845 ServerECPWDParams params; 846 case ff_pwd: 847 ServerFFPWDParams params; 848 }; 849 } ServerKeyExchange; 851 4.3.2.1. Generation of ServerKeyExchange 853 The scalar and Element that comprise the server's "commitment" are 854 generated as follows. 856 First two random numbers, called private and mask, between zero and 857 the order of the group (exclusive) are generated. If their sum 858 modulo the order of the group, q, equals zero the numbers must be 859 thrown away and new random numbers generated. If their sum modulo 860 the order of the group, q, is greater than zero the sum becomes the 861 scalar. 863 scalar = (private + mask) mod q 865 The Element is then calculated as the inverse of the group's scalar 866 operation (see the group specific operations in Section 3.2) with the 867 mask and PE. 869 Element = inverse(scalar-op(mask, PE)) 871 After calculation of the scalar and Element the mask SHALL be 872 irretrievably destroyed. 874 4.3.2.1.1. ECC Server Key Exchange 876 EEC domain parameters are specified in the ECParameters component of 877 the EEC-specific ServerKeyExchange as defined in [RFC4492]. The 878 scalar SHALL become the ec_sscalar component and the Element SHALL 879 become the ec_selement of the ServerKeyExchange. If the client 880 requested a specific point format (compressed or uncompressed) with 881 the Support Point Formats Extension (see [RFC4492]) in its Client 882 Hello, the Element MUST be formatted in the ec_selement to conform to 883 that request. If the client offered (an) elliptic curve(s) in its 884 ClientHello using the Supported Elliptic Curves Extension, the server 885 MUST include (one of the) named curve(s) in the ECParameters field in 886 the ServerKeyExchange and the key exchange operations specified in 887 Section 4.3.2.1 MUST use that group. 889 As mentioned in Section 3.2.1, elliptic curves over GF(2^m), so 890 called characteristic-2 curves, and curves with a co-factor greater 891 than one (1) SHALL NOT be used with TLS-PWD. 893 4.3.2.1.2. FFC Server Key Exchange 895 FFC domain parameters using the NamedGroup extension specified in 896 [RFC7919]. The scalar SHALL become the ff_sscalar component and the 897 Element SHALL become the ff_selement in the FFC-specific 898 ServerKeyExchange. 900 As mentioned in Section 3.2.2 if the prime is a safe prime and no 901 order is included in the domain parameter set, the order added to the 902 ServerKeyExchange SHALL be the prime minus one divided by two-- 903 (p-1)/2. 905 4.3.2.2. Processing of ServerKeyExchange 907 Upon receipt of the ServerKeyExchange, the client decides whether to 908 support the indicated group or not. If the client decides to support 909 the indicated group the server's "commitment" MUST be validated by 910 ensuring that: 1) the server's scalar value is greater than zero (0) 911 and less than the order of the group, q; and 2) that the Element is 912 valid for the chosen group (see Section 3.2.2 and Section 3.2.1 for 913 how to determine whether an Element is valid for the particular 914 group. Note that if the Element is a compressed point on an elliptic 915 curve it MUST be uncompressed before checking its validity). 917 If the group is acceptable and the server's "commitment" has been 918 successfully validated, the client extracts the salt from the 919 ServerKeyExchange and generates the password element, PE, according 920 to Section 3.4 and Section 4.2.2. If the group is not acceptable or 921 the server's "commitment" failed validation, the exchange MUST be 922 aborted. 924 4.3.3. Client Key Exchange Changes 926 When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd, 927 the ClientKeyExchange is used to convey the client's "commitment" to 928 the server. It, therefore, contains a scalar and an Element. 930 struct { 931 opaque ff_celement<1..2^16-1>; 932 opaque ff_cscalar<1..2^16-1>; 933 } ClientFFPWDParams; 935 struct 936 ECPoint ec_celement; 937 opaque ec_cscalar<1..2^8-1>; 938 } ClientECPWDParams; 940 struct { 941 select (KeyExchangeAlgorithm) { 942 case ff_pwd: ClientFFPWDParams; 943 case ec_pwd: ClientECPWDParams; 944 } exchange_keys; 945 } ClientKeyExchange; 947 4.3.3.1. Generation of Client Key Exchange 949 The client's scalar and Element are generated in the manner described 950 in Section 4.3.2.1. 952 For an FFC group, the scalar SHALL become the ff_cscalar component 953 and the Element SHALL become the ff_celement in the FFC-specific 954 ClientKeyExchange. 956 For an ECC group, the scalar SHALL become the ec_cscalar component 957 and the ELement SHALL become the ec_celement in the ECC-specific 958 ClientKeyExchange. If the client requested a specific point format 959 (compressed or uncompressed) with the Support Point Formats Extension 960 in its ClientHello, then the Element MUST be formatted in the 961 ec_celement to conform to its initial request. 963 4.3.3.2. Processing of Client Key Exchange 965 Upon receipt of the ClientKeyExchange, the server must validate the 966 client's "commitment" by ensuring that: 1) the client's scalar and 967 element differ from the server's scalar and element; 2) the client's 968 scalar value is greater than zero (0) and less than the order of the 969 group, q; and 3) that the Element is valid for the chosen group (see 970 Section 3.2.2 and Section 3.2.1 for how to determine whether an 971 Element is valid for a particular group. Note that if the Element is 972 a compressed point on an elliptic curve it MUST be uncompressed 973 before checking its validity. If any of these three conditions are 974 not met the server MUST abort the exchange. 976 4.4. Computing the Premaster Secret 978 The client uses the server's scalar and Element, denoted here as 979 ServerKeyExchange.scalar and ServerKeyExchange.Element, and the 980 random private value, denoted here as client.private, she created as 981 part of the generation of her "commit" to compute an intermediate 982 value, z, as indicated: 984 z = F(scalar-op(client.private, 985 element-op(ServerKeyExchange.Element, 986 scalar-op(ServerKeyExchange.scalar, PE)))) 988 With the same notation as above, the server the client's scalar and 989 Element, and his random private value, denoted here as 990 server.private, he created as part of the generation of his "commit" 991 to compute the premaster secret as follows: 993 z = F(scalar-op(server.private, 994 element-op(ClientKeyExchange.Element, 995 scalar-op(ClientKeyExchange.scalar, PE)))) 997 The intermediate value, z, is then used as the premaster secret after 998 any leading bytes of z that contain all zero bits have been stripped 999 off. 1001 5. Ciphersuite Definition 1003 This memo adds the following ciphersuites: 1005 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 1007 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 1009 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 1011 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 1013 Implementations conforming to this specification MUST support the 1014 TLS_ECCPWD_WITH_AES_128_GCM_SHA256, ciphersuite; they SHOULD support 1015 the remaining ciphersuites. 1017 When negotiated with a version of TLS prior to 1.2, the Pseudo-Random 1018 Function (PRF) from that version is used; otherwise, the PRF is the 1019 TLS PRF [RFC5246] using the hash function indicated by the 1020 ciphersuite. Regardless of the TLS version, the TLS-PWD random 1021 function, H, is always instantiated with the hash algorithm indicated 1022 by the ciphersuite. 1024 For those ciphersuites that use Cipher Block Chaining (CBC) 1025 [SP800-38A] mode, the MAC is HMAC [RFC2104] with the hash function 1026 indicated by the ciphersuite. 1028 6. Acknowledgements 1030 The authenticated key exchange defined here has also been defined for 1031 use in 802.11 networks, as an EAP method, and as an authentication 1032 method for IKE. Each of these specifications has elicited very 1033 helpful comments from a wide collection of people that have allowed 1034 the definition of the authenticated key exchange to be refined and 1035 improved. 1037 The authors would like to thank Scott Fluhrer for discovering the 1038 "password as exponent" attack that was possible in an early version 1039 of this key exchange and for his very helpful suggestions on the 1040 techniques for fixing the PE to prevent it. The authors would also 1041 like to thank Hideyuki Suzuki for his insight in discovering an 1042 attack against a previous version of the underlying key exchange 1043 protocol. Special thanks to Lily Chen for helpful discussions on 1044 hashing into an elliptic curve. Rich Davis suggested the defensive 1045 checks that are part of the processing of the ServerKeyExchange and 1046 ClientKeyExchange messages, and his various comments have greatly 1047 improved the quality of this memo and the underlying key exchange on 1048 which it is based. 1050 Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik, discussed the 1051 possibility of a side-channel attack against the hunting-and-pecking 1052 loop on the TLS mailing list. That discussion prompted the addition 1053 of the security parameter, m, to the hunting-and-pecking loop. Scott 1054 Flurer suggested the blinding technique to test whether a value is a 1055 quadratic residue modulo a prime in a manner that does not leak 1056 information about the value being tested. 1058 7. IANA Considerations 1060 IANA SHALL assign two values for a new TLS extention type from the 1061 TLS ExtensionType Registry defined in [RFC5246] with the name 1062 "pwd_protect" and "pwd_clear". The RFC editor SHALL replace TBD1 and 1063 TBD2 in Section 4.3.1 with the IANA-assigned value for these 1064 extensions. 1066 IANA SHALL assign nine new ciphersuites from the TLS Ciphersuite 1067 Registry defined in [RFC5246] for the following ciphersuites: 1069 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 1071 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 1073 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 1075 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 1077 The RFC editor SHALL replace (TBD, TBD) in all the ciphersuites 1078 defined in Section 5 with the appropriate IANA-assigned values. The 1079 "DTLS-OK" column in the ciphersuite registry SHALL be set to "Y" and 1080 the "IETF Recommended" column SHALL be set to "N" for all 1081 ciphersuites defined in this memo. 1083 8. Security Considerations 1085 A security proof of this key exchange in the random oracle model is 1086 found in [lanskro]. 1088 A passive attacker against this protocol will see the 1089 ServerKeyExchange and the ClientKeyExchange containing the server's 1090 scalar and Element, and the client's scalar and Element, 1091 respectively. The client and server effectively hide their secret 1092 private value by masking it modulo the order of the selected group. 1093 If the order is "q", then there are approximately "q" distinct pairs 1094 of numbers that will sum to the scalar values observed. It is 1095 possible for an attacker to iterate through all such values but for a 1096 large value of "q", this exhaustive search technique is 1097 computationally infeasible. The attacker would have a better chance 1098 in solving the discrete logarithm problem, which we have already 1099 assumed (see Section 3.5) to be an intractable problem. 1101 A passive attacker can take the Element from either the 1102 ServerKeyExchange or the ClientKeyExchange and try to determine the 1103 random "mask" value used in its construction and then recover the 1104 other party's "private" value from the scalar in the same message. 1105 But this requires the attacker to solve the discrete logarithm 1106 problem which we assumed was intractable. 1108 Both the client and the server obtain a shared secret, the premaster 1109 secret, based on a secret group element and the private information 1110 they contributed to the exchange. The secret group element is based 1111 on the password. If they do not share the same password they will be 1112 unable to derive the same secret group element and if they don't 1113 generate the same secret group element they will be unable to 1114 generate the same premaster secret. Seeing a finished message along 1115 with the ServerKeyExchange and ClientKeyExchange will not provide any 1116 additional advantage of attack since it is generated with the 1117 unknowable premaster secret. 1119 An active attacker impersonating the client can induce a server to 1120 send a ServerKeyExchange containing the server's scalar and Element. 1121 It can attempt to generate a ClientKeyExchange and send to the server 1122 but the attacker is required to send a finished message first so the 1123 only information she can obtain in this attack is less than the 1124 information she can obtain from a passive attack, so this particular 1125 active attack is not very fruitful. 1127 An active attacker can impersonate the server and send a forged 1128 ServerKeyExchange after receiving the ClientHello. The attacker then 1129 waits until it receives the ClientKeyExchange and finished message 1130 from the client. Now the attacker can attempt to run through all 1131 possible values of the password, computing PE (see Section 4.2), 1132 computing candidate premaster secrets (see Section 4.4), and 1133 attempting to recreate the client's finished message. 1135 But the attacker committed to a single guess of the password with her 1136 forged ServerKeyExchange. That value was used by the client in her 1137 computation of the premaster secret which was used to produce the 1138 finished message. Any guess of the password which differs from the 1139 one used in the forged ServerKeyExchange would result in each side 1140 using a different PE in the computation of the premaster secret and 1141 therefore the finished message cannot be verified as correct, even if 1142 a subsequent guess, while running through all possible values, was 1143 correct. The attacker gets one guess, and one guess only, per active 1144 attack. 1146 Instead of attempting to guess at the password, an attacker can 1147 attempt to determine PE and then launch an attack. But PE is 1148 determined by the output of the random function, H, which is 1149 indistinguishable from a random source since H is assumed to be a 1150 "random oracle" (Section 3.5). Therefore, each element of the finite 1151 cyclic group will have an equal probability of being the PE. The 1152 probability of guessing PE will be 1/q, where q is the order of the 1153 group. For a large value of "q" this will be computationally 1154 infeasible. 1156 The implications of resistance to dictionary attack are significant. 1157 An implementation can provision a password in a practical and 1158 realistic manner-- i.e. it MAY be a character string and it MAY be 1159 relatively short-- and still maintain security. The nature of the 1160 pool of potential passwords determines the size of the pool, D, and 1161 countermeasures can prevent an attacker from determining the password 1162 in the only possible way: repeated, active, guessing attacks. For 1163 example, a simple four character string using lower-case English 1164 characters, and assuming random selection of those characters, will 1165 result in D of over four hundred thousand. An attacker would need to 1166 mount over one hundred thousand active, guessing attacks (which will 1167 easily be detected) before gaining any significant advantage in 1168 determining the pre-shared key. 1170 Countermeasures to deal with successive active, guessing attacks are 1171 only possible by noticing a certain username is failing repeatedly 1172 over a certain period of time. Attacks which attempt to find a 1173 password for a random user are more difficult to detect. For 1174 instance, if a device uses a serial number as a username and the pool 1175 of potential passwords is sufficiently small, a more effective attack 1176 would be to select a password and try all potential "users" to 1177 disperse the attack and confound countermeasures. It is therefore 1178 RECOMMENDED that implementations of TLS-PWD keep track of the total 1179 number of failed authentications regardless of username in an effort 1180 to detect and thwart this type of attack. 1182 The benefits of resistance to dictionary attack can be lessened by a 1183 client using the same passwords with multiple servers. An attacker 1184 could re-direct a session from one server to the other if the 1185 attacker knew that the intended server stored the same password for 1186 the client as another server. 1188 An adversary that has access to, and a considerable amount of control 1189 over, a client or server could attempt to mount a side-channel attack 1190 to determine the number of times it took for a certain password (plus 1191 client random and server random) to select a password element. Each 1192 such attack could result in a successive paring-down of the size of 1193 the pool of potential passwords, resulting in a manageably small set 1194 from which to launch a series of active attacks to determine the 1195 password. A security parameter, m, is used to normalize the amount 1196 of work necessary to determine the password element (see 1197 Section 4.2). The probability that a password will require more than 1198 m iterations is roughly (q/2p)^m for ECC groups and (q/p)^m for FFC 1199 groups, so it is possible to mitigate side channel attack at the 1200 expense of a constant cost per connection attempt. But if a 1201 particular password requires more than k iterations it will leak k 1202 bits of information to the side-channel attacker, which for some 1203 dictionaries will uniquely identify the password. Therefore, the 1204 security parameter, m, needs to be set with great care. It is 1205 RECOMMENDED that an implementation set the security parameter, m, to 1206 a value of at least forty (40) which will put the probability that 1207 more than forty iterations are needed in the order of one in one 1208 trillion (1:1,000,000,000,000). 1210 The server uses a database of salted passwords. While this will 1211 prevent an adversary who gains access to the database from learning 1212 the client's password, it does not prevent such an adversary from 1213 impersonating the client back to the server. Each side uses the 1214 salted password, called the base, as the authenticaiton credential so 1215 the database of salted passwords MUST be afforded the security of a 1216 database of plaintext passwords. 1218 Authentication is performed by proving knowledge of the password. 1219 Any third party that knows the password shared by the client and 1220 server can impersonate one to the other. 1222 The static-ephemeral Diffie-Hellman exchange used to protect 1223 usernames requires the server to reuse its Diffie-Hellman public key. 1224 To prevent an invalid curve attack, an entity that reuses its Diffie- 1225 Hellman public key needs to check whether the received ephemeral 1226 public key is actually a point on the curve. This is done explicitly 1227 as part of the server's reconstruction of the client's public key out 1228 of only its x-coordinate ("compact representation"). 1230 9. Human Rights Considerations 1232 At the time of publication, there was a growing interest in 1233 considering the human rights impact of IETF (and IRTF) work. As 1234 such, the Human Rights Considerations of TLS-PWD are presented. 1236 The key exchange underlying TLS-PWD uses public key cryptography to 1237 perform authentication and authenticated key exchange. The keys it 1238 produces can be used to establish secure connections between two 1239 people to protect their communication. Implementations of TLS-PWD, 1240 like implementations of other TLS ciphersuites that perform 1241 authentication and authenticted key establishment, are considered 1242 'armaments' or 'munitions' by many governments around the world. 1244 The most fundamental of Human Rights is the right to protect oneself. 1245 The right to keep and bear arms is an example of this right. 1246 Implementations of TLS-PWD can be used as arms, kept and borne, to 1247 defend oneself against all manner of attackers-- criminals, 1248 governments, laywers, etc. TLS-PWD is a powerful tool in the 1249 promotion and defense of Universal Human Rights. 1251 10. Implementation Considerations 1253 The selection of the ciphersuite and selection of the particular 1254 finite cyclic group to use with the ciphersuite are divorced in this 1255 memo but they remain intimately close. 1257 It is RECOMMENDED that implementations take note of the strength 1258 estimates of particular groups and to select a ciphersuite providing 1259 commensurate security with its hash and encryption algorithms. A 1260 ciphersuite whose encryption algorithm has a keylength less than the 1261 strength estimate, or whose hash algorithm has a blocksize that is 1262 less than twice the strength estimate SHOULD NOT be used. 1264 For example, the elliptic curve named brainpoolP256r1 (whose IANA- 1265 assigned number is 26) provides an estimated 128 bits of strength and 1266 would be compatible with an encryption algorithm supporting a key of 1267 that length, and a hash algorithm that has at least a 256-bit 1268 blocksize. Therefore, a suitable ciphersuite to use with 1269 brainpoolP256r1 could be TLS_ECCPWD_WITH_AES_128_GCM_SHA256 (see 1270 Appendix A for an example of such an exchange). 1272 Resistance to dictionary attack means that the attacker must launch 1273 an active attack to make a single guess at the password. If the size 1274 of the pool from which the password was extracted was D, and each 1275 password in the pool has an equal probability of being chosen, then 1276 the probability of success after a single guess is 1/D. After X 1277 guesses, and removal of failed guesses from the pool of possible 1278 passwords, the probability becomes 1/(D-X). As X grows so does the 1279 probability of success. Therefore it is possible for an attacker to 1280 determine the password through repeated brute-force, active, guessing 1281 attacks. Implementations SHOULD take note of this fact and choose an 1282 appropriate pool of potential passwords-- i.e. make D big. 1283 Implementations SHOULD also take countermeasures, for instance 1284 refusing authentication attempts by a particular username for a 1285 certain amount of time, after the number of failed authentication 1286 attempts reaches a certain threshold. No such threshold or amount of 1287 time is recommended in this memo. 1289 11. References 1291 11.1. Normative References 1293 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1294 Hashing for Message Authentication", RFC 2104, DOI 1295 10.17487/RFC2104, February 1997, 1296 . 1298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1299 Requirement Levels", BCP 14, RFC 2119, March 1997. 1301 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1302 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1303 for Transport Layer Security (TLS)", RFC 4492, DOI 1304 10.17487/RFC4492, May 2006, 1305 . 1307 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1308 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1309 RFC5246, August 2008, 1310 . 1312 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 1313 Authenticated Encryption Using the Advanced Encryption 1314 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 1315 2008, . 1317 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1318 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 1319 RFC5869, May 2010, 1320 . 1322 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 1323 Enforcement, and Comparison of Internationalized Strings 1324 Representing Usernames and Passwords", RFC 7613, DOI 1325 10.17487/RFC7613, August 2015, 1326 . 1328 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 1329 Ephemeral Parameters for Transport Layer Security (TLS)", 1330 RFC 7919, DOI 10.17487/RFC7919, August 2016, 1331 . 1333 [named_groups] 1334 IANA, "TLS Supported Groups Registry", 1335 . 1338 11.2. Informative References 1340 [FIPS186-3] 1341 National Institute of Standards and Technology, "Digital 1342 Signature Standard (DSS)", Federal Information Processing 1343 Standards Publication 186-3, . 1345 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 1346 A Paradigm for Designing Efficient Protocols", Proceedings 1347 of the 1st ACM Conference on Computer and Communication 1348 Security, ACM Press, 1993. 1350 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1351 "Randomness Requirements for Security", BCP 106, RFC 4086, 1352 DOI 10.17487/RFC4086, June 2005, 1353 . 1355 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1356 Curve Cryptography Algorithms", RFC 6090, February 2011. 1358 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1359 "Enrollment over Secure Transport", RFC 7030, DOI 1360 10.17487/RFC7030, October 2013, 1361 . 1363 [RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 1364 10.17487/RFC7664, November 2015, 1365 . 1367 [SP800-38A] 1368 National Institute of Standards and Technology, 1369 "Recommendation for Block Cipher Modes of Operation-- 1370 Methods and Techniques", NIST Special Publication 800-38A, 1371 December 2001. 1373 [SP800-56A] 1374 Barker, E., Johnson, D., and M. Smid, "Recommendations for 1375 Pair-Wise Key Establishment Schemes Using Discrete 1376 Logarithm Cryptography", NIST Special Publication 800-56A, 1377 March 2007. 1379 [lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of 1380 the Dragonfly Protocol", Proceedings of 18th International 1381 Information Security Conference (ISC 2015), pp 244-261, 1382 DOI 10.1007/978-3-319-23318-5_14, September 2015. 1384 Appendix A. Example Exchange 1386 (Note: at the time of publication of this memo ciphersuites have 1387 not yet been assigned by IANA and the exchange that follows uses 1388 the private numberspace). 1390 username: fred 1391 password: barney 1393 ---- prior to running TLS-PWD ---- 1395 server generates salt: 1397 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 1398 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 1400 and a base: 1402 6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 1403 c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75 1405 ---- state derived during the TLS-PWD exchange ---- 1407 client and server agree to use brainpoolP256r1 1409 client and server generate PE: 1411 PE.x: 1412 29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 1413 a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6 1415 server private and mask: 1417 private: 1418 21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b 1419 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c 1420 mask: 1421 0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f 1422 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5 1424 client private and mask: 1426 private: 1427 17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f 1428 a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b 1429 mask: 1430 4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88 1431 83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd 1433 both parties generate pre-master secret and master secret 1435 pre-master secret: 1436 01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11 1437 af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4 1438 master secret: 1439 65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1 1440 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f 1441 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad 1443 ---- ssldump output of exchange ---- 1445 New TCP connection #1: Charlene Client <-> Sammy Server 1446 1 1 0.0018 (0.0018) C>SV3.3(173) Handshake 1447 ClientHello 1448 Version 3.3 1449 random[32]= 1450 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 1451 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d 1452 cipher suites 1453 TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV 1454 TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV 1455 Unknown value 0xff 1456 compression methods 1457 NULL 1458 extensions 1459 TLS-PWD unprotected name[5]= 1460 04 66 72 65 64 1461 elliptic curve point format[4]= 1462 03 00 01 02 1463 elliptic curve list[58]= 1464 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 1465 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 1466 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 1467 00 02 00 03 00 0f 00 10 00 11 1468 Packet data[178]= 1469 16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17 1470 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf 1471 a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3 1472 ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65 1473 64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00 1474 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 1475 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 1476 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 1477 03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06 1478 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 1479 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 1480 01 01 1482 1 2 0.0043 (0.0024) S>CV3.3(94) Handshake 1483 ServerHello 1484 Version 3.3 1485 random[32]= 1486 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 1487 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa 1488 session_id[32]= 1489 ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 1490 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 1491 cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV 1492 compressionMethod NULL 1493 extensions 1494 renegotiate[1]= 1495 00 1496 elliptic curve point format[4]= 1497 03 00 01 02 1498 heartbeat[1]= 1499 01 1500 Packet data[99]= 1501 16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43 1502 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 1503 ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08 1504 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 1505 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00 1506 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f 1507 00 01 01 1509 1 3 0.0043 (0.0000) S>CV3.3(141) Handshake 1510 ServerKeyExchange 1511 params 1512 salt[32]= 1513 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 1514 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 1515 EC parameters = 3 1516 curve id = 26 1517 element[65]= 1518 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 1519 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee 1520 f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 1521 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db 1522 e1 1523 scalar[32]= 1524 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a 1525 df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21 1526 Packet data[146]= 1527 16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1 1528 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 1529 47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04 1530 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 1531 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 1532 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 1533 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 1534 00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 1535 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 1536 49 21 1538 1 4 0.0043 (0.0000) S>CV3.3(4) Handshake 1539 ServerHelloDone 1541 Packet data[9]= 1542 16 03 03 00 04 0e 00 00 00 1544 1 5 0.0086 (0.0043) C>SV3.3(104) Handshake 1545 ClientKeyExchange 1546 element[65]= 1547 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 1548 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 1549 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 1550 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd 1551 a0 1552 scalar[32]= 1553 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 1554 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 1555 Packet data[109]= 1556 16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b 1557 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 1558 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd 1559 d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf 1560 e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44 1561 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 1562 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 1564 1 6 0.0086 (0.0000) C>SV3.3(1) ChangeCipherSpec 1565 Packet data[6]= 1566 14 03 03 00 01 01 1568 1 7 0.0086 (0.0000) C>SV3.3(40) Handshake 1569 Packet data[45]= 1570 16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7 1571 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a 1572 0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20 1574 1 8 0.0105 (0.0018) S>CV3.3(1) ChangeCipherSpec 1575 Packet data[6]= 1576 14 03 03 00 01 01 1578 1 9 0.0105 (0.0000) S>CV3.3(40) Handshake 1579 Packet data[45]= 1580 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c 1581 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 1582 a2 21 94 90 12 72 23 18 24 21 c3 60 a4 1584 1 10 0.0107 (0.0002) C>SV3.3(100) application_data 1585 Packet data.... 1587 Author's Address 1589 Dan Harkins (editor) 1590 HP Enterprise 1591 3333 Scott blvd 1592 Santa Clara, CA 95054 1593 United States of America 1595 Email: dharkins@lounge.org