idnits 2.17.1 draft-harkins-tls-pwd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 7, 2012) is 4249 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 Internet Engineering Task Force D. Harkins, Ed. 3 Internet-Draft Aruba Networks 4 Intended status: Standards Track D. Halasz, Ed. 5 Expires: March 11, 2013 Halasz Ventures 6 September 7, 2012 8 Secure Password Ciphersuites for Transport Layer Security (TLS) 9 draft-harkins-tls-pwd-03 11 Abstract 13 This memo defines several new ciphersuites for the Transport Layer 14 Security (TLS) protocol to support certificate-less, secure 15 authentication using only a simple, low-entropy, password. The 16 ciphersuites are all based on an authentication and key exchange 17 protocol that is resistant to off-line dictionary attack. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 11, 2013. 36 Copyright Notice 38 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 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 a database of 320 stored passwords, though, the password SHALL be salted and the 321 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. This technique need only 407 be used with ECC groups. 409 First, an 8-bit counter is set to the value one (1). Then, H is used 410 to generate a password seed from the a counter, the prime of the 411 selected group, and the base (which is derived from the username, 412 password, and salt): 414 pwd-seed = H(base | counter | p) 416 Then, the pwd-seed is expanded using the PRF to the length of the 417 prime from the negotiated group's domain parameter set, to create 418 pwd-value: 420 pwd-value = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 421 ClientHello.random | ServerHello.random) [0..p]; 423 If the pwd-value is greater than or equal to the prime, p, the 424 counter is incremented, and a new pwd-seed is generated and the 425 hunting-and-pecking continues. If pwd-value is less than the prime, 426 p, it is passed to the group-specific operation which either returns 427 the selected password element or fails. If the group-specific 428 operation fails, the counter is incremented, a new pwd-seed is 429 generated, and the hunting-and-pecking continues. This process 430 continues until the group-specific operation returns the password 431 element. For FCC groups, this terminates the hunting-and-pecking 432 process. For ECC groups, after the password element has been chosen, 433 the base is changed to a random number, the counter is incremented 434 and the hunting-and-pecking continues until the counter is greater 435 than the security parameter, k. 437 When PE has been discovered, pwd-seed and pwd-value SHALL be 438 irretrievably destroyed. 440 4.1.1. Computing an ECC Password Element 442 The group-specific operation for ECC groups uses pwd-value, pwd-seed, 443 and the equation for the curve to produce PE. First, pwd-value is 444 used directly as the x-coordinate, x, with the equation for the 445 elliptic curve, with parameters a and b from the domain parameter set 446 of the curve, to solve for a y-coordinate, y. If there is no 447 solution to the quadratic equation, this operation fails and the 448 hunting-and-pecking process continues. If a solution is found, then 449 an ambiguity exists as there are technically two solutions to the 450 equation and pwd-seed is used to unambiguously select one of them. 451 If the low-order bit of pwd-seed is equal to the low-order bit of y, 452 then a candidate PE is defined as the point (x, y); if the low-order 453 bit of pwd-seed differs from the low-order bit of y, then a candidate 454 PE is defined as the point (x, p - y), where p is the prime over 455 which the curve is defined. The candidate PE becomes PE, a random 456 number is used instead of the base, and the hunting and pecking 457 continues until it has looped through k iterations. 459 Algorithmically, the process looks like this: 461 found = 0 462 counter = 0 463 base = H(username | password | salt) 464 do { 465 counter = counter + 1 466 pwd-seed = H(base | counter | p) 467 pwd-value = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 468 ClientHello.random | ServerHello.random) [0..p] 469 if (pwd-value < p) 470 then 471 x = pwd-value 472 if ( (y = sqrt(x^3 + ax + b)) != FAIL) 473 then 474 if (found == 0) 475 then 476 if (LSB(y) == LSB(pwd-seed)) 477 then 478 PE = (x, y) 479 else 480 PE = (x, p-y) 481 fi 482 found = 1 483 else 484 base = random() 485 fi 486 fi 487 fi 488 } while ((found == 0) || (counter <= k)) 490 Figure 2: Fixing PE for ECC Groups 492 The probability that one requires more than "n" iterations of the 493 "hunting and pecking" loop to find PE is roughly (q/2p)^n which 494 rapidly approaches zero (0) as "n" increases. Therefore the security 495 parameter, k, SHOULD be set sufficiently large such that the 496 probability that finding PE would take more than k iterations is 497 sufficiently small. 499 4.1.2. Computing an FFC Password Element 501 The group-specific operation for FFC groups takes pwd-value, and the 502 prime, p, and order, q, from the group's domain parameter set (see 503 Section 3.2.2 when the order is not part of the defined domain 504 parameter set) to directly produce a candidate password element, by 505 exponentiating the pwd-value to the value ((p-1)/q) modulo the prime. 506 If the result is greater than one (1), the candidate password element 507 becomes PE, and the hunting and pecking terminates successfully. 509 Algorithmically, the process looks like this: 511 found = 0 512 counter = 0 513 do { 514 counter = counter + 1 515 pwd-seed = H(base | counter | p) 516 pwd-value = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 517 ClientHello.random | ServerHello.random) [0..p] 518 if (pwd-value < p) 519 then 520 PE = pwd-value ^ ((p-1)/q) mod p 521 if (PE > 1) 522 then 523 found = 1 524 fi 525 fi 526 } while (found == 0) 528 Figure 3: Fixing PE for FFC Groups 530 4.2. Changes to Handshake Message Contents 532 4.2.1. Client Hello Changes 534 The client is required to identify herself to the server by adding a 535 PWD extension to the Client Hello message. The PWD extension uses 536 the standard mechanism defined in [RFC5246]. The "extension data" 537 field of the PWD extension SHALL contain a PWD_name which is used to 538 identify the password shared between the client and server. 540 enum { pwd(TBD) } ExtensionType; 542 opaque PWD_name<1..2^8-1>; 544 The PWD_name SHALL be UTF-8 encoded character string processed 545 according to the rules of the [RFC4013] profile of [RFC3454]. 547 A client offering a PWD ciphersuite MUST include the PWD extension in 548 her Client Hello. 550 If a server does not have a password identified by the PWD_name in 551 the PWD extension of the Client Hello, the server SHOULD hide that 552 fact by simulating the protocol-- putting random data in the PWD- 553 specific components of the Server Key Exchange-- and then rejecting 554 the client's finished message with a "bad_record_mac" alert. To 555 properly effect a simulated TLS-PWD exchange, an appropriate delay 556 SHOULD be inserted between receipt of the Client Hello and response 557 of the Server Hello. Alternately, a server MAY choose to terminate 558 the exchange if a password identified by the PWD_name in the PWD 559 extension of the Client Hello is not found. 561 The server decides on a group to use with the named user (see 562 Section 9 and generates the password element, PE, according to 563 Section 4.1.2. 565 4.2.2. Server Key Exchange Changes 567 The domain parameter set for the selected group MUST be specified in 568 the ServerKeyExchange, either explicitly or, in the case of some 569 elliptic curve groups, by name. In addition to the group 570 specification, the ServerKeyExchange also contains the server's 571 "committment" in the form of a scalar and element, and the salt which 572 was used to store the user's password. 574 Two new values have been added to the enumerated KeyExchangeAlgorithm 575 to indicate TLS-PWD using finite field cryptography, ff_pwd, and TLS- 576 PWD using elliptic curve cryptography, ec_pwd. 578 enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms; 580 struct { 581 opaque salt<1..2^8-1>; 582 opaque pwd_p<1..2^16-1>; 583 opaque pwd_g<1..2^16-1>; 584 opaque pwd_q<1..2^16-1>; 585 opaque ff_selement<1..2^16-1>; 586 opaque ff_sscalar<1..2^16-1>; 587 } ServerFFPWDParams; 589 struct 590 opaque salt<1..2^8-1>; 591 ECParameters curve_params; 592 ECPoint ec_selement; 593 opaque ec_sscalar<1..2^8-1>; 594 } ServerECPWDParams; 596 struct { 597 select (KeyExchangeAlgorithm) { 598 case ec_pwd: 599 ServerECPWDParams params; 600 case ff_pwd: 601 ServerFFPWDParams params; 602 }; 603 } ServerKeyExchange; 605 4.2.2.1. Generation of ServerKeyExchange 607 The scalar and Element that comprise the server's "committment" are 608 generated as follows. 610 First two random numbers, called private and mask, between zero and 611 the order of the group (exclusive) are generated. If their sum 612 modulo the order of the group, q, equals zero the numbers must be 613 thrown away and new random numbers generated. If their sum modulo 614 the order of the group, q, is greater than zero the sum becomes the 615 scalar. 617 scalar = (private + mask) mod q 619 The Element is then calculated as the inverse of the group's scalar 620 operation (see the group specific operations in Section 3.2) with the 621 mask and PE. 623 Element = inverse(scalar-op(mask, PE)) 625 After calculation of the scalar and Element the mask SHALL be 626 irretrievably destroyed. 628 4.2.2.1.1. ECC Server Key Exchange 630 EEC domain parameters are specified, either explicitly or named, in 631 the ECParameters component of the EEC-specific ServerKeyExchange as 632 defined in [RFC4492]. The scalar SHALL become the ec_sscalar 633 component and the Element SHALL become the ec_selement of the 634 ServerKeyExchange. If the client requested a specific point format 635 (compressed or uncompressed) with the Support Point Formats Extension 636 (see [RFC4492]) in its Client Hello, the Element MUST be formatted in 637 the ec_selement to conform to that request. 639 As mentioned in Section 3.2.1, elliptic curves over GF(2^m), so 640 called characteristic-2 curves, and curves with a co-factor greater 641 than one (1) SHALL NOT be used with TLS-PWD. 643 4.2.2.1.2. FFC Server Key Exchange 645 FFC domain parameters sent in the ServerKeyExchange are for the 646 group's prime, generator (which is only used for verification of the 647 group specification), and the order of the group's generator. The 648 scalar SHALL become the ff_sscalar component and the Element SHALL 649 become the ff_selement in the FFC-specific ServerKeyExchange. 651 As mentioned in Section 3.2.2 if the prime is a safe prime and no 652 order is included in the domain parameter set, the order added to the 653 ServerKeyExchange SHALL be the prime minus one divided by two-- 654 (p-1)/2. 656 4.2.2.2. Processing of ServerKeyExchange 658 Upon receipt of the ServerKeyExchange, the client decides whether to 659 support the indicated group or not. Named elliptic curves are easy 660 to validate-- either they are supported or they are not, but care 661 must be taken with FFC groups and explicitly specified ECC groups. 662 As mentioned in Section 3.5, the discrete logarithm problem MUST be 663 hard for any group used with this memo. The specific steps taken to 664 come to this assurance for a particular group are outside the scope 665 of this memo but they are the same steps to take when using the 666 Diffie-Hellman key exchange with TLS. If the client decides not to 667 support the group indicated in the ServerKeyExchange, she MUST abort 668 the exchange. 670 If the client decides to support the indicated group the server's 671 "commitment" MUST be validated by ensuring that: 1) the server's 672 scalar value is greater than zero (0) and less than the order of the 673 group, q; and 2) that the Element is valid for the chosen group (see 674 Section 3.2.2 and Section 3.2.1 for how to determine whether an 675 Element is valid for the particular group. Note that if the Element 676 is a compressed point on an elliptic curve it MUST be uncompressed 677 before checking its validity). 679 If the group is acceptable, the client extracts the salt from the 680 ServerKeyExchange and generates the password element, PE, according 681 to Section 3.4 and Section 4.1.2. 683 4.2.3. Client Key Exchange Changes 685 When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd, 686 the ClientKeyExchange is used to convey the client's "committment" to 687 the server. It, therefore, contains a scalar and an Element. 689 struct { 690 opaque ff_celement<1..2^16-1>; 691 opaque ff_cscalar<1..2^16-1>; 692 } ClientFFPWDParams; 694 struct 695 ECPoint ec_celement; 696 opaque ec_cscalar<1..2^8-1>; 697 } ClientECPWDParams; 699 struct { 700 select (KeyExchangeAlgorithm) { 701 case ff_pwd: ClientFFPWDParams; 702 case ec_pwd: ClientECPWDParams; 703 } exchange_keys; 704 } ClientKeyExchange; 706 4.2.3.1. Generation of Client Key Exchange 708 The client's scalar and Element are generated in the manner described 709 in Section 4.2.2.1. 711 For an FFC group, the scalar SHALL become the ff_cscalar component 712 and the Element SHALL become the ff_celement in the FFC-specific 713 ClientKeyExchange. 715 For an ECC group, the scalar SHALL become the ec_cscalar component 716 and the ELement SHALL become the ec_celement in the ECC-specific 717 ClientKeyExchange. If the client requested a specific point format 718 (compressed or uncompressed) with the Support Point Formats Extension 719 in its ClientHello, then the Element MUST be formatted in the 720 ec_celement to conform to its initial request. 722 4.2.3.2. Processing of Client Key Exchange 724 The server MUST validate the client's "committment" by ensuring that: 725 1) the client's scalar value is greater than zero (0) and less than 726 the order of the group, q; and 2) that the Element is valid for the 727 chosen group (see Section 3.2.2 and Section 3.2.1 for how to determin 728 whether an Element is valid for a particular group. Note that if the 729 Element is a compressed point on an elliptic curve it MUST be 730 uncompressed before checking its validity. 732 4.3. Computing the Premaster Secret 734 The client uses her own scalar and Element, denoted here 735 ClientKeyExchange.scalar and ClientKeyExchange.Element, the server's 736 scalar and Element, denoted here as ServerKeyExchange.scalar and 737 ServerKeyExchange.Element, and the random private value, denoted here 738 as client.private, she created as part of the generation of her 739 "commit" to compute an intermediate value, z, as indicated: 741 z = F(scalar-op(client.private, 742 element-op(ServerKeyExchange.Element, 743 scalar-op(ServerKeyExchange.scalar, PE)))) 745 With the same notation as above, the server uses his own scalar and 746 Element, the client's scalar and Element, and his random private 747 value, denoted here as server.private, he created as part of the 748 generation of his "commit" to compute the premaster secret as 749 follows: 751 z = F(scalar-op(server.private, 752 element-op(ClientKeyExchange.Element, 753 scalar-op(ClientKeyExchange.scalar, PE)))) 755 The intermediate value, z, is then used as the premaster secret after 756 any leading bytes of z that contain all zero bits have been stripped 757 off. 759 5. Ciphersuite Definition 761 This memo adds the following ciphersuites: 763 CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); 765 CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 767 CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 769 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 771 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 773 CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 775 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 777 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 779 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 781 Implementations conforming to this specification MUST support the 782 TLS_ECCPWD_WITH_AES_128_CCM_SHA ciphersuite; they SHOULD support 783 TLS_FFCPWD_WITH_AES_128_CCM_SHA, TLS_FFCPWD_WITH_AES_128_CBC_SHA, 784 TLS_ECCPWD_WITH_AES_128_CBC_SHA, TLS_ECCPWD_WITH_AES_128_GCM_SHA256, 785 TLS_ECCPWD_WITH_AES_256_GCM_SHS384; and MAY support the remaining 786 ciphersuites. 788 When negotiated with a version of TLS prior to 1.2, the Pseudo-Random 789 Function (PRF) from that version is used; otherwise, the PRF is the 790 TLS PRF [RFC5246] using the hash function indicated by the 791 ciphersuite. Regardless of the TLS version, the TLS-PWD random 792 function, H, is always instantiated with the hash algorithm indicated 793 by the ciphersuite. 795 For those ciphersuites that use Cipher Block Chaining (CBC) 796 [SP800-38A] mode, the MAC is HMAC [RFC2104] with the hash function 797 indicated by the ciphersuite. 799 6. Acknowledgements 801 The authenticated key exchange defined here has also been defined for 802 use in 802.11 networks, as an EAP method, and as an authentication 803 method for IKE. Each of these specifications has elicited very 804 helpful comments from a wide collection of people that have allowed 805 the definition of the authenticated key exchange to be refined and 806 improved. 808 The authors would like to thank Scott Fluhrer for discovering the 809 "password as exponent" attack that was possible in an early version 810 of this key exchange and for his very helpful suggestions on the 811 techniques for fixing the PE to prevent it. The authors would also 812 like to thank Hideyuki Suzuki for his insight in discovering an 813 attack against a previous version of the underlying key exchange 814 protocol. Special thanks to Lily Chen for helpful discussions on 815 hashing into an elliptic curve and to Jin-Meng Ho for suggesting the 816 countermeasures to protect against a small sub-group attack. Rich 817 Davis suggested the defensive checks that are part of the processing 818 of the ServerKeyExchange and ClientKeyExchange messages, and his 819 various comments have greatly improved the quality of this memo and 820 the underlying key exchange on which it is based. 822 Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik, discussed the 823 possibility of a side-channel attack against the hunting-and-pecking 824 loop on the TLS mailing list. That discussion prompted the addition 825 of the security parameter, k, to the hunting-and-pecking loop. 827 7. IANA Considerations 829 IANA SHALL assign a value for a new TLS extention type from the TLS 830 ExtensionType Registry defined in [RFC5246] with the name "pwd". The 831 RFC editor SHALL replace TBD in Section 4.2.1 with the IANA-assigned 832 value for this extension. 834 IANA SHALL assign nine new ciphersuites from the TLS Ciphersuite 835 Registry defined in [RFC5246] for the following ciphersuites: 837 CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); 839 CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 841 CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); 843 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 845 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 847 CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 849 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); 851 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 853 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 855 The RFC editor SHALL replace (TBD, TBD) in all the ciphersuites 856 defined in Section 5 with the appropriate IANA-assigned values. 858 8. Security Considerations 860 A passive attacker against this protocol will see the 861 ServerKeyExchange and the ClientKeyExchange containing the server's 862 scalar and Element, and the client's scalar and Element, 863 respectively. The client and server effectively hide their secret 864 private value by masking it modulo the order of the selected group. 865 If the order is "q", then there are approximately "q" distinct pairs 866 of numbers that will sum to the scalar values observed. It is 867 possible for an attacker to iterate through all such values but for a 868 large value of "q", this exhaustive search technique is 869 computationally infeasible. The attacker would have a better chance 870 in solving the discrete logarithm problem, which we have already 871 assumed (see Section 3.5) to be an intractable problem. 873 A passive attacker can take the Element from either the 874 ServerKeyExchange or the ClientKeyExchange and try to determine the 875 random "mask" value used in its construction and then recover the 876 other party's "private" value from the scalar in the same message. 878 But this requires the attacker to solve the discrete logarithm 879 problem which we assumed was intractable. 881 Both the client and the server obtain a shared secret, the premaster 882 secret, based on a secret group element and the private information 883 they contributed to the exchange. The secret group element is based 884 on the password. If they do not share the same password they will be 885 unable to derive the same secret group element and if they don't 886 generate the same secret group element they will be unable to 887 generate the same premaster secret. Seeing a finished message along 888 with the ServerKeyExchange and ClientKeyExchange will not provide any 889 additional advantage of attack since it is generated with the 890 unknowable premaster secret. 892 An active attacker impersonating the client can induce a server to 893 send a ServerKeyExchange containing the server's scalar and Element. 894 It can attempt to generate a ClientKeyExchange and send to the server 895 but the attacker is required to send a finished message first so the 896 only information she can obtain in this attack is less than the 897 information she can obtain from a passive attack, so this particular 898 active attack is not very fruitful. 900 An active attacker can impersonate the server and send a forged 901 ServerKeyExchange after receiving the ClientHello. The attacker then 902 waits until it receives the ClientKeyExchange and finished message 903 from the client. Now the attacker can attempt to run through all 904 possible values of the password, computing PE (see Section 4.1), 905 computing candidate premaster secrets (see Section 4.3), and 906 attempting to recreate the client's finished message. 908 But the attacker committed to a single guess of the password with her 909 forged ServerKeyExchange. That value was used by the client in her 910 computation of the premaster secret which was used to produce the 911 finished message. Any guess of the password which differs from the 912 one used in the forged ServerKeyExchange would result in each side 913 using a different PE in the computation of the premaster secret and 914 therefore the finished message cannot be verified as correct, even if 915 a subsequent guess, while running through all possible values, was 916 correct. The attacker gets one guess, and one guess only, per active 917 attack. 919 Instead of attempting to guess at the password, an attacker can 920 attempt to determine PE and then launch an attack. But PE is 921 determined by the output of the random function, H, which is 922 indistinguishable from a random source since H is assumed to be a 923 "random oracle" (Section 3.5). Therefore, each element of the finite 924 cyclic group will have an equal probability of being the PE. The 925 probability of guessing PE will be 1/q, where q is the order of the 926 group. For a large value of "q" this will be computationally 927 infeasible. 929 The implications of resistance to dictionary attack are significant. 930 An implementation can provision a password in a practical and 931 realistic manner-- i.e. it MAY be a character string and it MAY be 932 relatively short-- and still maintain security. The nature of the 933 pool of potential passwords determines the size of the pool, D, and 934 countermeasures can prevent an attacker from determining the password 935 in the only possible way: repeated, active, guessing attacks. For 936 example, a simple four character string using lower-case English 937 characters, and assuming random selection of those characters, will 938 result in D of over four hundred thousand. An attacker would need to 939 mount over one hundred thousand active, guessing attacks (which will 940 easily be detected) before gaining any significant advantage in 941 determining the pre-shared key. 943 Countermeasures to deal with successive active, guessing attacks are 944 only possible by noticing a certain username is failing repeatedly 945 over a certain period of time. Attacks which attempt to find a 946 password for a random user are more difficult to detect. For 947 instance, if a device uses a serial number as a username and the pool 948 of potential passwords is sufficiently small, a more effective attack 949 would be to select a password and try all potential "users" to 950 disperse the attack and confound countermeasures. It is therefore 951 RECOMMENDED that implementations of TLS-pwd keep track of the total 952 number of failed authentications regardless of username in an effort 953 to detect and thwart this type of attack. 955 The benefits of resistance to dictionary attack can be lessened by a 956 client using the same passwords with multiple servers. An attacker 957 could re-direct a session from one server to the other if the 958 attacker knew that the intended server stored the same password for 959 the client as another server. 961 An adversary that has access to, and a considerable amount of control 962 over, a client or server could attempt to mount a side-channel attack 963 to determine the number of times it took for a certain password (plus 964 client random and server random) to select a password element. Each 965 such attack could result in a successive paring-down of the size of 966 the pool of potential passwords, resulting in a manageably small set 967 from which to launch a series of active attacks to determine the 968 password. A security parameter, k, is used to normalize the amount 969 of work necessary to determine the password element (see 970 Section 4.1). The probability that a password will require more than 971 k iterations is roughly (q/2p)^k so it is possible to mitigate a side 972 channel attack at the expense of a constant cost per connection 973 attempt. 975 9. Implementation Considerations 977 The selection of the ciphersuite and selection of the particular 978 finite cyclic group to use with the ciphersuite are divorced in this 979 memo but they remain intimately close. 981 It is RECOMMENDED that implementations take note of the strength 982 estimates of particular groups and to select a ciphersuite providing 983 commensurate security with its hash and encryption algorithms. A 984 ciphersuite whose encryption algorithm has a keylength less than the 985 strength estimate, or whose hash algorithm has a blocksize that is 986 less than twice the strength estimate SHOULD NOT be used. 988 For example, the elliptic curve named secp256r1 (whose IANA-assigned 989 number is 23) provides an estimated 128 bits of strength and would be 990 compatible with an encryption algorithm supporting a key of that 991 length, and a hash algorithm that has at least a 256-bit blocksize. 992 Therefore, a suitable ciphersuite to use with secp256r1 could be 993 TLS_ECCPWD_WITH_AES_128_GCM_SHA256. 995 Resistance to dictionary attack means that the attacker must launch 996 an active attack to make a single guess at the password. If the size 997 of the pool from which the password was extracted was D, and each 998 password in the pool has an equal probability of being chosen, then 999 the probability of success after a single guess is 1/D. After X 1000 guesses, and removal of failed guesses from the pool of possible 1001 passwords, the probability becomes 1/(D-X). As X grows so does the 1002 probability of success. Therefore it is possible for an attacker to 1003 determine the password through repeated brute-force, active, guessing 1004 attacks. Implementations SHOULD take note of this fact and choose an 1005 appropriate pool of potential passwords-- i.e. make D big. 1006 Implementations SHOULD also take countermeasures, for instance 1007 refusing authentication attempts by a particular username for a 1008 certain amount of time, after the number of failed authentication 1009 attempts reaches a certain threshold. No such threshold or amount of 1010 time is recommended in this memo. 1012 10. References 1014 10.1. Normative References 1016 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1017 Hashing for Message Authentication", RFC 2104, 1018 February 1997. 1020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1021 Requirement Levels", BCP 14, RFC 2119, March 1997. 1023 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1024 Internationalized Strings ("stringprep")", RFC 3454, 1025 December 2002. 1027 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 1028 and Passwords", RFC 4013, February 2005. 1030 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1031 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1033 [SP800-38A] 1034 National Institute of Standards and Technology, 1035 "Recommendation for Block Cipher Modes of Operation-- 1036 Methods and Techniques", NIST Special Publication 800-38A, 1037 December 2001. 1039 10.2. Informative References 1041 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 1042 A Paradigm for Designing Efficient Protocols", Proceedings 1043 of the 1st ACM Conference on Computer and Communication 1044 Security, ACM Press, 1993. 1046 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1047 Requirements for Security", BCP 106, RFC 4086, June 2005. 1049 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1050 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1051 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1053 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1054 Mail Extensions (S/MIME) Version 3.2 Message 1055 Specification", RFC 5751, January 2010. 1057 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 1058 August 2010. 1060 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1061 Curve Cryptography Algorithms", RFC 6090, February 2011. 1063 [SP800-56A] 1064 Barker, E., Johnson, D., and M. Smid, "Recommendations for 1065 Pair-Wise Key Establishment Schemes Using Discrete 1066 Logarithm Cryptography", NIST Special Publication 800-56A, 1067 March 2007. 1069 Authors' Addresses 1071 Dan Harkins (editor) 1072 Aruba Networks 1073 1322 Crossman Avenue 1074 Sunnyvale, CA 94089-1113 1075 United States of America 1077 Email: dharkins@arubanetworks.com 1079 Dave Halasz (editor) 1080 Halasz Ventures 1081 8401 Chagrin Road, Suite 10A 1082 Chagrin Falls, OH 44023 1083 United States of America 1085 Email: david.e.halasz@gmail.com