draft-ietf-tls-psk-09.txt		rfc4279.txt
	TLS Working Group P. Eronen, Ed.		Network Working Group P. Eronen, Ed.
	Internet-Draft Nokia		Request for Comments: 4279 Nokia
	Expires: December 20, 2005 H. Tschofenig, Ed.		Category: Standards Track H. Tschofenig, Ed.
	Siemens		Siemens
	June 21, 2005		December 2005
	Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)		Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
	draft-ietf-tls-psk-09.txt
	Status of this Memo
	By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as
	Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Status of This Memo
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 20, 2005.		This document specifies an Internet standards track protocol for the
			Internet community, and requests discussion and suggestions for
			improvements. Please refer to the current edition of the "Internet
			Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document specifies three sets of new ciphersuites for the		This document specifies three sets of new ciphersuites for the
	Transport Layer Security (TLS) protocol to support authentication		Transport Layer Security (TLS) protocol to support authentication
	based on pre-shared keys. These pre-shared keys are symmetric keys,		based on pre-shared keys (PSKs). These pre-shared keys are symmetric
	shared in advance among the communicating parties. The first set of		keys, shared in advance among the communicating parties. The first
	ciphersuites uses only symmetric key operations for authentication.		set of ciphersuites uses only symmetric key operations for
	The second set uses a Diffie-Hellman exchange authenticated with a		authentication. The second set uses a Diffie-Hellman exchange
	pre-shared key; and the third set combines public key authentication		authenticated with a pre-shared key, and the third set combines
	of the server with pre-shared key authentication of the client.		public key authentication of the server with pre-shared key
			authentication of the client.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction ....................................................2
	1.1 Applicability statement . . . . . . . . . . . . . . . . . 4		1.1. Applicability Statement ....................................3
	1.2 Conventions used in this document . . . . . . . . . . . . 4		1.2. Conventions Used in This Document ..........................4
	2. PSK key exchange algorithm . . . . . . . . . . . . . . . . . . 5		2. PSK Key Exchange Algorithm ......................................4
	3. DHE_PSK key exchange algorithm . . . . . . . . . . . . . . . . 7		3. DHE_PSK Key Exchange Algorithm ..................................6
	4. RSA_PSK key exchange algorithm . . . . . . . . . . . . . . . . 8		4. RSA_PSK Key Exchange Algorithm ..................................7
	5. Conformance requirements . . . . . . . . . . . . . . . . . . . 9		5. Conformance Requirements ........................................8
	5.1 PSK identity encoding . . . . . . . . . . . . . . . . . . 9		5.1. PSK Identity Encoding ......................................8
	5.2 Identity hint . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Identity Hint ..............................................9
	5.3 Requirements for TLS implementations . . . . . . . . . . 10		5.3. Requirements for TLS Implementations .......................9
	5.4 Requirements for management interfaces . . . . . . . . . 10		5.4. Requirements for Management Interfaces .....................9
	6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations ............................................10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations ........................................10
	7.1 Perfect forward secrecy (PFS) . . . . . . . . . . . . . . 11		7.1. Perfect Forward Secrecy (PFS) .............................10
	7.2 Brute-force and dictionary attacks . . . . . . . . . . . 11		7.2. Brute-Force and Dictionary Attacks ........................10
	7.3 Identity privacy . . . . . . . . . . . . . . . . . . . . 12		7.3. Identity Privacy ..........................................11
	7.4 Implementation notes . . . . . . . . . . . . . . . . . . 12		7.4. Implementation Notes ......................................11
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgements ...............................................11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References .....................................................12
	9.1 Normative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References ......................................12
	9.2 Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References ....................................12
	Authors' and Contributors' Addresses . . . . . . . . . . . . . . . 15
	Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	Usually TLS uses public key certificates [TLS] or Kerberos [KERB] for		Usually, TLS uses public key certificates [TLS] or Kerberos [KERB]
	authentication. This document describes how to use symmetric keys		for authentication. This document describes how to use symmetric
	(later called pre-shared keys or PSKs), shared in advance among the		keys (later called pre-shared keys or PSKs), shared in advance among
	communicating parties, to establish a TLS connection.		the 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, using pre-shared keys can, depending on the ciphersuite,		o First, using pre-shared keys can, depending on the ciphersuite,
	avoid the need for public key operations. This is useful if TLS		avoid the need for public key operations. This is useful if TLS
	is used in performance-constrained environments with limited CPU		is used in performance-constrained environments with limited CPU
	power.		power.
	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 three sets of new ciphersuites for TLS.		This document specifies three sets of new ciphersuites for TLS.
	These ciphersuites use new key exchange algorithms, and re-use		These ciphersuites use new key exchange algorithms, and reuse
	existing cipher and MAC algorithms from [TLS] and [AES]. A summary		existing cipher and MAC algorithms from [TLS] and [AES]. A summary
	of these ciphersuites is shown below.		of these ciphersuites is shown below.
	CipherSuite Key Exchange Cipher Hash		CipherSuite Key Exchange Cipher Hash
	TLS_PSK_WITH_RC4_128_SHA PSK RC4_128 SHA		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_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_128_CBC_SHA PSK AES_128_CBC SHA
	TLS_PSK_WITH_AES_256_CBC_SHA PSK AES_256_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_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_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_128_CBC_SHA DHE_PSK AES_128_CBC SHA
	TLS_DHE_PSK_WITH_AES_256_CBC_SHA DHE_PSK AES_256_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_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_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_128_CBC_SHA RSA_PSK AES_128_CBC SHA
	TLS_RSA_PSK_WITH_AES_256_CBC_SHA RSA_PSK AES_256_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),		The ciphersuites in Section 2 (with PSK key exchange algorithm) use
	defined in Section 2 use only symmetric key algorithms, and are thus		only symmetric key algorithms and are thus especially suitable for
	especially suitable for performance-constrained environments.		performance-constrained environments.
	The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)		The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
	use a PSK to authenticate a Diffie-Hellman exchange. These		use a PSK to authenticate a Diffie-Hellman exchange. These
	ciphersuites protect against dictionary attacks by passive		ciphersuites protect against dictionary attacks by passive
	eavesdroppers (but not active attackers), and also provide Perfect		eavesdroppers (but not active attackers) and also provide Perfect
	Forward Secrecy (PFS).		Forward Secrecy (PFS).
	The third set of ciphersuites (with RSA_PSK key exchange algorithm),		The ciphersuites in Section 4 (with RSA_PSK key exchange algorithm)
	defined in Section 4, combine public key based authentication of the		combine public-key-based authentication of the server (using RSA and
	server (using RSA and certificates) with mutual authentication using		certificates) with mutual authentication using a PSK.
	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 Public-Key Infrastructures (PKIs),
	considering is to use self-signed certificates with public key		another possibility worth considering is using self-signed
	fingerprints. Instead of manually configuring a shared secret in,		certificates with public key fingerprints. Instead of manually
	for instance, some configuration file, a fingerprint (hash) of the		configuring a shared secret in, for instance, some configuration
	other party's public key (or certificate) could be placed there		file, a fingerprint (hash) of the other party's public key (or
	instead.		certificate) could be placed there 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 [SRP]. SRP was		ciphersuites for shared secret authentication [SRP]. SRP was
	designed to be used with passwords, and incorporates protection		designed to be used with passwords, and it incorporates protection
	against dictionary attacks. However, it is computationally more		against dictionary attacks. However, it is computationally more
	expensive than the PSK ciphersuites in Section 2.		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 [KEYWORDS].
	2. PSK key exchange algorithm		2. PSK Key Exchange Algorithm
	This section defines the PSK key exchange algorithm and associated		This section defines the PSK key exchange algorithm and associated
	ciphersuites. These ciphersuites use only symmetric key algorithms.		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 the ordinary TLS
	handshake, shown below. The elements in parenthesis are not included		handshake, shown below. The elements in parenthesis are not included
	when PSK key exchange algorithm is used, and "*" indicates a		when the PSK key exchange algorithm is used, and "*" indicates a
	situation-dependent message that is not always sent.		situation-dependent message that is not always sent.
	Client Server		Client Server
	------ ------		------ ------
	ClientHello -------->		ClientHello -------->
	ServerHello		ServerHello
	(Certificate)		(Certificate)
	ServerKeyExchange*		ServerKeyExchange*
	(CertificateRequest)		(CertificateRequest)
	skipping to change at page 5, line 48		skipping to change at page 5, line 12
	ServerKeyExchange message (see below). The Certificate and		ServerKeyExchange message (see below). The Certificate and
	CertificateRequest payloads are omitted from the response.		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 [SHAREDKEYS], the session_id field in ClientHello		that unlike in [SHAREDKEYS], the session_id field in ClientHello
	message keeps its usual meaning). To help the client in selecting		message keeps its usual meaning). To help the client in selecting
	which identity to use, the server can provide a "PSK identity hint"		which identity to use, the server can provide a "PSK identity hint"
	in the ServerKeyExchange message. If no hint is provided, the		in the ServerKeyExchange message. If no hint is provided, the
	ServerKeyExchange message is omitted. See Section 5 for more		ServerKeyExchange message is omitted. See Section 5 for a more
	detailed description of these fields.		detailed description of these fields.
	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) {
	/* other cases for rsa, diffie_hellman, etc. */		/* other cases for rsa, diffie_hellman, etc. */
	case psk: /* NEW */		case psk: /* NEW */
	opaque psk_identity_hint<0..2^16-1>;		opaque psk_identity_hint<0..2^16-1>;
	skipping to change at page 6, line 26		skipping to change at page 5, line 39
	case psk: /* NEW */		case psk: /* NEW */
	opaque psk_identity<0..2^16-1>;		opaque psk_identity<0..2^16-1>;
	} exchange_keys;		} exchange_keys;
	} ClientKeyExchange;		} ClientKeyExchange;
	The premaster secret is formed as follows: if the PSK is N octets		The premaster secret is formed as follows: if the PSK is N octets
	long, concatenate a uint16 with the value N, N zero octets, a second		long, concatenate a uint16 with the value N, N zero octets, a second
	uint16 with the value N, and the PSK itself.		uint16 with the value N, and the PSK itself.
	Note 1: All the ciphersuites in this document share the same		Note 1: All the ciphersuites in this document share the same
	general structure for the premaster secret, namely		general structure for the premaster secret, namely,
	struct {		struct {
	opaque other_secret<0..2^16-1>;		opaque other_secret<0..2^16-1>;
	opaque psk<0..2^16-1>;		opaque psk<0..2^16-1>;
	};		};
	Here "other_secret" is either zeroes (plain PSK case), or comes		Here "other_secret" either is zeroes (plain PSK case) or comes
	from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,		from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
	respectively). See Sections 3 and 4 for a more detailed		respectively). See Sections 3 and 4 for a more detailed
	description.		description.
	Note 2: Using zeroes for "other_secret" effectively means that		Note 2: Using zeroes for "other_secret" effectively means that
	only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF		only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
	is used when constructing the master secret. This was considered		is used when constructing the master secret. This was considered
	more elegant from an analytical viewpoint than, for instance,		more elegant from an analytical viewpoint than, for instance,
	using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See		using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See
	[KRAWCZYK] for a more detailed rationale.		[KRAWCZYK] for a more detailed rationale.
	The TLS handshake is authenticated using the Finished messages as		The TLS handshake is authenticated using the Finished messages as
	usual.		usual.
	If the server does not recognize the PSK identity, it MAY respond		If the server does not recognize the PSK identity, it MAY respond
	with an "unknown_psk_identity" alert message. Alternatively, if the		with an "unknown_psk_identity" alert message. Alternatively, if the
	server wishes to hide the fact that the PSK identity was not known,		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		it MAY continue the protocol as if the PSK identity existed but the
	key was incorrect: that is, respond with a "decrypt_error" alert.		key was incorrect: that is, respond with a "decrypt_error" alert.
	3. DHE_PSK key exchange algorithm		3. DHE_PSK Key Exchange Algorithm
	This section defines additional ciphersuites that use a PSK to		This section defines additional ciphersuites that use a PSK to
	authenticate a Diffie-Hellman exchange. These ciphersuites give some		authenticate a Diffie-Hellman exchange. These ciphersuites give some
	additional protection against dictionary attacks, and also provide		additional protection against dictionary attacks and also provide
	Perfect Forward Secrecy (PFS). See Section 7 for discussion of		Perfect Forward Secrecy (PFS). See Section 7 for discussion of
	related security considerations.		related security considerations.
	When these ciphersuites are used, the ServerKeyExchange and		When these ciphersuites are used, the ServerKeyExchange and
	ClientKeyExchange messages also include the Diffie-Hellman		ClientKeyExchange messages also include the Diffie-Hellman
	parameters. The PSK identity and identity hint fields have the same		parameters. The PSK identity and identity hint fields have the same
	meaning as in the previous section (note that the ServerKeyExchange		meaning as in the previous section (note that the ServerKeyExchange
	message is always sent even if no PSK identity hint is provided).		message is always sent, even if no PSK identity hint is provided).
	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) {
	/* other cases for rsa, diffie_hellman, etc. */		/* other cases for rsa, diffie_hellman, etc. */
	case diffie_hellman_psk: /* NEW */		case diffie_hellman_psk: /* NEW */
	opaque psk_identity_hint<0..2^16-1>;		opaque psk_identity_hint<0..2^16-1>;
	ServerDHParams params;		ServerDHParams params;
	skipping to change at page 7, line 39		skipping to change at page 7, line 4
	} ServerKeyExchange;		} ServerKeyExchange;
	struct {		struct {
	select (KeyExchangeAlgorithm) {		select (KeyExchangeAlgorithm) {
	/* other cases for rsa, diffie_hellman, etc. */		/* other cases for rsa, diffie_hellman, etc. */
	case diffie_hellman_psk: /* NEW */		case diffie_hellman_psk: /* NEW */
	opaque psk_identity<0..2^16-1>;		opaque psk_identity<0..2^16-1>;
	ClientDiffieHellmanPublic public;		ClientDiffieHellmanPublic public;
	} exchange_keys;		} exchange_keys;
	} ClientKeyExchange;		} ClientKeyExchange;
	The premaster secret is formed as follows. First, perform the		The premaster secret is formed as follows. First, perform the
	Diffie-Hellman computation in the same way as for other		Diffie-Hellman computation in the same way as for other
	Diffie-Hellman based ciphersuites in [TLS]. Let Z be the value		Diffie-Hellman-based ciphersuites in [TLS]. Let Z be the value
	produced by this computation (with leading zero bytes stripped as in		produced by this computation (with leading zero bytes stripped as in
	other Diffie-Hellman based ciphersuites). Concatenate a uint16		other Diffie-Hellman-based ciphersuites). Concatenate a uint16
	containing the length of Z (in octets), Z itself, a uint16 containing		containing the length of Z (in octets), Z itself, a uint16 containing
	the length of the PSK (in octets), and the PSK itself.		the length of the PSK (in octets), and the PSK itself.
	This corresponds to the general structure for the premaster secrets		This corresponds to the general structure for the premaster secrets
	(see Note 1 in Section 2) in this document, with "other_secret"		(see Note 1 in Section 2) in this document, with "other_secret"
	containing Z.		containing Z.
	4. RSA_PSK key exchange algorithm		4. RSA_PSK Key Exchange Algorithm
	The ciphersuites in this section use RSA and certificates to		The ciphersuites in this section use RSA and certificates to
	authenticate the server, in addition to using a PSK.		authenticate the server, in addition to using a PSK.
	As in normal RSA ciphersuites, the server must send a Certificate		As in normal RSA ciphersuites, the server must send a Certificate
	message. The format of the ServerKeyExchange and ClientKeyExchange		message. The format of the ServerKeyExchange and ClientKeyExchange
	messages is shown below. If no PSK identity hint is provided, the		messages is shown below. If no PSK identity hint is provided, the
	ServerKeyExchange message is omitted.		ServerKeyExchange message is omitted.
	struct {		struct {
	skipping to change at page 8, line 51		skipping to change at page 8, line 14
	This corresponds to the general structure for the premaster secrets		This corresponds to the general structure for the premaster secrets
	(see Note 1 in Section 2) in this document, with "other_secret"		(see Note 1 in Section 2) in this document, with "other_secret"
	containing both the 2-byte version number and the 46-byte random		containing both the 2-byte version number and the 46-byte random
	value.		value.
	Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites		Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
	themselves specify what the certificates contain (in addition to the		themselves specify what the certificates contain (in addition to the
	RSA public key), or how the certificates are to be validated. In		RSA public key), or how the certificates are to be validated. In
	particular, it is possible to use the RSA_PSK ciphersuites with		particular, it is possible to use the RSA_PSK ciphersuites with
	unvalidated self-signed certificates to provide somewhat similar		unvalidated self-signed certificates to provide somewhat similar
	protection against dictionary attacks as the DHE_PSK ciphersuites		protection against dictionary attacks, as the DHE_PSK ciphersuites
	defined in Section 3.		define in Section 3.
	5. Conformance requirements		5. Conformance Requirements
	It is expected that different types of identities are useful for		It is expected that different types of identities are useful for
	different applications running over TLS. This document does not		different applications running over TLS. This document does not
	therefore mandate the use of any particular type of identity (such as		therefore mandate the use of any particular type of identity (such as
	IPv4 address or FQDN).		IPv4 address or Fully Qualified Domain Name (FQDN)).
	However, the TLS client and server clearly have to agree on the		However, the TLS client and server clearly have to agree on the
	identities and keys to be used. To improve interoperability, this		identities and keys to be used. To improve interoperability, this
	document places requirements on how the identity is encoded in the		document places requirements on how the identity is encoded in the
	protocol, and what kinds of identities and keys implementations have		protocol, and what kinds of identities and keys implementations have
	to support.		to support.
	The requirements for implementations are divided to two categories,		The requirements for implementations are divided into two categories,
	requirements for TLS implementations and management interfaces. In		requirements for TLS implementations and management interfaces. In
	this context, "TLS implementation" refers to a TLS library or module		this context, "TLS implementation" refers to a TLS library or module
	that is intended to be used for several different purposes, while		that is intended to be used for several different purposes, while
	"management interface" would typically be implemented by a particular		"management interface" would typically be implemented by a particular
	application that uses TLS.		application that uses TLS.
	This document does not specify how the server stores the keys and		This document does not specify how the server stores the keys and
	identities, or how exactly it finds the key corresponding to the		identities, or how exactly it finds the key corresponding to the
	identity it receives. For instance, if the identity is a domain		identity it receives. For instance, if the identity is a domain
	name, it might be appropriate to do a case-insensitive lookup. It is		name, it might be appropriate to do a case-insensitive lookup. It is
	RECOMMENDED that before looking up the key, the server processes the		RECOMMENDED that before looking up the key, the server processes the
	PSK identity with a stringprep profile [STRINGPREP] appropriate for		PSK identity with a stringprep profile [STRINGPREP] appropriate for
	the identity in question (such as Nameprep [NAMEPREP] for components		the identity in question (such as Nameprep [NAMEPREP] for components
	of domain names or SASLprep for usernames [SASLPREP]).		of domain names or SASLprep for usernames [SASLPREP]).
	5.1 PSK identity encoding		5.1. PSK Identity Encoding
	The PSK identity MUST be first converted to a character string, and		The PSK identity MUST be first converted to a character string, and
	then encoded to octets using UTF-8 [UTF8]. For instance,		then encoded to octets using UTF-8 [UTF8]. For instance,
	o IPv4 addresses are sent as dotted-decimal strings (e.g.,		o IPv4 addresses are sent as dotted-decimal strings (e.g.,
	"192.0.2.1"), not as 32-bit integers in network byte order.		"192.0.2.1"), not as 32-bit integers in network byte order.
	o Domain names are sent in their usual text form (e.g.,		o Domain names are sent in their usual text form [DNS] (e.g.,
	"www.example.com" or "embedded.dot.example.net"), not in DNS		"www.example.com" or "embedded\.dot.example.net"), not in DNS
	protocol format.		protocol format.
	o X.500 Distinguished Names are sent in their string representation		o X.500 Distinguished Names are sent in their string representation
	[LDAPDN], not as BER-encoded ASN.1.		[LDAPDN], not as BER-encoded ASN.1.
	This encoding is clearly not optimal for many types of identities.		This encoding is clearly not optimal for many types of identities.
	It was chosen to avoid identity type specific parsing and encoding		It was chosen to avoid identity-type-specific parsing and encoding
	code in implementations where the identity is configured by a person		code in implementations where the identity is configured by a person
	using some kind of management interface. Requiring such identity		using some kind of management interface. Requiring such identity-
	type specific code would also increase the chances for		type-specific code would also increase the chances for
	interoperability problems resulting from different implementations		interoperability problems resulting from different implementations
	supporting different identity types.		supporting different identity types.
	5.2 Identity hint		5.2. Identity Hint
	In the absence of an application profile specification specifying		In the absence of an application profile specification specifying
	otherwise, servers SHOULD NOT provide an identity hint and clients		otherwise, servers SHOULD NOT provide an identity hint and clients
	MUST ignore the identity hint field. Applications that do use this		MUST ignore the identity hint field. Applications that do use this
	field MUST specify its contents, how the value is chosen by the TLS		field MUST specify its contents, how the value is chosen by the TLS
	server, and what the TLS client is expected to do with the value.		server, and what the TLS client is expected to do with the value.
	5.3 Requirements for TLS implementations		5.3. Requirements for TLS Implementations
	TLS implementations supporting these ciphersuites MUST support		TLS implementations supporting these ciphersuites MUST support
	arbitrary PSK identities up to 128 octets in length, and arbitrary		arbitrary PSK identities up to 128 octets in length, and arbitrary
	PSKs up to 64 octets in length. Supporting longer identities and		PSKs up to 64 octets in length. Supporting longer identities and
	keys is RECOMMENDED.		keys is RECOMMENDED.
	5.4 Requirements for management interfaces		5.4. Requirements for Management Interfaces
	In the absence of an application profile specification specifying		In the absence of an application profile specification specifying
	otherwise, a management interface for entering the PSK and/or PSK		otherwise, a management interface for entering the PSK and/or PSK
	identity MUST support the following:		identity MUST support the following:
	o Entering PSK identities consisting of up to 128 printable Unicode		o Entering PSK identities consisting of up to 128 printable Unicode
	characters. Supporting as wide character repertoire and as long		characters. Supporting as wide a character repertoire and as long
	identities as feasible is RECOMMENDED.		identities as feasible is RECOMMENDED.
	o Entering PSKs up to 64 octets in length as ASCII strings and in		o Entering PSKs up to 64 octets in length as ASCII strings and in
	hexadecimal encoding.		hexadecimal encoding.
	6. IANA considerations		6. IANA Considerations
	IANA does not currently have a registry for TLS ciphersuite or alert		IANA does not currently have a registry for TLS ciphersuite or alert
	numbers, so there are no IANA actions associated with this document.		numbers, so there are no IANA actions associated with this document.
	For easier reference in the future, the ciphersuite numbers defined		For easier reference in the future, the ciphersuite numbers defined
	in this document are summarized below.		in this document are summarized below.
	CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A };		CipherSuite TLS_PSK_WITH_RC4_128_SHA = { 0x00, 0x8A };
	CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B };		CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8B };
	CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C };		CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA = { 0x00, 0x8C };
	skipping to change at page 11, line 35		skipping to change at page 10, line 35
	This document also defines a new TLS alert message,		This document also defines a new TLS alert message,
	unknown_psk_identity(115).		unknown_psk_identity(115).
	7. Security Considerations		7. 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.
	7.1 Perfect forward secrecy (PFS)		7.1. Perfect Forward Secrecy (PFS)
	The PSK and RSA_PSK ciphersuites defined in this document do not		The PSK and RSA_PSK ciphersuites defined in this document do not
	provide Perfect Forward Secrecy (PFS). That is, if the shared secret		provide Perfect Forward Secrecy (PFS). That is, if the shared secret
	key (in PSK ciphersuites), or both the shared secret key and the RSA		key (in PSK ciphersuites), or both the shared secret key and the RSA
	private key (in RSA_PSK ciphersuites), is somehow compromised, an		private key (in RSA_PSK ciphersuites), is somehow compromised, an
	attacker can decrypt old conversations.		attacker can decrypt old conversations.
	The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh		The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
	DH private key is generated for each handshake.		Diffie-Hellman private key is generated for each handshake.
	7.2 Brute-force and dictionary attacks		7.2. Brute-Force and Dictionary Attacks
	Use of a fixed shared secret of limited entropy (for example, a PSK		Use of a fixed shared secret of limited entropy (for example, a PSK
	that is relatively short, or was chosen by a human and thus may		that is relatively short, or was chosen by a human and thus may
	contain less entropy than its length would imply) may allow an		contain less entropy than its length would imply) may allow an
	attacker to perform a brute-force or dictionary attack to recover the		attacker to perform a brute-force or dictionary attack to recover the
	secret. This may be either an off-line attack (against a captured		secret. This may be either an off-line attack (against a captured
	TLS handshake messages), or an on-line attack where the attacker		TLS handshake messages) or an on-line attack where the attacker
	attempts to connect to the server and tries different keys.		attempts to connect to the server and tries different keys.
	For the PSK ciphersuites, an attacker can get the information		For the PSK ciphersuites, an attacker can get the information
	required for an off-line attack by eavesdropping a TLS handshake, or		required for an off-line attack by eavesdropping on a TLS handshake,
	by getting a valid client to attempt connection with the attacker (by		or by getting a valid client to attempt connection with the attacker
	tricking the client to connect to wrong address, or intercepting a		(by tricking the client to connect to the wrong address, or by
	connection attempt to the correct address, for instance).		intercepting a connection attempt to the correct address, for
			instance).
	For the DHE_PSK ciphersuites, an attacker can obtain the information		For the DHE_PSK ciphersuites, an attacker can obtain the information
	by getting a valid client to attempt connection with the attacker.		by getting a valid client to attempt connection with the attacker.
	Passive eavesdropping alone is not sufficient.		Passive eavesdropping alone is not sufficient.
	For the RSA_PSK ciphersuites, only the server (authenticated using		For the RSA_PSK ciphersuites, only the server (authenticated using
	RSA and certificates) can obtain sufficient information for an		RSA and certificates) can obtain sufficient information for an
	off-line attack.		off-line attack.
	It is RECOMMENDED that implementations that allow the administrator		It is RECOMMENDED that implementations that allow the administrator
	to manually configure the PSK also provide a functionality for		to manually configure the PSK also provide a functionality for
	generating a new random PSK, taking [RANDOMNESS] into account.		generating a new random PSK, taking [RANDOMNESS] into account.
	7.3 Identity privacy		7.3. Identity Privacy
	The PSK identity is sent in cleartext. While using a user name or		The PSK identity is sent in cleartext. Although 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 identify the 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.
	7.4 Implementation notes		7.4. Implementation Notes
	The implementation notes in [TLS11] about correct implementation and		The implementation notes in [TLS11] about correct implementation and
	use of RSA (including Section 7.4.7.1) and Diffie-Hellman (including		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		Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
	well.		well.
	8. Acknowledgments		8. Acknowledgements
	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 [SHAREDKEYS] and		Dierks and Peter Gutmann, and borrows some text from [SHAREDKEYS] and
	[AES]. The DHE_PSK and RSA_PSK ciphersuites are based on earlier		[AES]. The DHE_PSK and RSA_PSK ciphersuites are based on earlier
	work in [KEYEX].		work in [KEYEX].
	Valuable feedback was also provided by Bernard Aboba, Lakshminath		Valuable feedback was also provided by Bernard Aboba, Lakshminath
	Dondeti, Philip Ginzboorg, Peter Gutmann, Sam Hartman, Russ Housley,		Dondeti, Philip Ginzboorg, Peter Gutmann, Sam Hartman, Russ Housley,
	David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and		David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and
	Mika Tervonen.		Mika Tervonen.
	When the first version of this draft was almost ready, the authors		When the first version of this document 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
	[PASSAUTH]. However, this draft is not intended for web password		[PASSAUTH]. However, this document is not intended for web password
	authentication, but rather for other uses of TLS.		authentication, but rather for other uses of TLS.
	9. References		9. References
	9.1 Normative References		9.1. Normative References
	[AES] Chown, P., "Advanced Encryption Standard (AES)		[AES] Chown, P., "Advanced Encryption Standard (AES)
	Ciphersuites for Transport Layer Security (TLS)", RFC		Ciphersuites for Transport Layer Security (TLS)", RFC
	3268, June 2002.		3268, June 2002.
	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RANDOMNESS]		[RANDOMNESS] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
	Eastlake, D., 3rd, Schiller, J., and S. Crocker,		"Randomness Requirements for Security", BCP 106, RFC
	"Randomness Requirements for Security", BCP 106, RFC 4086,		4086, June 2005.
	June 2005.
	[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO		[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	9.2 Informative References		9.2. Informative References
			[DNS] Mockapetris, P., "Domain names - implementation and
			specification", STD 13, RFC 1035, November 1987.
	[KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher		[KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
	Suites to Transport Layer Security (TLS)", RFC 2712,		Suites to Transport Layer Security (TLS)", RFC 2712,
	October 1999.		October 1999.
	[KEYEX] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,		[KEYEX] Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
	"Pre-Shared-Key key Exchange methods for TLS",		"Pre-Shared-Key key Exchange methods for TLS", Work in
	draft-badra-tls-key-exchange-00 (expired), August 2004.		Progress, August 2004.
	[KRAWCZYK] Krawczyk, H., "Re: TLS shared keys PRF", message on		[KRAWCZYK] 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.
	[LDAPDN] Zeilenga, K., "LDAP: String Representation of		[LDAPDN] Zeilenga, K., "LDAP: String Representation of
	Distinguished Names", draft-ietf-ldapbis-dn-16 (work in		Distinguished Names", Work in Progress, February 2005.
	progress), February 2005.
	[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep		[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
	Profile for Internationalized Domain Names (IDN)", RFC		Profile for Internationalized Domain Names (IDN)", RFC
	3491, March 2003.		3491, March 2003.
	[PASSAUTH] Simon, D., "Addition of Shared Key Authentication to		[PASSAUTH] Simon, D., "Addition of Shared Key Authentication to
	Transport Layer Security (TLS)",		Transport Layer Security (TLS)", Work in Progress,
	draft-ietf-tls-passauth-00 (expired), November 1996.		November 1996.
	[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names		[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User
	and Passwords", RFC 4013, February 2005.		Names and Passwords", RFC 4013, February 2005.
	[SHAREDKEYS]		[SHAREDKEYS] Gutmann, P., "Use of Shared Keys in the TLS Protocol",
	Gutmann, P., "Use of Shared Keys in the TLS Protocol",		Work in Progress, October 2003.
	draft-ietf-tls-sharedkeys-02 (expired), October 2003.
	[SRP] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin,		[SRP] Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin,
	"Using SRP for TLS Authentication", draft-ietf-tls-srp-09		"Using SRP for TLS Authentication", Work in Progress,
	(work in progress), March 2005.		March 2005.
	[STRINGPREP]		[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
	Hoffman, P. and M. Blanchet, "Preparation of
	Internationalized Strings ("stringprep")", RFC 3454,		Internationalized Strings ("stringprep")", RFC 3454,
	December 2002.		December 2002.
	[TLS11] Dierks, T. and E. Rescorla, "The TLS Protocol Version		[TLS11] Dierks, T. and E. Rescorla, "The TLS Protocol Version
	1.1", draft-ietf-tls-rfc2246-bis-12 (work in progress),		1.1", Work in Progress, June 2005.
	June 2005.
	Authors' and Contributors' Addresses		Authors' and Contributors' 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
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	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
	Mohamad Badra		Mohamad Badra
	ENST Telecom		ENST Paris
	46 rue Barrault		46 rue Barrault
	75634 Paris		75634 Paris
	France		France
	Email: Mohamad.Badra@enst.fr
			EMail: Mohamad.Badra@enst.fr
	Omar Cherkaoui		Omar Cherkaoui
	UQAM University		UQAM University
	Montreal (Quebec)		Montreal (Quebec)
	Canada		Canada
	Email: cherkaoui.omar@uqam.ca
			EMail: cherkaoui.omar@uqam.ca
	Ibrahim Hajjeh		Ibrahim Hajjeh
	ENST Telecom		ESRGroups
	46 rue Barrault		17 passage Barrault
	75634 Paris		75013 Paris
	France		France
	Email: Ibrahim.Hajjeh@enst.fr
			EMail: Ibrahim.Hajjeh@esrgroups.org
	Ahmed Serhrouchni		Ahmed Serhrouchni
	ENST Telecom		ENST Paris
	46 rue Barrault		46 rue Barrault
	75634 Paris		75634 Paris
	France		France
	Email: Ahmed.Serhrouchni@enst.fr
	Appendix A. Changelog
	(This section should be removed by the RFC Editor before
	publication.)
	Changes from -08 to -09:
	o Clarified internationalization of PSK identities in Section 5.
	o Corrected the example IP address in Section 5.1.
	o Small clarification to IANA considerations on Section 6.
	o Editorial: changed numeric references to symbolic ones, updated
	references to latest versions.
	Changes from -07 to -08:
	o Added table of contents and updated I-D boilerplate.
	o Small clarification to motivation in Section 1.
	o Small clarification to note 2 in Section 2.
	o Corrected all instances of "an uint16" to "a uint16".
	o Updated references to latest versions.
	Changes from -06 to -07:		EMail: Ahmed.Serhrouchni@enst.fr
	o Small clarifications to management interface requirements.
	Changes from -05 to -06:
	o Small clarifications to how the premaster secret is formed.
	o Added a section about conformance requirements, and moved existing
	text about identity formats there.
	Changes from -04 to -05:
	o Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no
	identity hint is provided.
	Changes from -03 to -04:
	o Added a note about premaster secret "general structure" in
	Sections 3 and 4.
	o Something in the I-D submission procedure had removed all
	circumflexes from -03 version, turning e.g. "2^16" (two-to- the
	sixteenth power) to "216" (two hundred and sixteen). Let's try
	again.
	Changes from -02 to -03:
	o Aligned the way the premaster secret is derived.
	o Specified that identities must be sent as human-readable UTF-8
	strings, not in binary formats. Changed reference to RFC 3629
	from informative to normative.
	o Selected ciphersuite and alert numbers, and updated IANA
	considerations section to match this.
	o Reworded some text about dictionary attacks in Section 6.2.
	Changes from -01 to -02:
	o Clarified text about DHE_PSK ciphersuites in Section 1.
	o Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2.
	o Added note about certificate validation and self-signed
	certificates in Section 4.
	o Added Mohamad Badra et al. as contributors.
	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:
	o Updated dictionary attack considerations based on comments from
	David Jablon.
	o Added a recommendation about using UTF-8 in the identity field.		Full Copyright Statement
	o Removed Appendix A comparing this document with		Copyright (C) The Internet Society (2005).
	draft-ietf-tls-sharedkeys-02.
	o Removed IPR comment about SPR.		This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
	o Minor editorial changes.		This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property Statement		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at ietf-
	ietf-ipr@ietf.org.		ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 85 change blocks.
	278 lines changed or deleted		156 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/