idnits 2.17.1 draft-harkins-tls-dragonfly-01.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 (February 28, 2017) is 2608 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 February 28, 2017 5 Expires: September 1, 2017 7 Secure Password Ciphersuites for Transport Layer Security (TLS) 8 draft-harkins-tls-dragonfly-01 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 September 1, 2017. 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 . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 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. 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 (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]. Ciphersuites defined in this memo SHALL only use ECC 229 curves based on the Weierstrass equation y^2 = x^3 + a*x + b. 231 Domain parameters for the ECC groups used by this memo are: 233 o A prime, p, determining a prime field GF(p). The cryptographic 234 group will be a subgroup of the full elliptic curve group which 235 consists points on an elliptic curve-- elements from GF(p) that 236 satisfy the curve's equation-- together with the "point at 237 infinity" that serves as the identity element. 239 o Elements a and b from GF(p) that define the curve's equation. The 240 point (x,y) in GF(p) x GF(p) is on the elliptic curve if and only 241 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 243 o A point, G, on the elliptic curve, which serves as a generator for 244 the ECC group. G is chosen such that its order, with respect to 245 elliptic curve addition, is a sufficiently large prime. 247 o A prime, q, which is the order of G, and thus is also the size of 248 the cryptographic subgroup that is generated by G. 250 o A co-factor, f, defined by the requirement that the size of the 251 full elliptic curve group (including the "point at infinity") is 252 the product of f and q. 254 This memo uses the following ECC Functions: 256 o Z = elem-op(X,Y) = X + Y: two points on the curve X and Y, are 257 sumed to produce another point on the curve, Z. This is the group 258 operation for ECC groups. 260 o Z = scalar-op(x,Y) = x * Y: an integer scalar, x, acts on a point 261 on the curve, Y, via repetitive addition (Y is added to itself x 262 times), to produce another EEC element, Z. 264 o Y = inverse(X): a point on the curve, X, has an inverse, Y, which 265 is also a point on the curve, when their sum is the "point at 266 infinity" (the identity for elliptic curve addition). In other 267 words, R + inverse(R) = "0". 269 o z = F(X): the x-coordinate of a point (x, y) on the curve is 270 returned. This is a mapping function to convert a group element 271 into an integer. 273 Only ECC groups over GF(p) can be used with TLS-PWD. ECC groups over 274 GF(2^m) SHALL NOT be used by TLS-PWD. In addition, ECC groups with a 275 co-factor greater than one (1) SHALL NOT be used by TLS-PWD. 277 A composite (x, y) pair can be validated as a point on the elliptic 278 curve by checking whether: 1) both coordinates x and y are greater 279 than zero (0) and less than the prime defining the underlying field; 280 2) the x- and y- coordinates satisfy the equation of the curve; and 281 3) they do not represent the point-at-infinity "0". If any of those 282 conditions are not true the (x, y) pair is not a valid point on the 283 curve. 285 3.2.2. Finite Field Cryptography 287 Domain parameters for the FFC groups used by this memo are: 289 o A prime, p, determining a prime field GF(p), the integers modulo 290 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 291 group of non-zero elements in GF(p). 293 o An element, G, in GF(p)* which serves as a generator for the FFC 294 group. G is chosen such that its multiplicative order is a 295 sufficiently large prime divisor of ((p-1)/2). 297 o A prime, q, which is the multiplicative order of G, and thus also 298 the size of the cryptographic subgroup of GF(p)* that is generated 299 by G. 301 This memo uses the following FFC Functions: 303 o Z = elem-op(X,Y) = (X * Y) mod p: two FFC elements, X and Y, are 304 multiplied modulo the prime, p, to produce another FFC element, Z. 305 This is the group operation for FFC groups. 307 o Z = scalar-op(x,Y) = Y^x mod p: an integer scalar, x, acts on an 308 FFC group element, Y, via exponentiation modulo the prime, p, to 309 produce another FFC element, Z. 311 o Y = inverse(X): a group element, X, has an inverse, Y, when the 312 product of the element and its inverse modulo the prime equals one 313 (1). In other words, (X * inverse(X)) mod p = 1. 315 o z = F(X): is the identity function since an element in an FFC 316 group is already an integer. It is included here for consistency 317 in the specification. 319 Many FFC groups used in IETF protocols are based on safe primes and 320 do not define an order (q). For these groups, the order (q) used in 321 this memo shall be the prime of the group minus one divided by two-- 322 (p-1)/2. 324 An integer can be validated as being an element in an FFC group by 325 checking whether: 1) it is between one (1) and the prime, p, 326 exclusive; and 2) if modular exponentiation of the integer by the 327 group order, q, equals one (1). If either of these conditions are 328 not true the integer is not an element in the group. 330 3.3. Instantiating the Random Function 332 The protocol described in this memo uses a random function, H, which 333 is modeled as a "random oracle". At first glance, one may view this 334 as a hash function. As noted in [RANDOR], though, hash functions are 335 too structured to be used directly as a random oracle. But they can 336 be used to instantiate the random oracle. 338 The random function, H, in this memo is instantiated by using the 339 hash algorithm defined by the particular TLS-PWD ciphersuite in HMAC 340 mode with a key whose length is equal to block size of the hash 341 algorithm and whose value is zero. For example, if the ciphersuite 342 is TLS_ECCPWD_WITH_AES_128_GCM_SHA256 then H will be instantiated 343 with SHA256 as: 345 H(x) = HMAC-SHA256([0]32, x) 347 3.4. Passwords 349 The authenticated key exchange used in TLS-PWD requires each side to 350 have a common view of a shared credential. To protect the server's 351 database of stored passwords, though, the password SHALL be salted 352 and the result, called the base, SHALL be used as the authentication 353 credential. 355 The salting function is defined as: 357 base = HMAC-SHA256(salt, username | password) 359 The password used for generation of the base SHALL be represented as 360 a UTF-8 encoded character string processed according to the rules of 361 the OpaqueString profile of [RFC7613] and the salt SHALL be a 32 362 octet random number. The server SHALL store a triplet of the form: 364 { username, base, salt } 366 And the client SHALL generate the base upon receiving the salt from 367 the server. 369 3.5. Assumptions 371 The security properties of the authenticated key exchange defined in 372 this memo are based on a number of assumptions: 374 1. The random function, H, is a "random oracle" as defined in 375 [RANDOR]. 377 2. The discrete logarithm problem for the chosen group is hard. 378 That is, given g, p, and y = g^x mod p, it is computationally 379 infeasible to determine x. Similarly, for an ECC group given the 380 curve definition, a generator G, and Y = x * G, it is 381 computationally infeasible to determine x. 383 3. Quality random numbers with sufficient entropy can be created. 384 This may entail the use of specialized hardware. If such 385 hardware is unavailable a cryptographic mixing function (like a 386 strong hash function) to distill enropy from multiple, 387 uncorrelated sources of information and events may be needed. A 388 very good discussion of this can be found in [RFC4086]. 390 If the server supports username protection (see Section 4.1), it is 391 assumed that the server has chosen a domain parameter set and 392 generated a username-protection keypair. The chosen domain parameter 393 set and public key are assumed to be conveyed to the client at the 394 time the client's username and password were provisioned. 396 4. Specification of the TLS-PWD Handshake 398 The key exchange underlying TLS-PWD is the "dragonfly" PAKE as 399 defined in [RFC7664]. 401 The authenticated key exchange is accomplished by each side deriving 402 a password-based element, PE, in the chosen group, making a 403 "commitment" to a single guess of the password using PE, and 404 generating the Premaster Secret. The ability of each side to produce 405 a valid finished message authenticates itself to the other side. 407 The authenticated key exchange is dropped into the standard TLS 408 message handshake by defining extensions to some of the messages. 410 Client Server 411 -------- -------- 413 Client Hello (name) --------> 415 Server Hello 416 Server Key Exchange (commit) 417 <-------- Server Hello Done 419 Client Key Exchange (commit) 420 [Change cipher spec] 421 Finished --------> 423 [Change cipher spec] 424 <-------- Finished 426 Application Data <-------> Application Data 428 Figure 1 430 4.1. Protecting the Username 432 The client is required to identify herself to the server before the 433 server can look up the appropriate client credential with which to 434 perform the authenticated key exchange. This has negative privacy 435 implicaitons and opens up the client to tracking and increased 436 monitoring. It is therefore useful for the client to be able to 437 protect her username from passive monitors of the exchange and 438 against active attack by a malicious server. TLS-PWD provides such a 439 mechsnism. Support for protected usernames is RECOMMENDED. 441 To enable username protection a server choses a domain parameter set 442 and generates an ephemeral public/private keypair. This keypair 443 SHALL only be used for username protection. For efficiency, the 444 domain parameter set used for userame protection MUST be based on 445 elliptic curve cryptography. Any ECC group that is approprate for 446 TLS-PWD (see Section 3.2.1) is suitable for this purpose but for 447 interoperability prime256v1 (aka NIST's p256 curve) MUST be 448 supported. The domain parameter set chosen for username protection 449 is independent of the domain parameter set chosen for the underlying 450 key exchange-- i.e. they need not be the same. 452 When the client's username and password are provisioned on the 453 server, the chosen group and its public key are provisioned on the 454 client. This is stored on the client along with the server-specific 455 state (e.g. the hostname) it uses to initiate a TLS-PWD exchange. 456 The server uses the same group and public key with all clients. 458 To protect a username, the client and server perform a static- 459 ephemeral Diffie-Hellman exchange. Since the y-coordinate is not 460 necessary and eliminating it will reduce message size, compact 461 representation (and therefore compact output, see [RFC6090]) are used 462 in the static-ephemeral Diffie-Hellman exchange. The result of the 463 Diffie-Hellman exchange is passed to HKDF [RFC5869] to create a key- 464 encrypting key suitable for AES-SIV [RFC5297] in its deterministic 465 authenticated encryption mode. The length of the key-encrypting key, 466 l, and the hash function to use with HKDF depends on the length of 467 the prime, p, of the group used to provide username protection: 469 o SHA-256, SIV-128, l=256 bits: when len(p) <= 256 471 o SHA-384, SIV-192, l=384 bits: when 256 < len(p) <= 384 473 o SHA-512, SIV-256, l=512 bits: when len(p) > 384 475 4.1.1. Construction of a Protected Username 477 Prior to initiating a TLS-PWD exchange, the client chooses a random 478 secret, c, such that 1 < c < (q-1), where q is the order of the group 479 from which the server's public key was generated, and uses scalar- 480 op() with the group's generator to create a public key, C. It uses 481 scalar-op() with the server's public key and c to create a shared 482 secret and derives a key-encrypting key, k, using the "salt-less" 483 mode of HKDF [RFC5869]. 485 C = scalar-op(c, G) 487 Z = scalar-op(c, S) 489 k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) 491 Where NULL indicates the salt-free invocation and "" indicates an 492 empty string (i.e. there is no "context" passed to HKDF). 494 The client's username SHALL be represented as a UTF-8 encoded 495 character string processed according to the rules of the OpaqueString 496 profile of [RFC7613]. The output of OpaqueString is then passed with 497 the key, k, to SIV-encrypt with no AAD and no nonce to produce an 498 encrypted username, u: 500 u = SIV-encrypt(k, username) 502 Note: the format of the ciphertext output from SIV includes the 503 authenticating synthetic initialization vector. 505 The protected username SHALL be the concatenation of the x-coordinate 506 of the client's public key, C, and the encrypted username, u. The 507 length of the x-coordinate of C MUST be equal to the length of the 508 group's prime, p, pre-pended with zeros, if necessary. The protected 509 username is inserted into the PWD_name extension and the 510 ExtensionType MUST be PWD_protect (see Section 4.3.1). 512 The length of the ciphertext output from SIV, minus the synthetic 513 initialization vector, will be equal to the length of the input 514 plaintext, in this case the username. To further foil traffic 515 analysis, it is RECOMMENDED that clients append a series of NULL 516 bytes to their usernames prior to passing them to SIV-encrypt() such 517 that the resulting padded length of the username is at least 128 518 octets. 520 4.1.2. Recovery of a Protected Username 522 A server that receives a protected username needs to recover the 523 client's username prior to performing the key exchange. To do so, 524 the server computes the client's public key, completes the static- 525 ephemeral Diffie-Hellman exchange, derives the key encrypting key, k, 526 and decrypts the username. 528 The length of the x-coordinate of the client's public key is known 529 (it is the length of the prime from the domain parameter set used to 530 protect usernames) and can easily be separated from the ciphertext in 531 the PWD_name extension in the Client Hello-- the first len(p) bits 532 are the x-coordinate of the client's public key and the remaining 533 bits are the ciphertext. 535 Since compressed representation is used by the client, the server 536 MUST compute the y-coordinate of the client's public key by using the 537 equation of the curve: 539 y^2 = x^3 + ax + b 541 and solving for y. There are two solutions for y but since 542 compressed output is also being used, the selection is irrelevant. 543 The server reconstructs the client's public value, C, from (x, y). 544 If there is no solution for y, or if (x, y) is not a valid point on 545 the elliptic curve (see Section 3.2.1), the server MUST treat the 546 Client Hello as if it did not have a password for a given username 547 (see Section 4.3.1). 549 The server then uses scalar-op() with the reconstructed point C and 550 the private key it uses for protected passwords, s, to generate a 551 shared secret, and derives a key-encrypting key, k, in the same 552 manner as in Section 4.1.1. 554 Z = scalar-op(s, C) 556 k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) 558 The key, k, and the ciphertext portion of the PWD_name extension, u, 559 are passed to SIV-decrypt with no AAD and no nonce to produce the 560 username: 562 username = SIV-decrypt(k, u) 564 If SIV-decrypt returns the symbol FAIL indicating unsuccessful 565 decryption and verification the server MUST treat the ClientHello as 566 if it did not have a password for a given username (see 567 Section 4.3.1). If successful, the server has obtained the client's 568 username and can process it as needed. Any NULL octets added by the 569 client prior to encryption can be easily stripped off of the string 570 that represents the username. 572 4.2. Fixing the Password Element 574 Prior to making a "commitment" both sides must generate a secret 575 element, PE, in the chosen group using the common password-derived 576 base. The server generates PE after it receives the Client Hello and 577 chooses the particular group to use, and the client generates PE upon 578 receipt of the Server Key Exchange. 580 Fixing the password element involves an iterative "hunting and 581 pecking" technique using the prime from the negotiated group's domain 582 parameter set and an ECC- or FFC-specific operation depending on the 583 negotiated group. 585 To thwart side channel attacks which attempt to determine the number 586 of iterations of the "hunting-and-pecking" loop are used to find PE 587 for a given password, a security parameter, m, is used to ensure that 588 at least m iterations are always performed. 590 First, an 8-bit counter is set to the value one (1). Then, H is used 591 to generate a password seed from the a counter, the prime of the 592 selected group, and the base (which is derived from the username, 593 password, and salt): 595 pwd-seed = H(base | counter | p) 597 Then, using the technique from section B.5.1 of [FIPS186-3], the pwd- 598 seed is expanded using the PRF to the length of the prime from the 599 negotiated group's domain parameter set plus a constant sixty-four 600 (64) to produce an intermediate pwd-tmp which is modularly reduced to 601 create pwd-value: 603 n = len(p) + 64 604 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 605 ClientHello.random | ServerHello.random) [0..n]; 606 pwd-value = (pwd-tmp mod (p-1)) + 1 608 The pwd-value is then passed to the group-specific operation which 609 either returns the selected password element or fails. If the group- 610 specific operation fails, the counter is incremented, a new pwd-seed 611 is generated, and the hunting-and-pecking continues. This process 612 continues until the group-specific operation returns the password 613 element. After the password element has been chosen, the base is 614 changed to a random number, the counter is incremented and the 615 hunting-and-pecking continues until the counter is greater than the 616 security parameter, m. 618 The probability that one requires more than n iterations of the 619 "hunting and pecking" loop to find an ECC PE is roughly (q/2p)^n and 620 to find an FFC PE is roughly (q/p)^n, both of which rapidly approach 621 zero (0) as n increases. The security parameter, m, SHOULD be set 622 sufficiently large such that the probability that finding PE would 623 take more than m iterations is sufficiently small (see Section 8). 625 When PE has been discovered, pwd-seed, pwd-tmp, and pwd-value SHALL 626 be irretrievably destroyed. 628 4.2.1. Computing an ECC Password Element 630 The group-specific operation for ECC groups uses pwd-value, pwd-seed, 631 and the equation for the curve to produce PE. First, pwd-value is 632 used directly as the x-coordinate, x, with the equation for the 633 elliptic curve, with parameters a and b from the domain parameter set 634 of the curve, to solve for a y-coordinate, y. If there is no 635 solution to the quadratic equation, this operation fails and the 636 hunting-and-pecking process continues. If a solution is found, then 637 an ambiguity exists as there are technically two solutions to the 638 equation and pwd-seed is used to unambiguously select one of them. 639 If the low-order bit of pwd-seed is equal to the low-order bit of y, 640 then a candidate PE is defined as the point (x, y); if the low-order 641 bit of pwd-seed differs from the low-order bit of y, then a candidate 642 PE is defined as the point (x, p - y), where p is the prime over 643 which the curve is defined. The candidate PE becomes PE, a random 644 number is used instead of the base, and the hunting and pecking 645 continues until it has looped through m iterations. 647 Algorithmically, the process looks like this: 649 found = 0 650 counter = 0 651 base = H(username | password | salt) 652 n = len(p) + 64 653 do { 654 counter = counter + 1 655 seed = H(base | counter | p) 656 tmp = PRF(seed, "TLS-PWD Hunting And Pecking", 657 ClientHello.random | ServerHello.random) [0..n] 658 val = (tmp mod (p-1)) + 1 659 if ( (val^3 + a*val + b) mod p is a quadratic residue) 660 then 661 if (found == 0) 662 then 663 x = val 664 save = seed 665 found = 1 666 base = random() 667 fi 668 fi 669 } while ((found == 0) || (counter <= m)) 670 y = sqrt(x^3 + a*x + b) mod p 671 if ( lsb(y) == lsb(save)) 672 then 673 PE = (x, y) 674 else 675 PE = (x, p-y) 676 fi 678 Figure 2: Fixing PE for ECC Groups 680 Checking whether a value is a quadradic residue modulo a prime can 681 leak information about that value in a side-channel attack. 682 Therefore, it is RECOMMENDED that the technique used to determine if 683 the value is a quadratic residue modulo p first blind the value with 684 a random number so that the blinded value can take on all numbers 685 between 1 and p-1 with equal probability. Determining the quadratic 686 residue in a fashion that resists leakage of information is handled 687 by flipping a coin and multiplying the blinded value by either a 688 random quadratic residue or a random quadratic nonresidue and 689 checking whether the multiplied value is a quadradic residue or a 690 quadradic nonresidue modulo p, respectively. The random residue and 691 nonresidue can be calculated prior to hunting-and-pecking by 692 calculating the legendre symbol on random values until they are 693 found: 695 do { 696 qr = random() 697 } while ( lgr(qr, p) != 1) 699 do { 700 qnr = random() 701 } while ( lgr(qnr, p) != -1) 703 Algorithmically, the masking technique to find out whether a value is 704 a quadratic residue modulo a prime or not looks like this: 706 is_quadratic_residue (val, p) { 707 r = (random() mod (p - 1)) + 1 708 num = (val * r * r) mod p 709 if ( lsb(r) == 1 ) 710 num = (num * qr) mod p 711 if ( lgr(num, p) == 1) 712 then 713 return TRUE 714 fi 715 else 716 num = (num * qnr) mod p 717 if ( lgr(num, p) == -1) 718 then 719 return TRUE 720 fi 721 fi 722 return FALSE 723 } 725 The random quadratic residue and quadratic non-residue (qr and qnr 726 above) can be used for all the hunting-and-pecking loops but the 727 blinding value, r, MUST be chosen randomly for each loop. 729 4.2.2. Computing an FFC Password Element 731 The group-specific operation for FFC groups takes pwd-value, and the 732 prime, p, and order, q, from the group's domain parameter set (see 733 Section 3.2.2 when the order is not part of the defined domain 734 parameter set) to directly produce a candidate password element, by 735 exponentiating the pwd-value to the value ((p-1)/q) modulo the prime. 736 If the result is greater than one (1), the candidate password element 737 becomes PE, and the hunting and pecking terminates successfully. 739 Algorithmically, the process looks like this: 741 found = 0 742 counter = 0 743 base = H(username | password | salt) 744 n = len(p) + 64 745 do { 746 counter = counter + 1 747 pwd-seed = H(base | counter | p) 748 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 749 ClientHello.random | ServerHello.random) [0..n] 750 pwd-value = (pwd-tmp mod (p-1)) + 1 751 PE = pwd-value ^ ((p-1)/q) mod p 752 if (PE > 1) 753 then 754 found = 1 755 base = random() 756 fi 757 } while ((found == 0) || (counter <= m)) 759 Figure 3: Fixing PE for FFC Groups 761 4.3. Changes to Handshake Message Contents 763 4.3.1. Client Hello Changes 765 The client is required to identify herself to the server by adding a 766 either a PWD_protect or PWD_clear extension to the Client Hello 767 message depending on whether the client wishes to protect its 768 username (see Section 4.1) or not, respectively. The PWD_protect and 769 PWD_clear extensions use the standard mechanism defined in [RFC5246]. 770 The "extension data" field of the PWD extension SHALL contain a 771 PWD_name which is used to identify the password shared between the 772 client and server. If username protection is performed, and the 773 ExtensionType is PWD_protect, the contents of the PWD_name SHALL be 774 constructed according to Section 4.1.1). 776 enum { PWD_clear(TBD1), PWD_protect(TBD2) } ExtensionType; 778 opaque PWD_name<1..2^8-1>; 780 An unprotected PWD_name SHALL be UTF-8 encoded character string 781 processed according to the rules of the OpaqueString profile of 782 [RFC7613] and a protected PWD_name SHALL be a string of bits. 784 A client offering a PWD ciphersuite MUST include one of the PWD_name 785 extensions in her Client Hello. 787 If a server does not have a password for a client identified by the 788 username either extracted from the PWD_name, if unprotected, or 789 recovered using the technique in Section 4.1.2, if protected, or if 790 recovery of a protected username fails, the server SHOULD hide that 791 fact by simulating the protocol-- putting random data in the PWD- 792 specific components of the Server Key Exchange-- and then rejecting 793 the client's finished message with a "bad_record_mac" alert. To 794 properly effect a simulated TLS-PWD exchange, an appropriate delay 795 SHOULD be inserted between receipt of the Client Hello and response 796 of the Server Hello. Alternately, a server MAY choose to terminate 797 the exchange if a password is not found. 799 The server decides on a group to use with the named user (see 800 Section 10 and generates the password element, PE, according to 801 Section 4.2.2. 803 4.3.2. Server Key Exchange Changes 805 The domain parameter set for the selected group MUST be explicitly 806 specified by name in the ServerKeyExchange. ECC groups are specified 807 using the NamedGroup enumeration of [RFC4492] and FFC groups are 808 specified using the NamedGroup extensions added by [RFC7919]. In 809 addition to the group specification, the ServerKeyExchange also 810 contains the server's "commitment" in the form of a scalar and 811 element, and the salt which was used to store the user's password. 813 Two new values have been added to the enumerated KeyExchangeAlgorithm 814 to indicate TLS-PWD using finite field cryptography, ff_pwd, and TLS- 815 PWD using elliptic curve cryptography, ec_pwd. 817 enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms; 819 struct { 820 opaque salt<1..2^8-1>; 821 NamedGroup ff_group; 822 opaque ff_selement<1..2^16-1>; 823 opaque ff_sscalar<1..2^16-1>; 824 } ServerFFPWDParams; 826 struct 827 opaque salt<1..2^8-1>; 828 ECParameters curve_params; 829 ECPoint ec_selement; 830 opaque ec_sscalar<1..2^8-1>; 831 } ServerECPWDParams; 833 struct { 834 select (KeyExchangeAlgorithm) { 835 case ec_pwd: 836 ServerECPWDParams params; 837 case ff_pwd: 838 ServerFFPWDParams params; 839 }; 840 } ServerKeyExchange; 842 4.3.2.1. Generation of ServerKeyExchange 844 The scalar and Element that comprise the server's "commitment" are 845 generated as follows. 847 First two random numbers, called private and mask, between zero and 848 the order of the group (exclusive) are generated. If their sum 849 modulo the order of the group, q, equals zero the numbers must be 850 thrown away and new random numbers generated. If their sum modulo 851 the order of the group, q, is greater than zero the sum becomes the 852 scalar. 854 scalar = (private + mask) mod q 856 The Element is then calculated as the inverse of the group's scalar 857 operation (see the group specific operations in Section 3.2) with the 858 mask and PE. 860 Element = inverse(scalar-op(mask, PE)) 862 After calculation of the scalar and Element the mask SHALL be 863 irretrievably destroyed. 865 4.3.2.1.1. ECC Server Key Exchange 867 EEC domain parameters are specified, either explicitly or named, in 868 the ECParameters component of the EEC-specific ServerKeyExchange as 869 defined in [RFC4492]. The scalar SHALL become the ec_sscalar 870 component and the Element SHALL become the ec_selement of the 871 ServerKeyExchange. If the client requested a specific point format 872 (compressed or uncompressed) with the Support Point Formats Extension 873 (see [RFC4492]) in its Client Hello, the Element MUST be formatted in 874 the ec_selement to conform to that request. If the client offered 875 (an) elliptic curve(s) in its ClientHello using the Supported 876 Elliptic Curves Extension, the server MUST include (one of the) named 877 curve(s) in the ECParameters field in the ServerKeyExchange and the 878 key exchange operations specified in Section 4.3.2.1 MUST use that 879 group. 881 As mentioned in Section 3.2.1, elliptic curves over GF(2^m), so 882 called characteristic-2 curves, and curves with a co-factor greater 883 than one (1) SHALL NOT be used with TLS-PWD. 885 4.3.2.1.2. FFC Server Key Exchange 887 FFC domain parameters sent in the ServerKeyExchange are for the 888 group's prime, generator (which is only used for verification of the 889 group specification), and the order of the group's generator. The 890 scalar SHALL become the ff_sscalar component and the Element SHALL 891 become the ff_selement in the FFC-specific ServerKeyExchange. 893 As mentioned in Section 3.2.2 if the prime is a safe prime and no 894 order is included in the domain parameter set, the order added to the 895 ServerKeyExchange SHALL be the prime minus one divided by two-- 896 (p-1)/2. 898 4.3.2.2. Processing of ServerKeyExchange 900 Upon receipt of the ServerKeyExchange, the client decides whether to 901 support the indicated group or not. If the client used the Supported 902 Elliptic Curves Extension to offer (a) named curve(s) in her 903 ClientHello, the named curve in the ServerKeyExchange MUST be one 904 offered. If the server is explicitly specifying a group, either an 905 FFC or ECC group, the client and server MUST have agreed upon groups 906 prior to beginning the exchange (see Section 3.2) and the client MUST 907 compare each field of the explicit offer to the agreed-upon group(s). 908 Any discrepency SHALL result in the exchange being aborted. 910 If the client decides to support the indicated group the server's 911 "commitment" MUST be validated by ensuring that: 1) the server's 912 scalar value is greater than zero (0) and less than the order of the 913 group, q; and 2) that the Element is valid for the chosen group (see 914 Section 3.2.2 and Section 3.2.1 for how to determine whether an 915 Element is valid for the particular group. Note that if the Element 916 is a compressed point on an elliptic curve it MUST be uncompressed 917 before checking its validity). 919 If the group is acceptable and the server's "commitment" has been 920 successfully validated, the client extracts the salt from the 921 ServerKeyExchange and generates the password element, PE, according 922 to Section 3.4 and Section 4.2.2. If the group is not acceptable or 923 the server's "commitment" failed validation, the eexchange MUST be 924 aborted. 926 4.3.3. Client Key Exchange Changes 928 When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd, 929 the ClientKeyExchange is used to convey the client's "commitment" to 930 the server. It, therefore, contains a scalar and an Element. 932 struct { 933 opaque ff_celement<1..2^16-1>; 934 opaque ff_cscalar<1..2^16-1>; 935 } ClientFFPWDParams; 937 struct 938 ECPoint ec_celement; 939 opaque ec_cscalar<1..2^8-1>; 940 } ClientECPWDParams; 942 struct { 943 select (KeyExchangeAlgorithm) { 944 case ff_pwd: ClientFFPWDParams; 945 case ec_pwd: ClientECPWDParams; 946 } exchange_keys; 947 } ClientKeyExchange; 949 4.3.3.1. Generation of Client Key Exchange 951 The client's scalar and Element are generated in the manner described 952 in Section 4.3.2.1. 954 For an FFC group, the scalar SHALL become the ff_cscalar component 955 and the Element SHALL become the ff_celement in the FFC-specific 956 ClientKeyExchange. 958 For an ECC group, the scalar SHALL become the ec_cscalar component 959 and the ELement SHALL become the ec_celement in the ECC-specific 960 ClientKeyExchange. If the client requested a specific point format 961 (compressed or uncompressed) with the Support Point Formats Extension 962 in its ClientHello, then the Element MUST be formatted in the 963 ec_celement to conform to its initial request. 965 4.3.3.2. Processing of Client Key Exchange 967 Upon receipt of the ClientKeyExchange, the server must validate the 968 client's "commitment" by ensuring that: 1) the client's scalar and 969 element differ from the server's scalar and element; 2) the client's 970 scalar value is greater than zero (0) and less than the order of the 971 group, q; and 3) that the Element is valid for the chosen group (see 972 Section 3.2.2 and Section 3.2.1 for how to determin whether an 973 Element is valid for a particular group. Note that if the Element is 974 a compressed point on an elliptic curve it MUST be uncompressed 975 before checking its validity. If any of these three conditions are 976 not met the server MUST abort the exchange. 978 4.4. Computing the Premaster Secret 980 The client uses the server's scalar and Element, denoted here as 981 ServerKeyExchange.scalar and ServerKeyExchange.Element, and the 982 random private value, denoted here as client.private, she created as 983 part of the generation of her "commit" to compute an intermediate 984 value, z, as indicated: 986 z = F(scalar-op(client.private, 987 element-op(ServerKeyExchange.Element, 988 scalar-op(ServerKeyExchange.scalar, PE)))) 990 With the same notation as above, the server the client's scalar and 991 Element, and his random private value, denoted here as 992 server.private, he created as part of the generation of his "commit" 993 to compute the premaster secret as follows: 995 z = F(scalar-op(server.private, 996 element-op(ClientKeyExchange.Element, 997 scalar-op(ClientKeyExchange.scalar, PE)))) 999 The intermediate value, z, is then used as the premaster secret after 1000 any leading bytes of z that contain all zero bits have been stripped 1001 off. 1003 5. Ciphersuite Definition 1005 This memo adds the following ciphersuites: 1007 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 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 11.2. Informative References 1335 [FIPS186-3] 1336 National Institute of Standards and Technology, "Digital 1337 Signature Standard (DSS)", Federal Information Processing 1338 Standards Publication 186-3, . 1340 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 1341 A Paradigm for Designing Efficient Protocols", Proceedings 1342 of the 1st ACM Conference on Computer and Communication 1343 Security, ACM Press, 1993. 1345 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1346 "Randomness Requirements for Security", BCP 106, RFC 4086, 1347 DOI 10.17487/RFC4086, June 2005, 1348 . 1350 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1351 Curve Cryptography Algorithms", RFC 6090, February 2011. 1353 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1354 "Enrollment over Secure Transport", RFC 7030, DOI 1355 10.17487/RFC7030, October 2013, 1356 . 1358 [RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 1359 10.17487/RFC7664, November 2015, 1360 . 1362 [SP800-38A] 1363 National Institute of Standards and Technology, 1364 "Recommendation for Block Cipher Modes of Operation-- 1365 Methods and Techniques", NIST Special Publication 800-38A, 1366 December 2001. 1368 [SP800-56A] 1369 Barker, E., Johnson, D., and M. Smid, "Recommendations for 1370 Pair-Wise Key Establishment Schemes Using Discrete 1371 Logarithm Cryptography", NIST Special Publication 800-56A, 1372 March 2007. 1374 [lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of 1375 the Dragonfly Protocol", Proceedings of 18th International 1376 Information Security Conference (ISC 2015), pp 244-261, 1377 DOI 10.1007/978-3-319-23318-5_14, September 2015. 1379 Appendix A. Example Exchange 1381 (Note: at the time of publication of this memo ciphersuites have 1382 not yet been assigned by IANA and the exchange that follows uses 1383 the private numberspace). 1385 username: fred 1386 password: barney 1387 ---- prior to running TLS-PWD ---- 1389 server generates salt: 1391 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 1392 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 1394 and a base: 1396 6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 1397 c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75 1399 ---- state derived during the TLS-PWD exchange ---- 1401 client and server agree to use brainpoolP256r1 1403 client and server generate PE: 1405 PE.x: 1406 29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 1407 a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6 1409 server private and mask: 1411 private: 1412 21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b 1413 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c 1414 mask: 1415 0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f 1416 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5 1418 client private and mask: 1420 private: 1421 17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f 1422 a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b 1423 mask: 1424 4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88 1425 83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd 1427 both parties generate pre-master secret and master secret 1429 pre-master secret: 1430 01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11 1431 af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4 1432 master secret: 1433 65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1 1434 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f 1435 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad 1437 ---- ssldump output of exchange ---- 1439 New TCP connection #1: Charlene Client <-> Sammy Server 1440 1 1 0.0018 (0.0018) C>SV3.3(173) Handshake 1441 ClientHello 1442 Version 3.3 1443 random[32]= 1444 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 1445 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d 1446 cipher suites 1447 TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV 1448 TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV 1449 Unknown value 0xff 1450 compression methods 1451 NULL 1452 extensions 1453 TLS-PWD unprotected name[5]= 1454 04 66 72 65 64 1455 elliptic curve point format[4]= 1456 03 00 01 02 1457 elliptic curve list[58]= 1458 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 1459 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 1460 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 1461 00 02 00 03 00 0f 00 10 00 11 1462 Packet data[178]= 1463 16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17 1464 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf 1465 a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3 1466 ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65 1467 64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00 1468 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 1469 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 1470 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 1471 03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06 1472 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 1473 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 1474 01 01 1476 1 2 0.0043 (0.0024) S>CV3.3(94) Handshake 1477 ServerHello 1478 Version 3.3 1479 random[32]= 1480 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 1481 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa 1483 session_id[32]= 1484 ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 1485 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 1486 cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV 1487 compressionMethod NULL 1488 extensions 1489 renegotiate[1]= 1490 00 1491 elliptic curve point format[4]= 1492 03 00 01 02 1493 heartbeat[1]= 1494 01 1495 Packet data[99]= 1496 16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43 1497 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 1498 ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08 1499 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 1500 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00 1501 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f 1502 00 01 01 1504 1 3 0.0043 (0.0000) S>CV3.3(141) Handshake 1505 ServerKeyExchange 1506 params 1507 salt[32]= 1508 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 1509 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 1510 EC parameters = 3 1511 curve id = 26 1512 element[65]= 1513 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 1514 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee 1515 f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 1516 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db 1517 e1 1518 scalar[32]= 1519 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a 1520 df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21 1521 Packet data[146]= 1522 16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1 1523 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 1524 47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04 1525 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 1526 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 1527 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 1528 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 1529 00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 1530 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 1531 49 21 1533 1 4 0.0043 (0.0000) S>CV3.3(4) Handshake 1534 ServerHelloDone 1535 Packet data[9]= 1536 16 03 03 00 04 0e 00 00 00 1538 1 5 0.0086 (0.0043) C>SV3.3(104) Handshake 1539 ClientKeyExchange 1540 element[65]= 1541 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 1542 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 1543 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 1544 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd 1545 a0 1546 scalar[32]= 1547 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 1548 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 1549 Packet data[109]= 1550 16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b 1551 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 1552 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd 1553 d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf 1554 e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44 1555 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 1556 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 1558 1 6 0.0086 (0.0000) C>SV3.3(1) ChangeCipherSpec 1559 Packet data[6]= 1560 14 03 03 00 01 01 1562 1 7 0.0086 (0.0000) C>SV3.3(40) Handshake 1563 Packet data[45]= 1564 16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7 1565 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a 1566 0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20 1568 1 8 0.0105 (0.0018) S>CV3.3(1) ChangeCipherSpec 1569 Packet data[6]= 1570 14 03 03 00 01 01 1572 1 9 0.0105 (0.0000) S>CV3.3(40) Handshake 1573 Packet data[45]= 1574 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c 1575 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 1576 a2 21 94 90 12 72 23 18 24 21 c3 60 a4 1578 1 10 0.0107 (0.0002) C>SV3.3(100) application_data 1579 Packet data.... 1581 Author's Address 1583 Dan Harkins (editor) 1584 HP Enterprise 1585 1322 Crossman Avenue 1586 Sunnyvale, CA 94089-1113 1587 United States of America 1589 Email: dharkins@lounge.org