< draft-moskowitz-shared-secret-provprotocol-01.txt		draft-moskowitz-shared-secret-provprotocol-02.txt >
	Internet Draft R. Moskowitz		Internet Draft R. Moskowitz
	Document: draft-moskowitz-shared-secret- ICSAlabs		Document: draft-moskowitz-shared-secret- ICSAlabs
	provprotocol-01.txt		provprotocol-02.txt
	Expires: June 2003 January 2003		Expires: May 2004 November 2003
	Shared Secret Provisioning Protocol		Shared Secret Provisioning Protocol
	draft-moskowitz-shared-secret-provprotocol-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 [1].		all provisions of Section 10 of RFC2026 [1].
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 5 ¶		skipping to change at page 2, line 5 ¶
	these secrets and, through the life of the implementation, changing		these secrets and, through the life of the implementation, changing
	these secrets. The Shared Secret Provisioning Protocol (SSPP)		these secrets. The Shared Secret Provisioning Protocol (SSPP)
	provides a mechanism for both setting and changing shared secrets		provides a mechanism for both setting and changing shared secrets
	that are provably strong.		that are provably strong.
	Conventions used in this document		Conventions used in this document
	In examples, "C:" and "S:" indicate activities by the client and		In examples, "C:" and "S:" indicate activities by the client and
	server respectively.		server respectively.
	Shared Secret Provisioning Protocol December 2002		Shared Secret Provisioning Protocol November 2003
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC-2119 [2].		this document are to be interpreted as described in RFC-2119 [2].
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction...................................................2
	1.1 Diffie-Hellman and Man-in-the-Middle Attacks...............2		1.1 Diffie-Hellman and Man-in-the-Middle Attacks...............2
	2. The Diffie-Hellman Key Agreement Schemes.......................3		2. The Diffie-Hellman Key Agreement Schemes.......................3
	2.1 The Fixed Field Diffie-Hellman exchange....................3		2.1 The Fixed Field Diffie-Hellman exchange....................3
	2.2 The Elliptic Curve Diffie-Hellman exchange.................3		2.2 The Elliptic Curve Diffie-Hellman exchange.................3
	2.3 The Key Derivation Function................................4		2.3 The Key Derivation Function................................4
	3. The Shared Secret Provisioning Protocol........................5		3. The Shared Secret Provisioning Protocol........................5
	3.1 Managing Risk in SSPP......................................6		3.1 Managing Risk in SSPP......................................5
	Security Considerations...........................................6		Security Considerations...........................................6
	References........................................................7		References........................................................7
	Acknowledgments...................................................7		Acknowledgments...................................................7
	Author's Addresses................................................7		Author's Addresses................................................7
	1. Introduction		1. Introduction
	Provisioning strong, shared secrets is frequently considered as		Provisioning strong, shared secrets is frequently considered as
	'out-of-scope' in most protocols that use them. Yet, the quality of		'out-of-scope' in most protocols that use them. Yet, the quality of
	shared secrets has a significant impact on the security		shared secrets has a significant impact on the security
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 4 ¶
	This is a basic exchange; the actual implementation is left to		This is a basic exchange; the actual implementation is left to
	specific cases. Although SSPP is based on static Diffie-Hellman		specific cases. Although SSPP is based on static Diffie-Hellman
	keys, the use of nonces permit it to be rerun whenever a new shared		keys, the use of nonces permit it to be rerun whenever a new shared
	secret is needed without changing a Diffie-Hellman key.		secret is needed without changing a Diffie-Hellman key.
	1.1 Diffie-Hellman and Man-in-the-Middle Attacks		1.1 Diffie-Hellman and Man-in-the-Middle Attacks
	Although Diffie-Hellman is commonly used for establishing a secret		Although Diffie-Hellman is commonly used for establishing a secret
	between two parties, typically buried within a complex protocol like		between two parties, typically buried within a complex protocol like
	Shared Secret Provisioning Protocol December 2002		Shared Secret Provisioning Protocol November 2003
	IKE [4], Diffie-Hellman by itself has a significant man-in-the-middle		IKE [4], Diffie-Hellman by itself has a significant man-in-the-middle
	attack. The method used to detect this attack is to validate the		attack. The method used to detect this attack is to validate the
	public Diffie-Hellman keys that they really came for the expected		public Diffie-Hellman keys that they really came for the expected
	party. This attack is symmetric. That is really only one party		party. This attack is symmetric. That is really only one party
	needs to validate the otherÆs public key and back off on the		needs to validate the otherÆs public key and back off on the
	exchange if the validation fails.		exchange if the validation fails.
	This symmetric property is important as it allows SSPP to be used in		This symmetric property is important as it allows SSPP to be used in
	headless devices that cannot easily validate the public key of the		headless devices that cannot easily validate the public key of the
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 4 ¶
	Each party computes the shared secret Zs as shown below, and then		Each party computes the shared secret Zs as shown below, and then
	computes the shared secret by invoking the key derivation function		computes the shared secret by invoking the key derivation function
	using Zs.		using Zs.
	Party C Party S		Party C Party S
	Input (p, q, g), Xc, Ys (p, q, g), Xs, Yc		Input (p, q, g), Xc, Ys (p, q, g), Xs, Yc
	Computation Zs = Ys^Xc mod p Zs = Yc^Xs mod p		Computation Zs = Ys^Xc mod p Zs = Yc^Xs mod p
	2.2 The Elliptic Curve Diffie-Hellman exchange		2.2 The Elliptic Curve Diffie-Hellman exchange
	Shared Secret Provisioning Protocol December 2002		Shared Secret Provisioning Protocol November 2003
	Each party has a static key pair (ds, Qs) that was previously		Each party has a static key pair (ds, Qs) that was previously
	generated using the same domain parameters (q, FR, a, b, [SEED], G,		generated using the same domain parameters (q, FR, a, b, [SEED], G,
	n, h). Party C has (dsC, QsC); party S has (dsS, QsS). Each party		n, h). Party C has (dsC, QsC); party S has (dsS, QsS). Each party
	must obtain the other partyÆs static public key. One must obtain		must obtain the other partyÆs static public key. One must obtain
	the other's in a trusted manner.		the other's in a trusted manner.
	Each party computes the shared secret Zs as shown below, and then		Each party computes the shared secret Zs as shown below, and then
	computes the shared secret by invoking the key derivation function		computes the shared secret by invoking the key derivation function
	using Zs.		using Zs.
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 41 ¶
	Input description:		Input description:
	1. A bit string Zs is defined above.		1. A bit string Zs is defined above.
	2. Bit strings C and S that denote the identities of the		2. Bit strings C and S that denote the identities of the
	participating parties, where C is the party that initiated the		participating parties, where C is the party that initiated the
	key establishment process, and S is the responder in the key		key establishment process, and S is the responder in the key
	establishment process.		establishment process.
	3. An integer keydatalen that is the length in bits of the shared		3. A 32 bit integer keydatalen that is the length in bits of the
	secret to be generated. keydatalen must be less than hashlen x		shared secret to be generated. keydatalen must be less than
	(2^32-1).		hashlen x (2^32-1).
	4. An integer hashlen that is the length in bits of the hash		4. An integer hashlen that is the length in bits of the hash
	function to be used to derive the shared secret. Thus the		function to be used to derive the shared secret. Thus the
	selection of SHA-1, 256, or 512 is determined by the size of the		selection of SHA-1, SHA-2-256, or SHA-2-512 is determined by the
	desired shared secret.		size of the desired shared secret.
	5. Bit strings NonceC and NonceS are nonces from the parties C and S		5. Bit strings NonceC and NonceS are nonces from the parties C and S
	respectively. The recommended size for the nonces is twice		respectively. The recommended size for the nonces is twice
	hashlen.		hashlen.
	Shared Secret Provisioning Protocol December 2002		Shared Secret Provisioning Protocol November 2003
	Process:		Process:
	a. Initiate a 32-bit, big-endian bit string counter as x00000001.		a. Initiate a 32-bit, big-endian bit string counter as x00000001.
	b. For i=1 to i= int(keydatalen/hashlen), do the following:		b. For i=1 to i= int(keydatalen/hashlen), do the following:
	Compute Hashi = HMAC-SHAn(Zs,(counter || min(C,S) || max(C,S) ||		Compute Hashi = HMAC-SHAn(Zs,(counter || min(C,S) || max(C,S) ||
	keydatalen || hashlen || min(NonceC,NonceS) ||		keydatalen || hashlen || min(NonceC,NonceS) ||
	max(NonceC,NonceS)))		max(NonceC,NonceS)))
	Increment counter		Increment counter
	Increment i.		Increment i.
	c. Let Hhashj denote Hashj if keydatalen/hashlen is an integer, and		c. Let Hhashj denote Hashj if keydatalen/hashlen is an integer, and
	let it denote the (keydatalen - (hashlen x (j-1))) leftmost bits		let it denote the (keydatalen - (hashlen x (j-1))) leftmost bits
	of Hashj otherwise.		of Hashj otherwise.
	d. Set sharedsecret = Hash1 || Hash2 ||...|| Hashj-1 || Hhashj.		d. Set sharedsecret = Hash1 || Hash2 ||...|| Hashj-1 || Hhashj.
	Any attempt to call the key derivation function for a shared secret
	of length greater than or equal to hashlen x (2^32-1) bits must
	output "invalid" and stop.
	3. The Shared Secret Provisioning Protocol		3. The Shared Secret Provisioning Protocol
	In SSPP, the client is the party that starts the exchange and is		In SSPP, the client is the party that starts the exchange and is
	capable of validating the other partyÆs public key. This may well		capable of validating the other partyÆs public key. This may well
	NOT be the client in the normal sense. For example, if SSPP is used		NOT be the client in the normal sense. For example, if SSPP is used
	to set a shared secret between a headless monitoring device and a		to set a shared secret between a headless monitoring device and a
	data collection server, the server may be the SSPP client, as it may		data collection server, the server may be the SSPP client, as it may
	have a UI to check the fingerprint of the headless device's public		have a UI to check the fingerprint of the headless device's public
	key.		key.
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 46 ¶
	C: REQUEST values from Server		C: REQUEST values from Server
	S: Generate NonceS		S: Generate NonceS
	SEND (Domain parameters, Public key, AddressS, NonceS)		SEND (Domain parameters, Public key, AddressS, NonceS)
	C: If Domain parameters do not match Client's, stop		C: If Domain parameters do not match Client's, stop
	If the Public key is not valid, stop		If the Public key is not valid, stop
	Generate NonceC		Generate NonceC
	Generate Shared Secret		Generate Shared Secret
	SEND (Public key, AddressC, NonceC),		SEND (Public key, AddressC, NonceC),
	LTRUN96(HMAC-SHA1(Shared Secret, (Public key || AddressC ||		LTRUN96(HMAC-SHA1(Shared Secret, (Public key || AddressC ||
	NonceC)))		NonceS)))
	S: Generate Shared Secret		S: Generate Shared Secret
	SEND LTRUNC96(HMAC-SHA1(Shared Secret, (AddressS || NonceS)))		SEND LTRUNC96(HMAC-SHA1(Shared Secret, (AddressS || NonceC)))
	Shared Secret Provisioning Protocol December 2002
	3.1 Managing Risk in SSPP		3.1 Managing Risk in SSPP
	There are many potential opportunities for attacks against SSPP		There are many potential opportunities for attacks against SSPP
	unless limits are placed on its usage as a PROVISIONING protocol.		unless limits are placed on its usage as a PROVISIONING protocol.
			Shared Secret Provisioning Protocol November 2003
	An SSPP implementation MUST have controls placed on servers as to		An SSPP implementation MUST have controls placed on servers as to
	when they are available to limit attacks against them. A server has		when they are available to limit attacks against them. A server has
	no control over which clients provision secrets with them. A		no control over which clients provision secrets with them. A
	resource limited headless device could be rendered useless through		resource limited headless device could be rendered useless through
	this way. It is best if SSPP is only available at device setup time		this way. It is best if SSPP is only available at device setup time
	or when triggered through a process authenticated with an existing		or when triggered through a process authenticated with an existing
	established shared secret.		established shared secret.
	Since for the server, it is possible to attack the nonce state, the		Since for the server, it is possible to attack the nonce state, the
	server implementation could use the same nonce until an SSPP		server implementation could use the same nonce until an SSPP
	skipping to change at page 7, line 4 ¶		skipping to change at page 6, line 51 ¶
	fingerprint with a copy obtained out-of-band (for example stamped on		fingerprint with a copy obtained out-of-band (for example stamped on
	the server). The later can be addressed by connecting the client		the server). The later can be addressed by connecting the client
	and server with a crossover cable or by trusting the deployed		and server with a crossover cable or by trusting the deployed
	cabling (as in a small office).		cabling (as in a small office).
	The server is potentially open to establishing a shared secret with		The server is potentially open to establishing a shared secret with
	any system. Since the SSPP server is typically a client for all		any system. Since the SSPP server is typically a client for all
	other services, this could leave it open to attack through the		other services, this could leave it open to attack through the
	services that the shared secret is suppose to protect. As such,		services that the shared secret is suppose to protect. As such,
	there must be an external control on the use of SSPP for the		there must be an external control on the use of SSPP for the
	Shared Secret Provisioning Protocol December 2002
	servers. For example, a device might only be an SSPP server when in		servers. For example, a device might only be an SSPP server when in
	factory default state or when put into it via some protocol		factory default state or when put into it via some protocol
	authenticated with an existing shared secret.		authenticated with an existing shared secret.
			Shared Secret Provisioning Protocol November 2003
	The size of the Diffie-Hellman keys and the size of the SHA hash		The size of the Diffie-Hellman keys and the size of the SHA hash
	determine the strength of the shared secret. It is up to each		determine the strength of the shared secret. It is up to each
	application of SSPP to select these values, based on the needed		application of SSPP to select these values, based on the needed
	shared secret strength.		shared secret strength.
	References		References
	1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP		1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
	9, RFC 2026, October 1996.		9, RFC 2026, October 1996.
End of changes. 15 change blocks.
	22 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/