Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: ~sec-tls

RFC 8492

Secure Password Ciphersuites for Transport Layer Security (TLS)

Pages: 40
Informational
Errata
Part 1 of 2 – Pages 1 to 20
None   None   Next

Top   ToC   RFC8492 - Page 1
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.
Top   ToC   RFC8492 - Page 2
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
Top   ToC   RFC8492 - Page 3
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
Top   ToC   RFC8492 - Page 4
   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".
Top   ToC   RFC8492 - Page 5
   [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.
Top   ToC   RFC8492 - Page 6
   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.
Top   ToC   RFC8492 - Page 7
   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.
Top   ToC   RFC8492 - Page 8
   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)
Top   ToC   RFC8492 - Page 9
   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.
Top   ToC   RFC8492 - Page 10
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
Top   ToC   RFC8492 - Page 11
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
Top   ToC   RFC8492 - Page 12
   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.
Top   ToC   RFC8492 - Page 13
   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).
Top   ToC   RFC8492 - Page 14
   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)
Top   ToC   RFC8492 - Page 15
   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.
Top   ToC   RFC8492 - Page 16
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]).
Top   ToC   RFC8492 - Page 17
   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
Top   ToC   RFC8492 - Page 18
   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
Top   ToC   RFC8492 - Page 19
   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>;
Top   ToC   RFC8492 - Page 20
   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.



(page 20 continued on part 2)

Next Section