draft-ietf-tls-psk-00.txt		draft-ietf-tls-psk-01.txt
	TLS Working Group P. Eronen		TLS Working Group P. Eronen
	Internet-Draft Nokia		Internet-Draft Nokia
	Expires: November 22, 2004 H. Tschofenig		Expires: February 16, 2005 H. Tschofenig
	Siemens		Siemens
	May 24, 2004		August 18, 2004
	Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)		Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
	draft-ietf-tls-psk-00.txt		draft-ietf-tls-psk-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 22, 2004.		This Internet-Draft will expire on February 16, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document specifies new ciphersuites for the Transport Layer		This document specifies three sets of new ciphersuites for the
	Security (TLS) protocol to support authentication based on pre-shared		Transport Layer Security (TLS) protocol to support authentication
	keys. These pre-shared keys are symmetric keys, shared in advance		based on pre-shared keys. These pre-shared keys are symmetric keys,
	among the communicating parties, and do not require any public key		shared in advance among the communicating parties. The first set of
	operations.		ciphersuites uses only symmetric key operations for authentication.
			The second set uses a Diffie-Hellman exchange authenticated with a
			pre-shared key; and the third set combines public key authentication
			of the server with pre-shared key authentication of the client.
	1. Introduction		1. Introduction
	Usually TLS uses public key certificates [TLS] or Kerberos [TLS-KRB]		Usually TLS uses public key certificates [3] or Kerberos [11] for
	for authentication. This document describes how to use symmetric		authentication. This document describes how to use symmetric keys
	keys (later called pre-shared keys or PSKs), shared in advance among		(later called pre-shared keys or PSKs), shared in advance among the
	the communicating parties, to establish a TLS connection.		communicating parties, to establish a TLS connection.
	There are basically two reasons why one might want to do this:		There are basically two reasons why one might want to do this:
	o First, TLS may be used in performance-constrained environments		o First, TLS may be used in performance-constrained environments
	where the CPU power needed for public key operations is not		where the CPU power needed for public key operations is not
	available.		available.
	o Second, pre-shared keys may be more convenient from a key		o Second, pre-shared keys may be more convenient from a key
	management point of view. For instance, in closed environments		management point of view. For instance, in closed environments
	where the connections are mostly configured manually in advance,		where the connections are mostly configured manually in advance,
	it may be easier to configure a PSK than to use certificates.		it may be easier to configure a PSK than to use certificates.
	Another case is when the parties already have a mechanism for		Another case is when the parties already have a mechanism for
	setting up a shared secret key, and that mechanism could be used		setting up a shared secret key, and that mechanism could be used
	to "bootstrap" a key for authenticating a TLS connection.		to "bootstrap" a key for authenticating a TLS connection.
	This document specifies a number of new ciphersuites for TLS. These		This document specifies three sets of new ciphersuites for TLS.
	ciphersuites use a new authentication and key exchange algorithm for		These ciphersuites use new key exchange algorithms, and re-use
	PSKs, and re-use existing cipher and MAC algorithms from [TLS] and		existing cipher and MAC algorithms from [3] and [2]. A summary of
	[TLS-AES].		these ciphersuites is shown below.
			CipherSuite Key Exchange Cipher Hash
			TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA
			TLS_PSK_WITH_3DES_EDE_CBC_SHA PSK 3DES_EDE_CBC SHA
			TLS_PSK_WITH_AES_128_CBC_SHA PSK AES_128_CBC SHA
			TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_CBC SHA
			TLS_DHE_PSK_WITH_RC4_128_SHA DHE_PSK RC4_128 SHA
			TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA DHE_PSK 3DES_EDE_CBC SHA
			TLS_DHE_PSK_WITH_AES_128_CBC_SHA DHE_PSK AES_128_CBC SHA
			TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_CBC SHA
			TLS_RSA_PSK_WITH_RC4_128_SHA RSA_PSK RC4_128 SHA
			TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA RSA_PSK 3DES_EDE_CBC SHA
			TLS_RSA_PSK_WITH_AES_128_CBC_SHA RSA_PSK AES_128_CBC SHA
			TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_CBC SHA
			The first set of ciphersuites (with PSK key exchange algorithm),
			defined in Section 2 use only symmetric key algorithms, and are thus
			especially suitable for performance-constrained environments.
			The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
			use a PSK to authenticate a Diffie-Hellman exchange. These
			ciphersuites give some additional protection against dictionary
			attacks, and also provide Perfect Forward Secrecy (PFS).
			The third set of ciphersuites (with RSA_PSK key exchange algorithm),
			defined in Section 4, combine public key based authentication of the
			server (using RSA and certificates) with mutual authentication using
			a PSK.
	1.1 Applicability statement		1.1 Applicability statement
	The ciphersuites defined in this document are intended for a rather		The ciphersuites defined in this document are intended for a rather
	limited set of applications, usually involving only a very small		limited set of applications, usually involving only a very small
	number of clients and servers. Even in such environments, other		number of clients and servers. Even in such environments, other
	alternatives may be more appropriate.		alternatives may be more appropriate.
	If the main goal is to avoid PKIs, another possibility worth		If the main goal is to avoid PKIs, another possibility worth
	considering is to use self-signed certificates with public key		considering is to use self-signed certificates with public key
	fingerprints. Instead of manually configuring a shared secret in,		fingerprints. Instead of manually configuring a shared secret in,
	for instance, some configuration file, a fingerprint (hash) of the		for instance, some configuration file, a fingerprint (hash) of the
	other party's public key (or certificate) could be placed there		other party's public key (or certificate) could be placed there
	instead.		instead.
	It is also possible to use the SRP (Secure Remote Password)		It is also possible to use the SRP (Secure Remote Password)
	ciphersuites for shared secret authentication [TLS-SRP]. While SRP		ciphersuites for shared secret authentication [13]. SRP was designed
	protects against dictionary attacks, it requires more computational		to be used with passwords, and incorporates protection against
	resources.		dictionary attacks. However, it is computationally more expensive
			than the PSK ciphersuites in Section 2.
	1.2 Conventions used in this document		1.2 Conventions used in this document
	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 this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [KEYWORDS].		document are to be interpreted as described in [1].
	2. Protocol		2. PSK key exchange algorithm
			This section defines the PSK key exchange algorithm and associated
			ciphersuites. These ciphersuites use only symmetric key algorithms.
	It is assumed that the reader is familiar with ordinary TLS		It is assumed that the reader is familiar with ordinary TLS
	handshake, shown below. The elements in parenthesis are not included		handshake, shown below. The elements in parenthesis are not included
	in PSK-based ciphersuites.		when PSK key exchange algorithm is used.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello -------->		ClientHello -------->
	ServerHello		ServerHello
	(Certificate)		(Certificate)
	ServerKeyExchange		ServerKeyExchange
	(CertificateRequest)		(CertificateRequest)
	<-------- ServerHelloDone		<-------- ServerHelloDone
	(Certificate)		(Certificate)
	ClientKeyExchange		ClientKeyExchange
	(CertificateVerify)		(CertificateVerify)
	ChangeCipherSpec		ChangeCipherSpec
	Finished -------->		Finished -------->
	ChangeCipherSpec		ChangeCipherSpec
	<-------- Finished		<-------- Finished
	Application Data <-------> Application Data		Application Data <-------> Application Data
	The client indicates its willingness to use pre-shared key		The client indicates its willingness to use pre-shared key
	authentication by including one or more PSK-based ciphersuites in the		authentication by including one or more PSK ciphersuites in the
	ClientHello message. The following ciphersuites are defined in this		ClientHello message. If the TLS server also wants to use pre-shared
	document:		keys, it selects one of the PSK ciphersuites, places the selected
			ciphersuite in the ServerHello message, and includes an appropriate
	CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD };		ServerKeyExchange message (see below). The Certificate and
	CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD };		CertificateRequest payloads are omitted from the response.
	CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD };
	CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD };
	Note that this document defines only a new authentication and key
	exchange algorithm; see [TLS] and [TLS-AES] for description of the
	cipher and MAC algorithms.
	If the TLS server also wants to use pre-shared keys, it selects one
	of the PSK ciphersuites, places the selected ciphersuite in the
	ServerHello message, and includes an appropriate ServerKeyExchange
	message (see below). The Certificate and CertificateRequest payloads
	are omitted from the response.
	Both clients and servers may have pre-shared keys with several		Both clients and servers may have pre-shared keys with several
	different parties. The client indicates which key to use by		different parties. The client indicates which key to use by
	including a "PSK identity" in the ClientKeyExchange message (note		including a "PSK identity" in the ClientKeyExchange message (note
	that unlike in [TLS-SHAREDKEYS], the session_id field in ClientHello		that unlike in [6], the session_id field in ClientHello message keeps
	message keeps its usual meaning). To help the client in selecting		its usual meaning). To help the client in selecting which identity
	which identity to use, the server can provide a "PSK identity hint"		to use, the server can provide a "PSK identity hint" in the
	in the ServerKeyExchange message (note that if no hint is provided, a		ServerKeyExchange message (note that if no hint is provided, a
	ServerKeyExchange message is still sent).		ServerKeyExchange message is still sent).
	This document does not specify the format of the PSK identity or PSK		This document does not specify the format of the PSK identity or PSK
	identity hint; neither is specified how exactly the client uses the		identity hint; neither is specified how exactly the client uses the
	hint (if it uses it at all). The parties have to agree on the		hint (if it uses it at all). The parties have to agree on the
	identities when the shared secret is configured (however, see Section		identities when the shared secret is configured (however, see Section
	4 for related security considerations). In situations where the		6 for related security considerations). In situations where the
	identity is entered by a person, it is RECOMMENDED that the input is		identity is entered by a person, it is RECOMMENDED that the input is
	processed using an appropriate stringprep [STRINGPREP] profile and		processed using an appropriate stringprep [9] profile and encoded in
	encoded in octets using UTF-8 encoding [UTF8]. One possible		octets using UTF-8 encoding [14]. One possible stringprep profile is
	stringprep profile is described in [SASLPREP].		described in [8].
	The format of the ServerKeyExchange and ClientKeyExchange messages is		The format of the ServerKeyExchange and ClientKeyExchange messages is
	shown below.		shown below.
	struct {		struct {
	select (KeyExchangeAlgorithm) {		select (KeyExchangeAlgorithm) {
	case diffie_hellman:		/* other cases for rsa, diffie_hellman, etc. */
	ServerDHParams params;
	Signature signed_params;
	case rsa:
	ServerRSAParams params;
	Signature signed_params;
	case psk: /* NEW */		case psk: /* NEW */
	opaque psk_identity_hint<0..2^16-1>;		opaque psk_identity_hint<0..2^16-1>;
	};		};
	} ServerKeyExchange;		} ServerKeyExchange;
	struct {		struct {
	select (KeyExchangeAlgorithm) {		select (KeyExchangeAlgorithm) {
	case rsa: EncryptedPreMasterSecret;		/* other cases for rsa, diffie_hellman, etc. */
	case diffie_hellman: ClientDiffieHellmanPublic;		case psk: /* NEW */
	case psk: opaque psk_identity<0..2^16-1>; /* NEW */		opaque psk_identity<0..2^16-1>;
	} exchange_keys;		} exchange_keys;
	} ClientKeyExchange;		} ClientKeyExchange;
	The premaster secret is formed as follows: concatenate 24 zero		The premaster secret is formed as follows: If the PSK is N octets
	octets, followed by SHA-1 hash [FIPS180-2] of the PSK itself,		long, concatenate N zero octets and the PSK.
	followed by 4 zero octets.
	Note: This effectively means that only the HMAC-SHA1 part of the		Note: This effectively means that only the HMAC-SHA1 part of the
	TLS PRF is used, and the HMAC-MD5 part is not used. See		TLS PRF is used, and the HMAC-MD5 part is not used. See [7] for a
	[Krawczyk20040113] for a more detailed rationale. The PSK is		more detailed rationale.
	first hashed so that PSKs longer than 24 octets can be used; this
	is similar to what is done in [HMAC] if the key length is longer
	than the hash block size.
	If the server does not recognize the PSK identity, it SHOULD respond		The TLS handshake is authenticated using the Finished messages as
	with a decrypt_error alert message. This alert is also sent if		usual.
	validating the Finished message fails. The use of the same alert
	message makes it more difficult to find out which PSK identities are
	known to the server.
	3. IANA considerations		If the server does not recognize the PSK identity, it MAY respond
			with an "unknown_psk_identity" alert message. Alternatively, if the
			server wishes to hide the fact that the PSK identity was not known,
			it MAY continue the protocol as if the PSK identity existed but the
			key was incorrect: that is, respond with a "decrypt_error" alert.
	This document does not define any new namespaces to be managed by		3. DHE_PSK key exchange algorithm
	IANA. It does require assignment of several new ciphersuite numbers,
	but it is unclear how this is done, since the TLS spec does not say
	who is responsible for assigning them :-)
	4. Security Considerations		This section defines additional ciphersuites that use a PSK to
			authenticate a Diffie-Hellman exchange. These ciphersuites give some
			additional protection against dictionary attacks, and also provide
			Perfect Forward Secrecy (PFS). See Section 6 for discussion of
			related security considerations.
			When these ciphersuites are used, the ServerKeyExchange and
			ClientKeyExchange also include the Diffie-Hellman parameters. The
			PSK identity and identity hint fields have the same meaning as in the
			previous section.
			The format of the ServerKeyExchange and ClientKeyExchange messages is
			shown below.
			struct {
			select (KeyExchangeAlgorithm) {
			/* other cases for rsa, diffie_hellman, etc. */
			case diffie_hellman_psk: /* NEW */
			opaque psk_identity_hint<0..2^16-1>;
			ServerDHParams params;
			};
			} ServerKeyExchange;
			struct {
			select (KeyExchangeAlgorithm) {
			/* other cases for rsa, diffie_hellman, etc. */
			case diffie_hellman_psk: /* NEW */
			opaque psk_identity<0..2^16-1>;
			ClientDiffieHellmanPublic public;
			} exchange_keys;
			} ClientKeyExchange;
			The premaster secret is formed as follows: concatenate the value
			produced by the Diffie-Hellman exchange (with leading zero bytes
			stripped as in other Diffie-Hellman based ciphersuites) and the PSK,
			in this order.
			4. RSA_PSK key exchange algorithm
			The ciphersuites in this section use RSA and certificates to
			authenticate the server, in addition to using a PSK.
			As in normal RSA ciphersuites, the server must send a Certificate
			message. The format of the ServerKeyExchange and ClientKeyExchange
			messages is shown below.
			struct {
			select (KeyExchangeAlgorithm) {
			/* other cases for rsa, diffie_hellman, etc. */
			case rsa_psk: /* NEW */
			opaque psk_identity_hint<0..2^16-1>;
			};
			} ServerKeyExchange;
			struct {
			select (KeyExchangeAlgorithm) {
			/* other cases for rsa, diffie_hellman, etc. */
			case rsa_psk: /* NEW */
			opaque psk_identity<0..2^16-1>;
			EncryptedPreMasterSecret;
			} exchange_keys;
			} ClientKeyExchange;
			The premaster secret is formed as follows: concatenate the 48-byte
			value generated by the client (and sent to the server in
			ClientKeyExchange message) and the PSK, in this order.
			5. IANA considerations
			(This depends on whether this document is published before or after
			TLS 1.1.)
			(If after 1.1) This document does not create any new namespaces to be
			maintained by IANA, but it requires new values in the ciphersuite
			namespace defined in TLS 1.1 specification.
			(If before 1.1) There are no IANA actions associated with this
			document. For easier reference in the future, the ciphersuite
			numbers defined in this document are summarized below.
			CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0xTBD };
			CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA = { 0x00, 0xTBD };
			This document also defines a new TLS alert message,
			unknown_psk_identity(TBD). Since IANA does not maintain a registry
			of TLS alert messages, no IANA action is needed for this.
			6. Security Considerations
	As with all schemes involving shared keys, special care should be		As with all schemes involving shared keys, special care should be
	taken to protect the shared values and to limit their exposure over		taken to protect the shared values and to limit their exposure over
	time.		time.
	The ciphersuites defined in this document do not provide Perfect		6.1 Perfect forward secrecy (PFS)
	Forward Secrecy (PFS). That is, if the shared secret key is somehow
	compromised, an attacker can decrypt old conversations. (Note that		The PSK and RSA_PSK ciphersuites defined in this document do not
	the most popular TLS key exchange algorithm, RSA, does not provide		provide Perfect Forward Secrecy (PFS). That is, if the shared secret
	PFS either.)		key (in PSK ciphersuites), or both the shared secret key and the RSA
			private key (in RSA_PSK ciphersuites), is somehow compromised, an
			attacker can decrypt old conversations.
			The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
			DH private key is generated for each handshake.
			6.2 Brute-force and dictionary attacks
	Use of a fixed shared secret of limited entropy (such as a password)		Use of a fixed shared secret of limited entropy (such as a password)
	allows an attacker to perform a brute-force or dictionary attack to		may allow an attacker to perform a brute-force or dictionary attack
	recover the secret. This may be either an off-line attack (against a		to recover the secret. This may be either an off-line attack
	captured TLS conversation), or an on-line attack where the attacker		(against a captured TLS handshake messages), or an on-line attack
	attempts to connect to the server and tries different keys. An		where the attacker attempts to connect to the server and tries
	attacker can also get the information required for an off-line attack		different keys.
	if a valid client attempts to connect with the attacker. It is
	RECOMMENDED that implementations that allow the administrator to		For the PSK ciphersuites, an attacker can get the information
	manually configure the PSK also provide a functionality for		required for an off-line attack by eavesdropping a TLS handshake, or
	generating a new random PSK, taking [RANDOMNESS] into account.		by getting a valid client to attempt connection with the attacker (by
			tricking the client to connect to wrong address, or intercepting a
			connection attempt to the correct address, for instance).
			For the DHE_PSK ciphersuites, an attacker can obtain the information
			by getting a valid client to attempt connection with the attacker.
			Passive eavesdropping alone is not sufficient.
			For the RSA_PSK ciphersuites, only the server (authenticated using
			RSA and certificates) can obtain sufficient information for an
			off-line attack.
			It is RECOMMENDED that implementations that allow the administrator
			to manually configure the PSK also provide a functionality for
			generating a new random PSK, taking [4] into account.
			6.3 Identity privacy
	The PSK identity is sent in cleartext. While using a user name or		The PSK identity is sent in cleartext. While using a user name or
	other similar string as the PSK identity is the most straightforward		other similar string as the PSK identity is the most straightforward
	option, it may lead to problems in some environments since an		option, it may lead to problems in some environments since an
	eavesdropper is able to identify the communicating parties. Even		eavesdropper is able to identify the communicating parties. Even
	when the identity does not reveal any information itself, reusing the		when the identity does not reveal any information itself, reusing the
	same identity over time may eventually allow an attacker to perform		same identity over time may eventually allow an attacker to perform
	traffic analysis to the identify parties. It should be noted that		traffic analysis to identify the parties. It should be noted that
	this is no worse than client certificates, since they are also sent		this is no worse than client certificates, since they are also sent
	in cleartext.		in cleartext.
	5. Acknowledgments		6.4 Implementation notes
			The implementation notes in [10] about correct implementation and use
			of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
			Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
			well.
			7. Acknowledgments
	The protocol defined in this document is heavily based on work by Tim		The protocol defined in this document is heavily based on work by Tim
	Dierks and Peter Gutmann, and borrows some text from [TLS-SHAREDKEYS]		Dierks and Peter Gutmann, and borrows some text from [6] and [2].
	and [TLS-AES]. Valuable feedback was also provided by Philip		Valuable feedback was also provided by Philip Ginzboorg, Peter
	Ginzboorg, Peter Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo		Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, and Mika
	Moeller, and Mika Tervonen.		Tervonen.
	When the first version of this draft was almost ready, the authors		When the first version of this draft was almost ready, the authors
	learned that something similar had been proposed already in 1996		learned that something similar had been proposed already in 1996
	[TLS-PASSAUTH]. However, this draft is not intended for web password		[12]. However, this draft is not intended for web password
	authentication, but rather for other uses of TLS.		authentication, but rather for other uses of TLS.
	6. References		The DHE_PSK and RSA_PSK ciphersuites borrow heavily from [5].
	6.1 Normative References		8. Open issues
	[KEYWORDS]		o Identity privacy could be provided (in DHE_PSK/RSA_PSK versions)
	Bradner, S., "Key words for use in RFCs to Indicate		by encrypting the psk_identity payload with keys derived from the
	Requirement Levels", RFC 2119, March 1997.		DH value/RSA-encrypted random (but not PSK). But perhaps this
			would be an unnecessary complication.
	[TLS-AES] Chown, P., "Advanced Encryption Standard (AES)		o The way the PSK is combined with DH value (and is then used to
	Ciphersuites for Transport Layer Security (TLS)", RFC		calculate the Finished message) is not exactly the traditional
	3268, June 2002.		way. It should be OK with TLS-PRF, though.
	[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		9. References
	RFC 2246, January 1999.
	[RANDOMNESS]		9.1 Normative References
	Eastlake, D., Crocker, S. and J. Schiller, "Randomness
			[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", RFC 2119, March 1997.
			[2] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
			Transport Layer Security (TLS)", RFC 3268, June 2002.
			[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
			2246, January 1999.
			[4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
	Recommendations for Security", RFC 1750, December 1994.		Recommendations for Security", RFC 1750, December 1994.
	[FIPS180-2]		9.2 Informative References
	National Institute of Standards and Technology,
	"Specifications for the Secure Hash Standard", Federal
	Information Processing Standard (FIPS) Publication 180-2,
	August 2002.
	6.2 Informative References		[5] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
			"Pre-Shared-Key key Exchange methods for TLS",
			draft-badra-tls-key-exchange-00 (work in progress), August
			2004.
	[TLS-SHAREDKEYS]		[6] Gutmann, P., "Use of Shared Keys in the TLS Protocol",
	Gutmann, P., "Use of Shared Keys in the TLS Protocol",
	draft-ietf-tls-sharedkeys-02 (expired), October 2003.		draft-ietf-tls-sharedkeys-02 (expired), October 2003.
	[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:		[7] Krawczyk, H., "Re: TLS shared keys PRF", message on
	Keyed-Hashing for Message Authentication", RFC 2104,
	February 1997.
	[Krawczyk20040113]
	Krawczyk, H., "Re: TLS shared keys PRF", message on
	ietf-tls@lists.certicom.com mailing list 2004-01-13,		ietf-tls@lists.certicom.com mailing list 2004-01-13,
	http://www.imc.org/ietf-tls/mail-archive/msg04098.html.		http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
	[SASLPREP]		[8] Zeilenga, K., "SASLprep: Stringprep profile for user names and
	Zeilenga, K., "SASLprep: Stringprep profile for user names		passwords", draft-ietf-sasl-saslprep-10 (work in progress),
	and passwords", draft-ietf-sasl-saslprep-09 (work in		July 2004.
	progress), April 2004.
	[STRINGPREP]		[9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
	Hoffman, P. and M. Blanchet, "Preparation of		Strings ("stringprep")", RFC 3454, December 2002.
	Internationalized Strings ("stringprep")", RFC 3454,
	December 2002.
	[TLS-KRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher		[10] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
	Suites to Transport Layer Security (TLS)", RFC 2712,		draft-ietf-tls-rfc2246-bis-08 (work in progress), August 2004.
	October 1999.
	[TLS-PASSAUTH]		[11] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites
	Simon, D., "Addition of Shared Key Authentication to		to Transport Layer Security (TLS)", RFC 2712, October 1999.
	Transport Layer Security (TLS)",
	draft-ietf-tls-passauth-00 (expired), November 1996.
	[TLS-SRP] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin,		[12] Simon, D., "Addition of Shared Key Authentication to Transport
	"Using SRP for TLS Authentication", draft-ietf-tls-srp-06		Layer Security (TLS)", draft-ietf-tls-passauth-00 (expired),
	(work in progress), January 2004.		November 1996.
	[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO		[13] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
	10646", RFC 3629, November 2003.		SRP for TLS Authentication", draft-ietf-tls-srp-07 (work in
			progress), June 2004.
			[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
			3629, November 2003.
	Authors' Addresses		Authors' Addresses
	Pasi Eronen		Pasi Eronen
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	FIN-00045 Nokia Group		FIN-00045 Nokia Group
	Finland		Finland
	EMail: pasi.eronen@nokia.com		EMail: pasi.eronen@nokia.com
	skipping to change at page 8, line 16		skipping to change at page 11, line 32
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	EMail: Hannes.Tschofenig@siemens.com		EMail: Hannes.Tschofenig@siemens.com
	Appendix A. Changelog		Appendix A. Changelog
	(This section should be removed by the RFC Editor before		(This section should be removed by the RFC Editor before
	publication.)		publication.)
			Changes from draft-ietf-tls-psk-00 to -01:
			o Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
			other text accordingly
			o Removed SHA-1 hash from PSK key exchange premaster secret
			construction (since premaster secret doesn't need to be 48 bytes).
			o Added unknown_psk_identity alert message.
			o Updated IANA considerations section.
	Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:		Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:
	o Updated dictionary attack considerations based on comments from		o Updated dictionary attack considerations based on comments from
	David Jablon.		David Jablon.
	o Added a recommendation about using UTF-8 in the identity field.		o Added a recommendation about using UTF-8 in the identity field.
	o Removed Appendix A comparing this document with		o Removed Appendix A comparing this document with
	draft-ietf-tls-sharedkeys-02.		draft-ietf-tls-sharedkeys-02.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/