idnits 2.17.1 draft-ietf-tls-pwd-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 (August 15, 2013) is 3907 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-38A' -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 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: February 16, 2014 Halasz Ventures 6 August 15, 2013 8 Secure Password Ciphersuites for Transport Layer Security (TLS) 9 draft-ietf-tls-pwd-01 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 February 16, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. The Case for Certificate-less Authentication . . . . . . . 3 55 1.2. Resistance to Dictionary Attack . . . . . . . . . . . . . 3 56 2. Keyword Definitions . . . . . . . . . . . . . . . . . . . . . 4 57 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 5 60 3.2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . 5 61 3.2.2. Finite Field Cryptography . . . . . . . . . . . . . . 6 62 3.3. Instantiating the Random Function . . . . . . . . . . . . 7 63 3.4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8 65 4. Specification of the TLS-PWD Handshake . . . . . . . . . . . . 8 66 4.1. Fixing the Password Element . . . . . . . . . . . . . . . 9 67 4.1.1. Computing an ECC Password Element . . . . . . . . . . 10 68 4.1.2. Computing an FFC Password Element . . . . . . . . . . 11 69 4.2. Changes to Handshake Message Contents . . . . . . . . . . 12 70 4.2.1. Client Hello Changes . . . . . . . . . . . . . . . . . 12 71 4.2.2. Server Key Exchange Changes . . . . . . . . . . . . . 13 72 4.2.2.1. Generation of ServerKeyExchange . . . . . . . . . 14 73 4.2.2.2. Processing of ServerKeyExchange . . . . . . . . . 15 74 4.2.3. Client Key Exchange Changes . . . . . . . . . . . . . 15 75 4.2.3.1. Generation of Client Key Exchange . . . . . . . . 16 76 4.2.3.2. Processing of Client Key Exchange . . . . . . . . 16 77 4.3. Computing the Premaster Secret . . . . . . . . . . . . . . 16 78 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . . 17 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 9. Implementation Considerations . . . . . . . . . . . . . . . . 22 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 88 1. Background 90 1.1. The Case for Certificate-less Authentication 92 TLS usually uses public key certificates for authentication 93 [RFC5246]. This is problematic in some cases: 95 o Frequently, TLS [RFC5246] is used in devices owned, operated, and 96 provisioned by people who lack competency to properly use 97 certificates and merely want to establish a secure connection 98 using a more natural credential like a simple password. The 99 proliferation of deployments that use a self-signed server 100 certificate in TLS [RFC5246] followed by a PAP-style exchange over 101 the unauthenticated channel underscores this case. 103 o A password is a more natural credential than a certificate (from 104 early childhood people learn the semantics of a shared secret), so 105 a password-based TLS ciphersuite can be used to protect an HTTP- 106 based certificate enrollment scheme-- e.g. an [RFC5967] -style 107 request and an [RFC5751] -style response-- to parlay a simple 108 password into a certificate for subsequent use with any 109 certificate-based authentication protocol. This addresses a 110 significant "chicken-and-egg" dilemma found with certificate-only 111 use of [RFC5246]. 113 o Some PIN-code readers will transfer the entered PIN to a smart 114 card in clear text. Assuming a hostile environment, this is a bad 115 practice. A password-based TLS ciphersuite can enable the 116 establishment of an authenticated connection between reader and 117 card based on the PIN. 119 1.2. Resistance to Dictionary Attack 121 It is a common misconception that a protocol that authenticates with 122 a shared and secret credential is resistent to dictionary attack if 123 the credential is assumed to be an N-bit uniformly random secret, 124 where N is sufficiently large. The concept of resistence to 125 dictionary attack really has nothing to do with whether that secret 126 can be found in a standard collection of a language's defined words 127 (i.e. a dictionary). It has to do with how an adversary gains an 128 advantage in attacking the protocol. 130 For a protocol to be resistant to dictionary attack any advantage an 131 adversary can gain must be a function of the amount of interactions 132 she makes with an honest protocol participant and not a function of 133 the amount of computation she uses. The adversary will not be able 134 to obtain any information about the password except whether a single 135 guess from a single protocol run which she took part in is correct or 136 incorrect. 138 It is assumed that the attacker has access to a pool of data from 139 which the secret was drawn-- it could be all numbers between 1 and 140 2^N, it could be all defined words in a dictionary. The key is that 141 the attacker cannot do a an attack and then enumerate through the 142 pool trying potential secrets (computation) to see if one is correct. 143 She must do an active attack for each secret she wishes to try 144 (interaction) and the only information she can glean from that attack 145 is whether the secret used with that particular attack is correct or 146 not. 148 2. Keyword Definitions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 3. Introduction 156 3.1. Notation 158 The following notation is used in this memo: 160 password 161 a secret, and potentially low-entropy word, phrase, code or key 162 used as a credential for authentication. The password is shared 163 between the TLS client and TLS server. 165 y = H(x) 166 a binary string of arbitrary length, x, is given to a function H 167 which produces a fixed-length output, y. 169 a | b 170 denotes concatenation of string a with string b. 172 [a]b 173 indicates a string consisting of the single bit "a" repeated "b" 174 times. 176 x mod y 177 indicates the remainder of division of x by y. The result will 178 be between 0 and y. 180 LSB(x) 181 returns the least-significant bit of the bitstring "x". 183 3.2. Discrete Logarithm Cryptography 185 The ciphersuites defined in this memo use discrete logarithm 186 cryptography (see [SP800-56A]) to produce an authenticated and shared 187 secret value that is an element in a group defined by a set of domain 188 parameters. The domain parameters can be based on either Finite 189 Field Cryptography (FFC) or Elliptic Curve Cryptography (EEC). 191 Elements in a group, either an FFC or EEC group, are indicated using 192 upper-case while scalar values are indicated using lower-case. 194 3.2.1. Elliptic Curve Cryptography 196 The authenticated key exchange defined in this memo uses fundamental 197 algorithms of elliptic curves defined over GF(p) as described in 198 [RFC6090]. 200 Domain parameters for the ECC groups used by this memo are: 202 o A prime, p, determining a prime field GF(p). The cryptographic 203 group will be a subgroup of the full elliptic curve group which 204 consists points on an elliptic curve-- elements from GF(p) that 205 satisfy the curve's equation-- together with the "point at 206 infinity" that serves as the identity element. 208 o Elements a and b from GF(p) that define the curve's equation. The 209 point (x,y) in GF(p) x GF(p) is on the elliptic curve if and only 210 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 212 o A point, G, on the elliptic curve, which serves as a generator for 213 the ECC group. G is chosen such that its order, with respect to 214 elliptic curve addition, is a sufficiently large prime. 216 o A prime, q, which is the order of G, and thus is also the size of 217 the cryptographic subgroup that is generated by G. 219 o A co-factor, f, defined by the requirement that the size of the 220 full elliptic curve group (including the "point at infinity") is 221 the product of f and q. 223 This memo uses the following ECC Functions: 225 o Z = elem-op(X,Y) = X + Y: two points on the curve X and Y, are 226 sumed to produce another point on the curve, Z. This is the group 227 operation for ECC groups. 229 o Z = scalar-op(x,Y) = x * Y: an integer scalar, x, acts on a point 230 on the curve, Y, via repetitive addition (Y is added to itself x 231 times), to produce another EEC element, Z. 233 o Y = inverse(X): a point on the curve, X, has an inverse, Y, which 234 is also a point on the curve, when their sum is the "point at 235 infinity" (the identity for elliptic curve addition). In other 236 words, R + inverse(R) = "0". 238 o z = F(X): the x-coordinate of a point (x, y) on the curve is 239 returned. This is a mapping function to convert a group element 240 into an integer. 242 Only ECC groups over GF(p) can be used with TLS-PWD. ECC groups over 243 GF(2^m) SHALL NOT be used by TLS-PWD. In addition, ECC groups with a 244 co-factor greater than one (1) SHALL NOT be used by TLS-PWD. 246 A composite (x, y) pair can be validated as an a point on the 247 elliptic curve by checking whether: 1) both coordinates x and y are 248 greater than zero (0) and less than the prime defining the underlying 249 field; 2) the x- and y- coordinates satisfy the equation of the 250 curve; and 3) they do not represent the point-at-infinity "0". If 251 any of those conditions are not true the (x, y) pair is not a valid 252 point on the curve. 254 3.2.2. Finite Field Cryptography 256 Domain parameters for the FFC groups used by this memo are: 258 o A prime, p, determining a prime field GF(p), the integers modulo 259 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 260 group of non-zero elements in GF(p). 262 o An element, G, in GF(p)* which serves as a generator for the FFC 263 group. G is chosen such that its multiplicative order is a 264 sufficiently large prime divisor of ((p-1)/2). 266 o A prime, q, which is the multiplicative order of G, and thus also 267 the size of the cryptographic subgroup of GF(p)* that is generated 268 by G. 270 This memo uses the following FFC Functions: 272 o Z = elem-op(X,Y) = (X * Y) mod p: two FFC elements, X and Y, are 273 multiplied modulo the prime, p, to produce another FFC element, Z. 274 This is the group operation for FFC groups. 276 o Z = scalar-op(x,Y) = Y^x mod p: an integer scalar, x, acts on an 277 FFC group element, Y, via exponentiation modulo the prime, p, to 278 produce another FFC element, Z. 280 o Y = inverse(X): a group element, X, has an inverse, Y, when the 281 product of the element and its inverse modulo the prime equals one 282 (1). In other words, (X * inverse(X)) mod p = 1. 284 o z = F(X): is the identity function since an element in an FFC 285 group is already an integer. It is included here for consistency 286 in the specification. 288 Many FFC groups used in IETF protocols are based on safe primes and 289 do not define an order (q). For these groups, the order (q) used in 290 this memo shall be the prime of the group minus one divided by two-- 291 (p-1)/2. 293 An integer can be validated as being an element in an FFC group by 294 checking whether: 1) it is between one (1) and the prime, p, 295 exclusive; and 2) if modular exponentiation of the integer by the 296 group order, q, equals one (1). If either of these conditions are 297 not true the integer is not an element in the group. 299 3.3. Instantiating the Random Function 301 The protocol described in this memo uses a random function, H, which 302 is modeled as a "random oracle". At first glance, one may view this 303 as a hash function. As noted in [RANDOR], though, hash functions are 304 too structured to be used directly as a random oracle. But they can 305 be used to instantiate the random oracle. 307 The random function, H, in this memo is instantiated by using the 308 hash algorithm defined by the particular TLS-PWD ciphersuite in HMAC 309 mode with a key whose length is equal to block size of the hash 310 algorithm and whose value is zero. For example, if the ciphersuite 311 is TLS_ECCPWD_WITH_AES_128_GCM_SHA256 then H will be instantiated 312 with SHA256 as: 314 H(x) = HMAC-SHA256([0]32, x) 316 3.4. Passwords 318 The authenticated key exchange used in TLS-PWD requires each side to 319 have a common view of a shared credential. To protect the server's 320 database of stored passwords, though, the password SHALL be salted 321 and the result, called the base, SHALL be used as the authentication 322 credential. 324 The salting function is defined as: 326 base = HMAC-SHA256(salt, username | password) 328 The password used for generation of the base SHALL be represented as 329 a UTF-8 encoded character string processed according to the rules of 330 the [RFC4013] profile of [RFC3454] and the salt SHALL be a 32 octet 331 random number. The server SHALL store a triplet of the form: 333 { username, base, salt } 335 And the client SHALL generate the base upon receiving the salt from 336 the server. 338 3.5. Assumptions 340 The security properties of the authenticated key exchange defined in 341 this memo are based on a number of assumptions: 343 1. The random function, H, is a "random oracle" as defined in 344 [RANDOR]. 346 2. The discrete logarithm problem for the chosen group is hard. 347 That is, given g, p, and y = g^x mod p, it is computationally 348 infeasible to determine x. Similarly, for an ECC group given the 349 curve definition, a generator G, and Y = x * G, it is 350 computationally infeasible to determine x. 352 3. Quality random numbers with sufficient entropy can be created. 353 This may entail the use of specialized hardware. If such 354 hardware is unavailable a cryptographic mixing function (like a 355 strong hash function) to distill enropy from multiple, 356 uncorrelated sources of information and events may be needed. A 357 very good discussion of this can be found in [RFC4086]. 359 4. Specification of the TLS-PWD Handshake 361 The authenticated key exchange is accomplished by each side deriving 362 a password-based element, PE, in the chosen group, making a 363 "committment" to a single guess of the password using PE, and 364 generating the Premaster Secret. The ability of each side to produce 365 a valid finished message authenticates itself to the other side. 367 The authenticated key exchange is dropped into the standard TLS 368 message handshake by modifying some of the messages. 370 Client Server 371 -------- -------- 373 Client Hello (name) --------> 375 Server Hello 376 Server Key Exchange (commit) 377 <-------- Server Hello Done 379 Client Key Exchange (commit) 380 [Change cipher spec] 381 Finished --------> 383 [Change cipher spec] 384 <-------- Finished 386 Application Data <-------> Application Data 388 Figure 1 390 4.1. Fixing the Password Element 392 Prior to making a "committment" both sides must generate a secret 393 element, PE, in the chosen group using the common password-derived 394 base. The server generates PE after it receives the Client Hello and 395 chooses the particular group to use, and the client generates PE upon 396 receipt of the Server Key Exchange. 398 Fixing the password element involves an iterative "hunting and 399 pecking" technique using the prime from the negotiated group's domain 400 parameter set and an ECC- or FFC-specific operation depending on the 401 negotiated group. 403 To thwart side channel attacks which attempt to determine the number 404 of iterations of the "hunting-and-pecking" loop are used to find PE 405 for a given password, a security parameter, k, is used to ensure that 406 at least k iterations are always performed. 408 First, an 8-bit counter is set to the value one (1). Then, H is used 409 to generate a password seed from the a counter, the prime of the 410 selected group, and the base (which is derived from the username, 411 password, and salt): 413 pwd-seed = H(base | counter | p) 415 Then, using the technique from section B.5.1 of [FIPS186-3], the pwd- 416 seed is expanded using the PRF to the length of the prime from the 417 negotiated group's domain parameter set plus a constant sixty-four 418 (64) to produce an intermediate pwd-tmp which is modularly reduced to 419 create pwd-value: 421 n = p + 64 422 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 423 ClientHello.random | ServerHello.random) [0..n]; 424 pwd-value = (pwd-tmp mod (p-1)) + 1 426 The pwd-value is then passed to the group-specific operation which 427 either returns the selected password element or fails. If the group- 428 specific operation fails, the counter is incremented, a new pwd-seed 429 is generated, and the hunting-and-pecking continues. This process 430 continues until the group-specific operation returns the password 431 element. After the password element has been chosen, the base is 432 changed to a random number, the counter is incremented and the 433 hunting-and-pecking continues until the counter is greater than the 434 security parameter, k. 436 The probability that one requires more than "n" iterations of the 437 "hunting and pecking" loop to find an ECC PE is roughly (q/2p)^n and 438 to find an FFC PE is roughly (q/p)^n, both of which rapidly approach 439 zero (0) as "n" increases. The security parameter, k, SHOULD be set 440 sufficiently large such that the probability that finding PE would 441 take more than k iterations is sufficiently small (see Section 8). 443 When PE has been discovered, pwd-seed, pwd-tmp, and pwd-value SHALL 444 be irretrievably destroyed. 446 4.1.1. Computing an ECC Password Element 448 The group-specific operation for ECC groups uses pwd-value, pwd-seed, 449 and the equation for the curve to produce PE. First, pwd-value is 450 used directly as the x-coordinate, x, with the equation for the 451 elliptic curve, with parameters a and b from the domain parameter set 452 of the curve, to solve for a y-coordinate, y. If there is no 453 solution to the quadratic equation, this operation fails and the 454 hunting-and-pecking process continues. If a solution is found, then 455 an ambiguity exists as there are technically two solutions to the 456 equation and pwd-seed is used to unambiguously select one of them. 457 If the low-order bit of pwd-seed is equal to the low-order bit of y, 458 then a candidate PE is defined as the point (x, y); if the low-order 459 bit of pwd-seed differs from the low-order bit of y, then a candidate 460 PE is defined as the point (x, p - y), where p is the prime over 461 which the curve is defined. The candidate PE becomes PE, a random 462 number is used instead of the base, and the hunting and pecking 463 continues until it has looped through k iterations. 465 Algorithmically, the process looks like this: 467 found = 0 468 counter = 0 469 base = H(username | password | salt) 470 n = p + 64 471 do { 472 counter = counter + 1 473 pwd-seed = H(base | counter | p) 474 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 475 ClientHello.random | ServerHello.random) [0..n] 476 pwd-value = (pwd-tmp mod (p-1)) + 1 477 x = pwd-value 478 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 479 then 480 if (found == 0) 481 then 482 if (LSB(y) == LSB(pwd-seed)) 483 then 484 PE = (x, y) 485 else 486 PE = (x, p-y) 487 fi 488 found = 1 489 base = random() 490 fi 491 fi 492 } while ((found == 0) || (counter <= k)) 494 Figure 2: Fixing PE for ECC Groups 496 4.1.2. Computing an FFC Password Element 498 The group-specific operation for FFC groups takes pwd-value, and the 499 prime, p, and order, q, from the group's domain parameter set (see 500 Section 3.2.2 when the order is not part of the defined domain 501 parameter set) to directly produce a candidate password element, by 502 exponentiating the pwd-value to the value ((p-1)/q) modulo the prime. 503 If the result is greater than one (1), the candidate password element 504 becomes PE, and the hunting and pecking terminates successfully. 506 Algorithmically, the process looks like this: 508 found = 0 509 counter = 0 510 base = H(username | password | salt) 511 n = p + 64 512 do { 513 counter = counter + 1 514 pwd-seed = H(base | counter | p) 515 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 516 ClientHello.random | ServerHello.random) [0..n] 517 pwd-value = (pwd-tmp mod (p-1)) + 1 518 PE = pwd-value ^ ((p-1)/q) mod p 519 if (PE > 1) 520 then 521 found = 1 522 base = random() 523 fi 524 } while ((found == 0) || (counter <= k)) 526 Figure 3: Fixing PE for FFC Groups 528 4.2. Changes to Handshake Message Contents 530 4.2.1. Client Hello Changes 532 The client is required to identify herself to the server by adding a 533 PWD extension to the Client Hello message. The PWD extension uses 534 the standard mechanism defined in [RFC5246]. The "extension data" 535 field of the PWD extension SHALL contain a PWD_name which is used to 536 identify the password shared between the client and server. 538 enum { pwd(TBD) } ExtensionType; 540 opaque PWD_name<1..2^8-1>; 542 The PWD_name SHALL be UTF-8 encoded character string processed 543 according to the rules of the [RFC4013] profile of [RFC3454]. 545 A client offering a PWD ciphersuite MUST include the PWD extension in 546 her Client Hello. 548 If a server does not have a password identified by the PWD_name in 549 the PWD extension of the Client Hello, the server SHOULD hide that 550 fact by simulating the protocol-- putting random data in the PWD- 551 specific components of the Server Key Exchange-- and then rejecting 552 the client's finished message with a "bad_record_mac" alert. To 553 properly effect a simulated TLS-PWD exchange, an appropriate delay 554 SHOULD be inserted between receipt of the Client Hello and response 555 of the Server Hello. Alternately, a server MAY choose to terminate 556 the exchange if a password identified by the PWD_name in the PWD 557 extension of the Client Hello is not found. 559 The server decides on a group to use with the named user (see 560 Section 9 and generates the password element, PE, according to 561 Section 4.1.2. 563 4.2.2. Server Key Exchange Changes 565 The domain parameter set for the selected group MUST be specified in 566 the ServerKeyExchange, either explicitly or, in the case of some 567 elliptic curve groups, by name. In addition to the group 568 specification, the ServerKeyExchange also contains the server's 569 "committment" in the form of a scalar and element, and the salt which 570 was used to store the user's password. 572 Two new values have been added to the enumerated KeyExchangeAlgorithm 573 to indicate TLS-PWD using finite field cryptography, ff_pwd, and TLS- 574 PWD using elliptic curve cryptography, ec_pwd. 576 enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms; 578 struct { 579 opaque salt<1..2^8-1>; 580 opaque pwd_p<1..2^16-1>; 581 opaque pwd_g<1..2^16-1>; 582 opaque pwd_q<1..2^16-1>; 583 opaque ff_selement<1..2^16-1>; 584 opaque ff_sscalar<1..2^16-1>; 585 } ServerFFPWDParams; 587 struct 588 opaque salt<1..2^8-1>; 589 ECParameters curve_params; 590 ECPoint ec_selement; 591 opaque ec_sscalar<1..2^8-1>; 592 } ServerECPWDParams; 594 struct { 595 select (KeyExchangeAlgorithm) { 596 case ec_pwd: 597 ServerECPWDParams params; 598 case ff_pwd: 599 ServerFFPWDParams params; 600 }; 601 } ServerKeyExchange; 603 4.2.2.1. Generation of ServerKeyExchange 605 The scalar and Element that comprise the server's "committment" are 606 generated as follows. 608 First two random numbers, called private and mask, between zero and 609 the order of the group (exclusive) are generated. If their sum 610 modulo the order of the group, q, equals zero the numbers must be 611 thrown away and new random numbers generated. If their sum modulo 612 the order of the group, q, is greater than zero the sum becomes the 613 scalar. 615 scalar = (private + mask) mod q 617 The Element is then calculated as the inverse of the group's scalar 618 operation (see the group specific operations in Section 3.2) with the 619 mask and PE. 621 Element = inverse(scalar-op(mask, PE)) 623 After calculation of the scalar and Element the mask SHALL be 624 irretrievably destroyed. 626 4.2.2.1.1. ECC Server Key Exchange 628 EEC domain parameters are specified, either explicitly or named, in 629 the ECParameters component of the EEC-specific ServerKeyExchange as 630 defined in [RFC4492]. The scalar SHALL become the ec_sscalar 631 component and the Element SHALL become the ec_selement of the 632 ServerKeyExchange. If the client requested a specific point format 633 (compressed or uncompressed) with the Support Point Formats Extension 634 (see [RFC4492]) in its Client Hello, the Element MUST be formatted in 635 the ec_selement to conform to that request. 637 As mentioned in Section 3.2.1, elliptic curves over GF(2^m), so 638 called characteristic-2 curves, and curves with a co-factor greater 639 than one (1) SHALL NOT be used with TLS-PWD. 641 4.2.2.1.2. FFC Server Key Exchange 643 FFC domain parameters sent in the ServerKeyExchange are for the 644 group's prime, generator (which is only used for verification of the 645 group specification), and the order of the group's generator. The 646 scalar SHALL become the ff_sscalar component and the Element SHALL 647 become the ff_selement in the FFC-specific ServerKeyExchange. 649 As mentioned in Section 3.2.2 if the prime is a safe prime and no 650 order is included in the domain parameter set, the order added to the 651 ServerKeyExchange SHALL be the prime minus one divided by two-- 652 (p-1)/2. 654 4.2.2.2. Processing of ServerKeyExchange 656 Upon receipt of the ServerKeyExchange, the client decides whether to 657 support the indicated group or not. Named elliptic curves are easy 658 to validate-- either they are supported or they are not, but care 659 must be taken with FFC groups and explicitly specified ECC groups. 660 As mentioned in Section 3.5, the discrete logarithm problem MUST be 661 hard for any group used with this memo. The specific steps taken to 662 come to this assurance for a particular group are outside the scope 663 of this memo but they are the same steps to take when using the 664 Diffie-Hellman key exchange with TLS. If the client decides not to 665 support the group indicated in the ServerKeyExchange, she MUST abort 666 the exchange. 668 If the client decides to support the indicated group the server's 669 "commitment" MUST be validated by ensuring that: 1) the server's 670 scalar value is greater than zero (0) and less than the order of the 671 group, q; and 2) that the Element is valid for the chosen group (see 672 Section 3.2.2 and Section 3.2.1 for how to determine whether an 673 Element is valid for the particular group. Note that if the Element 674 is a compressed point on an elliptic curve it MUST be uncompressed 675 before checking its validity). 677 If the group is acceptable, the client extracts the salt from the 678 ServerKeyExchange and generates the password element, PE, according 679 to Section 3.4 and Section 4.1.2. 681 4.2.3. Client Key Exchange Changes 683 When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd, 684 the ClientKeyExchange is used to convey the client's "committment" to 685 the server. It, therefore, contains a scalar and an Element. 687 struct { 688 opaque ff_celement<1..2^16-1>; 689 opaque ff_cscalar<1..2^16-1>; 690 } ClientFFPWDParams; 692 struct 693 ECPoint ec_celement; 694 opaque ec_cscalar<1..2^8-1>; 695 } ClientECPWDParams; 697 struct { 698 select (KeyExchangeAlgorithm) { 699 case ff_pwd: ClientFFPWDParams; 700 case ec_pwd: ClientECPWDParams; 701 } exchange_keys; 702 } ClientKeyExchange; 704 4.2.3.1. Generation of Client Key Exchange 706 The client's scalar and Element are generated in the manner described 707 in Section 4.2.2.1. 709 For an FFC group, the scalar SHALL become the ff_cscalar component 710 and the Element SHALL become the ff_celement in the FFC-specific 711 ClientKeyExchange. 713 For an ECC group, the scalar SHALL become the ec_cscalar component 714 and the ELement SHALL become the ec_celement in the ECC-specific 715 ClientKeyExchange. If the client requested a specific point format 716 (compressed or uncompressed) with the Support Point Formats Extension 717 in its ClientHello, then the Element MUST be formatted in the 718 ec_celement to conform to its initial request. 720 4.2.3.2. Processing of Client Key Exchange 722 The server MUST validate the client's "committment" by ensuring that: 723 1) the client's scalar value is greater than zero (0) and less than 724 the order of the group, q; and 2) that the Element is valid for the 725 chosen group (see Section 3.2.2 and Section 3.2.1 for how to determin 726 whether an Element is valid for a particular group. Note that if the 727 Element is a compressed point on an elliptic curve it MUST be 728 uncompressed before checking its validity. 730 4.3. Computing the Premaster Secret 732 The client uses her own scalar and Element, denoted here 733 ClientKeyExchange.scalar and ClientKeyExchange.Element, the server's 734 scalar and Element, denoted here as ServerKeyExchange.scalar and 735 ServerKeyExchange.Element, and the random private value, denoted here 736 as client.private, she created as part of the generation of her 737 "commit" to compute an intermediate value, z, as indicated: 739 z = F(scalar-op(client.private, 740 element-op(ServerKeyExchange.Element, 741 scalar-op(ServerKeyExchange.scalar, PE)))) 743 With the same notation as above, the server uses his own scalar and 744 Element, the client's scalar and Element, and his random private 745 value, denoted here as server.private, he created as part of the 746 generation of his "commit" to compute the premaster secret as 747 follows: 749 z = F(scalar-op(server.private, 750 element-op(ClientKeyExchange.Element, 751 scalar-op(ClientKeyExchange.scalar, PE)))) 753 The intermediate value, z, is then used as the premaster secret after 754 any leading bytes of z that contain all zero bits have been stripped 755 off. 757 5. Ciphersuite Definition 759 This memo adds the following ciphersuites: 761 CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); 763 CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 765 CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 767 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 769 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 771 CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 773 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 775 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 777 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 779 Implementations conforming to this specification MUST support the 780 TLS_ECCPWD_WITH_AES_128_CBC_SHA ciphersuite; they SHOULD support 781 TLS_ECCPWD_WITH_AES_128_CCM_SHA, TLS_FFCPWD_WITH_AES_128_CCM_SHA, 782 TLS_ECCPWD_WITH_AES_128_GCM_SHA256, 783 TLS_ECCPWD_WITH_AES_256_GCM_SHA384; and MAY support the remaining 784 ciphersuites. 786 When negotiated with a version of TLS prior to 1.2, the Pseudo-Random 787 Function (PRF) from that version is used; otherwise, the PRF is the 788 TLS PRF [RFC5246] using the hash function indicated by the 789 ciphersuite. Regardless of the TLS version, the TLS-PWD random 790 function, H, is always instantiated with the hash algorithm indicated 791 by the ciphersuite. 793 For those ciphersuites that use Cipher Block Chaining (CBC) 794 [SP800-38A] mode, the MAC is HMAC [RFC2104] with the hash function 795 indicated by the ciphersuite. 797 6. Acknowledgements 799 The authenticated key exchange defined here has also been defined for 800 use in 802.11 networks, as an EAP method, and as an authentication 801 method for IKE. Each of these specifications has elicited very 802 helpful comments from a wide collection of people that have allowed 803 the definition of the authenticated key exchange to be refined and 804 improved. 806 The authors would like to thank Scott Fluhrer for discovering the 807 "password as exponent" attack that was possible in an early version 808 of this key exchange and for his very helpful suggestions on the 809 techniques for fixing the PE to prevent it. The authors would also 810 like to thank Hideyuki Suzuki for his insight in discovering an 811 attack against a previous version of the underlying key exchange 812 protocol. Special thanks to Lily Chen for helpful discussions on 813 hashing into an elliptic curve. Rich Davis suggested the defensive 814 checks that are part of the processing of the ServerKeyExchange and 815 ClientKeyExchange messages, and his various comments have greatly 816 improved the quality of this memo and the underlying key exchange on 817 which it is based. 819 Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik, discussed the 820 possibility of a side-channel attack against the hunting-and-pecking 821 loop on the TLS mailing list. That discussion prompted the addition 822 of the security parameter, k, to the hunting-and-pecking loop. 824 7. IANA Considerations 826 IANA SHALL assign a value for a new TLS extention type from the TLS 827 ExtensionType Registry defined in [RFC5246] with the name "pwd". The 828 RFC editor SHALL replace TBD in Section 4.2.1 with the IANA-assigned 829 value for this extension. 831 IANA SHALL assign nine new ciphersuites from the TLS Ciphersuite 832 Registry defined in [RFC5246] for the following ciphersuites: 834 CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); 836 CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 838 CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 840 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 842 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 844 CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 846 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 848 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 850 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 852 The RFC editor SHALL replace (TBD, TBD) in all the ciphersuites 853 defined in Section 5 with the appropriate IANA-assigned values. The 854 "DTLS-OK" column in the ciphersuite registry SHALL be set to "Y" for 855 all ciphersuites defined in this memo. 857 8. Security Considerations 859 A passive attacker against this protocol will see the 860 ServerKeyExchange and the ClientKeyExchange containing the server's 861 scalar and Element, and the client's scalar and Element, 862 respectively. The client and server effectively hide their secret 863 private value by masking it modulo the order of the selected group. 864 If the order is "q", then there are approximately "q" distinct pairs 865 of numbers that will sum to the scalar values observed. It is 866 possible for an attacker to iterate through all such values but for a 867 large value of "q", this exhaustive search technique is 868 computationally infeasible. The attacker would have a better chance 869 in solving the discrete logarithm problem, which we have already 870 assumed (see Section 3.5) to be an intractable problem. 872 A passive attacker can take the Element from either the 873 ServerKeyExchange or the ClientKeyExchange and try to determine the 874 random "mask" value used in its construction and then recover the 875 other party's "private" value from the scalar in the same message. 876 But this requires the attacker to solve the discrete logarithm 877 problem which we assumed was intractable. 879 Both the client and the server obtain a shared secret, the premaster 880 secret, based on a secret group element and the private information 881 they contributed to the exchange. The secret group element is based 882 on the password. If they do not share the same password they will be 883 unable to derive the same secret group element and if they don't 884 generate the same secret group element they will be unable to 885 generate the same premaster secret. Seeing a finished message along 886 with the ServerKeyExchange and ClientKeyExchange will not provide any 887 additional advantage of attack since it is generated with the 888 unknowable premaster secret. 890 An active attacker impersonating the client can induce a server to 891 send a ServerKeyExchange containing the server's scalar and Element. 892 It can attempt to generate a ClientKeyExchange and send to the server 893 but the attacker is required to send a finished message first so the 894 only information she can obtain in this attack is less than the 895 information she can obtain from a passive attack, so this particular 896 active attack is not very fruitful. 898 An active attacker can impersonate the server and send a forged 899 ServerKeyExchange after receiving the ClientHello. The attacker then 900 waits until it receives the ClientKeyExchange and finished message 901 from the client. Now the attacker can attempt to run through all 902 possible values of the password, computing PE (see Section 4.1), 903 computing candidate premaster secrets (see Section 4.3), and 904 attempting to recreate the client's finished message. 906 But the attacker committed to a single guess of the password with her 907 forged ServerKeyExchange. That value was used by the client in her 908 computation of the premaster secret which was used to produce the 909 finished message. Any guess of the password which differs from the 910 one used in the forged ServerKeyExchange would result in each side 911 using a different PE in the computation of the premaster secret and 912 therefore the finished message cannot be verified as correct, even if 913 a subsequent guess, while running through all possible values, was 914 correct. The attacker gets one guess, and one guess only, per active 915 attack. 917 Instead of attempting to guess at the password, an attacker can 918 attempt to determine PE and then launch an attack. But PE is 919 determined by the output of the random function, H, which is 920 indistinguishable from a random source since H is assumed to be a 921 "random oracle" (Section 3.5). Therefore, each element of the finite 922 cyclic group will have an equal probability of being the PE. The 923 probability of guessing PE will be 1/q, where q is the order of the 924 group. For a large value of "q" this will be computationally 925 infeasible. 927 The implications of resistance to dictionary attack are significant. 928 An implementation can provision a password in a practical and 929 realistic manner-- i.e. it MAY be a character string and it MAY be 930 relatively short-- and still maintain security. The nature of the 931 pool of potential passwords determines the size of the pool, D, and 932 countermeasures can prevent an attacker from determining the password 933 in the only possible way: repeated, active, guessing attacks. For 934 example, a simple four character string using lower-case English 935 characters, and assuming random selection of those characters, will 936 result in D of over four hundred thousand. An attacker would need to 937 mount over one hundred thousand active, guessing attacks (which will 938 easily be detected) before gaining any significant advantage in 939 determining the pre-shared key. 941 Countermeasures to deal with successive active, guessing attacks are 942 only possible by noticing a certain username is failing repeatedly 943 over a certain period of time. Attacks which attempt to find a 944 password for a random user are more difficult to detect. For 945 instance, if a device uses a serial number as a username and the pool 946 of potential passwords is sufficiently small, a more effective attack 947 would be to select a password and try all potential "users" to 948 disperse the attack and confound countermeasures. It is therefore 949 RECOMMENDED that implementations of TLS-pwd keep track of the total 950 number of failed authentications regardless of username in an effort 951 to detect and thwart this type of attack. 953 The benefits of resistance to dictionary attack can be lessened by a 954 client using the same passwords with multiple servers. An attacker 955 could re-direct a session from one server to the other if the 956 attacker knew that the intended server stored the same password for 957 the client as another server. 959 An adversary that has access to, and a considerable amount of control 960 over, a client or server could attempt to mount a side-channel attack 961 to determine the number of times it took for a certain password (plus 962 client random and server random) to select a password element. Each 963 such attack could result in a successive paring-down of the size of 964 the pool of potential passwords, resulting in a manageably small set 965 from which to launch a series of active attacks to determine the 966 password. A security parameter, k, is used to normalize the amount 967 of work necessary to determine the password element (see 968 Section 4.1). The probability that a password will require more than 969 k iterations is roughly (q/2p)^k for ECC groups and (q/p)^k for FFC 970 groups, so it is possible to mitigate side channel attack at the 971 expense of a constant cost per connection attempt. But if a 972 particular password requires more than k iterations it will leak k 973 bits of information to the side-channel attacker, which for some 974 dictionaries will uniquely identify the password. Therefore, the 975 security parameter, k, needs to be set with great care. It is 976 RECOMMENDED that an implementation set the security parameter, k, to 977 a value of at least forty (40) which will put the probability that 978 more than forty iterations are needed in the order of one in one 979 trillion (1:1,000,000,000,000). 981 The server uses a database of salted passwords. While this will 982 prevent an adversary who gains access to the database from learning 983 the client's password, it does not prevent such an adversary from 984 impersonating the client back to the server. Each side uses the 985 salted password, called the base, as the authenticaiton credential so 986 the database of salted passwords MUST be afforded the security of a 987 database of plaintext passwords. 989 9. Implementation Considerations 991 The selection of the ciphersuite and selection of the particular 992 finite cyclic group to use with the ciphersuite are divorced in this 993 memo but they remain intimately close. 995 It is RECOMMENDED that implementations take note of the strength 996 estimates of particular groups and to select a ciphersuite providing 997 commensurate security with its hash and encryption algorithms. A 998 ciphersuite whose encryption algorithm has a keylength less than the 999 strength estimate, or whose hash algorithm has a blocksize that is 1000 less than twice the strength estimate SHOULD NOT be used. 1002 For example, the elliptic curve named secp256r1 (whose IANA-assigned 1003 number is 23) provides an estimated 128 bits of strength and would be 1004 compatible with an encryption algorithm supporting a key of that 1005 length, and a hash algorithm that has at least a 256-bit blocksize. 1006 Therefore, a suitable ciphersuite to use with secp256r1 could be 1007 TLS_ECCPWD_WITH_AES_128_GCM_SHA256. 1009 Resistance to dictionary attack means that the attacker must launch 1010 an active attack to make a single guess at the password. If the size 1011 of the pool from which the password was extracted was D, and each 1012 password in the pool has an equal probability of being chosen, then 1013 the probability of success after a single guess is 1/D. After X 1014 guesses, and removal of failed guesses from the pool of possible 1015 passwords, the probability becomes 1/(D-X). As X grows so does the 1016 probability of success. Therefore it is possible for an attacker to 1017 determine the password through repeated brute-force, active, guessing 1018 attacks. Implementations SHOULD take note of this fact and choose an 1019 appropriate pool of potential passwords-- i.e. make D big. 1020 Implementations SHOULD also take countermeasures, for instance 1021 refusing authentication attempts by a particular username for a 1022 certain amount of time, after the number of failed authentication 1023 attempts reaches a certain threshold. No such threshold or amount of 1024 time is recommended in this memo. 1026 10. References 1028 10.1. Normative References 1030 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1031 Hashing for Message Authentication", RFC 2104, 1032 February 1997. 1034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1035 Requirement Levels", BCP 14, RFC 2119, March 1997. 1037 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1038 Internationalized Strings ("stringprep")", RFC 3454, 1039 December 2002. 1041 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1042 and Passwords", RFC 4013, February 2005. 1044 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1045 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1047 [SP800-38A] 1048 National Institute of Standards and Technology, 1049 "Recommendation for Block Cipher Modes of Operation-- 1050 Methods and Techniques", NIST Special Publication 800-38A, 1051 December 2001. 1053 10.2. Informative References 1055 [FIPS186-3] 1056 National Institute of Standards and Technology, "Digital 1057 Signature Standard (DSS)", Federal Information Processing 1058 Standards Publication 186-3. 1060 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 1061 A Paradigm for Designing Efficient Protocols", Proceedings 1062 of the 1st ACM Conference on Computer and Communication 1063 Security, ACM Press, 1993. 1065 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1066 Requirements for Security", BCP 106, RFC 4086, June 2005. 1068 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1069 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1070 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1072 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1073 Mail Extensions (S/MIME) Version 3.2 Message 1074 Specification", RFC 5751, January 2010. 1076 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1077 August 2010. 1079 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1080 Curve Cryptography Algorithms", RFC 6090, February 2011. 1082 [SP800-56A] 1083 Barker, E., Johnson, D., and M. Smid, "Recommendations for 1084 Pair-Wise Key Establishment Schemes Using Discrete 1085 Logarithm Cryptography", NIST Special Publication 800-56A, 1086 March 2007. 1088 Authors' Addresses 1090 Dan Harkins (editor) 1091 Aruba Networks 1092 1322 Crossman Avenue 1093 Sunnyvale, CA 94089-1113 1094 United States of America 1096 Email: dharkins@arubanetworks.com 1098 Dave Halasz (editor) 1099 Halasz Ventures 1100 8401 Chagrin Road, Suite 10A 1101 Chagrin Falls, OH 44023 1102 United States of America 1104 Email: david.e.halasz@gmail.com