draft-ietf-tls-pwd-05.txt   draft-ietf-tls-pwd-06.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: March 29, 2015 Halasz Ventures Expires: September 25, 2015 Halasz Ventures
September 25, 2014 March 24, 2015
Secure Password Ciphersuites for Transport Layer Security (TLS) Secure Password Ciphersuites for Transport Layer Security (TLS)
draft-ietf-tls-pwd-05 draft-ietf-tls-pwd-06
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 March 29, 2015. This Internet-Draft will expire on September 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 41 skipping to change at page 2, line 41
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. Human Rights Considerations . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Implementation Considerations . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 30 Appendix A. Example Exchange . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 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
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 o The alternatives to TLS-PWD for employing certificate-less TLS
authentication-- using pre-shared keys in an exchange that is authentication-- using pre-shared keys in an exchange that is
susceptible to dictionary attack, or using an SRP exchange that susceptible to dictionary attack, or using an SRP exchange that
requires users to, a priori, be fixed to a specific finite field requires users to, a priori, be fixed to a specific finite field
cryptorgraphy group for all subsequent connections-- are not cryptorgraphy group for all subsequent connections-- are not
acceptable for modern applications that require both security and acceptable for modern applications that require both security and
cryptographic agility. 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-
skipping to change at page 18, line 15 skipping to change at page 18, line 15
recovery of a protected username fails, the server SHOULD hide that recovery of a protected username fails, the server SHOULD hide that
fact by simulating the protocol-- putting random data in the PWD- fact by simulating the protocol-- putting random data in the PWD-
specific components of the Server Key Exchange-- and then rejecting specific components of the Server Key Exchange-- and then rejecting
the client's finished message with a "bad_record_mac" alert. To the client's finished message with a "bad_record_mac" alert. To
properly effect a simulated TLS-PWD exchange, an appropriate delay properly effect a simulated TLS-PWD exchange, an appropriate delay
SHOULD be inserted between receipt of the Client Hello and response SHOULD be inserted between receipt of the Client Hello and response
of the Server Hello. Alternately, a server MAY choose to terminate of the Server Hello. Alternately, a server MAY choose to terminate
the exchange if a password is not found. the exchange if a password is not found.
The server decides on a group to use with the named user (see The server decides on a group to use with the named user (see
Section 9 and generates the password element, PE, according to Section 10 and generates the password element, PE, according to
Section 4.2.2. Section 4.2.2.
4.3.2. Server Key Exchange Changes 4.3.2. Server Key Exchange Changes
The domain parameter set for the selected group MUST be specified in The domain parameter set for the selected group MUST be specified in
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.
skipping to change at page 28, line 13 skipping to change at page 28, line 13
server can impersonate one to the other. server can impersonate one to the other.
The static-ephemeral Diffie-Hellman exchange used to protect The static-ephemeral Diffie-Hellman exchange used to protect
usernames requires the server to reuse its Diffie-Hellman public key. usernames requires the server to reuse its Diffie-Hellman public key.
To prevent an invalid curve attack, an entity that reuses its Diffie- To prevent an invalid curve attack, an entity that reuses its Diffie-
Hellman public key needs to check whether the received ephemeral Hellman public key needs to check whether the received ephemeral
public key is actually a point on the curve. This is done explicitly public key is actually a point on the curve. This is done explicitly
as part of the server's reconstruction of the client's public key out as part of the server's reconstruction of the client's public key out
of only its x-coordinate ("compact representation"). of only its x-coordinate ("compact representation").
9. Implementation Considerations 9. Human Rights Considerations
At the time of publication, there was a growing interest in
considering the human rights impact of IETF (and IRTF) work. As
such, the Human Rights Considerations of TLS-PWD are presented.
The key exchange underlying TLS-PWD uses public key cryptography to
perform authentication and authenticated key exchange. The keys it
produces can be used to establish secure connections between two
people to protect their communication. Implementations of TLS-PWD,
like implementations of other TLS ciphersuites that perform
authentication and authenticted key establishment, are considered
'armaments' or 'munitions' by many governments around the world.
The most fundamental of Human Rights is the right to protect oneself.
The right to keep and bear arms is an example of this right.
Implementations of TLS-PWD can be used as arms, kept and borne, to
defend oneself against all manner of attackers-- criminals,
governments, laywers, etc. TLS-PWD is a powerful tool in the
promotion and defense of Universal Human Rights.
10. Implementation Considerations
The selection of the ciphersuite and selection of the particular The selection of the ciphersuite and selection of the particular
finite cyclic group to use with the ciphersuite are divorced in this finite cyclic group to use with the ciphersuite are divorced in this
memo but they remain intimately close. memo but they remain intimately close.
It is RECOMMENDED that implementations take note of the strength It is RECOMMENDED that implementations take note of the strength
estimates of particular groups and to select a ciphersuite providing estimates of particular groups and to select a ciphersuite providing
commensurate security with its hash and encryption algorithms. A commensurate security with its hash and encryption algorithms. A
ciphersuite whose encryption algorithm has a keylength less than the ciphersuite whose encryption algorithm has a keylength less than the
strength estimate, or whose hash algorithm has a blocksize that is strength estimate, or whose hash algorithm has a blocksize that is
skipping to change at page 29, line 5 skipping to change at page 29, line 24
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 11. References
10.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, 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,
skipping to change at page 29, line 33 skipping to change at page 30, line 5
[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, August 2008.
[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, 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 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.
 End of changes. 12 change blocks. 
16 lines changed or deleted 38 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/