Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8492

Secure Password Ciphersuites for Transport Layer Security (TLS)

Pages: 40
Informational
Errata
Part 2 of 2 – Pages 20 to 40
First   Prev   None

Top   ToC   RFC8492 - Page 20   prevText

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
Top   ToC   RFC8492 - Page 21
   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;
Top   ToC   RFC8492 - Page 22
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).
Top   ToC   RFC8492 - Page 23
   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.
Top   ToC   RFC8492 - Page 24
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).
Top   ToC   RFC8492 - Page 25
   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.
Top   ToC   RFC8492 - Page 26

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.
Top   ToC   RFC8492 - Page 27

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
Top   ToC   RFC8492 - Page 28
   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
Top   ToC   RFC8492 - Page 29
   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.
Top   ToC   RFC8492 - Page 30
   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.
Top   ToC   RFC8492 - Page 31
   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,
Top   ToC   RFC8492 - Page 32
   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>.
Top   ToC   RFC8492 - Page 33
   [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>.
Top   ToC   RFC8492 - Page 34
   [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>.
Top   ToC   RFC8492 - Page 35

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
Top   ToC   RFC8492 - Page 36
   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
Top   ToC   RFC8492 - Page 37
   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
Top   ToC   RFC8492 - Page 38
   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
Top   ToC   RFC8492 - Page 39
   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....
Top   ToC   RFC8492 - Page 40

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