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