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/