RFC 8492
Secure Password Ciphersuites for Transport Layer Security (TLS)
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.
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
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
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".
[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.
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.
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.
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)
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.
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
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 Handshake4.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
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) > 3844.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.
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).
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)
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.
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]).
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
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
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 Groups4.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>;
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)
