summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8492.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8492.txt')
-rw-r--r--doc/rfc/rfc8492.txt2243
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc8492.txt b/doc/rfc/rfc8492.txt
new file mode 100644
index 0000000..258c063
--- /dev/null
+++ b/doc/rfc/rfc8492.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Independent Submission D. Harkins, Ed.
+Request for Comments: 8492 HP Enterprise
+Category: Informational February 2019
+ISSN: 2070-1721
+
+
+ Secure Password Ciphersuites for Transport Layer Security (TLS)
+
+Abstract
+
+ This memo defines several new ciphersuites for the Transport Layer
+ Security (TLS) protocol to support certificateless, secure
+ authentication using only a simple, low-entropy password. The
+ exchange is called "TLS-PWD". The ciphersuites are all based on an
+ authentication and key exchange protocol, named "dragonfly", that is
+ resistant to offline dictionary attacks.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not candidates for any level of Internet Standard;
+ see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8492.
+
+Copyright Notice
+
+ Copyright (c) 2019 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+
+
+
+
+
+
+Harkins Informational [Page 1]
+
+RFC 8492 TLS Password February 2019
+
+
+Table of Contents
+
+ 1. Introduction and Motivation .....................................3
+ 1.1. The Case for Certificateless Authentication ................3
+ 1.2. Resistance to Dictionary Attacks ...........................3
+ 2. Key Words .......................................................4
+ 3. Notation and Background .........................................4
+ 3.1. Notation ...................................................4
+ 3.2. Discrete Logarithm Cryptography ............................5
+ 3.2.1. Elliptic Curve Cryptography .........................5
+ 3.2.2. Finite Field Cryptography ...........................7
+ 3.3. Instantiating the Random Function ..........................8
+ 3.4. Passwords ..................................................8
+ 3.5. Assumptions ................................................9
+ 4. Specification of the TLS-PWD Handshake .........................10
+ 4.1. TLS-PWD Pre-TLS 1.3 .......................................10
+ 4.2. TLS-PWD in TLS 1.3 ........................................11
+ 4.3. Protecting the Username ...................................11
+ 4.3.1. Construction of a Protected Username ...............12
+ 4.3.2. Recovery of a Protected Username ...................13
+ 4.4. Fixing the Password Element ...............................14
+ 4.4.1. Computing an ECC Password Element ..................16
+ 4.4.2. Computing an FFC Password Element ..................18
+ 4.4.3. Password Naming ....................................19
+ 4.4.4. Generating TLS-PWD Commit ..........................20
+ 4.5. Changes to Handshake Message Contents .....................20
+ 4.5.1. Pre-1.3 TLS ........................................20
+ 4.5.1.1. ClientHello Changes .......................20
+ 4.5.1.2. ServerKeyExchange Changes .................21
+ 4.5.1.3. ClientKeyExchange Changes .................23
+ 4.5.2. TLS 1.3 ............................................24
+ 4.5.2.1. TLS 1.3 KeyShare ..........................24
+ 4.5.2.2. ClientHello Changes .......................24
+ 4.5.2.3. ServerHello Changes .......................25
+ 4.5.2.4. HelloRetryRequest Changes .................25
+ 4.6. Computing the Shared Secret ...............................26
+ 5. Ciphersuite Definition .........................................26
+ 6. IANA Considerations ............................................27
+ 7. Security Considerations ........................................27
+ 8. Human Rights Considerations ....................................30
+ 9. Implementation Considerations ..................................31
+ 10. References ....................................................32
+ 10.1. Normative References .....................................32
+ 10.2. Informative References ...................................33
+ Appendix A. Example Exchange ......................................35
+ Acknowledgements ..................................................40
+ Author's Address ..................................................40
+
+
+
+
+Harkins Informational [Page 2]
+
+RFC 8492 TLS Password February 2019
+
+
+1. Introduction and Motivation
+
+1.1. The Case for Certificateless Authentication
+
+ Transport Layer Security (TLS) usually uses public key certificates
+ for authentication [RFC5246] [RFC8446]. This is problematic in some
+ cases:
+
+ o Frequently, TLS [RFC5246] is used in devices owned, operated, and
+ provisioned by people who lack competency to properly use
+ certificates and merely want to establish a secure connection
+ using a more natural credential like a simple password. The
+ proliferation of deployments that use a self-signed server
+ certificate in TLS [RFC5246] followed by a basic password exchange
+ over the unauthenticated channel underscores this case.
+
+ o The alternatives to TLS-PWD for employing certificateless TLS
+ authentication -- using pre-shared keys in an exchange that is
+ susceptible to dictionary attacks or using a Secure Remote
+ Password (SRP) exchange that requires users to, a priori, be fixed
+ to a specific Finite Field Cryptography (FFC) group for all
+ subsequent connections -- are not acceptable for modern
+ applications that require both security and cryptographic agility.
+
+ o A password is a more natural credential than a certificate (from
+ early childhood, people learn the semantics of a shared secret),
+ so a password-based TLS ciphersuite can be used to protect an
+ HTTP-based certificate enrollment scheme like Enrollment over
+ Secure Transport (EST) [RFC7030] to parlay a simple password into
+ a certificate for subsequent use with any certificate-based
+ authentication protocol. This addresses a significant
+ "chicken-and-egg" dilemma found with certificate-only use of
+ [RFC5246].
+
+ o Some PIN-code readers will transfer the entered PIN to a smart
+ card in cleartext. Assuming a hostile environment, this is a bad
+ practice. A password-based TLS ciphersuite can enable the
+ establishment of an authenticated connection between reader and
+ card based on the PIN.
+
+1.2. Resistance to Dictionary Attacks
+
+ It is a common misconception that a protocol that authenticates with
+ a shared and secret credential is resistant to dictionary attacks if
+ the credential is assumed to be an N-bit uniformly random secret,
+ where N is sufficiently large. The concept of resistance to
+ dictionary attacks really has nothing to do with whether that secret
+
+
+
+
+Harkins Informational [Page 3]
+
+RFC 8492 TLS Password February 2019
+
+
+ can be found in a standard collection of a language's defined words
+ (i.e., a dictionary). It has to do with how an adversary gains an
+ advantage in attacking the protocol.
+
+ For a protocol to be resistant to dictionary attacks, any advantage
+ an adversary can gain must be a function of the amount of
+ interactions she makes with an honest protocol participant and not a
+ function of the amount of computation she uses. This means that the
+ adversary will not be able to obtain any information about the
+ password except whether a single guess from a single protocol run
+ that she took part in is correct or incorrect.
+
+ It is assumed that the attacker has access to a pool of data from
+ which the secret was drawn -- it could be all numbers between 1 and
+ 2^N; it could be all defined words in a dictionary. The key is that
+ the attacker cannot do an attack and then go offline and enumerate
+ through the pool trying potential secrets (computation) to see if one
+ is correct. She must do an active attack for each secret she wishes
+ to try (interaction), and the only information she can glean from
+ that attack is whether the secret used with that particular attack is
+ correct or not.
+
+2. Key Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Notation and Background
+
+3.1. Notation
+
+ The following notation is used in this memo:
+
+ password
+ a secret -- and potentially low-entropy -- word, phrase, code, or
+ key used as a credential for authentication. The password is
+ shared between the TLS client and TLS server.
+
+ y = H(x)
+ a binary string of arbitrary length, x, is given to a function H,
+ which produces a fixed-length output, y.
+
+ a | b
+ denotes concatenation of string "a" with string "b".
+
+
+
+
+Harkins Informational [Page 4]
+
+RFC 8492 TLS Password February 2019
+
+
+ [a]b
+ indicates a string consisting of the single bit "a" repeated
+ "b" times.
+
+ x mod y
+ indicates the remainder of division of x by y. The result will
+ be between 0 and y.
+
+ len(x)
+ indicates the length in bits of the string "x".
+
+ lgr(a, b)
+ takes "a" and a prime, b, and returns the Legendre symbol (a/b).
+
+ LSB(x)
+ returns the least-significant bit of the bitstring "x".
+
+ G.x
+ indicates the x-coordinate of a point, G, on an elliptic curve.
+
+3.2. Discrete Logarithm Cryptography
+
+ The ciphersuites defined in this memo use discrete logarithm
+ cryptography (see [SP800-56A]) to produce an authenticated and shared
+ secret value that is an Element in a group defined by a set of domain
+ parameters. The domain parameters can be based on either FFC or
+ Elliptic Curve Cryptography (ECC).
+
+ Elements in a group -- either an FFC or ECC group -- are indicated
+ using uppercase, while scalar values are indicated using lowercase.
+
+3.2.1. Elliptic Curve Cryptography
+
+ The authenticated key exchange defined in this memo uses fundamental
+ algorithms of elliptic curves defined over GF(p) as described in
+ [RFC6090]. Ciphersuites defined in this memo SHALL only use ECC
+ curves based on the Weierstrass equation y^2 = x^3 + a*x + b.
+
+ Domain parameters for the ECC groups used by this memo are:
+
+ o A prime, p, determining a prime field GF(p). The cryptographic
+ group will be a subgroup of the full elliptic curve group, which
+ consists of points on an elliptic curve -- Elements from GF(p)
+ that satisfy the curve's equation -- together with the "point at
+ infinity" that serves as the identity Element.
+
+
+
+
+
+
+Harkins Informational [Page 5]
+
+RFC 8492 TLS Password February 2019
+
+
+ o Elements a and b from GF(p) that define the curve's equation. The
+ point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only
+ if (y^2 - x^3 - a*x - b) mod p equals zero (0).
+
+ o A point, G, on the elliptic curve, which serves as a generator for
+ the ECC group. G is chosen such that its order, with respect to
+ elliptic curve addition, is a sufficiently large prime.
+
+ o A prime, q, which is the order of G and thus is also the size of
+ the cryptographic subgroup that is generated by G.
+
+ o A co-factor, f, defined by the requirement that the size of the
+ full elliptic curve group (including the "point at infinity") be
+ the product of f and q.
+
+ This memo uses the following ECC functions:
+
+ o Z = elem-op(X, Y) = X + Y: two points on the curve, X and Y, are
+ summed to produce another point on the curve, Z. This is the
+ group operation for ECC groups.
+
+ o Z = scalar-op(x, Y) = x * Y: an integer scalar, x, acts on a point
+ on the curve, Y, via repetitive addition (Y is added to itself
+ x times), to produce another ECC Element, Z.
+
+ o Y = inverse(X): a point on the curve, X, has an inverse, Y, which
+ is also a point on the curve, when their sum is the "point at
+ infinity" (the identity for elliptic curve addition). In other
+ words, R + inverse(R) = "0".
+
+ o z = F(X): the x-coordinate of a point (x, y) on the curve is
+ returned. This is a mapping function to convert a group Element
+ into an integer.
+
+ Only ECC groups over GF(p) can be used with TLS-PWD.
+ Characteristic-2 curves SHALL NOT be used by TLS-PWD. ECC groups
+ over GF(2^m) SHALL NOT be used by TLS-PWD. In addition, ECC groups
+ with a co-factor greater than one (1) SHALL NOT be used by TLS-PWD.
+
+ A composite (x, y) pair can be validated as a point on the elliptic
+ curve by checking that 1) both coordinates x and y are greater than
+ zero (0) and less than the prime defining the underlying field,
+ 2) coordinates x and y satisfy the equation of the curve, and 3) they
+ do not represent the "point at infinity". If any of those conditions
+ are not true, the (x, y) pair is not a valid point on the curve.
+
+
+
+
+
+
+Harkins Informational [Page 6]
+
+RFC 8492 TLS Password February 2019
+
+
+ A compliant implementation of TLS-PWD SHALL support
+ group twenty-three (23) and SHOULD support group twenty-four (24)
+ from the "TLS Supported Groups" registry; see [TLS_REG].
+
+3.2.2. Finite Field Cryptography
+
+ Domain parameters for the FFC groups used by this memo are:
+
+ o A prime, p, determining a prime field GF(p) (i.e., the integers
+ modulo p). The FFC group will be a subgroup of GF(p)* (i.e., the
+ multiplicative group of non-zero Elements in GF(p)).
+
+ o An Element, G, in GF(p)*, which serves as a generator for the FFC
+ group. G is chosen such that its multiplicative order is a
+ sufficiently large prime divisor of ((p - 1)/2).
+
+ o A prime, q, which is the multiplicative order of G and thus is
+ also the size of the cryptographic subgroup of GF(p)* that is
+ generated by G.
+
+ This memo uses the following FFC functions:
+
+ o Z = elem-op(X, Y) = (X * Y) mod p: two FFC Elements, X and Y, are
+ multiplied modulo the prime, p, to produce another FFC Element, Z.
+ This is the group operation for FFC groups.
+
+ o Z = scalar-op(x, Y) = Y^x mod p: an integer scalar, x, acts on an
+ FFC group Element, Y, via exponentiation modulo the prime, p, to
+ produce another FFC Element, Z.
+
+ o Y = inverse(X): a group Element, X, has an inverse, Y, when the
+ product of the Element and its inverse modulo the prime equals
+ one (1). In other words, (X * inverse(X)) mod p = 1.
+
+ o z = F(X): is the identity function, since an Element in an FFC
+ group is already an integer. It is included here for consistency
+ in the specification.
+
+ Many FFC groups used in IETF protocols are based on safe primes and
+ do not define an order (q). For these groups, the order (q) used in
+ this memo shall be the prime of the group minus one divided by two --
+ (p - 1)/2.
+
+ An integer can be validated as being an Element in an FFC group by
+ checking that 1) it is between one (1) and the prime, p, exclusive
+ and 2) modular exponentiation of the integer by the group order, q,
+ equals one (1). If either of these conditions is not true, the
+ integer is not an Element in the group.
+
+
+
+Harkins Informational [Page 7]
+
+RFC 8492 TLS Password February 2019
+
+
+ A compliant implementation of TLS-PWD SHOULD support
+ group two hundred fifty-six (256) and group two hundred fifty-eight
+ (258) from the "TLS Supported Groups" registry on [TLS_REG].
+
+3.3. Instantiating the Random Function
+
+ The protocol described in this memo uses a random function, H, which
+ is modeled as a "random oracle". At first glance, one may view this
+ as a hash function. As noted in [RANDOR], though, hash functions are
+ too structured to be used directly as a random oracle. But they can
+ be used to instantiate the random oracle.
+
+ The random function, H, in this memo is instantiated by using the
+ hash algorithm defined by the particular TLS-PWD ciphersuite in
+ Hashed Message Authentication Code (HMAC) mode with a key whose
+ length is equal to the block size of the hash algorithm and whose
+ value is zero. For example, if the ciphersuite is
+ TLS_ECCPWD_WITH_AES_128_GCM_SHA256, then H will be instantiated with
+ SHA256 as:
+
+ H(x) = HMAC-SHA256([0]32, x)
+
+3.4. Passwords
+
+ The authenticated key exchange used in TLS-PWD requires each side to
+ have a common view of a shared credential. To protect the server's
+ database of stored passwords, a password MAY be salted. When
+ [RFC5246] or earlier is used, the password SHALL be salted. When
+ [RFC8446] is used, a password MAY be stored with a salt or without.
+ The password, username, and, optionally, the salt can create an
+ irreversible digest called the "base", which is used in the
+ authenticated key exchange.
+
+ The salting function is defined as:
+
+ base = HMAC-SHA256(salt, username | password)
+
+ The unsalted function is defined as:
+
+ base = SHA256(username | password)
+
+
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 8]
+
+RFC 8492 TLS Password February 2019
+
+
+ The password used for generation of the base SHALL be represented as
+ a UTF-8 encoded character string processed according to the rules of
+ the OpaqueString profile of [RFC8265], and the salt SHALL be a
+ 32-octet random number. The server SHALL store a tuple of the form:
+
+ { username, base, salt }
+
+ if the password is salted and:
+
+ { username, base }
+
+ if it is not. When password salting is being used, the client
+ generates the base upon receiving the salt from the server;
+ otherwise, it may store the base at the time the username and
+ password are provisioned.
+
+3.5. Assumptions
+
+ The security properties of the authenticated key exchange defined in
+ this memo are based on a number of assumptions:
+
+ 1. The random function, H, is a "random oracle" as defined in
+ [RANDOR].
+
+ 2. The discrete logarithm problem for the chosen group is hard.
+ That is, given g, p, and y = g^x mod p, it is computationally
+ infeasible to determine x. Similarly, for an ECC group given the
+ curve definition, a generator G, and Y = x * G, it is
+ computationally infeasible to determine x.
+
+ 3. Quality random numbers with sufficient entropy can be created.
+ This may entail the use of specialized hardware. If such
+ hardware is unavailable, a cryptographic mixing function (like a
+ strong hash function) to distill entropy from multiple,
+ uncorrelated sources of information and events may be needed. A
+ very good discussion of this can be found in [RFC4086].
+
+ If the server supports username protection (see Section 4.3), it is
+ assumed that the server has chosen a domain parameter set and
+ generated a username-protection keypair. The chosen domain parameter
+ set and public key are assumed to be conveyed to the client at the
+ time the client's username and password were provisioned.
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 9]
+
+RFC 8492 TLS Password February 2019
+
+
+4. Specification of the TLS-PWD Handshake
+
+ The key exchange underlying TLS-PWD is the "dragonfly"
+ password-authenticated key exchange (PAKE) as defined in [RFC7664].
+
+ The authenticated key exchange is accomplished by each side deriving
+ a Password Element (PE) [RFC7664] in the chosen group, making a
+ "commitment" to a single guess of the password using the PE, and
+ generating a shared secret. The ability of each side to produce a
+ valid finished message using a key derived from the shared secret
+ allows each side to authenticates itself to the other side.
+
+ The authenticated key exchange is dropped into the standard TLS
+ message handshake by defining extensions to some of the messages.
+
+4.1. TLS-PWD Pre-TLS 1.3
+
+ Client Server
+ -------- --------
+
+ ClientHello (name) -------->
+
+ ServerHello
+ ServerKeyExchange (commit)
+ <-------- ServerHello Done
+
+ ClientKeyExchange (commit)
+ ChangeCipherSpec
+ Finished -------->
+
+ ChangeCipherSpec
+ <-------- Finished
+
+ Application Data <-------> Application Data
+
+ Figure 1: Pre-TLS 1.3 TLS-PWD Handshake
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 10]
+
+RFC 8492 TLS Password February 2019
+
+
+4.2. TLS-PWD in TLS 1.3
+
+ Client Server
+ -------- --------
+ ClientHello (name)
+ + key_share (commit) -------->
+ ServerHello
+ + key_share (commit)
+ {EncryptedExtensions}
+ {Finished}
+ <-------- [Application Data*]
+ {Finished} -------->
+ [Application Data] <-------> [Application Data]
+
+ Figure 2: TLS 1.3 TLS-PWD Handshake
+
+4.3. Protecting the Username
+
+ The client is required to identify herself to the server before the
+ server can look up the appropriate client credential with which to
+ perform the authenticated key exchange. This has negative privacy
+ implications and opens up the client to tracking and increased
+ monitoring. It is therefore useful for the client to be able to
+ protect her username from passive monitors of the exchange and
+ against active attack by a malicious server. TLS-PWD provides such a
+ mechanism. Support for protected usernames is RECOMMENDED.
+
+ To enable username protection, a server chooses a domain parameter
+ set and generates an ephemeral public/private keypair. This keypair
+ SHALL only be used for username protection. For efficiency, the
+ domain parameter set used for username protection MUST be based on
+ ECC. Any ECC group that is appropriate for TLS-PWD (see
+ Section 3.2.1) is suitable for this purpose, but for
+ interoperability, prime256v1 (aka NIST's p256 curve) MUST be
+ supported. The domain parameter set chosen for username protection
+ is independent of the domain parameter set chosen for the underlying
+ key exchange -- i.e., they need not be the same.
+
+ When the client's username and password are provisioned on the
+ server, the chosen group and its public key are provisioned on the
+ client. This is stored on the client along with the server-specific
+ state (e.g., the hostname) it uses to initiate a TLS-PWD exchange.
+ The server uses the same group and public key with all clients.
+
+ To protect a username, the client and server perform a static-
+ ephemeral Diffie-Hellman exchange. Since the y-coordinate is not
+ necessary and eliminating it will reduce message size, compact
+ representation (and therefore compact output; see [RFC6090]) is used
+
+
+
+Harkins Informational [Page 11]
+
+RFC 8492 TLS Password February 2019
+
+
+ in the static-ephemeral Diffie-Hellman exchange. The result of the
+ Diffie-Hellman exchange is passed to the HMAC-based Key Derivation
+ Function (HKDF) [RFC5869] to create a key-encrypting key suitable for
+ AES-SIV [RFC5297] (where "AES" stands for "Advanced Encryption
+ Standard" and "SIV" stands for "Synthetic Initialization Vector") in
+ its deterministic authenticated encryption mode. The length of the
+ key-encrypting key (1) and the hash function to use with the HKDF
+ depend on the length of the prime, p, of the group used to provide
+ username protection:
+
+ o SHA-256, SIV-128, l=256 bits: when len(p) <= 256
+
+ o SHA-384, SIV-192, l=384 bits: when 256 < len(p) <= 384
+
+ o SHA-512, SIV-256, l=512 bits: when len(p) > 384
+
+4.3.1. Construction of a Protected Username
+
+ Prior to initiating a TLS-PWD exchange, the client chooses a random
+ secret, c, such that 1 < c < (q - 1), where q is the order of the
+ group from which the server's public key was generated, and it uses
+ scalar-op() with the group's generator to create a public key, C. It
+ uses scalar-op() with the server's public key and c to create a
+ shared secret, and it derives a key-encrypting key, k, using the
+ "saltless" mode of the HKDF [RFC5869]:
+
+ C = scalar-op(c, G)
+
+ Z = scalar-op(c, S)
+
+ k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
+
+ where NULL indicates the salt-free invocation and "" indicates an
+ empty string (i.e., there is no "context" passed to the HKDF).
+
+ The client's username SHALL be represented as a UTF-8 encoded
+ character string processed according to the rules of the OpaqueString
+ profile of [RFC8265]. The output of OpaqueString is then passed with
+ the key, k, to SIV-encrypt with no Additional Authenticated Data
+ (AAD) and no nonce, to produce an encrypted username, u:
+
+ u = SIV-encrypt(k, username)
+
+ Note: The format of the ciphertext output includes the
+ authenticating SIV.
+
+
+
+
+
+
+Harkins Informational [Page 12]
+
+RFC 8492 TLS Password February 2019
+
+
+ The protected username SHALL be the concatenation of the x-coordinate
+ of the client's public key, C, and the encrypted username, u. The
+ length of the x-coordinate of C MUST be equal to the length of the
+ group's prime, p, prepended with zeros, if necessary. The protected
+ username is inserted into the extension_data field of the pwd_protect
+ extension (see Section 4.4.3).
+
+ To ensure that the username remains confidential, the random secret,
+ c, MUST be generated from a source of random entropy; see
+ Section 3.5.
+
+ The length of the ciphertext output from SIV, minus the synthetic
+ initialization vector, will be equal to the length of the input
+ plaintext -- in this case, the username. To further foil traffic
+ analysis, it is RECOMMENDED that clients append a series of NULL
+ bytes to their usernames prior to passing them to SIV-encrypt() such
+ that the resulting padded length of the username is at least
+ 128 octets.
+
+4.3.2. Recovery of a Protected Username
+
+ A server that receives a protected username needs to recover the
+ client's username prior to performing the key exchange. To do so,
+ the server computes the client's public key; completes the static-
+ ephemeral Diffie-Hellman exchange; derives the key-encrypting key, k;
+ and decrypts the username.
+
+ The length of the x-coordinate of the client's public key is known
+ (it is the length of the prime from the domain parameter set used to
+ protect usernames) and can easily be separated from the ciphertext in
+ the pwd_name extension in the ClientHello -- the first len(p) bits
+ are the x-coordinate of the client's public key, and the remaining
+ bits are the ciphertext.
+
+ Since compressed representation is used by the client, the server
+ MUST compute the y-coordinate of the client's public key by using the
+ equation of the curve:
+
+ y^2 = x^3 + ax + b
+
+ and solving for y. There are two solutions for y, but since
+ compressed output is also being used, the selection is irrelevant.
+ The server reconstructs the client's public value, C, from (x, y).
+ If there is no solution for y or if (x, y) is not a valid point on
+ the elliptic curve (see Section 3.2.1), the server MUST treat the
+ ClientHello as if it did not have a password for a given username
+ (see Section 4.5.1.1).
+
+
+
+
+Harkins Informational [Page 13]
+
+RFC 8492 TLS Password February 2019
+
+
+ The server then uses scalar-op() with the reconstructed point C and
+ the private key it uses for protected passwords, s, to generate a
+ shared secret, and it derives a key-encrypting key, k, in the same
+ manner as that described in Section 4.3.1.
+
+ Z = scalar-op(s, C)
+
+ k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
+
+ The key, k, and the ciphertext portion of the pwd_name extension, u,
+ are passed to SIV-decrypt with no AAD and no nonce, to produce the
+ username:
+
+ username = SIV-decrypt(k, u)
+
+ If SIV-decrypt returns the symbol FAIL indicating unsuccessful
+ decryption and verification, the server MUST treat the ClientHello as
+ if it did not have a password for a given username (see
+ Section 4.5.1.1). If successful, the server has obtained the
+ client's username and can process it as needed. Any NULL octets
+ added by the client prior to encryption can be easily stripped off of
+ the string that represents the username.
+
+4.4. Fixing the Password Element
+
+ Prior to making a "commitment", both sides must generate a secret
+ Element (PE) in the chosen group, using the common password-derived
+ base. The server generates the PE after it receives the ClientHello
+ and chooses the particular group to use, and the client generates the
+ PE prior to sending the ClientHello in TLS 1.3 and upon receipt of
+ the ServerKeyExchange in TLS pre-1.3.
+
+ Fixing the PE involves an iterative "hunting-and-pecking" technique
+ using the prime from the negotiated group's domain parameter set and
+ an ECC-specific or FFC-specific operation, depending on the
+ negotiated group.
+
+ To thwart side-channel attacks that attempt to determine the number
+ of iterations of the hunting-and-pecking loop that are used to find
+ the PE for a given password, a security parameter, m, is used to
+ ensure that at least m iterations are always performed.
+
+ First, an 8-bit counter is set to the value one (1). Then, H is used
+ to generate a password seed from the counter, the prime of the
+ selected group, and the base (which is derived from the username,
+ password, and, optionally, the salt; see Section 3.4):
+
+ pwd-seed = H(base | counter | p)
+
+
+
+Harkins Informational [Page 14]
+
+RFC 8492 TLS Password February 2019
+
+
+ Next, a context is generated consisting of random information. For
+ versions of TLS less than 1.3, the context is a concatenation of the
+ ClientHello random and the ServerHello random. For TLS 1.3, the
+ context is the ClientHello random:
+
+ if (version < 1.3) {
+ context = ClientHello.random | ServerHello.random
+ } else {
+ context = ClientHello.random
+ }
+
+ Then, using the technique from Appendix B.5.1 of [FIPS186-4], the
+ pwd-seed is expanded, using the Pseudorandom Function (PRF), to the
+ length of the prime from the negotiated group's domain parameter set
+ plus a constant, sixty-four (64), to produce an intermediate pwd-tmp,
+ which is modularly reduced to create the pwd-value:
+
+ n = len(p) + 64
+ pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking",
+ context) [0..n];
+ pwd-value = (pwd-tmp mod (p - 1)) + 1
+
+ The pwd-value is then passed to the group-specific operation, which
+ either returns the selected PE or fails. If the group-specific
+ operation fails, the counter is incremented, a new pwd-seed is
+ generated, and the hunting-and-pecking process continues; this
+ procedure continues until the group-specific operation returns the
+ PE. After the PE has been chosen, the base is changed to a random
+ number, the counter is incremented, and the hunting-and-pecking
+ process continues until the counter is greater than the security
+ parameter, m.
+
+ The probability that one requires more than n iterations of the
+ hunting-and-pecking loop to find an ECC PE is roughly (q/2p)^n and to
+ find an FFC PE is roughly (q/p)^n, both of which rapidly approach
+ zero (0) as n increases. The security parameter, m, SHOULD be set
+ sufficiently large such that the probability that finding the PE
+ would take more than m iterations is sufficiently small (see
+ Section 7).
+
+ When the PE has been discovered, pwd-seed, pwd-tmp, and pwd-value
+ SHALL be irretrievably destroyed.
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 15]
+
+RFC 8492 TLS Password February 2019
+
+
+4.4.1. Computing an ECC Password Element
+
+ The group-specific operation for ECC groups uses pwd-value, pwd-seed,
+ and the equation for the curve to produce the PE. First, pwd-value
+ is used directly as the x-coordinate, x, with the equation for the
+ elliptic curve, with parameters a and b from the domain parameter set
+ of the curve, to solve for a y-coordinate, y. If there is no
+ solution to the quadratic equation, this operation fails and the
+ hunting-and-pecking process continues. If a solution is found, then
+ an ambiguity exists, as there are technically two solutions to the
+ equation, and pwd-seed is used to unambiguously select one of them.
+ If the low-order bit of pwd-seed is equal to the low-order bit of y,
+ then a candidate PE is defined as the point (x, y); if the low-order
+ bit of pwd-seed differs from the low-order bit of y, then a candidate
+ PE is defined as the point (x, p - y), where p is the prime over
+ which the curve is defined. The candidate PE becomes the PE, a
+ random number is used instead of the base, and the hunting-and-
+ pecking process continues until it has looped through m iterations,
+ where m is a suitably large number to prevent side-channel attacks
+ (see [RFC7664]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 16]
+
+RFC 8492 TLS Password February 2019
+
+
+ Algorithmically, the process looks like this:
+
+ found = 0
+ counter = 0
+ n = len(p) + 64
+ if (version < 1.3)
+ context = ClientHello.random | ServerHello.random
+ } else {
+ context = ClientHello.random
+ }
+ do {
+ counter = counter + 1
+ seed = H(base | counter | p)
+ tmp = PRF(seed, "TLS-PWD Hunting And Pecking", context) [0..n]
+ val = (tmp mod (p - 1)) + 1
+ if ( (val^3 + a*val + b) mod p is a quadratic residue)
+ then
+ if (found == 0)
+ then
+ x = val
+ save = seed
+ found = 1
+ base = random()
+ fi
+ fi
+ } while ((found == 0) || (counter <= m))
+ y = sqrt(x^3 + a*x + b) mod p
+ if ( lsb(y) == lsb(save))
+ then
+ PE = (x, y)
+ else
+ PE = (x, p - y)
+ fi
+
+ Figure 3: Fixing PE for ECC Groups
+
+ Checking whether a value is a quadratic residue modulo a prime can
+ leak information about that value in a side-channel attack.
+ Therefore, it is RECOMMENDED that the technique used to determine if
+ the value is a quadratic residue modulo p first blind the value with
+ a random number so that the blinded value can take on all numbers
+ between 1 and (p - 1) with equal probability. Determining the
+ quadratic residue in a fashion that resists leakage of information is
+ handled by flipping a coin and multiplying the blinded value by
+ either a random quadratic residue or a random quadratic nonresidue
+ and checking whether the multiplied value is a quadratic residue or a
+ quadratic nonresidue modulo p, respectively. The random residue and
+
+
+
+
+Harkins Informational [Page 17]
+
+RFC 8492 TLS Password February 2019
+
+
+ nonresidue can be calculated prior to hunting and pecking by
+ calculating the Legendre symbol on random values until they are
+ found:
+
+ do {
+ qr = random()
+ } while ( lgr(qr, p) != 1)
+
+ do {
+ qnr = random()
+ } while ( lgr(qnr, p) != -1)
+
+ Algorithmically, the masking technique to find out whether a value is
+ a quadratic residue modulo a prime or not looks like this:
+
+ is_quadratic_residue (val, p) {
+ r = (random() mod (p - 1)) + 1
+ num = (val * r * r) mod p
+ if ( lsb(r) == 1 )
+ num = (num * qr) mod p
+ if ( lgr(num, p) == 1)
+ then
+ return TRUE
+ fi
+ else
+ num = (num * qnr) mod p
+ if ( lgr(num, p) == -1)
+ then
+ return TRUE
+ fi
+ fi
+ return FALSE
+ }
+
+ The random quadratic residue and quadratic nonresidue (qr and qnr
+ above) can be used for all the hunting-and-pecking loops, but the
+ blinding value, r, MUST be chosen randomly for each loop.
+
+4.4.2. Computing an FFC Password Element
+
+ The group-specific operation for FFC groups takes the prime (p) and
+ the order (q) from the group's domain parameter set and the variable
+ pwd-value to directly produce a candidate PE, by exponentiating the
+ pwd-value to the value ((p - 1)/q) modulo p. See Section 3.2.2 when
+ the order is not part of the defined domain parameter set. If the
+ result is greater than one (1), the candidate PE becomes the PE, and
+
+
+
+
+
+Harkins Informational [Page 18]
+
+RFC 8492 TLS Password February 2019
+
+
+ the hunting-and-pecking process continues until it has looped through
+ m iterations, where m is a suitably large number to prevent
+ side-channel attacks (see [RFC7664]).
+
+ Algorithmically, the process looks like this:
+
+ found = 0
+ counter = 0
+ n = len(p) + 64
+ if (version < 1.3)
+ context = ClientHello.random | ServerHello.random
+ } else {
+ context = ClientHello.random
+ }
+ do {
+ counter = counter + 1
+ pwd-seed = H(base | counter | p)
+ pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking",
+ context) [0..n]
+ pwd-value = (pwd-tmp mod (p - 1)) + 1
+ PE = pwd-value^((p - 1)/q) mod p
+ if (PE > 1)
+ then
+ found = 1
+ base = random()
+ fi
+ } while ((found == 0) || (counter <= m))
+
+ Figure 4: Fixing PE for FFC Groups
+
+4.4.3. Password Naming
+
+ The client is required to identify herself to the server by adding
+ either a pwd_protect or pwd_clear extension to her ClientHello
+ message, depending on whether the client wishes to protect her
+ username (see Section 4.3) or not, respectively. The pwd_protect and
+ pwd_clear extensions use the standard mechanism defined in [RFC5246].
+ The "extension data" field of the extension SHALL contain a pwd_name,
+ which is used to identify the password shared between the client and
+ server. If username protection is performed and the ExtensionType is
+ pwd_protect, the contents of the pwd_name SHALL be constructed
+ according to Section 4.3.1.
+
+ enum { pwd_protect(29), pwd_clear(30) } ExtensionType;
+
+ opaque pwd_name<1..2^8-1>;
+
+
+
+
+
+Harkins Informational [Page 19]
+
+RFC 8492 TLS Password February 2019
+
+
+ An unprotected pwd_name SHALL be a UTF-8 encoded character string
+ processed according to the rules of the OpaqueString profile of
+ [RFC8265], and a protected pwd_name SHALL be a string of bits.
+
+4.4.4. Generating TLS-PWD Commit
+
+ The scalar and Element that comprise each peer's "commitment" are
+ generated as follows.
+
+ First, two random numbers, called "private" and "mask", between zero
+ and the order of the group (exclusive) are generated. If their sum
+ modulo the order of the group, q, equals zero (0) or one (1), the
+ numbers must be thrown away and new random numbers generated. If
+ their sum modulo the order of the group, q, is greater than one, the
+ sum becomes the scalar.
+
+ scalar = (private + mask) mod q
+
+ The Element is then calculated as the inverse of the group's scalar
+ operation (see the group-specific operations discussed in
+ Section 3.2) with the mask and PE.
+
+ Element = inverse(scalar-op(mask, PE))
+
+ After calculation of the scalar and Element, the mask SHALL be
+ irretrievably destroyed.
+
+4.5. Changes to Handshake Message Contents
+
+4.5.1. Pre-1.3 TLS
+
+4.5.1.1. ClientHello Changes
+
+ A client offering a PWD ciphersuite MUST include one of the pwd_name
+ extensions from Section 4.4.3 in her ClientHello.
+
+ If a server does not have a password for a client identified by the
+ username either extracted from the pwd_name (if unprotected) or
+ recovered using the technique provided in Section 4.3.2 (if
+ protected), or if recovery of a protected username fails, the server
+ SHOULD hide that fact by simulating the protocol -- putting random
+ data in the PWD-specific components of the ServerKeyExchange -- and
+ then rejecting the client's finished message with a "bad_record_mac"
+ alert [RFC8446]. To properly effect a simulated TLS-PWD exchange, an
+ appropriate delay SHOULD be inserted between receipt of the
+ ClientHello and response of the ServerHello. Alternately, a server
+
+
+
+
+
+Harkins Informational [Page 20]
+
+RFC 8492 TLS Password February 2019
+
+
+ MAY choose to terminate the exchange if a password is not found. The
+ security implication of terminating the exchange is to expose to an
+ attacker whether a username is valid or not.
+
+ The server decides on a group to use with the named user (see
+ Section 9) and generates the PE according to Section 4.4.2.
+
+4.5.1.2. ServerKeyExchange Changes
+
+ The domain parameter set for the selected group MUST be explicitly
+ specified by name in the ServerKeyExchange. ECC groups are specified
+ using the NamedCurve enumeration of [RFC8422], and FFC groups are
+ specified using the NamedGroup extensions added by [RFC7919] to the
+ "TLS Supported Groups" registry in [TLS_REG]. In addition to the
+ group specification, the ServerKeyExchange also contains the server's
+ "commitment" in the form of a scalar and Element, and the salt that
+ was used to store the user's password.
+
+ Two new values have been added to the enumerated KeyExchangeAlgorithm
+ to indicate TLS-PWD using FFC and TLS-PWD using ECC: ff_pwd and
+ ec_pwd, respectively.
+
+ enum { ff_pwd, ec_pwd } KeyExchangeAlgorithm;
+
+ struct {
+ opaque salt<1..2^8-1>;
+ NamedGroup ff_group;
+ opaque ff_selement<1..2^16-1>;
+ opaque ff_sscalar<1..2^16-1>;
+ } ServerFFPWDParams;
+
+ struct {
+ opaque salt<1..2^8-1>;
+ ECParameters curve_params;
+ ECPoint ec_selement;
+ opaque ec_sscalar<1..2^8-1>;
+ } ServerECPWDParams;
+
+ struct {
+ select (KeyExchangeAlgorithm) {
+ case ec_pwd:
+ ServerECPWDParams params;
+ case ff_pwd:
+ ServerFFPWDParams params;
+ };
+ } ServerKeyExchange;
+
+
+
+
+
+Harkins Informational [Page 21]
+
+RFC 8492 TLS Password February 2019
+
+
+4.5.1.2.1. Generation of ServerKeyExchange
+
+ The scalar and Element referenced in this section are derived
+ according to Section 4.4.4.
+
+4.5.1.2.1.1. ECC ServerKeyExchange
+
+ ECC domain parameters are specified in the ECParameters component of
+ the ECC-specific ServerKeyExchange as defined in [RFC8422]. The
+ scalar SHALL become the ec_sscalar component, and the Element SHALL
+ become the ec_selement of the ServerKeyExchange. If the client
+ requested a specific point format (compressed or uncompressed) with
+ the Supported Point Formats Extension (see [RFC8422]) in its
+ ClientHello, the Element MUST be formatted in the ec_selement to
+ conform to that request. If the client offered (an) elliptic
+ curve(s) in its ClientHello using the Supported Elliptic Curves
+ Extension, the server MUST include (one of the) named curve(s) in the
+ ECParameters field in the ServerKeyExchange and the key exchange
+ operations specified in Section 4.5.1.2.1 MUST use that group.
+
+ As mentioned in Section 3.2.1, characteristic-2 curves and curves
+ with a co-factor greater than one (1) SHALL NOT be used by TLS-PWD.
+
+4.5.1.2.1.2. FFC ServerKeyExchange
+
+ FFC domain parameters use the NamedGroup extension specified in
+ [RFC7919]. The scalar SHALL become the ff_sscalar component, and the
+ Element SHALL become the ff_selement in the FFC-specific
+ ServerKeyExchange.
+
+ As mentioned in Section 3.2.2, if the prime is a safe prime and no
+ order is included in the domain parameter set, the order added to the
+ ServerKeyExchange SHALL be the prime minus one divided by two --
+ (p - 1)/2.
+
+4.5.1.2.2. Processing of ServerKeyExchange
+
+ Upon receipt of the ServerKeyExchange, the client decides whether to
+ support the indicated group or not. If the client decides to support
+ the indicated group, the server's "commitment" MUST be validated by
+ ensuring that 1) the server's scalar value is greater than one (1)
+ and less than the order of the group, q and 2) the Element is valid
+ for the chosen group (see Sections 3.2.1 and 3.2.2 for how to
+ determine whether an Element is valid for the particular group. Note
+ that if the Element is a compressed point on an elliptic curve, it
+ MUST be uncompressed before checking its validity).
+
+
+
+
+
+Harkins Informational [Page 22]
+
+RFC 8492 TLS Password February 2019
+
+
+ If the group is acceptable and the server's "commitment" has been
+ successfully validated, the client extracts the salt from the
+ ServerKeyExchange and generates the PE according to Sections 3.4 and
+ 4.4.2. If the group is not acceptable or the server's "commitment"
+ failed validation, the exchange MUST be aborted.
+
+4.5.1.3. ClientKeyExchange Changes
+
+ When the value of KeyExchangeAlgorithm is either ff_pwd or ec_pwd,
+ the ClientKeyExchange is used to convey the client's "commitment" to
+ the server. It therefore contains a scalar and an Element.
+
+ struct {
+ opaque ff_celement<1..2^16-1>;
+ opaque ff_cscalar<1..2^16-1>;
+ } ClientFFPWDParams;
+
+ struct {
+ ECPoint ec_celement;
+ opaque ec_cscalar<1..2^8-1>;
+ } ClientECPWDParams;
+
+ struct {
+ select (KeyExchangeAlgorithm) {
+ case ff_pwd: ClientFFPWDParams;
+ case ec_pwd: ClientECPWDParams;
+ } exchange_keys;
+ } ClientKeyExchange;
+
+4.5.1.3.1. Generation of ClientKeyExchange
+
+ The client's scalar and Element are generated in the manner described
+ in Section 4.5.1.2.1.
+
+ For an FFC group, the scalar SHALL become the ff_cscalar component
+ and the Element SHALL become the ff_celement in the FFC-specific
+ ClientKeyExchange.
+
+ For an ECC group, the scalar SHALL become the ec_cscalar component
+ and the Element SHALL become the ec_celement in the ECC-specific
+ ClientKeyExchange. If the client requested a specific point format
+ (compressed or uncompressed) with the Supported Point Formats
+ Extension in its ClientHello, then the Element MUST be formatted in
+ the ec_celement to conform to its initial request.
+
+
+
+
+
+
+
+Harkins Informational [Page 23]
+
+RFC 8492 TLS Password February 2019
+
+
+4.5.1.3.2. Processing of ClientKeyExchange
+
+ Upon receipt of the ClientKeyExchange, the server must validate the
+ client's "commitment" by ensuring that 1) the client's scalar and
+ Element differ from the server's scalar and Element, 2) the client's
+ scalar value is greater than one (1) and less than the order of the
+ group, q, and 3) the Element is valid for the chosen group (see
+ Sections 3.2.1 and 3.2.2 for how to determine whether an Element is
+ valid for a particular group. Note that if the Element is a
+ compressed point on an elliptic curve, it MUST be uncompressed before
+ checking its validity). If any of these three conditions are not
+ met, the server MUST abort the exchange.
+
+4.5.2. TLS 1.3
+
+4.5.2.1. TLS 1.3 KeyShare
+
+ TLS 1.3 clients and servers convey their commit values in a
+ "key_share" extension. The structure of this extension SHALL be:
+
+ enum { ff_pwd, ec_pwd } KeyExchangeAlgorithm;
+
+ struct {
+ select (KeyExchangeAlgorithm) {
+ case ec_pwd:
+ opaque elemX[coordinate_length];
+ opaque elemY[coordinate_length];
+ case ff_pwd:
+ opaque elem[coordinate_length];
+ };
+ opaque scalar<1..2^8-1>
+ } PWDKeyShareEntry;
+
+ struct {
+ NamedGroup group;
+ PWDKeyShareEntry pwd_key_exchange<1..2^16-1>;
+ } KeyShareEntry;
+
+4.5.2.2. ClientHello Changes
+
+ The ClientHello message MUST include a pwd_name extension from
+ Section 4.4.3 and it MUST include a key_share extension from
+ Section 4.5.2.1.
+
+ Upon receipt of a ClientHello, the server MUST validate the key_share
+ extension_data [RFC8446] to ensure that the scalar value is greater
+ than one (1) and less than the order of the group q, and that the
+ Element is valid for the chosen group (see Sections 3.2.1 and 3.2.2).
+
+
+
+Harkins Informational [Page 24]
+
+RFC 8492 TLS Password February 2019
+
+
+ If a server does not have a password for a client identified by the
+ username either extracted from the pwd_name (if unprotected) or
+ recovered using the technique in Section 4.3.2 (if protected), or if
+ recovery of a protected username fails, the server SHOULD hide that
+ fact by simulating the protocol -- putting random data in the
+ PWD-specific components of its KeyShareEntry -- and then rejecting
+ the client's finished message with a "bad_record_mac" alert. To
+ properly effect a simulated TLS-PWD exchange, an appropriate delay
+ SHOULD be inserted between receipt of the ClientHello and response of
+ the ServerHello. Alternately, a server MAY choose to terminate the
+ exchange if a password is not found. The security implication of
+ terminating the exchange is to expose to an attacker whether a
+ username is valid or not.
+
+4.5.2.3. ServerHello Changes
+
+ If the server supports TLS-PWD, agrees with the group chosen by the
+ client, and finds an unsalted password indicated by the pwd_name
+ extension of the received ClientHello, its ServerHello MUST contain a
+ key_share extension from Section 4.5.2.1 in the same group as that
+ chosen by the client.
+
+ Upon receipt of a ServerHello, the client MUST validate the key_share
+ extension_data to ensure that the scalar value is greater than
+ one (1) and less than the order of the group q, and that the Element
+ is valid for the chosen group (see Sections 3.2.1 and 3.2.2).
+
+4.5.2.4. HelloRetryRequest Changes
+
+ The server sends this message in response to a ClientHello if it
+ desires a different group or if the password identified by the
+ client's password identified by pwd_name is salted.
+
+ A different group is indicated by adding the
+ KeyShareHelloRetryRequest extension to the HelloRetryRequest. The
+ indication of a salted password, and the salt used, is done by adding
+ the following structure:
+
+ enum { password_salt(31) } ExtensionType;
+
+ struct {
+ opaque pwd_salt<2^16-1>;
+ } password_salt;
+
+ A client that receives a HelloRetryRequest indicating the password
+ salt SHALL delete its computed PE and derive another version using
+ the salt prior to sending another ClientHello.
+
+
+
+
+Harkins Informational [Page 25]
+
+RFC 8492 TLS Password February 2019
+
+
+4.6. Computing the Shared Secret
+
+ The client and server use their private value as calculated in
+ Section 4.4.4 with the other party's Element and scalar for the
+ ServerHello or ClientHello, respectively (here denoted "Peer_Element"
+ and "peer_scalar") to generate the shared secret z.
+
+ z = F(scalar-op(private,
+ elem-op(Peer_Element,
+ scalar-op(peer_scalar, PE))))
+
+ For TLS versions prior to 1.3, the intermediate value, z, is then
+ used as the premaster secret after any leading bytes of z that
+ contain all zero bits have been stripped off. For TLS version 1.3,
+ leading zero bytes are retained, and the intermediate value z is used
+ as the (EC)DHE input in the key schedule.
+
+5. Ciphersuite Definition
+
+ This memo adds the following ciphersuites:
+
+ CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (0xC0,0xB0);
+
+ CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (0xC0,0xB1);
+
+ CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (0xC0,0xB2);
+
+ CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (0xC0,0xB3);
+
+ Implementations conforming to this specification MUST support the
+ TLS_ECCPWD_WITH_AES_128_GCM_SHA256 ciphersuite; they SHOULD support
+ the remaining ciphersuites.
+
+ When negotiated with a version of TLS prior to 1.2, the PRF from that
+ earlier version is used; when the negotiated version of TLS is TLS
+ 1.2, the PRF is the TLS 1.2 PRF [RFC5246], using the hash function
+ indicated by the ciphersuite; when the negotiated version of TLS is
+ TLS 1.3, the PRF is the Derive-Secret function from Section 7.1 of
+ [RFC8446]. Regardless of the TLS version, the TLS-PWD random
+ function, H, is always instantiated with the hash algorithm indicated
+ by the ciphersuite.
+
+ For those ciphersuites that use Cipher Block Chaining (CBC)
+ [SP800-38A] mode, the MAC is HMAC [RFC2104] with the hash function
+ indicated by the ciphersuite.
+
+
+
+
+
+
+Harkins Informational [Page 26]
+
+RFC 8492 TLS Password February 2019
+
+
+6. IANA Considerations
+
+ IANA has assigned three values for new TLS extension types from the
+ "TLS ExtensionType Values" registry defined in [RFC8446] and
+ [RFC8447]. They are pwd_protect (29), pwd_clear (30), and
+ password_salt (31). See Sections 4.5.1.1 and 4.5.2.2 for more
+ information.
+
+ In summary, the following rows have been added to the "TLS
+ ExtensionType Values" registry:
+
+ +-------+----------------+-------------+-----------+
+ | Value | Extension Name | TLS 1.3 | Reference |
+ +-------+----------------+-------------+-----------+
+ | 29 | pwd_protect | CH | RFC 8492 |
+ | 30 | pwd_clear | CH | RFC 8492 |
+ | 31 | password_salt | CH, SH, HRR | RFC 8492 |
+ +-------+----------------+-------------+-----------+
+
+ IANA has assigned the following ciphersuites from the "TLS Cipher
+ Suites" registry defined in [RFC8446] and [RFC8447]:
+
+ CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (0xC0,0xB0);
+
+ CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (0xC0,0xB1);
+
+ CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (0xC0,0xB2);
+
+ CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (0xC0,0xB3);
+
+ The "DTLS-OK" column in the registry has been set to "Y", and the
+ "Recommended" column has been set to "N" for all ciphersuites defined
+ in this memo.
+
+7. Security Considerations
+
+ A security proof of this key exchange in the random oracle model is
+ found in [lanskro].
+
+ A passive attacker against this protocol will see the
+ ServerKeyExchange and the ClientKeyExchange (in TLS pre-1.3), or the
+ KeyShare (from TLS 1.3), containing the scalar and Element of the
+ server and the client, respectively. The client and server
+ effectively hide their secret private value by masking it modulo the
+ order of the selected group. If the order is "q", then there are
+ approximately "q" distinct pairs of numbers that will sum to the
+ scalar values observed. It is possible for an attacker to iterate
+ through all such values, but for a large value of "q", this
+
+
+
+Harkins Informational [Page 27]
+
+RFC 8492 TLS Password February 2019
+
+
+ exhaustive search technique is computationally infeasible. The
+ attacker would have a better chance in solving the discrete logarithm
+ problem, which we have already assumed (see Section 3.5) to be an
+ intractable problem.
+
+ A passive attacker can take the Element from the ServerKeyExchange or
+ the ClientKeyExchange (in TLS pre-1.3), or from the KeyShare (from
+ TLS 1.3), and try to determine the random "mask" value used in its
+ construction and then recover the other party's "private" value from
+ the scalar in the same message. But this requires the attacker to
+ solve the discrete logarithm problem, which we assumed was
+ intractable.
+
+ Both the client and the server obtain a shared secret based on a
+ secret group Element and the private information they contributed to
+ the exchange. The secret group Element is based on the password. If
+ they do not share the same password, they will be unable to derive
+ the same secret group Element, and if they don't generate the same
+ secret group Element, they will be unable to generate the same shared
+ secret. Seeing a finished message will not provide any additional
+ advantage of attack, since it is generated with the unknowable
+ secret.
+
+ In TLS pre-1.3, an active attacker impersonating the client can
+ induce a server to send a ServerKeyExchange containing the server's
+ scalar and Element. The attacker can attempt to generate a
+ ClientKeyExchange and send it to the server, but she is required to
+ send a finished message first; therefore, the only information she
+ can obtain in this attack is less than the information she can obtain
+ from a passive attack, so this particular active attack is not very
+ fruitful.
+
+ In TLS pre-1.3, an active attacker can impersonate the server and
+ send a forged ServerKeyExchange after receiving the ClientHello. The
+ attacker then waits until it receives the ClientKeyExchange and
+ finished message from the client. Now the attacker can attempt to
+ run through all possible values of the password, computing the PE
+ (see Section 4.4), computing candidate premaster secrets (see
+ Section 4.6), and attempting to recreate the client's finished
+ message.
+
+ But the attacker committed to a single guess of the password with her
+ forged ServerKeyExchange. That value was used by the client in her
+ computation of the premaster secret, which was used to produce the
+ finished message. Any guess of the password that differs from the
+ password used in the forged ServerKeyExchange would result in each
+ side using a different PE in the computation of the premaster secret;
+ therefore, the finished message cannot be verified as correct, even
+
+
+
+Harkins Informational [Page 28]
+
+RFC 8492 TLS Password February 2019
+
+
+ if a subsequent guess, while running through all possible values, was
+ correct. The attacker gets one guess, and one guess only, per active
+ attack.
+
+ Instead of attempting to guess at the password, an attacker can
+ attempt to determine the PE and then launch an attack. But the PE is
+ determined by the output of the random function, H, which is
+ indistinguishable from a random source, since H is assumed to be a
+ "random oracle" (Section 3.5). Therefore, each Element of the finite
+ cyclic group will have an equal probability of being the PE. The
+ probability of guessing the PE will be 1/q, where q is the order of
+ the group. For a large value of "q", this will be computationally
+ infeasible.
+
+ The implications of resistance to dictionary attacks are significant.
+ An implementation can provision a password in a practical and
+ realistic manner -- i.e., it MAY be a character string, and it MAY be
+ relatively short -- and still maintain security. The nature of the
+ pool of potential passwords determines the size of the pool, D, and
+ countermeasures can prevent an attacker from determining the password
+ in the only possible way: repeated, active, guessing attacks. For
+ example, a simple four-character string using lowercase English
+ characters, and assuming random selection of those characters, will
+ result in D of over four hundred thousand. An attacker would need to
+ mount over one hundred thousand active, guessing attacks (which will
+ easily be detected) before gaining any significant advantage in
+ determining the pre-shared key.
+
+ Countermeasures to deal with successive active, guessing attacks are
+ only possible by noticing that a certain username is failing
+ repeatedly over a certain period of time. Attacks that attempt to
+ find a password for a random user are more difficult to detect. For
+ instance, if a device uses a serial number as a username and the pool
+ of potential passwords is sufficiently small, a more effective attack
+ would be to select a password and try all potential "users" to
+ disperse the attack and confound countermeasures. It is therefore
+ RECOMMENDED that implementations of TLS-PWD keep track of the total
+ number of failed authentications, regardless of username, in an
+ effort to detect and thwart this type of attack.
+
+ The benefits of resistance to dictionary attacks can be lessened by a
+ client using the same passwords with multiple servers. An attacker
+ could redirect a session from one server to the other if the attacker
+ knew that the intended server stored the same password for the client
+ as another server.
+
+
+
+
+
+
+Harkins Informational [Page 29]
+
+RFC 8492 TLS Password February 2019
+
+
+ An adversary that has access to, and a considerable amount of control
+ over, a client or server could attempt to mount a side-channel attack
+ to determine the number of times it took for a certain password (plus
+ client random and server random) to select a PE. Each such attack
+ could result in a successive "paring down" of the size of the pool of
+ potential passwords, resulting in a manageably small set from which
+ to launch a series of active attacks to determine the password. A
+ security parameter, m, is used to normalize the amount of work
+ necessary to determine the PE (see Section 4.4). The probability
+ that a password will require more than m iterations is roughly
+ (q/2p)^m for ECC groups and (q/p)^m for FFC groups, so it is possible
+ to mitigate side-channel attacks at the expense of a constant cost
+ per connection attempt. But if a particular password requires more
+ than k iterations, it will leak k bits of information to the
+ side-channel attacker; for some dictionaries, this will uniquely
+ identify the password. Therefore, the security parameter, m, needs
+ to be set with great care. It is RECOMMENDED that an implementation
+ set the security parameter, m, to a value of at least forty (40),
+ which will put the probability that more than forty iterations are
+ needed in the order of one in one trillion (1:1,000,000,000,000).
+
+ A database of salted passwords prevents an adversary who gains access
+ to the database from learning the client's password; it does not
+ prevent such an adversary from impersonating the client back to the
+ server. Each side uses the salted password, called the base, as the
+ authentication credential, so the database of salted passwords MUST
+ be afforded the security of a database of plaintext passwords.
+
+ Authentication is performed by proving knowledge of the password.
+ Any third party that knows the password shared by the client and
+ server can impersonate one to the other.
+
+ The static-ephemeral Diffie-Hellman exchange used to protect
+ usernames requires the server to reuse its Diffie-Hellman public key.
+ To prevent an "invalid curve" attack, an entity that reuses its
+ Diffie-Hellman public key needs to check whether the received
+ ephemeral public key is actually a point on the curve. This is done
+ explicitly as part of the server's reconstruction of the client's
+ public key out of only its x-coordinate ("compact representation").
+
+8. Human Rights Considerations
+
+ At the time of publication of this document, there was a growing
+ interest in considering the impacts that IETF (and IRTF) work can
+ have on human rights; some related research is discussed in
+ [RFC8280]. As such, the human rights considerations of TLS-PWD are
+ presented here.
+
+
+
+
+Harkins Informational [Page 30]
+
+RFC 8492 TLS Password February 2019
+
+
+ The key exchange underlying TLS-PWD uses public key cryptography to
+ perform authentication and authenticated key exchange. The keys it
+ produces can be used to establish secure connections between two
+ people to protect their communication. Implementations of TLS-PWD,
+ like implementations of other TLS ciphersuites that perform
+ authentication and authenticated key establishment, are considered
+ "armaments" or "munitions" by many governments around the world.
+
+ The most fundamental of human rights is the right to protect oneself.
+ The right to keep and bear arms is an example of this right.
+ Implementations of TLS-PWD can be used as arms, kept and borne, to
+ defend oneself against all manner of attackers -- criminals,
+ governments, lawyers, etc. TLS-PWD is a powerful tool in the
+ promotion and defense of universal human rights.
+
+9. Implementation Considerations
+
+ The selection of the ciphersuite and selection of the particular
+ finite cyclic group to use with the ciphersuite are divorced in this
+ memo, but they remain intimately close.
+
+ It is RECOMMENDED that implementations take note of the strength
+ estimates of particular groups and select a ciphersuite providing
+ commensurate security with its hash and encryption algorithms. A
+ ciphersuite whose encryption algorithm has a keylength less than the
+ strength estimate or whose hash algorithm has a block size that is
+ less than twice the strength estimate SHOULD NOT be used.
+
+ For example, the elliptic curve named "brainpoolP256r1" (whose
+ IANA-assigned number is 26) [RFC7027] provides an estimated 128 bits
+ of strength and would be compatible with 1) an encryption algorithm
+ supporting a key of that length and 2) a hash algorithm that has at
+ least a 256-bit block size. Therefore, a suitable ciphersuite to use
+ with brainpoolP256r1 could be TLS_ECCPWD_WITH_AES_128_GCM_SHA256 (see
+ Appendix A for an example of such an exchange).
+
+ Resistance to dictionary attacks means that the attacker must launch
+ an active attack to make a single guess at the password. If the size
+ of the pool from which the password was extracted was D and each
+ password in the pool has an equal probability of being chosen, then
+ the probability of success after a single guess is 1/D. After X
+ guesses and the removal of failed guesses from the pool of possible
+ passwords, the probability becomes 1/(D-X). As X grows, so does the
+ probability of success. Therefore, it is possible for an attacker to
+ determine the password through repeated brute-force, active, guessing
+ attacks. Implementations SHOULD take note of this fact and choose an
+ appropriate pool of potential passwords -- i.e., make D big.
+ Implementations SHOULD also take countermeasures -- for instance,
+
+
+
+Harkins Informational [Page 31]
+
+RFC 8492 TLS Password February 2019
+
+
+ refusing authentication attempts by a particular username for a
+ certain amount of time, after the number of failed authentication
+ attempts reaches a certain threshold. No such threshold or amount of
+ time is recommended in this memo.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti,
+ "HMAC: Keyed-Hashing for Message Authentication",
+ RFC 2104, DOI 10.17487/RFC2104, February 1997,
+ <https://www.rfc-editor.org/info/rfc2104>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246,
+ DOI 10.17487/RFC5246, August 2008,
+ <https://www.rfc-editor.org/info/rfc5246>.
+
+ [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV)
+ Authenticated Encryption Using the Advanced Encryption
+ Standard (AES)", RFC 5297, DOI 10.17487/RFC5297,
+ October 2008, <https://www.rfc-editor.org/info/rfc5297>.
+
+ [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
+ Key Derivation Function (HKDF)", RFC 5869,
+ DOI 10.17487/RFC5869, May 2010,
+ <https://www.rfc-editor.org/info/rfc5869>.
+
+ [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman
+ Ephemeral Parameters for Transport Layer Security (TLS)",
+ RFC 7919, DOI 10.17487/RFC7919, August 2016,
+ <https://www.rfc-editor.org/info/rfc7919>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+
+
+Harkins Informational [Page 32]
+
+RFC 8492 TLS Password February 2019
+
+
+ [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
+ Enforcement, and Comparison of Internationalized Strings
+ Representing Usernames and Passwords", RFC 8265,
+ DOI 10.17487/RFC8265, October 2017,
+ <https://www.rfc-editor.org/info/rfc8265>.
+
+ [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
+ Curve Cryptography (ECC) Cipher Suites for Transport Layer
+ Security (TLS) Versions 1.2 and Earlier", RFC 8422,
+ DOI 10.17487/RFC8422, August 2018,
+ <https://www.rfc-editor.org/info/rfc8422>.
+
+ [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
+ Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+ <https://www.rfc-editor.org/info/rfc8446>.
+
+ [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
+ and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
+ <https://www.rfc-editor.org/info/rfc8447>.
+
+ [TLS_REG] IANA, "Transport Layer Security (TLS) Parameters",
+ <https://www.iana.org/assignments/tls-parameters/>.
+
+10.2. Informative References
+
+ [FIPS186-4]
+ National Institute of Standards and Technology, "Digital
+ Signature Standard (DSS)", Federal Information Processing
+ Standards Publication 186-4, DOI 10.6028/NIST.FIPS.186-4,
+ July 2013, <https://nvlpubs.nist.gov/nistpubs/FIPS/
+ NIST.FIPS.186-4.pdf>.
+
+ [lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of
+ the Dragonfly Protocol", ISC 2015 Proceedings of the 18th
+ International Conference on Information
+ Security - Volume 9290, pp. 244-261,
+ DOI 10.1007/978-3-319-23318-5_14, September 2015.
+
+ [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical:
+ A Paradigm for Designing Efficient Protocols", Proceedings
+ of the 1st ACM Conference on Computer and Communications
+ Security, pp. 62-73, ACM Press, DOI 10.1145/168588.168596,
+ November 1993.
+
+ [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106, RFC 4086,
+ DOI 10.17487/RFC4086, June 2005,
+ <https://www.rfc-editor.org/info/rfc4086>.
+
+
+
+Harkins Informational [Page 33]
+
+RFC 8492 TLS Password February 2019
+
+
+ [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
+ Curve Cryptography Algorithms", RFC 6090,
+ DOI 10.17487/RFC6090, February 2011,
+ <https://www.rfc-editor.org/info/rfc6090>.
+
+ [RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography
+ (ECC) Brainpool Curves for Transport Layer Security
+ (TLS)", RFC 7027, DOI 10.17487/RFC7027, October 2013,
+ <https://www.rfc-editor.org/info/rfc7027>.
+
+ [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
+ "Enrollment over Secure Transport", RFC 7030,
+ DOI 10.17487/RFC7030, October 2013,
+ <https://www.rfc-editor.org/info/rfc7030>.
+
+ [RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664,
+ DOI 10.17487/RFC7664, November 2015,
+ <https://www.rfc-editor.org/info/rfc7664>.
+
+ [RFC8280] ten Oever, N. and C. Cath, "Research into Human Rights
+ Protocol Considerations", RFC 8280, DOI 10.17487/RFC8280,
+ October 2017, <https://www.rfc-editor.org/info/rfc8280>.
+
+ [SP800-38A]
+ Dworkin, M., "Recommendation for Block Cipher Modes of
+ Operation - Methods and Techniques", NIST Special
+ Publication 800-38A, DOI 10.6028/NIST.SP.800-38A,
+ December 2001, <https://nvlpubs.nist.gov/nistpubs/
+ Legacy/SP/nistspecialpublication800-38a.pdf>.
+
+ [SP800-56A]
+ Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
+ Davis, "Recommendation for Pair-Wise Key-Establishment
+ Schemes Using Discrete Logarithm Cryptography", NIST
+ Special Publication 800-56A, Revision 3,
+ DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
+ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
+ NIST.SP.800-56Ar3.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 34]
+
+RFC 8492 TLS Password February 2019
+
+
+Appendix A. Example Exchange
+
+ username: fred
+ password: barney
+
+ ---- prior to running TLS-PWD ----
+
+ server generates salt:
+
+ 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29
+ 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3
+
+ and a base:
+
+ 6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28
+ c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75
+
+ ---- state derived during the TLS-PWD exchange ----
+
+ client and server agree to use brainpoolP256r1
+
+ client and server generate the PE:
+
+ PE.x:
+ 29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3
+ a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6
+
+ server private and mask:
+
+ private:
+ 21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b
+ 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c
+ mask:
+ 0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f
+ 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5
+
+ client private and mask:
+
+ private:
+ 17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f
+ a1 89 ae 7a 6a 09 c7 7f 7b 43 8a f1 6d f4 a8 8b
+ mask:
+ 4f 74 5b df c2 95 d3 b3 84 29 f7 eb 30 25 a4 88
+ 83 72 8b 07 d8 86 05 c0 ee 20 23 16 a0 72 d1 bd
+
+
+
+
+
+
+
+Harkins Informational [Page 35]
+
+RFC 8492 TLS Password February 2019
+
+
+ both parties generate premaster secret and master secret
+
+ premaster secret:
+ 01 f7 a7 bd 37 9d 71 61 79 eb 80 c5 49 83 45 11
+ af 58 cb b6 dc 87 e0 18 1c 83 e7 01 e9 26 92 a4
+ master secret:
+ 65 ce 15 50 ee ff 3d aa 2b f4 78 cb 84 29 88 a1
+ 60 26 a4 be f2 2b 3f ab 23 96 e9 8a 7e 05 a1 0f
+ 3d 8c ac 51 4d da 42 8d 94 be a9 23 89 18 4c ad
+
+ ---- ssldump output of exchange ----
+
+ New TCP connection #1: Charlene Client <-> Sammy Server
+ 1 1 0.0018 (0.0018) C>SV3.3(173) Handshake
+ ClientHello
+ Version 3.3
+ random[32]=
+ 52 8f bf 52 17 5d e2 c8 69 84 5f db fa 83 44 f7
+ d7 32 71 2e bf a6 79 d8 64 3c d3 1a 88 0e 04 3d
+ ciphersuites
+ TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV
+ TLS_ECCPWD_WITH_AES_256_GCM_SHA384_PRIV
+ Unknown value 0xff
+ compression methods
+ NULL
+ extensions
+ TLS-PWD unprotected name[5]=
+ 04 66 72 65 64
+ elliptic curve point format[4]=
+ 03 00 01 02
+ elliptic curve list[58]=
+ 00 38 00 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b
+ 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00 06
+ 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00 01
+ 00 02 00 03 00 0f 00 10 00 11
+ Packet data[178]=
+ 16 03 03 00 ad 01 00 00 a9 03 03 52 8f bf 52 17
+ 5d e2 c8 69 84 5f db fa 83 44 f7 d7 32 71 2e bf
+ a6 79 d8 64 3c d3 1a 88 0e 04 3d 00 00 06 ff b3
+ ff b4 00 ff 01 00 00 7a b8 aa 00 05 04 66 72 65
+ 64 00 0b 00 04 03 00 01 02 00 0a 00 3a 00 38 00
+ 0e 00 0d 00 1c 00 19 00 0b 00 0c 00 1b 00 18 00
+ 09 00 0a 00 1a 00 16 00 17 00 08 00 06 00 07 00
+ 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00
+ 03 00 0f 00 10 00 11 00 0d 00 22 00 20 06 01 06
+ 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03
+ 01 03 02 03 03 02 01 02 02 02 03 01 01 00 0f 00
+ 01 01
+
+
+
+Harkins Informational [Page 36]
+
+RFC 8492 TLS Password February 2019
+
+
+ 1 2 0.0043 (0.0024) S>CV3.3(94) Handshake
+ ServerHello
+ Version 3.3
+ random[32]=
+ 52 8f bf 52 43 78 a1 b1 3b 8d 2c bd 24 70 90 72
+ 13 69 f8 bf a3 ce eb 3c fc d8 5c bf cd d5 8e aa
+ session_id[32]=
+ ef ee 38 08 22 09 f2 c1 18 38 e2 30 33 61 e3 d6
+ e6 00 6d 18 0e 09 f0 73 d5 21 20 cf 9f bf 62 88
+ cipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256_PRIV
+ compressionMethod NULL
+ extensions
+ renegotiate[1]=
+ 00
+ elliptic curve point format[4]=
+ 03 00 01 02
+ heartbeat[1]=
+ 01
+ Packet data[99]=
+ 16 03 03 00 5e 02 00 00 5a 03 03 52 8f bf 52 43
+ 78 a1 b1 3b 8d 2c bd 24 70 90 72 13 69 f8 bf a3
+ ce eb 3c fc d8 5c bf cd d5 8e aa 20 ef ee 38 08
+ 22 09 f2 c1 18 38 e2 30 33 61 e3 d6 e6 00 6d 18
+ 0e 09 f0 73 d5 21 20 cf 9f bf 62 88 ff b3 00 00
+ 12 ff 01 00 01 00 00 0b 00 04 03 00 01 02 00 0f
+ 00 01 01
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 37]
+
+RFC 8492 TLS Password February 2019
+
+
+ 1 3 0.0043 (0.0000) S>CV3.3(141) Handshake
+ ServerKeyExchange
+ params
+ salt[32]=
+ 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29
+ 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3
+ EC parameters = 3
+ curve id = 26
+ element[65]=
+ 04 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06
+ 61 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee
+ f3 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43
+ be 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db
+ e1
+ scalar[32]=
+ 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64 4f 5a
+ df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc 49 21
+ Packet data[146]=
+ 16 03 03 00 8d 0c 00 00 89 00 20 96 3c 77 cd c1
+ 3a 2a 8d 75 cd dd d1 e0 44 99 29 84 37 11 c2 1d
+ 47 ce 6e 63 83 cd da 37 e4 7d a3 03 00 1a 41 04
+ 22 bb d5 6b 48 1d 7f a9 0c 35 e8 d4 2f cd 06 61
+ 8a 07 78 de 50 6b 1b c3 88 82 ab c7 31 32 ee f3
+ 7f 02 e1 3b d5 44 ac c1 45 bd d8 06 45 0d 43 be
+ 34 b9 28 83 48 d0 3d 6c d9 83 24 87 b1 29 db e1
+ 00 20 2f 70 48 96 69 9f c4 24 d3 ce c3 37 17 64
+ 4f 5a df 7f 68 48 34 24 ee 51 49 2b b9 66 13 fc
+ 49 21
+
+ 1 4 0.0043 (0.0000) S>CV3.3(4) Handshake
+ ServerHelloDone
+ Packet data[9]=
+ 16 03 03 00 04 0e 00 00 00
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 38]
+
+RFC 8492 TLS Password February 2019
+
+
+ 1 5 0.0086 (0.0043) C>SV3.3(104) Handshake
+ ClientKeyExchange
+ element[65]=
+ 04 a0 c6 9b 45 0b 85 ae e3 9f 64 6b 6e 64 d3 c1
+ 08 39 5f 4b a1 19 2d bf eb f0 de c5 b1 89 13 1f
+ 59 5d d4 ba cd bd d6 83 8d 92 19 fd 54 29 91 b2
+ c0 b0 e4 c4 46 bf e5 8f 3c 03 39 f7 56 e8 9e fd
+ a0
+ scalar[32]=
+ 66 92 44 aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8
+ 24 fc 39 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48
+ Packet data[109]=
+ 16 03 03 00 68 10 00 00 64 41 04 a0 c6 9b 45 0b
+ 85 ae e3 9f 64 6b 6e 64 d3 c1 08 39 5f 4b a1 19
+ 2d bf eb f0 de c5 b1 89 13 1f 59 5d d4 ba cd bd
+ d6 83 8d 92 19 fd 54 29 91 b2 c0 b0 e4 c4 46 bf
+ e5 8f 3c 03 39 f7 56 e8 9e fd a0 00 20 66 92 44
+ aa 67 cb 00 ea 72 c0 9b 84 a9 db 5b b8 24 fc 39
+ 82 42 8f cd 40 69 63 ae 08 0e 67 7a 48
+
+ 1 6 0.0086 (0.0000) C>SV3.3(1) ChangeCipherSpec
+ Packet data[6]=
+ 14 03 03 00 01 01
+
+ 1 7 0.0086 (0.0000) C>SV3.3(40) Handshake
+ Packet data[45]=
+ 16 03 03 00 28 44 cd 3f 26 ed 64 9a 1b bb 07 c7
+ 0c 6d 3e 28 af e6 32 b1 17 29 49 a1 14 8e cb 7a
+ 0b 4b 70 f5 1f 39 c2 9c 7b 6c cc 57 20
+
+ 1 8 0.0105 (0.0018) S>CV3.3(1) ChangeCipherSpec
+ Packet data[6]=
+ 14 03 03 00 01 01
+
+ 1 9 0.0105 (0.0000) S>CV3.3(40) Handshake
+ Packet data[45]=
+ 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c
+ 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41
+ a2 21 94 90 12 72 23 18 24 21 c3 60 a4
+
+ 1 10 0.0107 (0.0002) C>SV3.3(100) application_data
+ Packet data....
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 39]
+
+RFC 8492 TLS Password February 2019
+
+
+Acknowledgements
+
+ The authenticated key exchange defined here has also been defined for
+ use in 802.11 networks, as an Extensible Authentication Protocol
+ (EAP) method, and as an authentication method for the Internet Key
+ Exchange Protocol (IKE). Each of these specifications has elicited
+ very helpful comments from a wide collection of people that have
+ allowed the definition of the authenticated key exchange to be
+ refined and improved.
+
+ The author would like to thank Scott Fluhrer for discovering the
+ "password as exponent" attack that was possible in an early version
+ of this key exchange and for his very helpful suggestions on the
+ techniques for fixing the PE to prevent it. The author would also
+ like to thank Hideyuki Suzuki for his insight in discovering an
+ attack against a previous version of the underlying key exchange
+ protocol. Special thanks to Lily Chen for helpful discussions on
+ hashing into an elliptic curve. Rich Davis suggested the defensive
+ checks that are part of the processing of the ServerKeyExchange and
+ ClientKeyExchange messages, and his various comments have greatly
+ improved the quality of this memo and the underlying key exchange on
+ which it is based.
+
+ Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik discussed on
+ the TLS mailing list the possibility of a side-channel attack against
+ the hunting-and-pecking loop. That discussion prompted the addition
+ of the security parameter, m, to the hunting-and-pecking loop. Scott
+ Fluhrer suggested the blinding technique to test whether a value is a
+ quadratic residue modulo a prime in a manner that does not leak
+ information about the value being tested.
+
+Author's Address
+
+ Dan Harkins (editor)
+ HP Enterprise
+ 3333 Scott Blvd.
+ Santa Clara, CA 95054
+ United States of America
+
+ Email: dharkins@lounge.org
+
+
+
+
+
+
+
+
+
+
+
+Harkins Informational [Page 40]
+