draft-ietf-tls-pwd-03.txt   draft-ietf-tls-pwd-04.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: June 15, 2014 Halasz Ventures Expires: September 29, 2014 Halasz Ventures
December 12, 2013 March 28, 2014
Secure Password Ciphersuites for Transport Layer Security (TLS) Secure Password Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-pwd-03 draft-ietf-tls-pwd-04
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 June 15, 2014. This Internet-Draft will expire on September 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . 6
3.3. Instantiating the Random Function . . . . . . . . . . . . 7 3.3. Instantiating the Random Function . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . 9
4.1.1. Construction of a Protected Username . . . . . . . . . 10 4.1.1. Construction of a Protected Username . . . . . . . . . 10
4.1.2. Recovery of a Protected Username . . . . . . . . . . . 11 4.1.2. Recovery of a Protected Username . . . . . . . . . . . 11
4.2. Fixing the Password Element . . . . . . . . . . . . . . . 12 4.2. Fixing the Password Element . . . . . . . . . . . . . . . 12
4.2.1. Computing an ECC Password Element . . . . . . . . . . 13 4.2.1. Computing an ECC Password Element . . . . . . . . . . 14
4.2.2. Computing an FFC Password Element . . . . . . . . . . 15 4.2.2. Computing an FFC Password Element . . . . . . . . . . 16
4.3. Changes to Handshake Message Contents . . . . . . . . . . 15 4.3. Changes to Handshake Message Contents . . . . . . . . . . 17
4.3.1. Client Hello Changes . . . . . . . . . . . . . . . . . 15 4.3.1. Client Hello Changes . . . . . . . . . . . . . . . . . 17
4.3.2. Server Key Exchange Changes . . . . . . . . . . . . . 16 4.3.2. Server Key Exchange Changes . . . . . . . . . . . . . 18
4.3.2.1. Generation of ServerKeyExchange . . . . . . . . . 17 4.3.2.1. Generation of ServerKeyExchange . . . . . . . . . 19
4.3.2.2. Processing of ServerKeyExchange . . . . . . . . . 18 4.3.2.2. Processing of ServerKeyExchange . . . . . . . . . 20
4.3.3. Client Key Exchange Changes . . . . . . . . . . . . . 19 4.3.3. Client Key Exchange Changes . . . . . . . . . . . . . 21
4.3.3.1. Generation of Client Key Exchange . . . . . . . . 19 4.3.3.1. Generation of Client Key Exchange . . . . . . . . 21
4.3.3.2. Processing of Client Key Exchange . . . . . . . . 20 4.3.3.2. Processing of Client Key Exchange . . . . . . . . 22
4.4. Computing the Premaster Secret . . . . . . . . . . . . . . 20 4.4. Computing the Premaster Secret . . . . . . . . . . . . . . 22
5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . . 21 5. Ciphersuite Definition . . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Implementation Considerations . . . . . . . . . . . . . . . . 26 9. Implementation Considerations . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 28 Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
indicates a string consisting of the single bit "a" repeated "b" indicates a string consisting of the single bit "a" repeated "b"
times. times.
x mod y x mod y
indicates the remainder of division of x by y. The result will indicates the remainder of division of x by y. The result will
be between 0 and y. be between 0 and y.
len(x) len(x)
indicates the length in bits of the string 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) LSB(x)
returns the least-significant bit of the bitstring "x". returns the least-significant bit of the bitstring "x".
G.x G.x
indicates the x-coordinate of a point, G, on and elliptic curve. indicates the x-coordinate of a point, G, on an elliptic curve.
3.2. Discrete Logarithm Cryptography 3.2. Discrete Logarithm Cryptography
The ciphersuites defined in this memo use discrete logarithm The ciphersuites defined in this memo use discrete logarithm
cryptography (see [SP800-56A]) to produce an authenticated and shared 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 secret value that is an element in a group defined by a set of domain
parameters. The domain parameters can be based on either Finite parameters. The domain parameters can be based on either Finite
Field Cryptography (FFC) or Elliptic Curve Cryptography (EEC). Field Cryptography (FFC) or Elliptic Curve Cryptography (EEC).
TLS [RFC5246] allows for both FFC and ECC domain parameter sets to be TLS [RFC5246] allows for both FFC and ECC domain parameter sets to be
skipping to change at page 14, line 20 skipping to change at page 15, line 5
If the low-order bit of pwd-seed is equal to the low-order bit of y, 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 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 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 PE is defined as the point (x, p - y), where p is the prime over
which the curve is defined. The candidate PE becomes PE, a random which the curve is defined. The candidate PE becomes PE, a random
number is used instead of the base, and the hunting and pecking number is used instead of the base, and the hunting and pecking
continues until it has looped through m iterations. continues until it has looped through m iterations.
Algorithmically, the process looks like this: Algorithmically, the process looks like this:
found = 0 found = 0
counter = 0 counter = 0
base = H(username | password | salt) base = H(username | password | salt)
n = len(p) + 64 n = len(p) + 64
do { do {
counter = counter + 1 counter = counter + 1
pwd-seed = H(base | counter | p) seed = H(base | counter | p)
pwd-tmp = PRF(pwd-seed, "TLS-PWD Hunting And Pecking", tmp = PRF(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 val = (tmp mod (p-1)) + 1
x = pwd-value if ( (val^3 + a*val + b) mod p is a quadratic residue)
if ( (y = sqrt(x^3 + ax + b)) != FAIL)
then
if (found == 0)
then
if (LSB(y) == LSB(pwd-seed))
then then
PE = (x, y) if (found == 0)
else then
PE = (x, p-y) x = val
save = seed
found = 1
base = random()
fi fi
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 fi
} while ((found == 0) || (counter <= m))
Figure 2: Fixing PE for ECC Groups Figure 2: Fixing PE for ECC Groups
Checking whether a value is a quadradic 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 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 quadradic residue or a
quadradic 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 non-residue (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.2.2. Computing an FFC Password Element 4.2.2. Computing an FFC Password Element
The group-specific operation for FFC groups takes pwd-value, and the The group-specific operation for FFC groups takes pwd-value, and the
prime, p, and order, q, from the group's domain parameter set (see prime, p, and order, q, from the group's domain parameter set (see
Section 3.2.2 when the order is not part of the defined domain Section 3.2.2 when the order is not part of the defined domain
parameter set) to directly produce a candidate password element, by parameter set) to directly produce a candidate password element, by
exponentiating the pwd-value to the value ((p-1)/q) modulo the prime. exponentiating the pwd-value to the value ((p-1)/q) modulo the prime.
If the result is greater than one (1), the candidate password element If the result is greater than one (1), the candidate password element
becomes PE, and the hunting and pecking terminates successfully. becomes PE, and the hunting and pecking terminates successfully.
skipping to change at page 22, line 22 skipping to change at page 24, line 22
protocol. Special thanks to Lily Chen for helpful discussions on protocol. Special thanks to Lily Chen for helpful discussions on
hashing into an elliptic curve. Rich Davis suggested the defensive hashing into an elliptic curve. Rich Davis suggested the defensive
checks that are part of the processing of the ServerKeyExchange and checks that are part of the processing of the ServerKeyExchange and
ClientKeyExchange messages, and his various comments have greatly ClientKeyExchange messages, and his various comments have greatly
improved the quality of this memo and the underlying key exchange on improved the quality of this memo and the underlying key exchange on
which it is based. which it is based.
Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik, discussed the Martin Rex, Peter Gutmann, Marsh Ray, and Rene Struik, discussed the
possibility of a side-channel attack against the hunting-and-pecking possibility of a side-channel attack against the hunting-and-pecking
loop on the TLS mailing list. That discussion prompted the addition loop on the TLS mailing list. That discussion prompted the addition
of the security parameter, m, to the hunting-and-pecking loop. of the security parameter, m, to the hunting-and-pecking loop. Scott
Flurer suggested the blinding technique to test whether a value is a
quadratic residue modulo a prime in a manner that does not leak
information about the value being tested.
7. IANA Considerations 7. IANA Considerations
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
skipping to change at page 28, line 43 skipping to change at page 30, line 49
96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29 96 3c 77 cd c1 3a 2a 8d 75 cd dd d1 e0 44 99 29
84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3 84 37 11 c2 1d 47 ce 6e 63 83 cd da 37 e4 7d a3
and a base: and a base:
6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28 6e 7c 79 82 1b 9f 8e 80 21 e9 e7 e8 26 e9 ed 28
c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75 c4 a1 8a ef c8 75 0c 72 6f 74 c7 09 61 d7 00 75
---- state derived during the TLS-PWD exchange ---- ---- state derived during the TLS-PWD exchange ----
client and server agree to use brainpoolP256r1
client and server generate PE: client and server generate PE:
pe.x: PE.x:
29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3 29 b2 38 55 81 9f 9c 3f c3 71 ba e2 84 f0 93 a3
a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6 a4 fd 34 72 d4 bd 2e 9d f7 15 2d 22 ab 37 aa e6
server private and mask: server private and mask:
private: private:
21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b 21 d9 9d 34 1c 97 97 b3 ae 72 df d2 89 97 1f 1b
74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c 74 ce 9d e6 8a d4 b9 ab f5 48 88 d8 f6 c5 04 3c
mask: mask:
0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f 0d 96 ab 62 4d 08 2c 71 25 5b e3 64 8d cd 30 3f
6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5 6a b0 ca 61 a9 50 34 a5 53 e3 30 8d 1d 37 44 e5
client private and mask: client private and mask:
private: private:
17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f 17 1d e8 ca a5 35 2d 36 ee 96 a3 99 79 b5 b7 2f
 End of changes. 17 change blocks. 
52 lines changed or deleted 110 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/