idnits 2.17.1 draft-harkins-tls-dragonfly-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 23, 2018) is 2073 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7613 (Obsoleted by RFC 8265) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security D. Harkins, Ed. 3 Internet-Draft HP Enterprise 4 Intended status: Informational August 23, 2018 5 Expires: February 24, 2019 7 Secure Password Ciphersuites for Transport Layer Security (TLS) 8 draft-harkins-tls-dragonfly-04 10 Abstract 12 This memo defines several new ciphersuites for the Transport Layer 13 Security (TLS) protocol to support certificate-less, secure 14 authentication using only a simple, low-entropy, password. The 15 exchange is called TLS-PWD. The ciphersuites are all based on an 16 authentication and key exchange protocol, named "dragonfly", that is 17 resistant to off-line dictionary attack. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 24, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. The Case for Certificate-less Authentication . . . . . . 3 55 1.2. Resistance to Dictionary Attack . . . . . . . . . . . . . 3 56 2. Keyword Definitions . . . . . . . . . . . . . . . . . . . . . 4 57 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 5 60 3.2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . 5 61 3.2.2. Finite Field Cryptography . . . . . . . . . . . . . . 7 62 3.3. Instantiating the Random Function . . . . . . . . . . . . 8 63 3.4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 65 4. Specification of the TLS-PWD Handshake . . . . . . . . . . . 9 66 4.1. TLS-PWD pre-TLS 1.3 . . . . . . . . . . . . . . . . . . . 10 67 4.2. TLS-PWD in TLS 1.3 . . . . . . . . . . . . . . . . . . . 10 68 4.3. Protecting the Username . . . . . . . . . . . . . . . . . 10 69 4.3.1. Construction of a Protected Username . . . . . . . . 11 70 4.3.2. Recovery of a Protected Username . . . . . . . . . . 12 71 4.4. Fixing the Password Element . . . . . . . . . . . . . . . 13 72 4.4.1. Computing an ECC Password Element . . . . . . . . . . 15 73 4.4.2. Computing an FFC Password Element . . . . . . . . . . 17 74 4.4.3. Password Naming . . . . . . . . . . . . . . . . . . . 18 75 4.4.4. Generating TLS-PWD Commit . . . . . . . . . . . . . . 18 76 4.5. Changes to Handshake Message Contents . . . . . . . . . . 19 77 4.5.1. Changes to pre-1.3 TLS . . . . . . . . . . . . . . . 19 78 4.5.1.1. Client Hello Changes . . . . . . . . . . . . . . 19 79 4.5.1.2. Server Key Exchange Changes . . . . . . . . . . . 19 80 4.5.1.3. Client Key Exchange Changes . . . . . . . . . . . 21 81 4.5.2. Changes to TLS 1.3 . . . . . . . . . . . . . . . . . 23 82 4.5.2.1. TLS 1.3 KeyShare . . . . . . . . . . . . . . . . 23 83 4.5.2.2. Client Hello Changes . . . . . . . . . . . . . . 23 84 4.5.2.3. Server Hello Changes . . . . . . . . . . . . . . 24 85 4.5.2.4. Hello Retry Request Changes . . . . . . . . . . . 24 86 4.6. Computing the Shared Secret . . . . . . . . . . . . . . . 24 87 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . 25 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 91 9. Human Rights Considerations . . . . . . . . . . . . . . . . . 30 92 10. Implementation Considerations . . . . . . . . . . . . . . . . 30 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 95 11.2. Informative References . . . . . . . . . . . . . . . . . 32 97 Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 33 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 100 1. Background 102 1.1. The Case for Certificate-less Authentication 104 TLS usually uses public key certificates for authentication 105 [RFC5246]. This is problematic in some cases: 107 o Frequently, TLS [RFC5246] is used in devices owned, operated, and 108 provisioned by people who lack competency to properly use 109 certificates and merely want to establish a secure connection 110 using a more natural credential like a simple password. The 111 proliferation of deployments that use a self-signed server 112 certificate in TLS [RFC5246] followed by a basic password exchange 113 over the unauthenticated channel underscores this case. 115 o The alternatives to TLS-PWD for employing certificate-less TLS 116 authentication-- using pre-shared keys in an exchange that is 117 susceptible to dictionary attack, or using an SRP exchange that 118 requires users to, a priori, be fixed to a specific finite field 119 cryptography group for all subsequent connections-- are not 120 acceptable for modern applications that require both security and 121 cryptographic agility. 123 o A password is a more natural credential than a certificate (from 124 early childhood people learn the semantics of a shared secret), so 125 a password-based TLS ciphersuite can be used to protect an HTTP- 126 based certificate enrollment scheme like EST [RFC7030] to parlay a 127 simple password into a certificate for subsequent use with any 128 certificate-based authentication protocol. This addresses a 129 significant "chicken-and-egg" dilemma found with certificate-only 130 use of [RFC5246]. 132 o Some PIN-code readers will transfer the entered PIN to a smart 133 card in clear text. Assuming a hostile environment, this is a bad 134 practice. A password-based TLS ciphersuite can enable the 135 establishment of an authenticated connection between reader and 136 card based on the PIN. 138 1.2. Resistance to Dictionary Attack 140 It is a common misconception that a protocol that authenticates with 141 a shared and secret credential is resistent to dictionary attack if 142 the credential is assumed to be an N-bit uniformly random secret, 143 where N is sufficiently large. The concept of resistence to 144 dictionary attack really has nothing to do with whether that secret 145 can be found in a standard collection of a language's defined words 146 (i.e. a dictionary). It has to do with how an adversary gains an 147 advantage in attacking the protocol. 149 For a protocol to be resistant to dictionary attack any advantage an 150 adversary can gain must be a function of the amount of interactions 151 she makes with an honest protocol participant and not a function of 152 the amount of computation she uses. This means that the adversary 153 will not be able to obtain any information about the password except 154 whether a single guess from a single protocol run which she took part 155 in is correct or incorrect. 157 It is assumed that the attacker has access to a pool of data from 158 which the secret was drawn-- it could be all numbers between 1 and 159 2^N, it could be all defined words in a dictionary. The key is that 160 the attacker cannot do an attack and then go off-line and enumerate 161 through the pool trying potential secrets (computation) to see if one 162 is correct. She must do an active attack for each secret she wishes 163 to try (interaction) and the only information she can glean from that 164 attack is whether the secret used with that particular attack is 165 correct or not. 167 2. Keyword Definitions 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 3. Introduction 175 3.1. Notation 177 The following notation is used in this memo: 179 password 180 a secret, and potentially low-entropy word, phrase, code or key 181 used as a credential for authentication. The password is shared 182 between the TLS client and TLS server. 184 y = H(x) 185 a binary string of arbitrary length, x, is given to a function H 186 which produces a fixed-length output, y. 188 a | b 189 denotes concatenation of string a with string b. 191 [a]b 192 indicates a string consisting of the single bit "a" repeated "b" 193 times. 195 x mod y 196 indicates the remainder of division of x by y. The result will 197 be between 0 and y. 199 len(x) 200 indicates the length in bits of the string x. 202 lgr(a,b) 203 takes "a" and a prime, b and returns the legendre symbol (a/b). 205 LSB(x) 206 returns the least-significant bit of the bitstring "x". 208 G.x 209 indicates the x-coordinate of a point, G, on an elliptic curve. 211 3.2. Discrete Logarithm Cryptography 213 The ciphersuites defined in this memo use discrete logarithm 214 cryptography (see [SP800-56A]) to produce an authenticated and shared 215 secret value that is an element in a group defined by a set of domain 216 parameters. The domain parameters can be based on either Finite 217 Field Cryptography (FFC) or Elliptic Curve Cryptography (ECC). 219 Elements in a group, either an FFC or ECC group, are indicated using 220 upper-case while scalar values are indicated using lower-case. 222 3.2.1. Elliptic Curve Cryptography 224 The authenticated key exchange defined in this memo uses fundamental 225 algorithms of elliptic curves defined over GF(p) as described in 226 [RFC6090]. Ciphersuites defined in this memo SHALL only use ECC 227 curves based on the Weierstrass equation y^2 = x^3 + a*x + b. 229 Domain parameters for the ECC groups used by this memo are: 231 o A prime, p, determining a prime field GF(p). The cryptographic 232 group will be a subgroup of the full elliptic curve group which 233 consists points on an elliptic curve-- elements from GF(p) that 234 satisfy the curve's equation-- together with the "point at 235 infinity" that serves as the identity element. 237 o Elements a and b from GF(p) that define the curve's equation. The 238 point (x,y) in GF(p) x GF(p) is on the elliptic curve if and only 239 if (y^2 - x^3 - a*x - b) mod p equals zero (0). 241 o A point, G, on the elliptic curve, which serves as a generator for 242 the ECC group. G is chosen such that its order, with respect to 243 elliptic curve addition, is a sufficiently large prime. 245 o A prime, q, which is the order of G, and thus is also the size of 246 the cryptographic subgroup that is generated by G. 248 o A co-factor, f, defined by the requirement that the size of the 249 full elliptic curve group (including the "point at infinity") is 250 the product of f and q. 252 This memo uses the following ECC Functions: 254 o Z = elem-op(X,Y) = X + Y: two points on the curve X and Y, are 255 sumed to produce another point on the curve, Z. This is the group 256 operation for ECC groups. 258 o Z = scalar-op(x,Y) = x * Y: an integer scalar, x, acts on a point 259 on the curve, Y, via repetitive addition (Y is added to itself x 260 times), to produce another EEC element, Z. 262 o Y = inverse(X): a point on the curve, X, has an inverse, Y, which 263 is also a point on the curve, when their sum is the "point at 264 infinity" (the identity for elliptic curve addition). In other 265 words, R + inverse(R) = "0". 267 o z = F(X): the x-coordinate of a point (x, y) on the curve is 268 returned. This is a mapping function to convert a group element 269 into an integer. 271 Only ECC groups over GF(p) can be used with TLS-PWD. ECC groups over 272 GF(2^m) SHALL NOT be used by TLS-PWD. In addition, ECC groups with a 273 co-factor greater than one (1) SHALL NOT be used by TLS-PWD. 275 A composite (x, y) pair can be validated as a point on the elliptic 276 curve by checking whether: 1) both coordinates x and y are greater 277 than zero (0) and less than the prime defining the underlying field; 278 2) the x- and y- coordinates satisfy the equation of the curve; and 279 3) they do not represent the point-at-infinity "0". If any of those 280 conditions are not true the (x, y) pair is not a valid point on the 281 curve. 283 A compliant implementaiton of TLS-PWD SHALL support group twenty- 284 three (23) and SHOULD support group group twenty-four (24) from 285 [named_groups]. 287 3.2.2. Finite Field Cryptography 289 Domain parameters for the FFC groups used by this memo are: 291 o A prime, p, determining a prime field GF(p), the integers modulo 292 p. The FFC group will be a subgroup of GF(p)*, the multiplicative 293 group of non-zero elements in GF(p). 295 o An element, G, in GF(p)* which serves as a generator for the FFC 296 group. G is chosen such that its multiplicative order is a 297 sufficiently large prime divisor of ((p-1)/2). 299 o A prime, q, which is the multiplicative order of G, and thus also 300 the size of the cryptographic subgroup of GF(p)* that is generated 301 by G. 303 This memo uses the following FFC Functions: 305 o Z = elem-op(X,Y) = (X * Y) mod p: two FFC elements, X and Y, are 306 multiplied modulo the prime, p, to produce another FFC element, Z. 307 This is the group operation for FFC groups. 309 o Z = scalar-op(x,Y) = Y^x mod p: an integer scalar, x, acts on an 310 FFC group element, Y, via exponentiation modulo the prime, p, to 311 produce another FFC element, Z. 313 o Y = inverse(X): a group element, X, has an inverse, Y, when the 314 product of the element and its inverse modulo the prime equals one 315 (1). In other words, (X * inverse(X)) mod p = 1. 317 o z = F(X): is the identity function since an element in an FFC 318 group is already an integer. It is included here for consistency 319 in the specification. 321 Many FFC groups used in IETF protocols are based on safe primes and 322 do not define an order (q). For these groups, the order (q) used in 323 this memo shall be the prime of the group minus one divided by two-- 324 (p-1)/2. 326 An integer can be validated as being an element in an FFC group by 327 checking whether: 1) it is between one (1) and the prime, p, 328 exclusive; and 2) if modular exponentiation of the integer by the 329 group order, q, equals one (1). If either of these conditions are 330 not true the integer is not an element in the group. 332 A compliant implementaiton of TLS-PWD SHOULD support group two- 333 hundred fifty-six (256) and group group two-hundred fifty-eight (258) 334 from [named_groups]. 336 3.3. Instantiating the Random Function 338 The protocol described in this memo uses a random function, H, which 339 is modeled as a "random oracle". At first glance, one may view this 340 as a hash function. As noted in [RANDOR], though, hash functions are 341 too structured to be used directly as a random oracle. But they can 342 be used to instantiate the random oracle. 344 The random function, H, in this memo is instantiated by using the 345 hash algorithm defined by the particular TLS-PWD ciphersuite in HMAC 346 mode with a key whose length is equal to block size of the hash 347 algorithm and whose value is zero. For example, if the ciphersuite 348 is TLS_ECCPWD_WITH_AES_128_GCM_SHA256 then H will be instantiated 349 with SHA256 as: 351 H(x) = HMAC-SHA256([0]32, x) 353 3.4. Passwords 355 The authenticated key exchange used in TLS-PWD requires each side to 356 have a common view of a shared credential. To protect the server's 357 database of stored passwords, a password MAY be salted. When 358 [RFC5246] or earlier is used, the password SHALL be salted. When 359 [RFC8446] is used, a password MAY be stored with a salt or without. 360 The password, username, and optionally the salt can create an 361 irreversible digest called the base which is used in the 362 authenticated key exchange. 364 The salting function is defined as: 366 base = HMAC-SHA256(salt, username | password) 368 The unsalted function is defined as: 370 base = SHA256(username | password) 372 The password used for generation of the base SHALL be represented as 373 a UTF-8 encoded character string processed according to the rules of 374 the OpaqueString profile of [RFC7613] and the salt SHALL be a 32 375 octet random number. The server SHALL store a tuple of the form: 377 { username, base, salt } 379 if the password is salted and: 381 { username, base } 383 if it is not. When password salting is being used the client 384 generates the base upon receiving the salt from the server, otherwise 385 it may store the base at the time the username and password is 386 provisioned. 388 3.5. Assumptions 390 The security properties of the authenticated key exchange defined in 391 this memo are based on a number of assumptions: 393 1. The random function, H, is a "random oracle" as defined in 394 [RANDOR]. 396 2. The discrete logarithm problem for the chosen group is hard. 397 That is, given g, p, and y = g^x mod p, it is computationally 398 infeasible to determine x. Similarly, for an ECC group given the 399 curve definition, a generator G, and Y = x * G, it is 400 computationally infeasible to determine x. 402 3. Quality random numbers with sufficient entropy can be created. 403 This may entail the use of specialized hardware. If such 404 hardware is unavailable a cryptographic mixing function (like a 405 strong hash function) to distill enropy from multiple, 406 uncorrelated sources of information and events may be needed. A 407 very good discussion of this can be found in [RFC4086]. 409 If the server supports username protection (see Section 4.3), it is 410 assumed that the server has chosen a domain parameter set and 411 generated a username-protection keypair. The chosen domain parameter 412 set and public key are assumed to be conveyed to the client at the 413 time the client's username and password were provisioned. 415 4. Specification of the TLS-PWD Handshake 417 The key exchange underlying TLS-PWD is the "dragonfly" PAKE as 418 defined in [RFC7664]. 420 The authenticated key exchange is accomplished by each side deriving 421 a password-based element, PE, in the chosen group, making a 422 "commitment" to a single guess of the password using PE, and 423 generating a shared secret. The ability of each side to produce a 424 valid finished message using a key derived from the shared secret 425 authenticates itself to the other side. 427 The authenticated key exchange is dropped into the standard TLS 428 message handshake by defining extensions to some of the messages. 430 4.1. TLS-PWD pre-TLS 1.3 432 Client Server 433 -------- -------- 435 Client Hello (name) --------> 437 Server Hello 438 Server Key Exchange (commit) 439 <-------- Server Hello Done 441 Client Key Exchange (commit) 442 [Change cipher spec] 443 Finished --------> 445 [Change cipher spec] 446 <-------- Finished 448 Application Data <-------> Application Data 450 Figure 1 452 4.2. TLS-PWD in TLS 1.3 454 Client Server 455 -------- -------- 456 ClientHello (name) 457 + key_share (commit) --------> 458 ServerHello 459 + key_share (commit) 460 {EncryptedExtensions} 461 {Finished} 462 <-------- [Application Data*] 463 {Finished} --------> 464 [Application Data] <-------> [Application Data] 466 Figure 2 468 4.3. Protecting the Username 470 The client is required to identify herself to the server before the 471 server can look up the appropriate client credential with which to 472 perform the authenticated key exchange. This has negative privacy 473 implicaitons and opens up the client to tracking and increased 474 monitoring. It is therefore useful for the client to be able to 475 protect her username from passive monitors of the exchange and 476 against active attack by a malicious server. TLS-PWD provides such a 477 mechsnism. Support for protected usernames is RECOMMENDED. 479 To enable username protection a server choses a domain parameter set 480 and generates an ephemeral public/private keypair. This keypair 481 SHALL only be used for username protection. For efficiency, the 482 domain parameter set used for userame protection MUST be based on 483 elliptic curve cryptography. Any ECC group that is appropriate for 484 TLS-PWD (see Section 3.2.1) is suitable for this purpose but for 485 interoperability prime256v1 (aka NIST's p256 curve) MUST be 486 supported. The domain parameter set chosen for username protection 487 is independent of the domain parameter set chosen for the underlying 488 key exchange-- i.e. they need not be the same. 490 When the client's username and password are provisioned on the 491 server, the chosen group and its public key are provisioned on the 492 client. This is stored on the client along with the server-specific 493 state (e.g. the hostname) it uses to initiate a TLS-PWD exchange. 494 The server uses the same group and public key with all clients. 496 To protect a username, the client and server perform a static- 497 ephemeral Diffie-Hellman exchange. Since the y-coordinate is not 498 necessary and eliminating it will reduce message size, compact 499 representation (and therefore compact output, see [RFC6090]) are used 500 in the static-ephemeral Diffie-Hellman exchange. The result of the 501 Diffie-Hellman exchange is passed to HKDF [RFC5869] to create a key- 502 encrypting key suitable for AES-SIV [RFC5297] in its deterministic 503 authenticated encryption mode. The length of the key-encrypting key, 504 l, and the hash function to use with HKDF depends on the length of 505 the prime, p, of the group used to provide username protection: 507 o SHA-256, SIV-128, l=256 bits: when len(p) <= 256 509 o SHA-384, SIV-192, l=384 bits: when 256 < len(p) <= 384 511 o SHA-512, SIV-256, l=512 bits: when len(p) > 384 513 4.3.1. Construction of a Protected Username 515 Prior to initiating a TLS-PWD exchange, the client chooses a random 516 secret, c, such that 1 < c < (q-1), where q is the order of the group 517 from which the server's public key was generated, and uses scalar- 518 op() with the group's generator to create a public key, C. It uses 519 scalar-op() with the server's public key and c to create a shared 520 secret and derives a key-encrypting key, k, using the "salt-less" 521 mode of HKDF [RFC5869]. 523 C = scalar-op(c, G) 524 Z = scalar-op(c, S) 526 k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) 528 Where NULL indicates the salt-free invocation and "" indicates an 529 empty string (i.e. there is no "context" passed to HKDF). 531 The client's username SHALL be represented as a UTF-8 encoded 532 character string processed according to the rules of the OpaqueString 533 profile of [RFC7613]. The output of OpaqueString is then passed with 534 the key, k, to SIV-encrypt with no AAD and no nonce to produce an 535 encrypted username, u: 537 u = SIV-encrypt(k, username) 539 Note: the format of the ciphertext output from SIV includes the 540 authenticating synthetic initialization vector. 542 The protected username SHALL be the concatenation of the x-coordinate 543 of the client's public key, C, and the encrypted username, u. The 544 length of the x-coordinate of C MUST be equal to the length of the 545 group's prime, p, pre-pended with zeros, if necessary. The protected 546 username is inserted into the PWD_name extension and the 547 ExtensionType MUST be PWD_protect (see Section 4.5.1.1). 549 To ensure the username remains confidential, the random secret, c, 550 MUST be generated from a source of random entropy, see section 551 Section 3.5. 553 The length of the ciphertext output from SIV, minus the synthetic 554 initialization vector, will be equal to the length of the input 555 plaintext, in this case the username. To further foil traffic 556 analysis, it is RECOMMENDED that clients append a series of NULL 557 bytes to their usernames prior to passing them to SIV-encrypt() such 558 that the resulting padded length of the username is at least 128 559 octets. 561 4.3.2. Recovery of a Protected Username 563 A server that receives a protected username needs to recover the 564 client's username prior to performing the key exchange. To do so, 565 the server computes the client's public key, completes the static- 566 ephemeral Diffie-Hellman exchange, derives the key encrypting key, k, 567 and decrypts the username. 569 The length of the x-coordinate of the client's public key is known 570 (it is the length of the prime from the domain parameter set used to 571 protect usernames) and can easily be separated from the ciphertext in 572 the PWD_name extension in the Client Hello-- the first len(p) bits 573 are the x-coordinate of the client's public key and the remaining 574 bits are the ciphertext. 576 Since compressed representation is used by the client, the server 577 MUST compute the y-coordinate of the client's public key by using the 578 equation of the curve: 580 y^2 = x^3 + ax + b 582 and solving for y. There are two solutions for y but since 583 compressed output is also being used, the selection is irrelevant. 584 The server reconstructs the client's public value, C, from (x, y). 585 If there is no solution for y, or if (x, y) is not a valid point on 586 the elliptic curve (see Section 3.2.1), the server MUST treat the 587 Client Hello as if it did not have a password for a given username 588 (see Section 4.5.1.1). 590 The server then uses scalar-op() with the reconstructed point C and 591 the private key it uses for protected passwords, s, to generate a 592 shared secret, and derives a key-encrypting key, k, in the same 593 manner as in Section 4.3.1. 595 Z = scalar-op(s, C) 597 k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) 599 The key, k, and the ciphertext portion of the PWD_name extension, u, 600 are passed to SIV-decrypt with no AAD and no nonce to produce the 601 username: 603 username = SIV-decrypt(k, u) 605 If SIV-decrypt returns the symbol FAIL indicating unsuccessful 606 decryption and verification the server MUST treat the ClientHello as 607 if it did not have a password for a given username (see 608 Section 4.5.1.1). If successful, the server has obtained the 609 client's username and can process it as needed. Any NULL octets 610 added by the client prior to encryption can be easily stripped off of 611 the string that represents the username. 613 4.4. Fixing the Password Element 615 Prior to making a "commitment" both sides must generate a secret 616 element, PE, in the chosen group using the common password-derived 617 base. The server generates PE after it receives the Client Hello and 618 chooses the particular group to use, and the client generates PE 619 prior to sending the ClientHello in TLS 1.3 and upon receipt of the 620 Server Key Exchange in TLS pre 1.3. 622 Fixing the password element involves an iterative "hunting and 623 pecking" technique using the prime from the negotiated group's domain 624 parameter set and an ECC- or FFC-specific operation depending on the 625 negotiated group. 627 To thwart side channel attacks which attempt to determine the number 628 of iterations of the "hunting-and-pecking" loop are used to find PE 629 for a given password, a security parameter, m, is used to ensure that 630 at least m iterations are always performed. 632 First, an 8-bit counter is set to the value one (1). Then, H is used 633 to generate a password seed from the a counter, the prime of the 634 selected group, and the base (which is derived from the username, 635 password, and, optionally, salt): 637 pwd-seed = H(base | counter | p) 639 Then, using the technique from section B.5.1 of [FIPS186-3], the pwd- 640 seed is expanded using the PRF to the length of the prime from the 641 negotiated group's domain parameter set plus a constant sixty-four 642 (64) to produce an intermediate pwd-tmp which is modularly reduced to 643 create pwd-value: 645 n = len(p) + 64 646 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 647 ClientHello.random | ServerHello.random) [0..n]; 648 pwd-value = (pwd-tmp mod (p-1)) + 1 650 The pwd-value is then passed to the group-specific operation which 651 either returns the selected password element or fails. If the group- 652 specific operation fails, the counter is incremented, a new pwd-seed 653 is generated, and the hunting-and-pecking continues. This process 654 continues until the group-specific operation returns the password 655 element. After the password element has been chosen, the base is 656 changed to a random number, the counter is incremented and the 657 hunting-and-pecking continues until the counter is greater than the 658 security parameter, m. 660 The probability that one requires more than n iterations of the 661 "hunting and pecking" loop to find an ECC PE is roughly (q/2p)^n and 662 to find an FFC PE is roughly (q/p)^n, both of which rapidly approach 663 zero (0) as n increases. The security parameter, m, SHOULD be set 664 sufficiently large such that the probability that finding PE would 665 take more than m iterations is sufficiently small (see Section 8). 667 When PE has been discovered, pwd-seed, pwd-tmp, and pwd-value SHALL 668 be irretrievably destroyed. 670 4.4.1. Computing an ECC Password Element 672 The group-specific operation for ECC groups uses pwd-value, pwd-seed, 673 and the equation for the curve to produce PE. First, pwd-value is 674 used directly as the x-coordinate, x, with the equation for the 675 elliptic curve, with parameters a and b from the domain parameter set 676 of the curve, to solve for a y-coordinate, y. If there is no 677 solution to the quadratic equation, this operation fails and the 678 hunting-and-pecking process continues. If a solution is found, then 679 an ambiguity exists as there are technically two solutions to the 680 equation and pwd-seed is used to unambiguously select one of them. 681 If the low-order bit of pwd-seed is equal to the low-order bit of y, 682 then a candidate PE is defined as the point (x, y); if the low-order 683 bit of pwd-seed differs from the low-order bit of y, then a candidate 684 PE is defined as the point (x, p - y), where p is the prime over 685 which the curve is defined. The candidate PE becomes PE, a random 686 number is used instead of the base, and the hunting and pecking 687 continues until it has looped through m iterations, where m is a 688 suitably large number to prevent side channel attack (see [RFC7664]). 690 Algorithmically, the process looks like this: 692 found = 0 693 counter = 0 694 n = len(p) + 64 695 do { 696 counter = counter + 1 697 seed = H(base | counter | p) 698 tmp = PRF(seed, "TLS-PWD Hunting And Pecking", 699 ClientHello.random | ServerHello.random) [0..n] 700 val = (tmp mod (p-1)) + 1 701 if ( (val^3 + a*val + b) mod p is a quadratic residue) 702 then 703 if (found == 0) 704 then 705 x = val 706 save = seed 707 found = 1 708 base = random() 709 fi 710 fi 711 } while ((found == 0) || (counter <= m)) 712 y = sqrt(x^3 + a*x + b) mod p 713 if ( lsb(y) == lsb(save)) 714 then 715 PE = (x, y) 716 else 717 PE = (x, p-y) 718 fi 720 Figure 3: Fixing PE for ECC Groups 722 Checking whether a value is a quadradic residue modulo a prime can 723 leak information about that value in a side-channel attack. 724 Therefore, it is RECOMMENDED that the technique used to determine if 725 the value is a quadratic residue modulo p first blind the value with 726 a random number so that the blinded value can take on all numbers 727 between 1 and p-1 with equal probability. Determining the quadratic 728 residue in a fashion that resists leakage of information is handled 729 by flipping a coin and multiplying the blinded value by either a 730 random quadratic residue or a random quadratic nonresidue and 731 checking whether the multiplied value is a quadradic residue or a 732 quadradic nonresidue modulo p, respectively. The random residue and 733 nonresidue can be calculated prior to hunting-and-pecking by 734 calculating the legendre symbol on random values until they are 735 found: 737 do { 738 qr = random() 739 } while ( lgr(qr, p) != 1) 741 do { 742 qnr = random() 743 } while ( lgr(qnr, p) != -1) 745 Algorithmically, the masking technique to find out whether a value is 746 a quadratic residue modulo a prime or not looks like this: 748 is_quadratic_residue (val, p) { 749 r = (random() mod (p - 1)) + 1 750 num = (val * r * r) mod p 751 if ( lsb(r) == 1 ) 752 num = (num * qr) mod p 753 if ( lgr(num, p) == 1) 754 then 755 return TRUE 756 fi 757 else 758 num = (num * qnr) mod p 759 if ( lgr(num, p) == -1) 760 then 761 return TRUE 762 fi 763 fi 764 return FALSE 765 } 767 The random quadratic residue and quadratic non-residue (qr and qnr 768 above) can be used for all the hunting-and-pecking loops but the 769 blinding value, r, MUST be chosen randomly for each loop. 771 4.4.2. Computing an FFC Password Element 773 The group-specific operation for FFC groups takes pwd-value, and the 774 prime, p, and order, q, from the group's domain parameter set (see 775 Section 3.2.2 when the order is not part of the defined domain 776 parameter set) to directly produce a candidate password element, by 777 exponentiating the pwd-value to the value ((p-1)/q) modulo the prime. 778 If the result is greater than one (1), the candidate password element 779 becomes PE, and the hunting and pecking continues until it has looped 780 through m iterations, where m is a suitably large number to prevent 781 side channel attack (see [RFC7664]). 783 Algorithmically, the process looks like this: 785 found = 0 786 counter = 0 787 n = len(p) + 64 788 do { 789 counter = counter + 1 790 pwd-seed = H(base | counter | p) 791 pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", 792 ClientHello.random | ServerHello.random) [0..n] 793 pwd-value = (pwd-tmp mod (p-1)) + 1 794 PE = pwd-value ^ ((p-1)/q) mod p 795 if (PE > 1) 796 then 797 found = 1 798 base = random() 799 fi 800 } while ((found == 0) || (counter <= m)) 802 Figure 4: Fixing PE for FFC Groups 804 4.4.3. Password Naming 806 The client is required to identify herself to the server by adding a 807 either a PWD_protect or PWD_clear extension to her Client Hello 808 message depending on whether the client wishes to protect her 809 username (see Section 4.3) or not, respectively. The PWD_protect and 810 PWD_clear extensions use the standard mechanism defined in [RFC5246]. 811 The "extension data" field of the PWD extension SHALL contain a 812 PWD_name which is used to identify the password shared between the 813 client and server. If username protection is performed, and the 814 ExtensionType is PWD_protect, the contents of the PWD_name SHALL be 815 constructed according to Section 4.3.1). 817 enum { PWD_clear(TBD1), PWD_protect(TBD2) } ExtensionType; 819 opaque PWD_name<1..2^8-1>; 821 An unprotected PWD_name SHALL be UTF-8 encoded character string 822 processed according to the rules of the OpaqueString profile of 823 [RFC7613] and a protected PWD_name SHALL be a string of bits. 825 4.4.4. Generating TLS-PWD Commit 827 The scalar and Element that comprise each peer's "commitment" are 828 generated as follows. 830 First two random numbers, called private and mask, between zero and 831 the order of the group (exclusive) are generated. If their sum 832 modulo the order of the group, q, equals zero (0) or one (1) the 833 numbers must be thrown away and new random numbers generated. If 834 their sum modulo the order of the group, q, is greater than one the 835 sum becomes the scalar. 837 scalar = (private + mask) mod q 839 The Element is then calculated as the inverse of the group's scalar 840 operation (see the group specific operations in Section 3.2) with the 841 mask and PE. 843 Element = inverse(scalar-op(mask, PE)) 845 After calculation of the scalar and Element the mask SHALL be 846 irretrievably destroyed. 848 4.5. Changes to Handshake Message Contents 850 4.5.1. Changes to pre-1.3 TLS 852 4.5.1.1. Client Hello Changes 854 A client offering a PWD ciphersuite MUST include one of the PWD_name 855 extensions from Section 4.4.3 in her Client Hello. 857 If a server does not have a password for a client identified by the 858 username either extracted from the PWD_name, if unprotected, or 859 recovered using the technique in Section 4.3.2, if protected, or if 860 recovery of a protected username fails, the server SHOULD hide that 861 fact by simulating the protocol-- putting random data in the PWD- 862 specific components of the Server Key Exchange-- and then rejecting 863 the client's finished message with a "bad_record_mac" alert. To 864 properly effect a simulated TLS-PWD exchange, an appropriate delay 865 SHOULD be inserted between receipt of the Client Hello and response 866 of the Server Hello. Alternately, a server MAY choose to terminate 867 the exchange if a password is not found. The security implication of 868 terminating the exchange is to expose to an attacker whether a 869 username is valid or not. 871 The server decides on a group to use with the named user (see 872 Section 10 and generates the password element, PE, according to 873 Section 4.4.2. 875 4.5.1.2. Server Key Exchange Changes 877 The domain parameter set for the selected group MUST be explicitly 878 specified by name in the ServerKeyExchange. ECC groups are specified 879 using the NamedGroup enumeration of [RFC4492] and FFC groups are 880 specified using the NamedGroup extensions added by [RFC7919] and the 881 registry in [named_groups]. In addition to the group specification, 882 the ServerKeyExchange also contains the server's "commitment" in the 883 form of a scalar and element, and the salt which was used to store 884 the user's password. 886 Two new values have been added to the enumerated KeyExchangeAlgorithm 887 to indicate TLS-PWD using finite field cryptography, ff_pwd, and TLS- 888 PWD using elliptic curve cryptography, ec_pwd. 890 enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms; 892 struct { 893 opaque salt<1..2^8-1>; 894 NamedGroup ff_group; 895 opaque ff_selement<1..2^16-1>; 896 opaque ff_sscalar<1..2^16-1>; 897 } ServerFFPWDParams; 899 struct { 900 opaque salt<1..2^8-1>; 901 ECParameters curve_params; 902 ECPoint ec_selement; 903 opaque ec_sscalar<1..2^8-1>; 904 } ServerECPWDParams; 906 struct { 907 select (KeyExchangeAlgorithm) { 908 case ec_pwd: 909 ServerECPWDParams params; 910 case ff_pwd: 911 ServerFFPWDParams params; 912 }; 913 } ServerKeyExchange; 915 4.5.1.2.1. Generation of ServerKeyExchange 917 The scalar and Element referenced in this section are derived 918 according to Section 4.4.4. 920 4.5.1.2.1.1. ECC Server Key Exchange 922 EEC domain parameters are specified in the ECParameters component of 923 the EEC-specific ServerKeyExchange as defined in [RFC4492]. The 924 scalar SHALL become the ec_sscalar component and the Element SHALL 925 become the ec_selement of the ServerKeyExchange. If the client 926 requested a specific point format (compressed or uncompressed) with 927 the Support Point Formats Extension (see [RFC4492]) in its Client 928 Hello, the Element MUST be formatted in the ec_selement to conform to 929 that request. If the client offered (an) elliptic curve(s) in its 930 ClientHello using the Supported Elliptic Curves Extension, the server 931 MUST include (one of the) named curve(s) in the ECParameters field in 932 the ServerKeyExchange and the key exchange operations specified in 933 Section 4.5.1.2.1 MUST use that group. 935 As mentioned in Section 3.2.1, elliptic curves over GF(2^m), so 936 called characteristic-2 curves, and curves with a co-factor greater 937 than one (1) SHALL NOT be used with TLS-PWD. 939 4.5.1.2.1.2. FFC Server Key Exchange 941 FFC domain parameters using the NamedGroup extension specified in 942 [RFC7919]. The scalar SHALL become the ff_sscalar component and the 943 Element SHALL become the ff_selement in the FFC-specific 944 ServerKeyExchange. 946 As mentioned in Section 3.2.2 if the prime is a safe prime and no 947 order is included in the domain parameter set, the order added to the 948 ServerKeyExchange SHALL be the prime minus one divided by two-- 949 (p-1)/2. 951 4.5.1.2.2. Processing of ServerKeyExchange 953 Upon receipt of the ServerKeyExchange, the client decides whether to 954 support the indicated group or not. If the client decides to support 955 the indicated group the server's "commitment" MUST be validated by 956 ensuring that: 1) the server's scalar value is greater than one (1) 957 and less than the order of the group, q; and 2) that the Element is 958 valid for the chosen group (see Section 3.2.2 and Section 3.2.1 for 959 how to determine whether an Element is valid for the particular 960 group. Note that if the Element is a compressed point on an elliptic 961 curve it MUST be uncompressed before checking its validity). 963 If the group is acceptable and the server's "commitment" has been 964 successfully validated, the client extracts the salt from the 965 ServerKeyExchange and generates the password element, PE, according 966 to Section 3.4 and Section 4.4.2. If the group is not acceptable or 967 the server's "commitment" failed validation, the exchange MUST be 968 aborted. 970 4.5.1.3. Client Key Exchange Changes 972 When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd, 973 the ClientKeyExchange is used to convey the client's "commitment" to 974 the server. It, therefore, contains a scalar and an Element. 976 struct { 977 opaque ff_celement<1..2^16-1>; 978 opaque ff_cscalar<1..2^16-1>; 979 } ClientFFPWDParams; 981 struct { 982 ECPoint ec_celement; 983 opaque ec_cscalar<1..2^8-1>; 984 } ClientECPWDParams; 986 struct { 987 select (KeyExchangeAlgorithm) { 988 case ff_pwd: ClientFFPWDParams; 989 case ec_pwd: ClientECPWDParams; 990 } exchange_keys; 991 } ClientKeyExchange; 993 4.5.1.3.1. Generation of Client Key Exchange 995 The client's scalar and Element are generated in the manner described 996 in Section 4.5.1.2.1. 998 For an FFC group, the scalar SHALL become the ff_cscalar component 999 and the Element SHALL become the ff_celement in the FFC-specific 1000 ClientKeyExchange. 1002 For an ECC group, the scalar SHALL become the ec_cscalar component 1003 and the ELement SHALL become the ec_celement in the ECC-specific 1004 ClientKeyExchange. If the client requested a specific point format 1005 (compressed or uncompressed) with the Support Point Formats Extension 1006 in its ClientHello, then the Element MUST be formatted in the 1007 ec_celement to conform to its initial request. 1009 4.5.1.3.2. Processing of Client Key Exchange 1011 Upon receipt of the ClientKeyExchange, the server must validate the 1012 client's "commitment" by ensuring that: 1) the client's scalar and 1013 element differ from the server's scalar and element; 2) the client's 1014 scalar value is greater than one (1) and less than the order of the 1015 group, q; and 3) that the Element is valid for the chosen group (see 1016 Section 3.2.2 and Section 3.2.1 for how to determine whether an 1017 Element is valid for a particular group. Note that if the Element is 1018 a compressed point on an elliptic curve it MUST be uncompressed 1019 before checking its validity. If any of these three conditions are 1020 not met the server MUST abort the exchange. 1022 4.5.2. Changes to TLS 1.3 1024 4.5.2.1. TLS 1.3 KeyShare 1026 TLS 1.3 clients and servers convey their commit values in a 1027 "key_share" extension. The structure of this extension SHALL be: 1029 enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms; 1031 struct { 1032 select (KeyExchangeAlgorithm) { 1033 case ec_pwd: 1034 opaque elemX[coordinate_length]; 1035 opaque elemY[coordinate_length]; 1036 case ff_pwd: 1037 opaque elem[coordinate_length; 1038 ); 1039 opaque scalar<1..2^8-1> 1040 } PWDKeyShareEntry; 1042 struct { 1043 NamedGroup group; 1044 PWDKeyShareEntry pwd_key_exchange<1..2^16-1>; 1045 } KeyShareEntry; 1047 4.5.2.2. Client Hello Changes 1049 The ClientHello message MUST include a PWD_name extension from 1050 Section 4.4.3 and it MUST include a key_share extension from 1051 Section 4.5.2.1. 1053 Upon receipt of a ClientHello the server MUST validate the key_share 1054 extension_data to ensure that the scalar value is greater than one 1055 (1) and less than the order of the group q, and that the Element is 1056 valid for the chosen group (see Section 3.2.2 and Section 3.2.1). 1058 If a server does not have a password for a client identified by the 1059 username either extracted from the PWD_name, if unprotected, or 1060 recovered using the technique in Section 4.3.2, if protected, or if 1061 recovery of a protected username fails, the server SHOULD hide that 1062 fact by simulating the protocol-- putting random data in the PWD- 1063 specific components of its KeyShareEntry-- and then rejecting the 1064 client's finished message with a "bad_record_mac" alert. To properly 1065 effect a simulated TLS-PWD exchange, an appropriate delay SHOULD be 1066 inserted between receipt of the Client Hello and response of the 1067 Server Hello. Alternately, a server MAY choose to terminate the 1068 exchange if a password is not found. The security impliication of 1069 terminating the exchange is to expose to an attacker whether a 1070 username is valid or not. 1072 4.5.2.3. Server Hello Changes 1074 If the server supports TLS-PWD, agrees with the group chosen by the 1075 client, and finds an unsalted password indicated by the PWD_name 1076 extension of the received ClientHello, its ServerHello MUST contain a 1077 key_share extension from Section 4.5.2.1 in the same group as that 1078 chosen by the client. 1080 Upon receit of a ServerHello the client MUST validate the key_share 1081 extension_data to ensure that the scalar value is greater than one 1082 (1) and less than the order of the group q, and that the Element is 1083 valid for the chosen group (see Section 3.2.2 and Section 3.2.1). 1085 4.5.2.4. Hello Retry Request Changes 1087 The server sends this message in response to a ClientHello if it 1088 desires a different group or if the password identified by the 1089 client's password identified by PWD_name is salted. 1091 A different group is indicated by adding the 1092 KeyShareHelloRetryRequest extension to the HelloRetryRequest. 1093 Indication of a salted password, and the salt used, is done by adding 1094 the following structure: 1096 enum { PWD_salt(TBD3) } ExtensionType; 1098 struct { 1099 opaque pwd_salt<2^16-1>; 1100 } PWD_salt; 1102 A client that receives a HelloRetryRequest indicating password salt 1103 SHALL delete its computed PE and derive another version using the 1104 salt prior to sending another ClientHello. 1106 4.6. Computing the Shared Secret 1108 The client and server use their private value calculated in 1109 Section 4.4.4 with the other party's element and Scalar for the 1110 ServerHello or ClientHello, respectively (here denoted Peer_Element 1111 and peer_scalar) to generate the shared secret z. 1113 z = F(scalar-op(private, 1114 element-op(Peer_Element, 1115 scalar-op(peer_scalar, PE)))) 1117 For TLS versions prior to 1.3, intermediate value, z, is then used as 1118 the premaster secret after any leading bytes of z that contain all 1119 zero bits have been stripped off. For TLS version 1.3, leading zero 1120 bytes are retained and the intermediate value z is used as the 1121 (EC)DHE input in the key schedule. 1123 5. Ciphersuite Definition 1125 This memo adds the following ciphersuites: 1127 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 1129 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 1131 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 1133 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 1135 Implementations conforming to this specification MUST support the 1136 TLS_ECCPWD_WITH_AES_128_GCM_SHA256, ciphersuite; they SHOULD support 1137 the remaining ciphersuites. 1139 When negotiated with a version of TLS prior to 1.2, the Pseudo-Random 1140 Function (PRF) from that version is used; otherwise, the PRF is the 1141 TLS PRF [RFC5246] using the hash function indicated by the 1142 ciphersuite. Regardless of the TLS version, the TLS-PWD random 1143 function, H, is always instantiated with the hash algorithm indicated 1144 by the ciphersuite. 1146 For those ciphersuites that use Cipher Block Chaining (CBC) 1147 [SP800-38A] mode, the MAC is HMAC [RFC2104] with the hash function 1148 indicated by the ciphersuite. 1150 6. Acknowledgements 1152 The authenticated key exchange defined here has also been defined for 1153 use in 802.11 networks, as an EAP method, and as an authentication 1154 method for IKE. Each of these specifications has elicited very 1155 helpful comments from a wide collection of people that have allowed 1156 the definition of the authenticated key exchange to be refined and 1157 improved. 1159 The authors would like to thank Scott Fluhrer for discovering the 1160 "password as exponent" attack that was possible in an early version 1161 of this key exchange and for his very helpful suggestions on the 1162 techniques for fixing the PE to prevent it. The authors would also 1163 like to thank Hideyuki Suzuki for his insight in discovering an 1164 attack against a previous version of the underlying key exchange 1165 protocol. Special thanks to Lily Chen for helpful discussions on 1166 hashing into an elliptic curve. Rich Davis suggested the defensive 1167 checks that are part of the processing of the ServerKeyExchange and 1168 ClientKeyExchange messages, and his various comments have greatly 1169 improved the quality of this memo and the underlying key exchange on 1170 which it is based. 1172 Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik, discussed the 1173 possibility of a side-channel attack against the hunting-and-pecking 1174 loop on the TLS mailing list. That discussion prompted the addition 1175 of the security parameter, m, to the hunting-and-pecking loop. Scott 1176 Flurer suggested the blinding technique to test whether a value is a 1177 quadratic residue modulo a prime in a manner that does not leak 1178 information about the value being tested. 1180 7. IANA Considerations 1182 IANA SHALL assign two values for a new TLS extention type from the 1183 TLS ExtensionType Registry defined in [RFC5246] with the name 1184 "pwd_protect" and "pwd_clear". The RFC editor SHALL replace TBD1 and 1185 TBD2 in Section 4.5.1.1 with the IANA-assigned value for these 1186 extensions. 1188 IANA SHALL assign a new TLS extension type from the TLS ExtensionType 1189 Registry defined in [RFC5246] with the name "password_salt". The RFC 1190 editor SHALL replace TBD3 in Section 4.5.2.4 with the IANA-assigned 1191 value for this extension. 1193 IANA SHALL update the TLS ExtensionType registry for TLS 1.3 with the 1194 following contents: 1196 +-------+----------------+-------------+---------------+ 1197 | Value | Extension Name | TLS 1.3 | Reference | 1198 +-------+----------------+-------------+---------------+ 1199 | TBD3 | Password Salt | CH, SH, HRR | this document | 1200 +-------+----------------+-------------+---------------+ 1202 And replace "this document" with the resulting RFC citation 1204 IANA SHALL assign nine new ciphersuites from the TLS Ciphersuite 1205 Registry defined in [RFC5246] for the following ciphersuites: 1207 CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); 1209 CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); 1211 CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); 1212 CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); 1214 The RFC editor SHALL replace (TBD, TBD) in all the ciphersuites 1215 defined in Section 5 with the appropriate IANA-assigned values. The 1216 "DTLS-OK" column in the ciphersuite registry SHALL be set to "Y" and 1217 the "IETF Recommended" column SHALL be set to "N" for all 1218 ciphersuites defined in this memo. 1220 8. Security Considerations 1222 A security proof of this key exchange in the random oracle model is 1223 found in [lanskro]. 1225 A passive attacker against this protocol will see the 1226 ServerKeyExchange and the ClientKeyExchange, or KeyShare, containing 1227 scalar and Element of the two client and server. The client and 1228 server effectively hide their secret private value by masking it 1229 modulo the order of the selected group. If the order is "q", then 1230 there are approximately "q" distinct pairs of numbers that will sum 1231 to the scalar values observed. It is possible for an attacker to 1232 iterate through all such values but for a large value of "q", this 1233 exhaustive search technique is computationally infeasible. The 1234 attacker would have a better chance in solving the discrete logarithm 1235 problem, which we have already assumed (see Section 3.5) to be an 1236 intractable problem. 1238 A passive attacker can take the Element from either the 1239 ServerKeyExchange or the ClientKeyExchange (in TLS pre 1.3) or the 1240 KeyShare (from TLS 1.3) and try to determine the random "mask" value 1241 used in its construction and then recover the other party's "private" 1242 value from the scalar in the same message. But this requires the 1243 attacker to solve the discrete logarithm problem which we assumed was 1244 intractable. 1246 Both the client and the server obtain a shared secret based on a 1247 secret group element and the private information they contributed to 1248 the exchange. The secret group element is based on the password. If 1249 they do not share the same password they will be unable to derive the 1250 same secret group element and if they don't generate the same secret 1251 group element they will be unable to generate the same shared secret. 1252 Seeing a finished message will not provide any additional advantage 1253 of attack since it is generated with the unknowable secret. 1255 In TLS pre-1.3, an active attacker impersonating the client can 1256 induce a server to send a ServerKeyExchange containing the server's 1257 scalar and Element. It can attempt to generate a ClientKeyExchange 1258 and send to the server but the attacker is required to send a 1259 finished message first so the only information she can obtain in this 1260 attack is less than the information she can obtain from a passive 1261 attack, so this particular active attack is not very fruitful. 1263 In TLS pre-1.3, an active attacker can impersonate the server and 1264 send a forged ServerKeyExchange after receiving the ClientHello. The 1265 attacker then waits until it receives the ClientKeyExchange and 1266 finished message from the client. Now the attacker can attempt to 1267 run through all possible values of the password, computing PE (see 1268 Section 4.4), computing candidate premaster secrets (see 1269 Section 4.6), and attempting to recreate the client's finished 1270 message. 1272 But the attacker committed to a single guess of the password with her 1273 forged ServerKeyExchange. That value was used by the client in her 1274 computation of the premaster secret which was used to produce the 1275 finished message. Any guess of the password which differs from the 1276 one used in the forged ServerKeyExchange would result in each side 1277 using a different PE in the computation of the premaster secret and 1278 therefore the finished message cannot be verified as correct, even if 1279 a subsequent guess, while running through all possible values, was 1280 correct. The attacker gets one guess, and one guess only, per active 1281 attack. 1283 Instead of attempting to guess at the password, an attacker can 1284 attempt to determine PE and then launch an attack. But PE is 1285 determined by the output of the random function, H, which is 1286 indistinguishable from a random source since H is assumed to be a 1287 "random oracle" (Section 3.5). Therefore, each element of the finite 1288 cyclic group will have an equal probability of being the PE. The 1289 probability of guessing PE will be 1/q, where q is the order of the 1290 group. For a large value of "q" this will be computationally 1291 infeasible. 1293 The implications of resistance to dictionary attack are significant. 1294 An implementation can provision a password in a practical and 1295 realistic manner-- i.e. it MAY be a character string and it MAY be 1296 relatively short-- and still maintain security. The nature of the 1297 pool of potential passwords determines the size of the pool, D, and 1298 countermeasures can prevent an attacker from determining the password 1299 in the only possible way: repeated, active, guessing attacks. For 1300 example, a simple four character string using lower-case English 1301 characters, and assuming random selection of those characters, will 1302 result in D of over four hundred thousand. An attacker would need to 1303 mount over one hundred thousand active, guessing attacks (which will 1304 easily be detected) before gaining any significant advantage in 1305 determining the pre-shared key. 1307 Countermeasures to deal with successive active, guessing attacks are 1308 only possible by noticing a certain username is failing repeatedly 1309 over a certain period of time. Attacks which attempt to find a 1310 password for a random user are more difficult to detect. For 1311 instance, if a device uses a serial number as a username and the pool 1312 of potential passwords is sufficiently small, a more effective attack 1313 would be to select a password and try all potential "users" to 1314 disperse the attack and confound countermeasures. It is therefore 1315 RECOMMENDED that implementations of TLS-PWD keep track of the total 1316 number of failed authentications regardless of username in an effort 1317 to detect and thwart this type of attack. 1319 The benefits of resistance to dictionary attack can be lessened by a 1320 client using the same passwords with multiple servers. An attacker 1321 could re-direct a session from one server to the other if the 1322 attacker knew that the intended server stored the same password for 1323 the client as another server. 1325 An adversary that has access to, and a considerable amount of control 1326 over, a client or server could attempt to mount a side-channel attack 1327 to determine the number of times it took for a certain password (plus 1328 client random and server random) to select a password element. Each 1329 such attack could result in a successive paring-down of the size of 1330 the pool of potential passwords, resulting in a manageably small set 1331 from which to launch a series of active attacks to determine the 1332 password. A security parameter, m, is used to normalize the amount 1333 of work necessary to determine the password element (see 1334 Section 4.4). The probability that a password will require more than 1335 m iterations is roughly (q/2p)^m for ECC groups and (q/p)^m for FFC 1336 groups, so it is possible to mitigate side channel attack at the 1337 expense of a constant cost per connection attempt. But if a 1338 particular password requires more than k iterations it will leak k 1339 bits of information to the side-channel attacker, which for some 1340 dictionaries will uniquely identify the password. Therefore, the 1341 security parameter, m, needs to be set with great care. It is 1342 RECOMMENDED that an implementation set the security parameter, m, to 1343 a value of at least forty (40) which will put the probability that 1344 more than forty iterations are needed in the order of one in one 1345 trillion (1:1,000,000,000,000). 1347 A database of salted passwords prevents an adversary who gains access 1348 to the database from learning the client's password, it does not 1349 prevent such an adversary from impersonating the client back to the 1350 server. Each side uses the salted password, called the base, as the 1351 authenticaiton credential so the database of salted passwords MUST be 1352 afforded the security of a database of plaintext passwords. 1354 Authentication is performed by proving knowledge of the password. 1355 Any third party that knows the password shared by the client and 1356 server can impersonate one to the other. 1358 The static-ephemeral Diffie-Hellman exchange used to protect 1359 usernames requires the server to reuse its Diffie-Hellman public key. 1360 To prevent an invalid curve attack, an entity that reuses its Diffie- 1361 Hellman public key needs to check whether the received ephemeral 1362 public key is actually a point on the curve. This is done explicitly 1363 as part of the server's reconstruction of the client's public key out 1364 of only its x-coordinate ("compact representation"). 1366 9. Human Rights Considerations 1368 At the time of publication, there was a growing interest in 1369 considering the human rights impact of IETF (and IRTF) work. As 1370 such, the Human Rights Considerations of TLS-PWD are presented. 1372 The key exchange underlying TLS-PWD uses public key cryptography to 1373 perform authentication and authenticated key exchange. The keys it 1374 produces can be used to establish secure connections between two 1375 people to protect their communication. Implementations of TLS-PWD, 1376 like implementations of other TLS ciphersuites that perform 1377 authentication and authenticted key establishment, are considered 1378 'armaments' or 'munitions' by many governments around the world. 1380 The most fundamental of Human Rights is the right to protect oneself. 1381 The right to keep and bear arms is an example of this right. 1382 Implementations of TLS-PWD can be used as arms, kept and borne, to 1383 defend oneself against all manner of attackers-- criminals, 1384 governments, laywers, etc. TLS-PWD is a powerful tool in the 1385 promotion and defense of Universal Human Rights. 1387 10. Implementation Considerations 1389 The selection of the ciphersuite and selection of the particular 1390 finite cyclic group to use with the ciphersuite are divorced in this 1391 memo but they remain intimately close. 1393 It is RECOMMENDED that implementations take note of the strength 1394 estimates of particular groups and to select a ciphersuite providing 1395 commensurate security with its hash and encryption algorithms. A 1396 ciphersuite whose encryption algorithm has a keylength less than the 1397 strength estimate, or whose hash algorithm has a blocksize that is 1398 less than twice the strength estimate SHOULD NOT be used. 1400 For example, the elliptic curve named brainpoolP256r1 (whose IANA- 1401 assigned number is 26) provides an estimated 128 bits of strength and 1402 would be compatible with an encryption algorithm supporting a key of 1403 that length, and a hash algorithm that has at least a 256-bit 1404 blocksize. Therefore, a suitable ciphersuite to use with 1405 brainpoolP256r1 could be TLS_ECCPWD_WITH_AES_128_GCM_SHA256 (see 1406 Appendix A for an example of such an exchange). 1408 Resistance to dictionary attack means that the attacker must launch 1409 an active attack to make a single guess at the password. If the size 1410 of the pool from which the password was extracted was D, and each 1411 password in the pool has an equal probability of being chosen, then 1412 the probability of success after a single guess is 1/D. After X 1413 guesses, and removal of failed guesses from the pool of possible 1414 passwords, the probability becomes 1/(D-X). As X grows so does the 1415 probability of success. Therefore it is possible for an attacker to 1416 determine the password through repeated brute-force, active, guessing 1417 attacks. Implementations SHOULD take note of this fact and choose an 1418 appropriate pool of potential passwords-- i.e. make D big. 1419 Implementations SHOULD also take countermeasures, for instance 1420 refusing authentication attempts by a particular username for a 1421 certain amount of time, after the number of failed authentication 1422 attempts reaches a certain threshold. No such threshold or amount of 1423 time is recommended in this memo. 1425 11. References 1427 11.1. Normative References 1429 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1430 Hashing for Message Authentication", RFC 2104, DOI 1431 10.17487/RFC2104, February 1997, 1432 . 1434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1435 Requirement Levels", BCP 14, RFC 2119, March 1997. 1437 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1438 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1439 for Transport Layer Security (TLS)", RFC 4492, DOI 1440 10.17487/RFC4492, May 2006, 1441 . 1443 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1444 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1445 RFC5246, August 2008, 1446 . 1448 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 1449 Authenticated Encryption Using the Advanced Encryption 1450 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 1451 2008, . 1453 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1454 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 1455 RFC5869, May 2010, 1456 . 1458 [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, 1459 Enforcement, and Comparison of Internationalized Strings 1460 Representing Usernames and Passwords", RFC 7613, DOI 1461 10.17487/RFC7613, August 2015, 1462 . 1464 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 1465 Ephemeral Parameters for Transport Layer Security (TLS)", 1466 RFC 7919, DOI 10.17487/RFC7919, August 2016, 1467 . 1469 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1470 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1471 . 1473 [named_groups] 1474 IANA, "TLS Supported Groups Registry", 1475 . 1478 11.2. Informative References 1480 [FIPS186-3] 1481 National Institute of Standards and Technology, "Digital 1482 Signature Standard (DSS)", Federal Information Processing 1483 Standards Publication 186-3, . 1485 [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: 1486 A Paradigm for Designing Efficient Protocols", Proceedings 1487 of the 1st ACM Conference on Computer and Communication 1488 Security, ACM Press, 1993. 1490 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1491 "Randomness Requirements for Security", BCP 106, RFC 4086, 1492 DOI 10.17487/RFC4086, June 2005, 1493 . 1495 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1496 Curve Cryptography Algorithms", RFC 6090, February 2011. 1498 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1499 "Enrollment over Secure Transport", RFC 7030, DOI 1500 10.17487/RFC7030, October 2013, 1501 . 1503 [RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI 1504 10.17487/RFC7664, November 2015, 1505 . 1507 [SP800-38A] 1508 National Institute of Standards and Technology, 1509 "Recommendation for Block Cipher Modes of Operation-- 1510 Methods and Techniques", NIST Special Publication 800-38A, 1511 December 2001. 1513 [SP800-56A] 1514 Barker, E., Johnson, D., and M. Smid, "Recommendations for 1515 Pair-Wise Key Establishment Schemes Using Discrete 1516 Logarithm Cryptography", NIST Special Publication 800-56A, 1517 March 2007. 1519 [lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of 1520 the Dragonfly Protocol", Proceedings of 18th International 1521 Information Security Conference (ISC 2015), pp 244-261, 1522 DOI 10.1007/978-3-319-23318-5_14, September 2015. 1524 Appendix A. Example Exchange 1526 (Note: at the time of publication of this memo ciphersuites have 1527 not yet been assigned by IANA and the exchange that follows uses 1528 the private numberspace). 1530 username: fred 1531 password: barney 1533 ---- prior to running TLS-PWD ---- 1535 server generates salt: 1537 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 1538 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 1540 and a base: 1542 6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 1543 c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75 1545 ---- state derived during the TLS-PWD exchange ---- 1547 client and server agree to use brainpoolP256r1 1549 client and server generate PE: 1551 PE.x: 1552 29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 1553 a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6 1555 server private and mask: 1557 private: 1558 21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b 1559 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c 1560 mask: 1561 0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f 1562 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5 1564 client private and mask: 1566 private: 1567 17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f 1568 a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b 1569 mask: 1570 4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88 1571 83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd 1573 both parties generate pre-master secret and master secret 1575 pre-master secret: 1576 01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11 1577 af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4 1578 master secret: 1579 65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1 1580 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f 1581 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad 1583 ---- ssldump output of exchange ---- 1585 New TCP connection #1: Charlene Client <-> Sammy Server 1586 1 1 0.0018 (0.0018) C>SV3.3(173) Handshake 1587 ClientHello 1588 Version 3.3 1589 random[32]= 1590 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7 1591 d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d 1592 cipher suites 1593 TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV 1594 TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV 1595 Unknown value 0xff 1596 compression methods 1597 NULL 1598 extensions 1599 TLS-PWD unprotected name[5]= 1600 04 66 72 65 64 1601 elliptic curve point format[4]= 1602 03 00 01 02 1603 elliptic curve list[58]= 1604 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 1605 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06 1606 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01 1607 00 02 00 03 00 0f 00 10 00 11 1608 Packet data[178]= 1609 16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17 1610 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf 1611 a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3 1612 ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65 1613 64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00 1614 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00 1615 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00 1616 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00 1617 03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06 1618 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 1619 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00 1620 01 01 1622 1 2 0.0043 (0.0024) S>CV3.3(94) Handshake 1623 ServerHello 1624 Version 3.3 1625 random[32]= 1626 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72 1627 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa 1628 session_id[32]= 1629 ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 1630 e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 1631 cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV 1632 compressionMethod NULL 1633 extensions 1634 renegotiate[1]= 1635 00 1636 elliptic curve point format[4]= 1637 03 00 01 02 1639 heartbeat[1]= 1640 01 1641 Packet data[99]= 1642 16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43 1643 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3 1644 ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08 1645 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18 1646 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00 1647 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f 1648 00 01 01 1650 1 3 0.0043 (0.0000) S>CV3.3(141) Handshake 1651 ServerKeyExchange 1652 params 1653 salt[32]= 1654 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 1655 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 1656 EC parameters = 3 1657 curve id = 26 1658 element[65]= 1659 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 1660 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee 1661 f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 1662 be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db 1663 e1 1664 scalar[32]= 1665 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a 1666 df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21 1667 Packet data[146]= 1668 16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1 1669 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d 1670 47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04 1671 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61 1672 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3 1673 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be 1674 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1 1675 00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 1676 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 1677 49 21 1679 1 4 0.0043 (0.0000) S>CV3.3(4) Handshake 1680 ServerHelloDone 1681 Packet data[9]= 1682 16 03 03 00 04 0e 00 00 00 1684 1 5 0.0086 (0.0043) C>SV3.3(104) Handshake 1685 ClientKeyExchange 1686 element[65]= 1687 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1 1688 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f 1689 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2 1690 c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd 1691 a0 1692 scalar[32]= 1693 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 1694 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 1695 Packet data[109]= 1696 16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b 1697 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19 1698 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd 1699 d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf 1700 e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44 1701 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39 1702 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48 1704 1 6 0.0086 (0.0000) C>SV3.3(1) ChangeCipherSpec 1705 Packet data[6]= 1706 14 03 03 00 01 01 1708 1 7 0.0086 (0.0000) C>SV3.3(40) Handshake 1709 Packet data[45]= 1710 16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7 1711 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a 1712 0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20 1714 1 8 0.0105 (0.0018) S>CV3.3(1) ChangeCipherSpec 1715 Packet data[6]= 1716 14 03 03 00 01 01 1718 1 9 0.0105 (0.0000) S>CV3.3(40) Handshake 1719 Packet data[45]= 1720 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c 1721 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 1722 a2 21 94 90 12 72 23 18 24 21 c3 60 a4 1724 1 10 0.0107 (0.0002) C>SV3.3(100) application_data 1725 Packet data.... 1727 Author's Address 1729 Dan Harkins (editor) 1730 HP Enterprise 1731 3333 Scott blvd 1732 Santa Clara, CA 95054 1733 United States of America 1735 Email: dharkins@lounge.org