idnits 2.17.1 draft-harkins-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 (October 31, 2011) is 4560 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) == Unused Reference: 'RFC5751' is defined on line 1059, but no explicit reference was found in the text == Unused Reference: 'RFC5967' is defined on line 1063, but no explicit reference was found in the text ** 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 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** 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 5751 (Obsoleted by RFC 8551) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Harkins, Ed. 3 Internet-Draft Aruba Networks 4 Intended status: Standards Track D. Halasz, Ed. 5 Expires: May 3, 2012 Intwine Energy 6 October 31, 2011 8 Secure Password Ciphersuites for Transport Layer Security (TLS) 9 draft-harkins-tls-pwd-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 3, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. 46 Abstract 48 This memo defines several new ciphersuites for the Transport Layer 49 Security (TLS) protocol to support certificate-less, secure 50 authentication using only a simple, low-entropy, password. The 51 ciphersuites are all based on an authentication and key exchange 52 protocol that is resistant to off-line dictionary attack. 54 Table of Contents 56 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. The Case for Certificate-less Authentication . . . . . . . 3 58 1.2. Resistance to Dictionary Attack . . . . . . . . . . . . . 3 59 2. Keyword Definitions . . . . . . . . . . . . . . . . . . . . . 4 60 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 5 63 3.2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . 5 64 3.2.2. Finite Field Cryptography . . . . . . . . . . . . . . 6 65 3.3. Instantiating the Random Function . . . . . . . . . . . . 7 66 3.4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8 68 4. Specification of the TLS-PWD Handshake . . . . . . . . . . . . 8 69 4.1. Fixing the Password Element . . . . . . . . . . . . . . . 9 70 4.1.1. Computing an ECC Password Element . . . . . . . . . . 10 71 4.1.2. Computing an FFC Password Element . . . . . . . . . . 11 72 4.2. Changes to Handshake Message Contents . . . . . . . . . . 12 73 4.2.1. Client Hello Changes . . . . . . . . . . . . . . . . . 12 74 4.2.2. Server Key Exchange Changes . . . . . . . . . . . . . 13 75 4.2.2.1. Generation of ServerKeyExchange . . . . . . . . . 14 76 4.2.2.2. Processing of ServerKeyExchange . . . . . . . . . 15 77 4.2.3. Client Key Exchange Changes . . . . . . . . . . . . . 15 78 4.2.3.1. Generation of Client Key Exchange . . . . . . . . 16 79 4.2.3.2. Processing of Client Key Exchange . . . . . . . . 16 80 4.3. Computing the Premaster Secret . . . . . . . . . . . . . . 16 81 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . . 17 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 9. Implementation Considerations . . . . . . . . . . . . . . . . 22 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Background 93 1.1. The Case for Certificate-less Authentication 95 TLS usually uses public key certificates for authentication 96 [RFC5246]. This is problematic in some cases: 98 o Frequently, TLS [RFC5246] is used in devices owned, operated, and 99 provisioned by people who lack competency to properly use 100 certificates and merely want to establish a secure connection 101 using a more natural credential like a simple password. The 102 proliferation of deployments that use a self-signed server 103 certificate in TLS [RFC5246] followed by a PAP-style exchange over 104 the unauthenticated channel underscores this case. 106 o A password is a more natural credential than a certificate (from 107 early childhood people learn the semantics of a shared secret), so 108 a password-based TLS ciphersuite can be used to protect an HTTP- 109 based certificate enrollment scheme-- e.g. an [RFC5967]-style 110 request and an [RFC5751]-style response-- to parlay a simple 111 password into a certificate for subsequent use with any 112 certificate-based authentication protocol. This addresses a 113 significant "chicken-and-egg" dilemma found with certificate-only 114 use of [RFC5246]. 116 o Some PIN-code readers will transfer the entered PIN to a smart 117 card in clear text. Assuming a hostile environment, this is a bad 118 practice. A password-based TLS ciphersuite can enable the 119 establishment of an authenticated connection between reader and 120 card based on the PIN. 122 1.2. Resistance to Dictionary Attack 124 It is a common misconception that a protocol that authenticates with 125 a shared and secret credential is resistent to dictionary attack if 126 the credential is assumed to be an N-bit uniformly random secret, 127 where N is sufficiently large. The concept of resistence to 128 dictionary attack really has nothing to do with whether that secret 129 can be found in a standard collection of a language's defined words 130 (i.e. a dictionary). It has to do with how an adversary gains an 131 advantage in attacking the protocol. 133 For a protocol to be resistant to dictionary attack any advantage an 134 adversary can gain must be a function of the amount of interactions 135 she makes with an honest protocol participant and not a function of 136 the amount of computation she uses. The adversary will not be able 137 to obtain any information about the password except whether a single 138 guess from a single protocol run which she took part in is correct or 139 incorrect. 141 It is assumed that the attacker has access to a pool of data from 142 which the secret was drawn-- it could be all numbers between 1 and 143 2^N, it could be all defined words in a dictionary. The key is that 144 the attacker cannot do a an attack and then enumerate through the 145 pool trying potential secrets (computation) to see if one is correct. 146 She must do an active attack for each secret she wishes to try 147 (interaction) and the only information she can glean from that attack 148 is whether the secret used with that particular attack is correct or 149 not. 151 2. Keyword Definitions 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 3. Introduction 159 3.1. Notation 161 The following notation is used in this memo: 163 password 164 a secret, and potentially low-entropy word, phrase, code or key 165 used as a credential for authentication. The password is shared 166 between the TLS client and TLS server. 168 y = H(x) 169 a binary string of arbitrary length, x, is given to a function H 170 which produces a fixed-length output, y. 172 a | b 173 denotes concatenation of string a with string b. 175 [a]b 176 indicates a string consisting of the single bit "a" repeated "b" 177 times. 179 x mod y 180 indicates the remainder of division of x by y. The result will 181 be between 0 and y. 183 LSB(x) 184 returns the least-significant bit of the bitstring "x". 186 3.2. Discrete Logarithm Cryptography 188 The ciphersuites defined in this memo use discrete logarithm 189 cryptography (see [SP800-56A]) to produce an authenticated and shared 190 secret value that is an element in a group defined by a set of domain 191 parameters. The domain parameters can be based on either Finite 192 Field Cryptography (FFC) or Elliptic Curve Cryptography (EEC). 194 Elements in a group, either an FFC or EEC group, are indicated using 195 upper-case while scalar values are indicated using lower-case. 197 3.2.1. Elliptic Curve Cryptography 199 The authenticated key exchange defined in this memo uses fundamental 200 algorithms of elliptic curves defined over GF(p) as described in 201 [RFC6090]. 203 Domain parameters for the ECC groups used by this memo are: 205 o A prime, p, determining a prime field GF(p). The cryptographic 206 group will be a subgroup of the full elliptic curve group which 207 consists points on an elliptic curve-- elements from GF(p) that 208 satisfy the curve's equation-- together with the "point at 209 infinity" that serves as the identity element. 211 o Elements a and b from GF(p) that define the curve's equation. The 212 point (x,y) in GF(p) x GF(p) is on the elliptic curve if and only 213 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 215 o A point, G, on the elliptic curve, which serves as a generator for 216 the ECC group. G is chosen such that its order, with respect to 217 elliptic curve addition, is a sufficiently large prime. 219 o A prime, q, which is the order of G, and thus is also the size of 220 the cryptographic subgroup that is generated by G. 222 o A co-factor, f, defined by the requirement that the size of the 223 full elliptic curve group (including the "point at infinity") is 224 the product of f and q. 226 This memo uses the following ECC Functions: 228 o Z = elem-op(X,Y) = X + Y: two points on the curve X and Y, are 229 sumed to produce another point on the curve, Z. This is the group 230 operation for ECC groups. 232 o Z = scalar-op(x,Y) = x * Y: an integer scalar, x, acts on a point 233 on the curve, Y, via repetitive addition (Y is added to itself x 234 times), to produce another EEC element, Z. 236 o Y = inverse(X): a point on the curve, X, has an inverse, Y, which 237 is also a point on the curve, when their sum is the "point at 238 infinity" (the identity for elliptic curve addition). In other 239 words, R + inverse(R) = "0". 241 o z = F(X): the x-coordinate of a point (x, y) on the curve is 242 returned. This is a mapping function to convert a group element 243 into an integer. 245 Only ECC groups over GF(p) can be used with TLS-PWD. ECC groups over 246 GF(2^m) SHALL NOT be used by TLS-PWD. In addition, ECC groups with a 247 co-factor greater than one (1) SHALL NOT be used by TLS-PWD. 249 A composite (x, y) pair can be validated as an a point on the 250 elliptic curve by checking whether: 1) both coordinates x and y are 251 greater than zero (0) and less than the prime defining the underlying 252 field; 2) the x- and y- coordinates satisfy the equation of the 253 curve; and 3) they do not represent the point-at-infinity "0". If 254 any of those conditions are not true the (x, y) pair is not a valid 255 point on the curve. 257 3.2.2. Finite Field Cryptography 259 Domain parameters for the FFC groups used by this memo are: 261 o A prime, p, determining a prime field GF(p), the integers modulo 262 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 263 group of non-zero elements in GF(p). 265 o An element, G, in GF(p)* which serves as a generator for the FFC 266 group. G is chosen such that its multiplicative order is a 267 sufficiently large prime divisor of ((p-1)/2). 269 o A prime, q, which is the multiplicative order of G, and thus also 270 the size of the cryptographic subgroup of GF(p)* that is generated 271 by G. 273 This memo uses the following FFC Functions: 275 o Z = elem-op(X,Y) = (X * Y) mod p: two FFC elements, X and Y, are 276 multiplied modulo the prime, p, to produce another FFC element, Z. 277 This is the group operation for FFC groups. 279 o Z = scalar-op(x,Y) = Y^x mod p: an integer scalar, x, acts on an 280 FFC group element, Y, via exponentiation modulo the prime, p, to 281 produce another FFC element, Z. 283 o Y = inverse(X): a group element, X, has an inverse, Y, when the 284 product of the element and its inverse modulo the prime equals one 285 (1). In other words, (X * inverse(X)) mod p = 1. 287 o z = F(X): is the identity function since an element in an FFC 288 group is already an integer. It is included here for consistency 289 in the specification. 291 Many FFC groups used in IETF protocols are based on safe primes and 292 do not define an order (q). For these groups, the order (q) used in 293 this memo shall be the prime of the group minus one divided by two-- 294 (p-1)/2. 296 An integer can be validated as being an element in an FFC group by 297 checking whether: 1) it is between one (1) and the prime, p, 298 exclusive; and 2) if modular exponentiation of the integer by the 299 group order, q, equals one (1). If either of these conditions are 300 not true the integer is not an element in the group. 302 3.3. Instantiating the Random Function 304 The protocol described in this memo uses a random function, H, which 305 is modeled as a "random oracle". At first glance, one may view this 306 as a hash function. As noted in [RANDOR], though, hash functions are 307 too structured to be used directly as a random oracle. But they can 308 be used to instantiate the random oracle. 310 The random function, H, in this memo is instantiated by using the 311 hash algorithm defined by the particular TLS-PWD ciphersuite in HMAC 312 mode with a key whose length is equal to block size of the hash 313 algorithm and whose value is zero. For example, if the ciphersuite 314 is TLS_ECCPWD_WITH_AES_128_GCM_SHA256 then H will be instantiated 315 with SHA256 as: 317 H(x) = HMAC-SHA256([0]32, x) 319 3.4. Passwords 321 The authenticated key exchange used in TLS-PWD requires each side to 322 have a common view of a shared credential. To protect a database of 323 stored passwords, though, the password SHALL be salted and the 324 result, called the base, SHALL be used as the authentication 325 credential. 327 The salting function is defined as: 329 base = HMAC-SHA256(salt, username | password) 331 The password used for generation of the base SHALL be represented as 332 a UTF-8 encoded character string processed according to the rules of 333 the [RFC4013] profile of [RFC3454] and the salt SHALL be a 32 octet 334 random number. The server SHALL store a triplet of the form: 336 { username, base, salt } 338 And the client SHALL generate the base upon receiving the salt from 339 the server. 341 3.5. Assumptions 343 The security properties of the authenticated key exchange defined in 344 this memo are based on a number of assumptions: 346 1. The random function, H, is a "random oracle" as defined in 347 [RANDOR]. 349 2. The discrete logarithm problem for the chosen group is hard. 350 That is, given g, p, and y = g^x mod p, it is computationally 351 infeasible to determine x. Similarly, for an ECC group given the 352 curve definition, a generator G, and Y = x * G, it is 353 computationally infeasible to determine x. 355 3. Quality random numbers with sufficient entropy can be created. 356 This may entail the use of specialized hardware. If such 357 hardware is unavailable a cryptographic mixing function (like a 358 strong hash function) to distill enropy from multiple, 359 uncorrelated sources of information and events may be needed. A 360 very good discussion of this can be found in [RFC4086]. 362 4. Specification of the TLS-PWD Handshake 364 The authenticated key exchange is accomplished by each side deriving 365 a password-based element, PE, in the chosen group, making a 366 "committment" to a single guess of the password using PE, and 367 generating the Premaster Secret. The ability of each side to produce 368 a valid finished message authenticates itself to the other side. 370 The authenticated key exchange is dropped into the standard TLS 371 message handshake by modifying some of the messages. 373 Client Server 374 -------- -------- 376 Client Hello (name) --------> 378 Server Hello 379 Server Key Exchange (commit) 380 <-------- Server Hello Done 382 Client Key Exchange (commit) 383 [Change cipher spec] 384 Finished --------> 386 [Change cipher spec] 387 <-------- Finished 389 Application Data <-------> Application Data 391 Figure 1 393 4.1. Fixing the Password Element 395 Prior to making a "committment" both sides must generate a secret 396 element, PE, in the chosen group using the common password-derived 397 base. The server generates PE after it receives the Client Hello and 398 chooses the particular group to use, and the client generates PE upon 399 receipt of the Server Key Exchange. 401 Fixing the password element involves an iterative "hunting and 402 pecking" technique using the prime from the negotiated group's domain 403 parameter set and an ECC- or FFC-specific operation depending on the 404 negotiated group. 406 To thwart side channel attacks which attempt to determine the number 407 of iterations of the "hunting-and-pecking" loop are used to find PE 408 for a given password, a security parameter, k, is used to ensure that 409 at least k iterations are always performed. This technique need only 410 be used with ECC groups. 412 First, an 8-bit counter is set to the value one (1). Then, H is used 413 to generate a password seed from the a counter, the prime of the 414 selected group, and the base (which is derived from the username, 415 password, and salt): 417 pwd-seed = H(base | counter | p) 419 Then, the pwd-seed is expanded using the PRF to the length of the 420 prime from the negotiated group's domain parameter set, to create 421 pwd-value: 423 pwd-value = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 424 ClientHello.random | ServerHello.random) [0..p]; 426 If the pwd-value is greater than or equal to the prime, p, the 427 counter is incremented, and a new pwd-seed is generated and the 428 hunting-and-pecking continues. If pwd-value is less than the prime, 429 p, it is passed to the group-specific operation which either returns 430 the selected password element or fails. If the group-specific 431 operation fails, the counter is incremented, a new pwd-seed is 432 generated, and the hunting-and-pecking continues. This process 433 continues until the group-specific operation returns the password 434 element. For FCC groups, this terminates the hunting-and-pecking 435 process. For ECC groups, after the password element has been chosen, 436 the base is changed to a random number, the counter is incremented 437 and the hunting-and-pecking continues until the counter is greater 438 than the security parameter, k. 440 When PE has been discovered, pwd-seed and pwd-value SHALL be 441 irretrievably destroyed. 443 4.1.1. Computing an ECC Password Element 445 The group-specific operation for ECC groups uses pwd-value, pwd-seed, 446 and the equation for the curve to produce PE. First, pwd-value is 447 used directly as the x-coordinate, x, with the equation for the 448 elliptic curve, with parameters a and b from the domain parameter set 449 of the curve, to solve for a y-coordinate, y. If there is no 450 solution to the quadratic equation, this operation fails and the 451 hunting-and-pecking process continues. If a solution is found, then 452 an ambiguity exists as there are technically two solutions to the 453 equation and pwd-seed is used to unambiguously select one of them. 454 If the low-order bit of pwd-seed is equal to the low-order bit of y, 455 then a candidate PE is defined as the point (x, y); if the low-order 456 bit of pwd-seed differs from the low-order bit of y, then a candidate 457 PE is defined as the point (x, p - y), where p is the prime over 458 which the curve is defined. The candidate PE becomes PE, a random 459 number is used instead of the base, and the hunting and pecking 460 continues until it has looped through k iterations. 462 Algorithmically, the process looks like this: 464 found = 0 465 counter = 0 466 base = H(username | password | salt) 467 do { 468 counter = counter + 1 469 pwd-seed = H(base | counter | p) 470 pwd-value = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 471 ClientHello.random | ServerHello.random) [0..p] 472 if (pwd-value < p) 473 then 474 x = pwd-value 475 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 476 then 477 if (found == 0) 478 then 479 if (LSB(y) == LSB(pwd-seed)) 480 then 481 PE = (x, y) 482 else 483 PE = (x, p-y) 484 fi 485 found = 1 486 else 487 base = random() 488 fi 489 fi 490 } while ((found == 0) && (counter <= k)) 492 Figure 2: Fixing PE for ECC Groups 494 The probability that one requires more than "n" iterations of the 495 "hunting and pecking" loop to find PE is roughly (q/2p)^n which 496 rapidly approaches zero (0) as "n" increases. Therefore the security 497 parameter, k, SHOULD be set sufficiently large such that the 498 probability that finding PE would take more than k iterations is 499 sufficiently small. 501 4.1.2. Computing an FFC Password Element 503 The group-specific operation for FFC groups takes pwd-value, and the 504 prime, p, and order, q, from the group's domain parameter set (see 505 Section 3.2.2 when the order is not part of the defined domain 506 parameter set) to directly produce a candidate password element, by 507 exponentiating the pwd-value to the value ((p-1)/q) modulo the prime. 508 If the result is greater than one (1), the candidate password element 509 becomes PE, and the hunting and pecking terminates successfully. 511 Algorithmically, the process looks like this: 513 found = 0 514 counter = 0 515 do { 516 counter = counter + 1 517 pwd-seed = H(base | counter | p) 518 pwd-value = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 519 ClientHello.random | ServerHello.random) [0..p] 520 if (pwd-value < p) 521 then 522 PE = pwd-value ^ ((p-1)/q) mod p 523 if (PE > 1) 524 then 525 found = 1 526 fi 527 fi 528 } while (found == 0) 530 Figure 3: Fixing PE for FFC Groups 532 4.2. Changes to Handshake Message Contents 534 4.2.1. Client Hello Changes 536 The client is required to identify herself to the server by adding a 537 PWD extension to the Client Hello message. The PWD extension uses 538 the standard mechanism defined in [RFC4366]. The "extension data" 539 field of the PWD extension SHALL contain a PWD_name which is used to 540 identify the password shared between the client and server. 542 enum { pwd(TBD) } ExtensionType; 544 opaque PWD_name<1..2^8-1>; 546 The PWD_name SHALL be UTF-8 encoded character string processed 547 according to the rules of the [RFC4013] profile of [RFC3454]. 549 A client offering a PWD ciphersuite MUST include the PWD extension in 550 her Client Hello. 552 If a server does not have a password identified by the PWD_name in 553 the PWD extension of the Client Hello, the server SHOULD hide that 554 fact by simulating the protocol-- putting random data in the PWD- 555 specific components of the Server Key Exchange-- and then rejecting 556 the client's finished message with a "bad_record_mac" alert. To 557 properly effect a simulated TLS-PWD exchange, an appropriate delay 558 SHOULD be inserted between receipt of the Client Hello and response 559 of the Server Hello. Alternately, a server MAY choose to terminate 560 the exchange if a password identified by the PWD_name in the PWD 561 extension of the Client Hello is not found. 563 The server decides on a group to use with the named user (see 564 Section 9 and generates the password element, PE, according to 565 Section 4.1.2. 567 4.2.2. Server Key Exchange Changes 569 The domain parameter set for the selected group MUST be specified in 570 the ServerKeyExchange, either explicitly or, in the case of some 571 elliptic curve groups, by name. In addition to the group 572 specification, the ServerKeyExchange also contains the server's 573 "committment" in the form of a scalar and element, and the salt which 574 was used to store the user's password. 576 Two new values have been added to the enumerated KeyExchangeAlgorithm 577 to indicate TLS-PWD using finite field cryptography, ff_pwd, and TLS- 578 PWD using elliptic curve cryptography, ec_pwd. 580 enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms; 582 struct { 583 opaque salt<1..2^8-1>; 584 opaque pwd_p<1..2^16-1>; 585 opaque pwd_g<1..2^16-1>; 586 opaque pwd_q<1..2^16-1>; 587 opaque ff_sscalar<1..2^16-1>; 588 opaque ff_selement<1..2^16-1>; 589 } ServerFFPWDParams; 591 struct 592 opaque salt<1..2^8-1>; 593 ECParameters curve_params; 594 opaque ec_sscalar<1..2^8-1>; 595 ECPoint ec_selement; 596 } ServerECPWDParams; 598 struct { 599 select (KeyExchangeAlgorithm) { 600 case ec_pwd: 601 ServerECPWDParams params; 602 case ff_pwd: 603 ServerFFPWDParams params; 604 }; 605 } ServerKeyExchange; 607 4.2.2.1. Generation of ServerKeyExchange 609 The scalar and Element that comprise the server's "committment" are 610 generated as follows. 612 First two random numbers, called private and mask, between zero and 613 the order of the group (exclusive) are generated. If their sum 614 modulo the order of the group, q, equals zero the numbers must be 615 thrown away and new random numbers generated. If their sum modulo 616 the order of the group, q, is greater than zero the sum becomes the 617 scalar. 619 scalar = (private + mask) mod q 621 The Element is then calculated as the inverse of the group's scalar 622 operation (see the group specific operations in Section 3.2) with the 623 mask and PE. 625 Element = inverse(scalar-op(mask, PE)) 627 After calculation of the scalar and Element the mask SHALL be 628 irretrievably destroyed. 630 4.2.2.1.1. ECC Server Key Exchange 632 EEC domain parameters are specified, either explicitly or named, in 633 the ECParameters component of the EEC-specific ServerKeyExchange as 634 defined in [RFC4492]. The scalar SHALL become the ec_sscalar 635 component and the Element SHALL become the ec_selement of the 636 ServerKeyExchange. If the client requested a specific point format 637 (compressed or uncompressed) with the Support Point Formats Extension 638 (see [RFC4492]) in its Client Hello, the Element MUST be formatted in 639 the ec_selement to conform to that request. 641 As mentioned in Section 3.2.1, elliptic curves over GF(2^m), so 642 called characteristic-2 curves, and curves with a co-factor greater 643 than one (1) SHALL NOT be used with TLS-PWD. 645 4.2.2.1.2. FFC Server Key Exchange 647 FFC domain parameters sent in the ServerKeyExchange are for the 648 group's prime, generator (which is only used for verification of the 649 group specification), and the order of the group's generator. The 650 scalar SHALL become the ff_sscalar component and the Element SHALL 651 become the ff_selement in the FFC-specific ServerKeyExchange. 653 As mentioned in Section 3.2.2 if the prime is a safe prime and no 654 order is included in the domain parameter set, the order added to the 655 ServerKeyExchange SHALL be the prime minus one divided by two-- 656 (p-1)/2. 658 4.2.2.2. Processing of ServerKeyExchange 660 Upon receipt of the ServerKeyExchange, the client decides whether to 661 support the indicated group or not. Named elliptic curves are easy 662 to validate-- either they are supported or they are not, but care 663 must be taken with FFC groups and explicitly specified ECC groups. 664 As mentioned in Section 3.5, the discrete logarithm problem MUST be 665 hard for any group used with this memo. The specific steps taken to 666 come to this assurance for a particular group are outside the scope 667 of this memo but they are the same steps to take when using the 668 Diffie-Hellman key exchange with TLS. If the client decides not to 669 support the group indicated in the ServerKeyExchange, she MUST abort 670 the exchange. 672 If the client decides to support the indicated group the server's 673 "commitment" MUST be validated by ensuring that: 1) the server's 674 scalar value is greater than zero (0) and less than the order of the 675 group, q; and 2) that the Element is valid for the chosen group (see 676 Section 3.2.2 and Section 3.2.1 for how to determine whether an 677 Element is valid for the particular group. Note that if the Element 678 is a compressed point on an elliptic curve it MUST be uncompressed 679 before checking its validity). 681 If the group is acceptable, the client extracts the salt from the 682 ServerKeyExchange and generates the password element, PE, according 683 to Section 3.4 and Section 4.1.2. 685 4.2.3. Client Key Exchange Changes 687 When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd, 688 the ClientKeyExchange is used to convey the client's "committment" to 689 the server. It, therefore, contains a scalar and an Element. 691 struct { 692 opaque ff_cscalar<1..2^16-1>; 693 opaque ff_celement<1..2^16-1>; 694 } ClientFFPWDParams; 696 struct 697 opaque ec_cscalar<1..2^8-1>; 698 ECPoint ec_celement; 699 } ClientECPWDParams; 701 struct { 702 select (KeyExchangeAlgorithm) { 703 case ff_pwd: ClientFFPWDParams; 704 case ec_pwd: ClientECPWDParams; 705 } exchange_keys; 706 } ClientKeyExchange; 708 4.2.3.1. Generation of Client Key Exchange 710 The client's scalar and Element are generated in the manner described 711 in Section 4.2.2.1. 713 For an FFC group, the scalar SHALL become the ff_cscalar component 714 and the Element SHALL become the ff_celement in the FFC-specific 715 ClientKeyExchange. 717 For an ECC group, the scalar SHALL become the ec_cscalar component 718 and the ELement SHALL become the ec_celement in the ECC-specific 719 ClientKeyExchange. If the client requested a specific point format 720 (compressed or uncompressed) with the Support Point Formats Extension 721 in its ClientHello, then the Element MUST be formatted in the 722 ec_celement to conform to its initial request. 724 4.2.3.2. Processing of Client Key Exchange 726 The server MUST validate the client's "committment" by ensuring that: 727 1) the client's scalar value is greater than zero (0) and less than 728 the order of the group, q; and 2) that the Element is valid for the 729 chosen group (see Section 3.2.2 and Section 3.2.1 for how to determin 730 whether an Element is valid for a particular group. Note that if the 731 Element is a compressed point on an elliptic curve it MUST be 732 uncompressed before checking its validity. 734 4.3. Computing the Premaster Secret 736 The client uses her own scalar and Element, denoted here 737 ClientKeyExchange.scalar and ClientKeyExchange.Element, the server's 738 scalar and Element, denoted here as ServerKeyExchange.scalar and 739 ServerKeyExchange.Element, and the random private value, denoted here 740 as client.private, she created as part of the generation of her 741 "commit" to compute an intermediate value, z, as indicated: 743 z = F(scalar-op(client.private, 744 element-op(ServerKeyExchange.Element, 745 scalar-op(ServerKeyExchange.scalar, PE)))) 747 With the same notation as above, the server uses his own scalar and 748 Element, the client's scalar and Element, and his random private 749 value, denoted here as server.private, he created as part of the 750 generation of his "commit" to compute the premaster secret as 751 follows: 753 z = F(scalar-op(server.private, 754 element-op(ClientKeyExchange.Element, 755 scalar-op(ClientKeyExchange.scalar, PE)))) 757 The intermediate value, z, is then used as the premaster secret after 758 any leading bytes of z that contain all zero bits have been stripped 759 off. 761 5. Ciphersuite Definition 763 This memo adds the following ciphersuites: 765 CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); 767 CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 769 CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 771 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 773 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 775 CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 777 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 779 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 781 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 783 Implementations conforming to this specification MUST support the 784 TLS_ECCPWD_WITH_AES_128_CCM_SHA ciphersuite; they SHOULD support 785 TLS_FFCPWD_WITH_AES_128_CCM_SHA, TLS_FFCPWD_WITH_AES_128_CBC_SHA, 786 TLS_ECCPWD_WITH_AES_128_CBC_SHA, TLS_ECCPWD_WITH_AES_128_GCM_SHA256, 787 TLS_ECCPWD_WITH_AES_256_GCM_SHS384; and MAY support the remaining 788 ciphersuites. 790 When negotiated with a version of TLS prior to 1.2, the Pseudo-Random 791 Function (PRF) from that version is used; otherwise, the PRF is the 792 TLS PRF [RFC5246] using the hash function indicated by the 793 ciphersuite. Regardless of the TLS version, the TLS-PWD random 794 function, H, is always instantiated with the hash algorithm indicated 795 by the ciphersuite. 797 For those ciphersuites that use Cipher Block Chaining (CBC) 798 [SP800-38A] mode, the MAC is HMAC [RFC2104] with the hash function 799 indicated by the ciphersuite. 801 6. Acknowledgements 803 The authenticated key exchange defined here has also been defined for 804 use in 802.11 networks, as an EAP method, and as an authentication 805 method for IKE. Each of these specifications has elicited very 806 helpful comments from a wide collection of people that have allowed 807 the definition of the authenticated key exchange to be refined and 808 improved. 810 The authors would like to thank Scott Fluhrer for discovering the 811 "password as exponent" attack that was possible in an early version 812 of this key exchange and for his very helpful suggestions on the 813 techniques for fixing the PE to prevent it. The authors would also 814 like to thank Hideyuki Suzuki for his insight in discovering an 815 attack against a previous version of the underlying key exchange 816 protocol. Special thanks to Lily Chen for helpful discussions on 817 hashing into an elliptic curve and to Jin-Meng Ho for suggesting the 818 countermeasures to protect against a small sub-group attack. Rich 819 Davis suggested the defensive checks that are part of the processing 820 of the ServerKeyExchange and ClientKeyExchange messages, and his 821 various comments have greatly improved the quality of this memo and 822 the underlying key exchange on which it is based. 824 Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik, discussed the 825 possibility of a side-channel attack against the hunting-and-pecking 826 loop on the TLS mailing list. That discussion prompted the addition 827 of the security parameter, k, to the hunting-and-pecking loop. 829 7. IANA Considerations 831 IANA SHALL assign a value for a new TLS extention type from the TLS 832 ExtensionType Registry defined in [RFC4366] with the name "pwd". The 833 RFC editor SHALL replace TBD in Section 4.2.1 with the IANA-assigned 834 value for this extension. 836 IANA SHALL assign nine new ciphersuites from the TLS Ciphersuite 837 Registry defined in [RFC5246] for the following ciphersuites: 839 CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); 841 CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 843 CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 845 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 847 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 849 CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 851 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 853 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 855 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 857 The RFC editor SHALL replace (TBD, TBD) in all the ciphersuites 858 defined in Section 5 with the appropriate IANA-assigned values. 860 8. Security Considerations 862 A passive attacker against this protocol will see the 863 ServerKeyExchange and the ClientKeyExchange containing the server's 864 scalar and Element, and the client's scalar and Element, 865 respectively. The client and server effectively hide their secret 866 private value by masking it modulo the order of the selected group. 867 If the order is "q", then there are approximately "q" distinct pairs 868 of numbers that will sum to the scalar values observed. It is 869 possible for an attacker to iterate through all such values but for a 870 large value of "q", this exhaustive search technique is 871 computationally infeasible. The attacker would have a better chance 872 in solving the discrete logarithm problem, which we have already 873 assumed (see Section 3.5) to be an intractable problem. 875 A passive attacker can take the Element from either the 876 ServerKeyExchange or the ClientKeyExchange and try to determine the 877 random "mask" value used in its construction and then recover the 878 other party's "private" value from the scalar in the same message. 880 But this requires the attacker to solve the discrete logarithm 881 problem which we assumed was intractable. 883 Both the client and the server obtain a shared secret, the premaster 884 secret, based on a secret group element and the private information 885 they contributed to the exchange. The secret group element is based 886 on the password. If they do not share the same password they will be 887 unable to derive the same secret group element and if they don't 888 generate the same secret group element they will be unable to 889 generate the same premaster secret. Seeing a finished message along 890 with the ServerKeyExchange and ClientKeyExchange will not provide any 891 additional advantage of attack since it is generated with the 892 unknowable premaster secret. 894 An active attacker impersonating the client can induce a server to 895 send a ServerKeyExchange containing the server's scalar and Element. 896 It can attempt to generate a ClientKeyExchange and send to the server 897 but the attacker is required to send a finished message first so the 898 only information she can obtain in this attack is less than the 899 information she can obtain from a passive attack, so this particular 900 active attack is not very fruitful. 902 An active attacker can impersonate the server and send a forged 903 ServerKeyExchange after receiving the ClientHello. The attacker then 904 waits until it receives the ClientKeyExchange and finished message 905 from the client. Now the attacker can attempt to run through all 906 possible values of the password, computing PE (see Section 4.1), 907 computing candidate premaster secrets (see Section 4.3), and 908 attempting to recreate the client's finished message. 910 But the attacker committed to a single guess of the password with her 911 forged ServerKeyExchange. That value was used by the client in her 912 computation of the premaster secret which was used to produce the 913 finished message. Any guess of the password which differs from the 914 one used in the forged ServerKeyExchange would result in each side 915 using a different PE in the computation of the premaster secret and 916 therefore the finished message cannot be verified as correct, even if 917 a subsequent guess, while running through all possible values, was 918 correct. The attacker gets one guess, and one guess only, per active 919 attack. 921 Instead of attempting to guess at the password, an attacker can 922 attempt to determine PE and then launch an attack. But PE is 923 determined by the output of the random function, H, which is 924 indistinguishable from a random source since H is assumed to be a 925 "random oracle" (Section 3.5). Therefore, each element of the finite 926 cyclic group will have an equal probability of being the PE. The 927 probability of guessing PE will be 1/q, where q is the order of the 928 group. For a large value of "q" this will be computationally 929 infeasible. 931 The implications of resistance to dictionary attack are significant. 932 An implementation can provision a password in a practical and 933 realistic manner-- i.e. it MAY be a character string and it MAY be 934 relatively short-- and still maintain security. The nature of the 935 pool of potential passwords determines the size of the pool, D, and 936 countermeasures can prevent an attacker from determining the password 937 in the only possible way: repeated, active, guessing attacks. For 938 example, a simple four character string using lower-case English 939 characters, and assuming random selection of those characters, will 940 result in D of over four hundred thousand. An attacker would need to 941 mount over one hundred thousand active, guessing attacks (which will 942 easily be detected) before gaining any significant advantage in 943 determining the pre-shared key. 945 Countermeasures to deal with successive active, guessing attacks are 946 only possible by noticing a certain username is failing repeatedly 947 over a certain period of time. Attacks which attempt to find a 948 password for a random user are more difficult to detect. For 949 instance, if a device uses a serial number as a username and the pool 950 of potential passwords is sufficiently small, a more effective attack 951 would be to select a password and try all potential "users" to 952 disperse the attack and confound countermeasures. It is therefore 953 RECOMMENDED that implementations of TLS-pwd keep track of the total 954 number of failed authentications regardless of username in an effort 955 to detect and thwart this type of attack. 957 The benefits of resistance to dictionary attack can be lessened by a 958 client using the same passwords with multiple servers. An attacker 959 could re-direct a session from one server to the other if the 960 attacker knew that the intended server stored the same password for 961 the client as another server. 963 An adversary that has access to, and a considerable amount of control 964 over, a client or server could attempt to mount a side-channel attack 965 to determine the number of times it took for a certain password (plus 966 client random and server random) to select a password element. Each 967 such attack could result in a successive paring-down of the size of 968 the pool of potential passwords, resulting in a manageably small set 969 from which to launch a series of active attacks to determine the 970 password. A security parameter, k, is used to normalize the amount 971 of work necessary to determine the password element (see 972 Section 4.1). The probability that a password will require more than 973 k iterations is roughly (q/2p)^k so it is possible to mitigate a side 974 channel attack at the expense of a constant cost per connection 975 attempt. 977 9. Implementation Considerations 979 The selection of the ciphersuite and selection of the particular 980 finite cyclic group to use with the ciphersuite are divorced in this 981 memo but they remain intimately close. 983 It is RECOMMENDED that implementations take note of the strength 984 estimates of particular groups and to select a ciphersuite providing 985 commensurate security with its hash and encryption algorithms. A 986 ciphersuite whose encryption algorithm has a keylength less than the 987 strength estimate, or whose hash algorithm has a blocksize that is 988 less than twice the strength estimate SHOULD NOT be used. 990 For example, the elliptic curve named secp256r1 (whose IANA-assigned 991 number is 23) provides an estimated 128 bits of strength and would be 992 compatible with an encryption algorithm supporting a key of that 993 length, and a hash algorithm that has at least a 256-bit blocksize. 994 Therefore, a suitable ciphersuite to use with secp256r1 could be 995 TLS_ECCPWD_WITH_AES_128_GCM_SHA256. 997 Resistance to dictionary attack means that the attacker must launch 998 an active attack to make a single guess at the password. If the size 999 of the pool from which the password was extracted was D, and each 1000 password in the pool has an equal probability of being chosen, then 1001 the probability of success after a single guess is 1/D. After X 1002 guesses, and removal of failed guesses from the pool of possible 1003 passwords, the probability becomes 1/(D-X). As X grows so does the 1004 probability of success. Therefore it is possible for an attacker to 1005 determine the password through repeated brute-force, active, guessing 1006 attacks. Implementations SHOULD take note of this fact and choose an 1007 appropriate pool of potential passwords-- i.e. make D big. 1008 Implementations SHOULD also take countermeasures, for instance 1009 refusing authentication attempts by a particular username for a 1010 certain amount of time, after the number of failed authentication 1011 attempts reaches a certain threshold. No such threshold or amount of 1012 time is recommended in this memo. 1014 10. References 1016 10.1. Normative References 1018 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1019 Hashing for Message Authentication", RFC 2104, 1020 February 1997. 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, March 1997. 1025 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1026 Internationalized Strings ("stringprep")", RFC 3454, 1027 December 2002. 1029 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1030 and Passwords", RFC 4013, February 2005. 1032 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1033 and T. Wright, "Transport Layer Security (TLS) 1034 Extensions", RFC 4366, April 2006. 1036 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1037 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1038 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1040 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1041 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1043 [SP800-38A] 1044 National Institute of Standards and Technology, 1045 "Recommendation for Block Cipher Modes of Operation-- 1046 Methods and Techniques", NIST Special Publication 800-38A, 1047 December 2001. 1049 10.2. Informative References 1051 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 1052 A Paradigm for Designing Efficient Protocols", Proceedings 1053 of the 1st ACM Conference on Computer and Communication 1054 Security, ACM Press, 1993. 1056 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1057 Requirements for Security", BCP 106, RFC 4086, June 2005. 1059 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1060 Mail Extensions (S/MIME) Version 3.2 Message 1061 Specification", RFC 5751, January 2010. 1063 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1064 August 2010. 1066 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1067 Curve Cryptography Algorithms", RFC 6090, February 2011. 1069 [SP800-56A] 1070 Barker, E., Johnson, D., and M. Smid, "Recommendations for 1071 Pair-Wise Key Establishment Schemes Using Discrete 1072 Logarithm Cryptography", NIST Special Publication 800-56A, 1073 March 2007. 1075 Authors' Addresses 1077 Dan Harkins (editor) 1078 Aruba Networks 1079 1322 Crossman Avenue 1080 Sunnyvale, CA 94089-1113 1081 United States of America 1083 Email: dharkins@arubanetworks.com 1085 Dave Halasz (editor) 1086 Intwine Energy 1087 8401 Chagrin Road, Suite 10A 1088 Chagrin Falls, OH 44023 1089 United States of America 1091 Email: dhalasz@intwineenergy.com