idnits 2.16.01
/tmp/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 document date (August 23, 2018) is 109 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 (~~), 0 warnings (==), 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