Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

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