draft-ietf-tls-pwd-06.txt   draft-ietf-tls-pwd-07.txt 
Transport Layer Security D. Harkins, Ed. Transport Layer Security D. Harkins, Ed.
Internet-Draft Aruba Networks Internet-Draft HP Enterprise
Intended status: Standards Track D. Halasz, Ed. Intended status: Standards Track D. Halasz, Ed.
Expires: September 25, 2015 Halasz Ventures Expires: August 28, 2016 Halasz Ventures
March 24, 2015 February 25, 2016
Secure Password Ciphersuites for Transport Layer Security (TLS) Secure Password Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-pwd-06 draft-ietf-tls-pwd-07
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 September 25, 2015. This Internet-Draft will expire on August 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 46 skipping to change at page 2, line 46
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. Human Rights Considerations . . . . . . . . . . . . . . . . . 28 9. Human Rights Considerations . . . . . . . . . . . . . . . . . 28
10. Implementation Considerations . . . . . . . . . . . . . . . . 28 10. Implementation Considerations . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 30 Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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
skipping to change at page 9, line 26 skipping to change at page 9, line 26
very good discussion of this can be found in [RFC4086]. very good discussion of this can be found in [RFC4086].
If the server supports username protection (see Section 4.1), it is If the server supports username protection (see Section 4.1), it is
assumed that the server has chosen a domain parameter set and assumed that the server has chosen a domain parameter set and
generated a username-protection keypair. The chosen domain parameter generated a username-protection keypair. The chosen domain parameter
set and public key are assumed to be conveyed to the client at the set and public key are assumed to be conveyed to the client at the
time the client's username and password were provisioned. time the client's username and password were provisioned.
4. Specification of the TLS-PWD Handshake 4. Specification of the TLS-PWD Handshake
The key exchange underlying TLS-PWD is the "dragonfly" PAKE as
defined in [RFC7664].
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
skipping to change at page 16, line 7 skipping to change at page 16, line 7
by flipping a coin and multiplying the blinded value by either a by flipping a coin and multiplying the blinded value by either a
random quadratic residue or a random quadratic nonresidue and random quadratic residue or a random quadratic nonresidue and
checking whether the multiplied value is a quadradic residue or a checking whether the multiplied value is a quadradic residue or a
quadradic nonresidue modulo p, respectively. The random residue and quadradic nonresidue modulo p, respectively. The random residue and
nonresidue can be calculated prior to hunting-and-pecking by nonresidue can be calculated prior to hunting-and-pecking by
calculating the legendre symbol on random values until they are calculating the legendre symbol on random values until they are
found: found:
do { do {
qr = random() qr = random()
} while ( lgr(qr, p) == -1) } while ( lgr(qr, p) != 1)
do { do {
qnr = random() qnr = random()
} while ( lgr(qnr, p) == 1) } while ( lgr(qnr, p) != -1)
Algorithmically, the masking technique to find out whether a value is Algorithmically, the masking technique to find out whether a value is
a quadratic residue modulo a prime or not looks like this: a quadratic residue modulo a prime or not looks like this:
is_quadratic_residue (val, p) { is_quadratic_residue (val, p) {
r = (random() mod (p - 1)) + 1 r = (random() mod (p - 1)) + 1
num = (val * r * r) mod p num = (val * r * r) mod p
if ( lsb(r) == 1 ) if ( lsb(r) == 1 )
num = (num * qr) mod p num = (num * qr) mod p
if ( lgr(num, p) == 1) if ( lgr(num, p) == 1)
skipping to change at page 25, line 13 skipping to change at page 25, line 13
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 );
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 security proof of this key exchange in the random oracle model is
found in [lanskro].
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
scalar and Element, and the client's scalar and Element, scalar and Element, and the client's scalar and Element,
respectively. The client and server effectively hide their secret respectively. The client and server effectively hide their secret
private value by masking it modulo the order of the selected group. private value by masking it modulo the order of the selected group.
If the order is "q", then there are approximately "q" distinct pairs If the order is "q", then there are approximately "q" distinct pairs
of numbers that will sum to the scalar values observed. It is of numbers that will sum to the scalar values observed. It is
possible for an attacker to iterate through all such values but for a possible for an attacker to iterate through all such values but for a
large value of "q", this exhaustive search technique is large value of "q", this exhaustive search technique is
computationally infeasible. The attacker would have a better chance computationally infeasible. The attacker would have a better chance
skipping to change at page 29, line 29 skipping to change at page 29, line 32
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.
11. References 11. References
11.1. Normative References 11.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, February Hashing for Message Authentication", RFC 2104, DOI
1997. 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[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, DOI
December 2002. 10.17487/RFC3454, December 2002,
<http://www.rfc-editor.org/info/rfc3454>.
[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, DOI 10.17487/RFC4013, February
2005, <http://www.rfc-editor.org/info/rfc4013>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV)
Authenticated Encryption Using the Advanced Encryption Authenticated Encryption Using the Advanced Encryption
Standard (AES)", RFC 5297, October 2008. Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October
2008, <http://www.rfc-editor.org/info/rfc5297>.
[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, DOI 10.17487/
RFC5869, May 2010,
<http://www.rfc-editor.org/info/rfc5869>.
11.2. Informative References 11.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 3rd, D., Schiller, J., and S. Crocker,
Requirements for Security", BCP 106, RFC 4086, June 2005. "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492, DOI
10.17487/RFC4492, May 2006,
<http://www.rfc-editor.org/info/rfc4492>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011. Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
Secure Transport", RFC 7030, October 2013. "Enrollment over Secure Transport", RFC 7030, DOI
10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>.
[RFC7664] Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664, DOI
10.17487/RFC7664, November 2015,
<http://www.rfc-editor.org/info/rfc7664>.
[SP800-38A] [SP800-38A]
National Institute of Standards and Technology, National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation-- "Recommendation for Block Cipher Modes of Operation--
Methods and Techniques", NIST Special Publication 800-38A, Methods and Techniques", NIST Special Publication 800-38A,
December 2001. December 2001.
[SP800-56A] [SP800-56A]
Barker, E., Johnson, D., and M. Smid, "Recommendations for Barker, E., Johnson, D., and M. Smid, "Recommendations for
Pair-Wise Key Establishment Schemes Using Discrete Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography", NIST Special Publication 800-56A, Logarithm Cryptography", NIST Special Publication 800-56A,
March 2007. March 2007.
[lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of
the Dragonfly Protocol", Proceedings of 18th International
Information Security Conference (ISC 2015), pp 244-261,
DOI 10.1007/978-3-319-23318-5_14, September 2015.
Appendix A. Example Exchange Appendix A. Example Exchange
(Note: at the time of publication of this memo ciphersuites have (Note: at the time of publication of this memo ciphersuites have
not yet been assigned by IANA and the exchange that follows uses not yet been assigned by IANA and the exchange that follows uses
the private numberspace). the private numberspace).
username: fred username: fred
password: barney password: barney
---- prior to running TLS-PWD ---- ---- prior to running TLS-PWD ----
skipping to change at page 35, line 11 skipping to change at page 35, line 36
16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c 16 03 03 00 28 fd da 3c 9e 48 0a e7 99 ba 41 8c
9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41 9f fd 47 c8 41 2c fd 22 10 77 3f 0f 78 54 5e 41
a2 21 94 90 12 72 23 18 24 21 c3 60 a4 a2 21 94 90 12 72 23 18 24 21 c3 60 a4
1 10 0.0107 (0.0002) C>SV3.3(100) application_data 1 10 0.0107 (0.0002) C>SV3.3(100) application_data
Packet data.... Packet data....
Authors' Addresses Authors' Addresses
Dan Harkins (editor) Dan Harkins (editor)
Aruba Networks HP Enterprise
1322 Crossman Avenue 1322 Crossman Avenue
Sunnyvale, CA 94089-1113 Sunnyvale, CA 94089-1113
United States of America United States of America
Email: dharkins@arubanetworks.com Email: dharkins@arubanetworks.com
Dave Halasz (editor) Dave Halasz (editor)
Halasz Ventures Halasz Ventures
8401 Chagrin Road, Suite 10A 8401 Chagrin Road, Suite 10A
Chagrin Falls, OH 44023 Chagrin Falls, OH 44023
United States of America United States of America
Email: david.e.halasz@gmail.com Email: david.e.halasz@gmail.com
 End of changes. 22 change blocks. 
24 lines changed or deleted 52 lines changed or added

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