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/