draft-ietf-tls-pwd-04.txt   draft-ietf-tls-pwd-05.txt 
Transport Layer Security D. Harkins, Ed. Transport Layer Security D. Harkins, Ed.
Internet-Draft Aruba Networks Internet-Draft Aruba Networks
Intended status: Standards Track D. Halasz, Ed. Intended status: Standards Track D. Halasz, Ed.
Expires: September 29, 2014 Halasz Ventures Expires: March 29, 2015 Halasz Ventures
March 28, 2014 September 25, 2014
Secure Password Ciphersuites for Transport Layer Security (TLS) Secure Password Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-pwd-04 draft-ietf-tls-pwd-05
Abstract Abstract
This memo defines several new ciphersuites for the Transport Layer This memo defines several new ciphersuites for the Transport Layer
Security (TLS) protocol to support certificate-less, secure Security (TLS) protocol to support certificate-less, secure
authentication using only a simple, low-entropy, password. The authentication using only a simple, low-entropy, password. The
ciphersuites are all based on an authentication and key exchange ciphersuites are all based on an authentication and key exchange
protocol that is resistant to off-line dictionary attack. protocol that is resistant to off-line dictionary attack.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 29, 2014. This Internet-Draft will expire on March 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Case for Certificate-less Authentication . . . . . . . 3 1.1. The Case for Certificate-less Authentication . . . . . . 3
1.2. Resistance to Dictionary Attack . . . . . . . . . . . . . 3 1.2. Resistance to Dictionary Attack . . . . . . . . . . . . . 3
2. Keyword Definitions . . . . . . . . . . . . . . . . . . . . . 4 2. Keyword Definitions . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 5 3.2. Discrete Logarithm Cryptography . . . . . . . . . . . . . 5
3.2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . 5 3.2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . 5
3.2.2. Finite Field Cryptography . . . . . . . . . . . . . . 6 3.2.2. Finite Field Cryptography . . . . . . . . . . . . . . 7
3.3. Instantiating the Random Function . . . . . . . . . . . . 7 3.3. Instantiating the Random Function . . . . . . . . . . . . 8
3.4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 8
4. Specification of the TLS-PWD Handshake . . . . . . . . . . . . 9 4. Specification of the TLS-PWD Handshake . . . . . . . . . . . 9
4.1. Protecting the Username . . . . . . . . . . . . . . . . . 9 4.1. Protecting the Username . . . . . . . . . . . . . . . . . 10
4.1.1. Construction of a Protected Username . . . . . . . . . 10 4.1.1. Construction of a Protected Username . . . . . . . . 11
4.1.2. Recovery of a Protected Username . . . . . . . . . . . 11 4.1.2. Recovery of a Protected Username . . . . . . . . . . 12
4.2. Fixing the Password Element . . . . . . . . . . . . . . . 12 4.2. Fixing the Password Element . . . . . . . . . . . . . . . 13
4.2.1. Computing an ECC Password Element . . . . . . . . . . 14 4.2.1. Computing an ECC Password Element . . . . . . . . . . 14
4.2.2. Computing an FFC Password Element . . . . . . . . . . 16 4.2.2. Computing an FFC Password Element . . . . . . . . . . 16
4.3. Changes to Handshake Message Contents . . . . . . . . . . 17 4.3. Changes to Handshake Message Contents . . . . . . . . . . 17
4.3.1. Client Hello Changes . . . . . . . . . . . . . . . . . 17 4.3.1. Client Hello Changes . . . . . . . . . . . . . . . . 17
4.3.2. Server Key Exchange Changes . . . . . . . . . . . . . 18 4.3.2. Server Key Exchange Changes . . . . . . . . . . . . . 18
4.3.2.1. Generation of ServerKeyExchange . . . . . . . . . 19 4.3.2.1. Generation of ServerKeyExchange . . . . . . . . . 19
4.3.2.2. Processing of ServerKeyExchange . . . . . . . . . 20 4.3.2.2. Processing of ServerKeyExchange . . . . . . . . . 20
4.3.3. Client Key Exchange Changes . . . . . . . . . . . . . 21 4.3.3. Client Key Exchange Changes . . . . . . . . . . . . . 21
4.3.3.1. Generation of Client Key Exchange . . . . . . . . 21 4.3.3.1. Generation of Client Key Exchange . . . . . . . . 21
4.3.3.2. Processing of Client Key Exchange . . . . . . . . 22 4.3.3.2. Processing of Client Key Exchange . . . . . . . . 22
4.4. Computing the Premaster Secret . . . . . . . . . . . . . . 22 4.4. Computing the Premaster Secret . . . . . . . . . . . . . 22
5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . . 23 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Implementation Considerations . . . . . . . . . . . . . . . . 28 9. Implementation Considerations . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 30 Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Background 1. Background
1.1. The Case for Certificate-less Authentication 1.1. The Case for Certificate-less Authentication
TLS usually uses public key certificates for authentication TLS usually uses public key certificates for authentication
[RFC5246]. This is problematic in some cases: [RFC5246]. This is problematic in some cases:
o Frequently, TLS [RFC5246] is used in devices owned, operated, and o Frequently, TLS [RFC5246] is used in devices owned, operated, and
provisioned by people who lack competency to properly use provisioned by people who lack competency to properly use
certificates and merely want to establish a secure connection certificates and merely want to establish a secure connection
using a more natural credential like a simple password. The using a more natural credential like a simple password. The
proliferation of deployments that use a self-signed server proliferation of deployments that use a self-signed server
certificate in TLS [RFC5246] followed by a PAP-style exchange over certificate in TLS [RFC5246] followed by a PAP-style exchange over
the unauthenticated channel underscores this case. the unauthenticated channel underscores this case.
o The alternatives to TLS-pwd for employing certificate-less TLS
authentication-- using pre-shared keys in an exchange that is
susceptible to dictionary attack, or using an SRP exchange that
requires users to, a priori, be fixed to a specific finite field
cryptorgraphy 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 o A password is a more natural credential than a certificate (from
early childhood people learn the semantics of a shared secret), so early childhood people learn the semantics of a shared secret), so
a password-based TLS ciphersuite can be used to protect an HTTP- a password-based TLS ciphersuite can be used to protect an HTTP-
based certificate enrollment scheme like EST [RFC7030] to parlay a based certificate enrollment scheme like EST [RFC7030] to parlay a
simple password into a certificate for subsequent use with any simple password into a certificate for subsequent use with any
certificate-based authentication protocol. This addresses a certificate-based authentication protocol. This addresses a
significant "chicken-and-egg" dilemma found with certificate-only significant "chicken-and-egg" dilemma found with certificate-only
use of [RFC5246]. use of [RFC5246].
o Some PIN-code readers will transfer the entered PIN to a smart o Some PIN-code readers will transfer the entered PIN to a smart
skipping to change at page 6, line 19 skipping to change at page 6, line 23
o A prime, q, which is the order of G, and thus is also the size of 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. the cryptographic subgroup that is generated by G.
o A co-factor, f, defined by the requirement that the size of the o A co-factor, f, defined by the requirement that the size of the
full elliptic curve group (including the "point at infinity") is full elliptic curve group (including the "point at infinity") is
the product of f and q. the product of f and q.
This memo uses the following ECC Functions: This memo uses the following ECC Functions:
o Z = elem-op(X,Y) = X + Y: two points on the curve X and Y, are o Z = elem-op(X,Y) = X + Y: two points on the curve X and Y, are
sumed to produce another point on the curve, Z. This is the group sumed to produce another point on the curve, Z. This is the group
operation for ECC groups. operation for ECC groups.
o Z = scalar-op(x,Y) = x * Y: an integer scalar, x, acts on a point 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 on the curve, Y, via repetitive addition (Y is added to itself x
times), to produce another EEC element, Z. times), to produce another EEC element, Z.
o Y = inverse(X): a point on the curve, X, has an inverse, Y, which 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 is also a point on the curve, when their sum is the "point at
infinity" (the identity for elliptic curve addition). In other infinity" (the identity for elliptic curve addition). In other
words, R + inverse(R) = "0". words, R + inverse(R) = "0".
skipping to change at page 8, line 10 skipping to change at page 8, line 20
too structured to be used directly as a random oracle. But they can too structured to be used directly as a random oracle. But they can
be used to instantiate the random oracle. be used to instantiate the random oracle.
The random function, H, in this memo is instantiated by using the The random function, H, in this memo is instantiated by using the
hash algorithm defined by the particular TLS-PWD ciphersuite in HMAC hash algorithm defined by the particular TLS-PWD ciphersuite in HMAC
mode with a key whose length is equal to block size of the hash mode with a key whose length is equal to block size of the hash
algorithm and whose value is zero. For example, if the ciphersuite algorithm and whose value is zero. For example, if the ciphersuite
is TLS_ECCPWD_WITH_AES_128_GCM_SHA256 then H will be instantiated is TLS_ECCPWD_WITH_AES_128_GCM_SHA256 then H will be instantiated
with SHA256 as: with SHA256 as:
H(x) = HMAC-SHA256([0]32, x) H(x) = HMAC-SHA256([0]32, x)
3.4. Passwords 3.4. Passwords
The authenticated key exchange used in TLS-PWD requires each side to 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 have a common view of a shared credential. To protect the server's
database of stored passwords, though, the password SHALL be salted database of stored passwords, though, the password SHALL be salted
and the result, called the base, SHALL be used as the authentication and the result, called the base, SHALL be used as the authentication
credential. credential.
The salting function is defined as: The salting function is defined as:
base = HMAC-SHA256(salt, username | password) base = HMAC-SHA256(salt, username | password)
The password used for generation of the base SHALL be represented as The password used for generation of the base SHALL be represented as
a UTF-8 encoded character string processed according to the rules of a UTF-8 encoded character string processed according to the rules of
the [RFC4013] profile of [RFC3454] and the salt SHALL be a 32 octet the [RFC4013] profile of [RFC3454] and the salt SHALL be a 32 octet
random number. The server SHALL store a triplet of the form: random number. The server SHALL store a triplet of the form:
{ username, base, salt } { username, base, salt }
And the client SHALL generate the base upon receiving the salt from And the client SHALL generate the base upon receiving the salt from
the server. the server.
3.5. Assumptions 3.5. Assumptions
The security properties of the authenticated key exchange defined in The security properties of the authenticated key exchange defined in
this memo are based on a number of assumptions: this memo are based on a number of assumptions:
1. The random function, H, is a "random oracle" as defined in 1. The random function, H, is a "random oracle" as defined in
skipping to change at page 9, line 24 skipping to change at page 10, line 5
The authenticated key exchange is accomplished by each side deriving The authenticated key exchange is accomplished by each side deriving
a password-based element, PE, in the chosen group, making a a password-based element, PE, in the chosen group, making a
"commitment" to a single guess of the password using PE, and "commitment" to a single guess of the password using PE, and
generating the Premaster Secret. The ability of each side to produce generating the Premaster Secret. The ability of each side to produce
a valid finished message authenticates itself to the other side. a valid finished message authenticates itself to the other side.
The authenticated key exchange is dropped into the standard TLS The authenticated key exchange is dropped into the standard TLS
message handshake by modifying some of the messages. message handshake by modifying some of the messages.
Client Server Client Server
-------- -------- -------- --------
Client Hello (name) --------> Client Hello (name) -------->
Server Hello Server Hello
Server Key Exchange (commit) Server Key Exchange (commit)
<-------- Server Hello Done <-------- Server Hello Done
Client Key Exchange (commit) Client Key Exchange (commit)
[Change cipher spec] [Change cipher spec]
Finished --------> Finished -------->
[Change cipher spec] [Change cipher spec]
<-------- Finished <-------- Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 1 Figure 1
4.1. Protecting the Username 4.1. Protecting the Username
The client is required to identify herself to the server before the The client is required to identify herself to the server before the
server can look up the appropriate client credential with which to server can look up the appropriate client credential with which to
perform the authenticated key exchange. This has negative privacy perform the authenticated key exchange. This has negative privacy
implicaitons and opens up the client to tracking and increased implicaitons and opens up the client to tracking and increased
monitoring. It is therefore useful for the client to be able to monitoring. It is therefore useful for the client to be able to
protect her username from passive monitors of the exchange and protect her username from passive monitors of the exchange and
against active attack by a malicious server. TLS-PWD provides such a against active attack by a malicious server. TLS-PWD provides such a
mechsnism. Support for protected usernames is RECOMMENDED. mechsnism. Support for protected usernames is RECOMMENDED.
To enable username protection a server choses a domain parameter set, To enable username protection a server choses a domain parameter set,
chooses a random private key, s, such that 1 < s < (q-1), where q is chooses a random private key, s, such that 1 < s < (q-1), where q is
the order of the chosen group, uses scalar-op() with the selected the order of the chosen group, uses scalar-op() with the selected
group's generator to generate a public key, S: group's generator to generate a public key, S:
S = scalar-op(s, G) S = scalar-op(s, G)
This keypair SHALL only be used for username protection. For This keypair SHALL only be used for username protection. For
efficiency, the domain parameter set used for userame protection MUST efficiency, the domain parameter set used for userame protection MUST
be based on elliptic curve cryptography. Any ECC group that is be based on elliptic curve cryptography. Any ECC group that is
approprate for TLS-PWD (see Section 3.2.1) is suitable for this approprate for TLS-PWD (see Section 3.2.1) is suitable for this
purpose but for interoperability, brainpoolP256r1 MUST be supported. purpose but for interoperability, brainpoolP256r1 MUST be supported.
The domain parameter set used for username protection does not The domain parameter set used for username protection does not
restrict the choice of domain parameter set used for the underlying restrict the choice of domain parameter set used for the underlying
key exchange in any way. key exchange in any way.
skipping to change at page 10, line 50 skipping to change at page 11, line 30
o SHA-256, SIV-128, l=256 bits: when len(p) <= 256 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-384, SIV-192, l=384 bits: when 256 < len(p) <= 384
o SHA-512, SIV-256, l=512 bits: when len(p) > 384 o SHA-512, SIV-256, l=512 bits: when len(p) > 384
4.1.1. Construction of a Protected Username 4.1.1. Construction of a Protected Username
Prior to initiating a TLS-PWD exchange, the client chooses a random 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 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 uses from which the server's public key was generated, and uses scalar-
scalar-op() with the group's generator to create a public key, C. It op() with the group's generator to create a public key, C. It uses
uses scalar-op() with the server's public key and c to create a scalar-op() with the server's public key and c to create a shared
shared secret and derives a key-encrypting key, k, using the "salt- secret and derives a key-encrypting key, k, using the "salt-less"
less" mode of HKDF [RFC5869]. mode of HKDF [RFC5869].
C = scalar-op(c, G) C = scalar-op(c, G)
Z = scalar-op(c, S) Z = scalar-op(c, S)
k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
Where NULL indicates the salt-free invocation and "" indicates an Where NULL indicates the salt-free invocation and "" indicates an
empty string (i.e. there is no "context" passed to HKDF). empty string (i.e. there is no "context" passed to HKDF).
The key, k, and the client's username is then passed to SIV-encrypt The key, k, and the client's username is then passed to SIV-encrypt
with no AAD and no nonce to produce an encrypted username, u: with no AAD and no nonce to produce an encrypted username, u:
u = SIV-encrypt(k, username) u = SIV-encrypt(k, username)
Note: the format of the ciphertext output from SIV includes the Note: the format of the ciphertext output from SIV includes the
authenticating synthetic initialization vector. authenticating synthetic initialization vector.
The protected username SHALL be the concatenation of the x-coordinate The protected username SHALL be the concatenation of the x-coordinate
of the client's public key, C, and the encrypted username, u. The 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 length of the x-coordinate of C MUST be equal to the length of the
group's prime, p, pre-pended with zeros, if necessary. The protected group's prime, p, pre-pended with zeros, if necessary. The protected
username is inserted into the PWD_name extension and the username is inserted into the PWD_name extension and the
ExtensionType MUST be PWD_protect (see Section 4.3.1). ExtensionType MUST be PWD_protect (see Section 4.3.1).
skipping to change at page 12, line 10 skipping to change at page 12, line 38
(it is the length of the prime from the domain parameter set used to (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 protect usernames) and can easily be separated from the ciphertext in
the PWD_name extension in the Client Hello-- the first len(p) bits the PWD_name extension in the Client Hello-- the first len(p) bits
are the x-coordinate of the client's public key and the remaining are the x-coordinate of the client's public key and the remaining
bits are the ciphertext. bits are the ciphertext.
Since compressed representation is used by the client, the server Since compressed representation is used by the client, the server
MUST compute the y-coordinate of the client's public key by using the MUST compute the y-coordinate of the client's public key by using the
equation of the curve: equation of the curve:
y^2 = x^3 + ax + b y^2 = x^3 + ax + b
and solving for y. There are two solutions for y but since and solving for y. There are two solutions for y but since
compressed output is also being used, the selection is irrelevant. compressed output is also being used, the selection is irrelevant.
The server reconstructs the client's public value, C, from (x, y). 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 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 the elliptic curve (see Section 3.2.1), the server MUST treat the
Client Hello as if it did not have a password for a given username Client Hello as if it did not have a password for a given username
(see Section 4.3.1). (see Section 4.3.1).
The server then uses scalar-op() with the reconstructed point C and The server then uses scalar-op() with the reconstructed point C and
the private key it uses for protected passwords, s, to generate a the private key it uses for protected passwords, s, to generate a
shared secret, and derives a key-encrypting key, k, in the same shared secret, and derives a key-encrypting key, k, in the same
manner as in Section 4.1.1. manner as in Section 4.1.1.
Z = scalar-op(s, C) Z = scalar-op(s, C)
k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l) k = HKDF-expand(HKDF-extract(NULL, Z.x), "", l)
The key, k, and the ciphertext portion of the PWD_name extension, u, 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 are passed to SIV-decrypt with no AAD and no nonce to produce the
username: username:
username = SIV-decrypt(k, u) username = SIV-decrypt(k, u)
If SIV-decrypt returns the symbol FAIL indicating unsuccessful If SIV-decrypt returns the symbol FAIL indicating unsuccessful
decryption and verification the server MUST treat the ClientHello as decryption and verification the server MUST treat the ClientHello as
if it did not have a password for a given username (see if it did not have a password for a given username (see
Section 4.3.1). If successful, the server has obtained the client's Section 4.3.1). If successful, the server has obtained the client's
username and can process it as needed. Any NULL octets added by the 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 client prior to encryption can be easily stripped off of the string
that represents the username. that represents the username.
4.2. Fixing the Password Element 4.2. Fixing the Password Element
skipping to change at page 13, line 18 skipping to change at page 13, line 46
To thwart side channel attacks which attempt to determine the number To thwart side channel attacks which attempt to determine the number
of iterations of the "hunting-and-pecking" loop are used to find PE of iterations of the "hunting-and-pecking" loop are used to find PE
for a given password, a security parameter, m, is used to ensure that for a given password, a security parameter, m, is used to ensure that
at least m iterations are always performed. at least m iterations are always performed.
First, an 8-bit counter is set to the value one (1). Then, H is used First, an 8-bit counter is set to the value one (1). Then, H is used
to generate a password seed from the a counter, the prime of the to generate a password seed from the a counter, the prime of the
selected group, and the base (which is derived from the username, selected group, and the base (which is derived from the username,
password, and salt): password, and salt):
pwd-seed = H(base | counter | p) pwd-seed = H(base | counter | p)
Then, using the technique from section B.5.1 of [FIPS186-3], the pwd- Then, using the technique from section B.5.1 of [FIPS186-3], the pwd-
seed is expanded using the PRF to the length of the prime from the seed is expanded using the PRF to the length of the prime from the
negotiated group's domain parameter set plus a constant sixty-four negotiated group's domain parameter set plus a constant sixty-four
(64) to produce an intermediate pwd-tmp which is modularly reduced to (64) to produce an intermediate pwd-tmp which is modularly reduced to
create pwd-value: create pwd-value:
n = len(p) + 64 n = len(p) + 64
pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking",
ClientHello.random | ServerHello.random) [0..n]; ClientHello.random | ServerHello.random) [0..n];
pwd-value = (pwd-tmp mod (p-1)) + 1 pwd-value = (pwd-tmp mod (p-1)) + 1
The pwd-value is then passed to the group-specific operation which The pwd-value is then passed to the group-specific operation which
either returns the selected password element or fails. If the group- either returns the selected password element or fails. If the group-
specific operation fails, the counter is incremented, a new pwd-seed specific operation fails, the counter is incremented, a new pwd-seed
is generated, and the hunting-and-pecking continues. This process is generated, and the hunting-and-pecking continues. This process
continues until the group-specific operation returns the password continues until the group-specific operation returns the password
element. After the password element has been chosen, the base is element. After the password element has been chosen, the base is
changed to a random number, the counter is incremented and the changed to a random number, the counter is incremented and the
hunting-and-pecking continues until the counter is greater than the hunting-and-pecking continues until the counter is greater than the
security parameter, m. security parameter, m.
skipping to change at page 17, line 40 skipping to change at page 17, line 40
either a PWD_protect or PWD_clear extension to the Client Hello either a PWD_protect or PWD_clear extension to the Client Hello
message depending on whether the client wishes to protect its message depending on whether the client wishes to protect its
username (see Section 4.1) or not, respectively. The PWD_protect and username (see Section 4.1) or not, respectively. The PWD_protect and
PWD_clear extensions use the standard mechanism defined in [RFC5246]. PWD_clear extensions use the standard mechanism defined in [RFC5246].
The "extension data" field of the PWD extension SHALL contain a The "extension data" field of the PWD extension SHALL contain a
PWD_name which is used to identify the password shared between the PWD_name which is used to identify the password shared between the
client and server. If username protection is performed, and the client and server. If username protection is performed, and the
ExtensionType is PWD_protect, the contents of the PWD_name SHALL be ExtensionType is PWD_protect, the contents of the PWD_name SHALL be
constructed according to Section 4.1.1). constructed according to Section 4.1.1).
enum { PWD_clear(TBD1), PWD_protect(TBD2) } ExtensionType; enum { PWD_clear(TBD1), PWD_protect(TBD2) } ExtensionType;
opaque PWD_name<1..2^8-1>; opaque PWD_name<1..2^8-1>;
An unprotected PWD_name SHALL be UTF-8 encoded character string An unprotected PWD_name SHALL be UTF-8 encoded character string
processed according to the rules of the [RFC4013] profile of processed according to the rules of the [RFC4013] profile of
[RFC3454] and a protected PWD_name SHALL be a string of bits. [RFC3454] and a protected PWD_name SHALL be a string of bits.
A client offering a PWD ciphersuite MUST include one of the PWD_name A client offering a PWD ciphersuite MUST include one of the PWD_name
extensions in her Client Hello. extensions in her Client Hello.
If a server does not have a password for a client identified by the If a server does not have a password for a client identified by the
username either extracted from the PWD_name, if unprotected, or username either extracted from the PWD_name, if unprotected, or
skipping to change at page 19, line 5 skipping to change at page 19, line 5
the ServerKeyExchange, either explicitly or, in the case of some the ServerKeyExchange, either explicitly or, in the case of some
elliptic curve groups, by name. In addition to the group elliptic curve groups, by name. In addition to the group
specification, the ServerKeyExchange also contains the server's specification, the ServerKeyExchange also contains the server's
"commitment" in the form of a scalar and element, and the salt which "commitment" in the form of a scalar and element, and the salt which
was used to store the user's password. was used to store the user's password.
Two new values have been added to the enumerated KeyExchangeAlgorithm Two new values have been added to the enumerated KeyExchangeAlgorithm
to indicate TLS-PWD using finite field cryptography, ff_pwd, and TLS- to indicate TLS-PWD using finite field cryptography, ff_pwd, and TLS-
PWD using elliptic curve cryptography, ec_pwd. PWD using elliptic curve cryptography, ec_pwd.
enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms; enum { ff_pwd, ec_pwd } KeyExchangeAlgorithms;
struct { struct {
opaque salt<1..2^8-1>; opaque salt<1..2^8-1>;
opaque pwd_p<1..2^16-1>; opaque pwd_p<1..2^16-1>;
opaque pwd_g<1..2^16-1>; opaque pwd_g<1..2^16-1>;
opaque pwd_q<1..2^16-1>; opaque pwd_q<1..2^16-1>;
opaque ff_selement<1..2^16-1>; opaque ff_selement<1..2^16-1>;
opaque ff_sscalar<1..2^16-1>; opaque ff_sscalar<1..2^16-1>;
} ServerFFPWDParams; } ServerFFPWDParams;
struct struct
opaque salt<1..2^8-1>; opaque salt<1..2^8-1>;
ECParameters curve_params; ECParameters curve_params;
ECPoint ec_selement; ECPoint ec_selement;
opaque ec_sscalar<1..2^8-1>; opaque ec_sscalar<1..2^8-1>;
} ServerECPWDParams; } ServerECPWDParams;
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case ec_pwd: case ec_pwd:
ServerECPWDParams params; ServerECPWDParams params;
case ff_pwd: case ff_pwd:
ServerFFPWDParams params; ServerFFPWDParams params;
}; };
} ServerKeyExchange; } ServerKeyExchange;
4.3.2.1. Generation of ServerKeyExchange 4.3.2.1. Generation of ServerKeyExchange
The scalar and Element that comprise the server's "commitment" are The scalar and Element that comprise the server's "commitment" are
generated as follows. generated as follows.
First two random numbers, called private and mask, between zero and First two random numbers, called private and mask, between zero and
the order of the group (exclusive) are generated. If their sum the order of the group (exclusive) are generated. If their sum
modulo the order of the group, q, equals zero the numbers must be modulo the order of the group, q, equals zero the numbers must be
thrown away and new random numbers generated. If their sum modulo thrown away and new random numbers generated. If their sum modulo
the order of the group, q, is greater than zero the sum becomes the the order of the group, q, is greater than zero the sum becomes the
scalar. scalar.
scalar = (private + mask) mod q scalar = (private + mask) mod q
The Element is then calculated as the inverse of the group's scalar The Element is then calculated as the inverse of the group's scalar
operation (see the group specific operations in Section 3.2) with the operation (see the group specific operations in Section 3.2) with the
mask and PE. mask and PE.
Element = inverse(scalar-op(mask, PE)) Element = inverse(scalar-op(mask, PE))
After calculation of the scalar and Element the mask SHALL be After calculation of the scalar and Element the mask SHALL be
irretrievably destroyed. irretrievably destroyed.
4.3.2.1.1. ECC Server Key Exchange 4.3.2.1.1. ECC Server Key Exchange
EEC domain parameters are specified, either explicitly or named, in EEC domain parameters are specified, either explicitly or named, in
the ECParameters component of the EEC-specific ServerKeyExchange as the ECParameters component of the EEC-specific ServerKeyExchange as
defined in [RFC4492]. The scalar SHALL become the ec_sscalar defined in [RFC4492]. The scalar SHALL become the ec_sscalar
component and the Element SHALL become the ec_selement of the component and the Element SHALL become the ec_selement of the
skipping to change at page 23, line 9 skipping to change at page 23, line 9
scalar-op(ClientKeyExchange.scalar, PE)))) scalar-op(ClientKeyExchange.scalar, PE))))
The intermediate value, z, is then used as the premaster secret after The intermediate value, z, is then used as the premaster secret after
any leading bytes of z that contain all zero bits have been stripped any leading bytes of z that contain all zero bits have been stripped
off. off.
5. Ciphersuite Definition 5. Ciphersuite Definition
This memo adds the following ciphersuites: This memo adds the following ciphersuites:
CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD );
CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD );
CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD );
Implementations conforming to this specification MUST support the Implementations conforming to this specification MUST support the
TLS_ECCPWD_WITH_AES_128_CBC_SHA ciphersuite; they SHOULD support TLS_ECCPWD_WITH_AES_128_CBC_SHA ciphersuite; they SHOULD support
TLS_ECCPWD_WITH_AES_128_CCM_SHA, TLS_FFCPWD_WITH_AES_128_CCM_SHA, TLS_ECCPWD_WITH_AES_128_CCM_SHA, TLS_FFCPWD_WITH_AES_128_CCM_SHA,
TLS_ECCPWD_WITH_AES_128_GCM_SHA256, TLS_ECCPWD_WITH_AES_128_GCM_SHA256,
TLS_ECCPWD_WITH_AES_256_GCM_SHA384; and MAY support the remaining TLS_ECCPWD_WITH_AES_256_GCM_SHA384; and MAY support the remaining
ciphersuites. ciphersuites.
When negotiated with a version of TLS prior to 1.2, the Pseudo-Random When negotiated with a version of TLS prior to 1.2, the Pseudo-Random
Function (PRF) from that version is used; otherwise, the PRF is the Function (PRF) from that version is used; otherwise, the PRF is the
skipping to change at page 24, line 38 skipping to change at page 24, line 37
IANA SHALL assign two values for a new TLS extention type from the IANA SHALL assign two values for a new TLS extention type from the
TLS ExtensionType Registry defined in [RFC5246] with the name TLS ExtensionType Registry defined in [RFC5246] with the name
"pwd_protect" and "pwd_clear". The RFC editor SHALL replace TBD1 and "pwd_protect" and "pwd_clear". The RFC editor SHALL replace TBD1 and
TBD2 in Section 4.3.1 with the IANA-assigned value for these TBD2 in Section 4.3.1 with the IANA-assigned value for these
extensions. extensions.
IANA SHALL assign nine new ciphersuites from the TLS Ciphersuite IANA SHALL assign nine new ciphersuites from the TLS Ciphersuite
Registry defined in [RFC5246] for the following ciphersuites: Registry defined in [RFC5246] for the following ciphersuites:
CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD ); CipherSuite TLS_FFCPWD_WITH_3DES_EDE_CBC_SHA = ( TBD, TBD );
CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); CipherSuite TLS_FFCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_128_CBC_SHA = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_128_GCM_SHA256 = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_256_GCM_SHA384 = (TBD, TBD );
CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD ); CipherSuite TLS_FFCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD ); CipherSuite TLS_ECCPWD_WITH_AES_128_CCM_SHA256 = (TBD, TBD );
CipherSuite TLS_ECCPWD_WITH_AES_256_CCM_SHA384 = (TBD, TBD );
The RFC editor SHALL replace (TBD, TBD) in all the ciphersuites The RFC editor SHALL replace (TBD, TBD) in all the ciphersuites
defined in Section 5 with the appropriate IANA-assigned values. The defined in Section 5 with the appropriate IANA-assigned values. The
"DTLS-OK" column in the ciphersuite registry SHALL be set to "Y" for "DTLS-OK" column in the ciphersuite registry SHALL be set to "Y" for
all ciphersuites defined in this memo. all ciphersuites defined in this memo.
8. Security Considerations 8. Security Considerations
A passive attacker against this protocol will see the A passive attacker against this protocol will see the
ServerKeyExchange and the ClientKeyExchange containing the server's ServerKeyExchange and the ClientKeyExchange containing the server's
skipping to change at page 28, line 42 skipping to change at page 28, line 38
would be compatible with an encryption algorithm supporting a key of would be compatible with an encryption algorithm supporting a key of
that length, and a hash algorithm that has at least a 256-bit that length, and a hash algorithm that has at least a 256-bit
blocksize. Therefore, a suitable ciphersuite to use with blocksize. Therefore, a suitable ciphersuite to use with
brainpoolP256r1 could be TLS_ECCPWD_WITH_AES_128_GCM_SHA256 (see brainpoolP256r1 could be TLS_ECCPWD_WITH_AES_128_GCM_SHA256 (see
Appendix A for an example of such an exchange). Appendix A for an example of such an exchange).
Resistance to dictionary attack means that the attacker must launch Resistance to dictionary attack means that the attacker must launch
an active attack to make a single guess at the password. If the size an active attack to make a single guess at the password. If the size
of the pool from which the password was extracted was D, and each of the pool from which the password was extracted was D, and each
password in the pool has an equal probability of being chosen, then password in the pool has an equal probability of being chosen, then
the probability of success after a single guess is 1/D. After X the probability of success after a single guess is 1/D. After X
guesses, and removal of failed guesses from the pool of possible guesses, and removal of failed guesses from the pool of possible
passwords, the probability becomes 1/(D-X). As X grows so does the passwords, the probability becomes 1/(D-X). As X grows so does the
probability of success. Therefore it is possible for an attacker to probability of success. Therefore it is possible for an attacker to
determine the password through repeated brute-force, active, guessing determine the password through repeated brute-force, active, guessing
attacks. Implementations SHOULD take note of this fact and choose an attacks. Implementations SHOULD take note of this fact and choose an
appropriate pool of potential passwords-- i.e. make D big. appropriate pool of potential passwords-- i.e. make D big.
Implementations SHOULD also take countermeasures, for instance Implementations SHOULD also take countermeasures, for instance
refusing authentication attempts by a particular username for a refusing authentication attempts by a particular username for a
certain amount of time, after the number of failed authentication certain amount of time, after the number of failed authentication
attempts reaches a certain threshold. No such threshold or amount of attempts reaches a certain threshold. No such threshold or amount of
time is recommended in this memo. time is recommended in this memo.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104, February
February 1997. 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, Internationalized Strings ("stringprep")", RFC 3454,
December 2002. December 2002.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005. and Passwords", RFC 4013, February 2005.
skipping to change at page 29, line 40 skipping to change at page 29, line 38
Standard (AES)", RFC 5297, October 2008. Standard (AES)", RFC 5297, October 2008.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010. Key Derivation Function (HKDF)", RFC 5869, May 2010.
10.2. Informative References 10.2. Informative References
[FIPS186-3] [FIPS186-3]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", Federal Information Processing Signature Standard (DSS)", Federal Information Processing
Standards Publication 186-3. Standards Publication 186-3, .
[RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: [RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical:
A Paradigm for Designing Efficient Protocols", Proceedings A Paradigm for Designing Efficient Protocols", Proceedings
of the 1st ACM Conference on Computer and Communication of the 1st ACM Conference on Computer and Communication
Security, ACM Press, 1993. Security, ACM Press, 1993.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
 End of changes. 56 change blocks. 
127 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/