draft-ietf-tls-rfc4366-bis-06.txt		draft-ietf-tls-rfc4366-bis-07.txt
	TLS Working Group Donald Eastlake 3rd		TLS Working Group Donald Eastlake 3rd
	INTERNET-DRAFT Stellar Switches		INTERNET-DRAFT Stellar Switches
	Obsoletes: RFC 4366		Obsoletes: 4366
	Intended status: Proposed Standard		Intended status: Proposed Standard
	Expires: April 24, 2010 October 25, 2009		Expires: November 13, 2010 May 14, 2010
	Transport Layer Security (TLS) Extensions: Extension Definitions		Transport Layer Security (TLS) Extensions: Extension Definitions
	<draft-ietf-tls-rfc4366-bis-06.txt>		<draft-ietf-tls-rfc4366-bis-07.txt>
	Status of This Document		Abstract
	This Internet-Draft is submitted to IETF in full conformance with the		This document provides specifications for existing TLS extensions. It
			is a companion document for the TLS 1.2 specification [RFC5246]. The
			extensions specified are server_name, max_fragment_length,
			client_certificate_url, trusted_ca_keys, truncated_hmac, and
			status_request.
			Status of This Memo
			This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this		the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and		document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards		derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to		Process, except to format it for publication as an RFC or to
	skipping to change at page 1, line 43		skipping to change at page 2, line 5
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
			INTERNET-DRAFT TLS Extension Definitions
	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
	Abstract
	This document provides specifications for existing TLS extensions. It
	is a companion document for the TLS 1.2 specification [RFC5246]. The
	extensions specified are server_name, max_fragment_length,
	client_certificate_url, trusted_ca_keys, truncated_hmac, and
	status_request.
	INTERNET-DRAFT TLS Extension Definitions		INTERNET-DRAFT TLS Extension Definitions
	Acknowledgements		Acknowledgements
	This draft is based on material from RFC 4366 for which the authors		This draft is based on material from RFC 4366 for which the authors
	were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T.		were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T.
	Wright.		Wright.
	Table of Contents		Table of Contents
	Status of This Document....................................1		1. Introduction............................................4
	Abstract...................................................1		1.1 Specific Extensions Covered............................4
	Acknowledgements...........................................2		1.2 Conventions Used in This Document......................5
	1. Introduction............................................3
	1.1 Specific Extensions Covered............................3
	1.2 Conventions Used in This Document......................4
	2. Extensions to the Handshake Protocol....................5
	3. Server Name Indication..................................6
	4. Maximum Fragment Length Negotiation.....................8
	5. Client Certificate URLs................................10
	6. Trusted CA Indication..................................13
	7. Truncated HMAC.........................................15
	8. Certificate Status Request.............................16
	9. Error Alerts...........................................18
	10. IANA Considerations...................................19		2. Extensions to the Handshake Protocol....................6
	11. Security Considerations...............................19		3. Server Name Indication..................................7
	11.1 Security Considerations for server_name..............19		4. Maximum Fragment Length Negotiation.....................9
	11.2 Security Considerations for max_fragment_length......19		5. Client Certificate URLs................................11
	11.3 Security Considerations for client_certificate_url...20		6. Trusted CA Indication..................................14
	11.4 Security Considerations for trusted_ca_keys..........21		7. Truncated HMAC.........................................16
	11.5 Security Considerations for truncated_hmac...........21		8. Certificate Status Request.............................17
	11.6 Security Considerations for status_request...........21		9. Error Alerts...........................................19
			10. IANA Considerations...................................20
	12. Normative References..................................23		11. Security Considerations...............................20
	13. Informative References................................23		11.1 Security Considerations for server_name..............20
			11.2 Security Considerations for max_fragment_length......20
			11.3 Security Considerations for client_certificate_url...21
			11.4 Security Considerations for trusted_ca_keys..........22
			11.5 Security Considerations for truncated_hmac...........22
			11.6 Security Considerations for status_request...........23
	Annex A: pkipath MIME Type Registration...................25		12. Normative References..................................24
	Annex B: Changes from RFC 4366............................27		13. Informative References................................24
	Author's Address..........................................28		Annex A: pkipath MIME Type Registration...................26
	Copyright and IPR Provisions..............................29		Annex B: Changes from RFC 4366............................28
	INTERNET-DRAFT TLS Extension Definitions		INTERNET-DRAFT TLS Extension Definitions
	1. Introduction		1. Introduction
	The TLS (Transport Layer Security) Protocol Version 1.2 is specified		The TLS (Transport Layer Security) Protocol Version 1.2 is specified
	in [RFC5246]. That specification includes the framework for		in [RFC5246]. That specification includes the framework for
	extensions to TLS, considerations in designing such extensions (see		extensions to TLS, considerations in designing such extensions (see
	Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the		Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the
	allocation of new extension code points; however, it does not specify		allocation of new extension code points; however, it does not specify
	skipping to change at page 6, line 37		skipping to change at page 7, line 37
	enum {		enum {
	host_name(0), (255)		host_name(0), (255)
	} NameType;		} NameType;
	opaque HostName<1..2^16-1>;		opaque HostName<1..2^16-1>;
	struct {		struct {
	ServerName server_name_list<1..2^16-1>		ServerName server_name_list<1..2^16-1>
	} ServerNameList;		} ServerNameList;
	If the server understood the client hello extension but does not		The ServerNameList MUST NOT contain more than one name of the same
	recognize any of the server names, it SHOULD send an		name_type. If the server understood the client hello extension but
			does not recognize any of the server names, it SHOULD send an
	unrecognized_name(112) alert (which MAY be fatal).		unrecognized_name(112) alert (which MAY be fatal).
			Note: Earlier versions of this specification permitted multiple
			names of the same name_type. In practice, current client
			implementations only send one name, and the client cannot
			necessarily find out which name the server selected. Multiple
			names of the same name_type are therefore now prohibited.
	Currently, the only server names supported are DNS hostnames;		Currently, the only server names supported are DNS hostnames;
	however, this does not imply any dependency of TLS on DNS, and other		however, this does not imply any dependency of TLS on DNS, and other
	name types may be added in the future (by an RFC that updates this		name types may be added in the future (by an RFC that updates this
	document). However, for backward compatibility, all future NameTypes		document). However, for backward compatibility, all future NameTypes
	MUST begin with a 16-bit length field. TLS MAY treat provided server		MUST begin with a 16-bit length field. TLS MAY treat provided server
	names as opaque data and pass the names and types to the application.		names as opaque data and pass the names and types to the application.
	"HostName" contains the fully qualified DNS hostname of the server,		"HostName" contains the fully qualified DNS hostname of the server,
	as understood by the client. The hostname is represented as a byte		as understood by the client. The hostname is represented as a byte
			INTERNET-DRAFT TLS Extension Definitions
	string using ASCII encoding without a trailing dot.		string using ASCII encoding without a trailing dot.
	Literal IPv4 and IPv6 addresses are not permitted in "HostName".		Literal IPv4 and IPv6 addresses are not permitted in "HostName".
	It is RECOMMENDED that clients include an extension of type		It is RECOMMENDED that clients include an extension of type
	"server_name" in the client hello whenever they locate a server by a		"server_name" in the client hello whenever they locate a server by a
	supported name type.		supported name type.
	INTERNET-DRAFT TLS Extension Definitions
	A server that receives a client hello containing the "server_name"		A server that receives a client hello containing the "server_name"
	extension MAY use the information contained in the extension to guide		extension MAY use the information contained in the extension to guide
	its selection of an appropriate certificate to return to the client,		its selection of an appropriate certificate to return to the client,
	and/or other aspects of security policy. In this event, the server		and/or other aspects of security policy. In this event, the server
	SHALL include an extension of type "server_name" in the (extended)		SHALL include an extension of type "server_name" in the (extended)
	server hello. The "extension_data" field of this extension SHALL be		server hello. The "extension_data" field of this extension SHALL be
	empty.		empty.
			When the server resumes a session, the server_name extension is
			ignored.
	If an application negotiates a server name using an application		If an application negotiates a server name using an application
	protocol and then upgrades to TLS, and if a server_name extension is		protocol and then upgrades to TLS, and if a server_name extension is
	sent, then the extension SHOULD contain the same name that was		sent, then the extension SHOULD contain the same name that was
	negotiated in the application protocol. If the server_name is		negotiated in the application protocol. If the server_name is
	established in the TLS session handshake, the client SHOULD NOT		established in the TLS session handshake, the client SHOULD NOT
	attempt to request a different server name at the application layer.		attempt to request a different server name at the application layer.
	INTERNET-DRAFT TLS Extension Definitions		INTERNET-DRAFT TLS Extension Definitions
	4. Maximum Fragment Length Negotiation		4. Maximum Fragment Length Negotiation
	skipping to change at page 8, line 56		skipping to change at page 9, line 56
	messages.		messages.
	The negotiated length applies for the duration of the session		The negotiated length applies for the duration of the session
	including session resumptions.		including session resumptions.
	The negotiated length limits the input that the record layer may		The negotiated length limits the input that the record layer may
	process without fragmentation (that is, the maximum value of		process without fragmentation (that is, the maximum value of
	TLSPlaintext.length; see [RFC5246], Section 6.2.1). Note that the		TLSPlaintext.length; see [RFC5246], Section 6.2.1). Note that the
	output of the record layer may be larger. For example, if the		output of the record layer may be larger. For example, if the
	negotiated length is 2^9=512, then for currently defined cipher		negotiated length is 2^9=512, then for currently defined cipher
	suites (those defined in [RFC5246], [RFC2712], and [RFC3268]), and		suites (those defined in [RFC5246] and [RFC2712]), and when null
	INTERNET-DRAFT TLS Extension Definitions		INTERNET-DRAFT TLS Extension Definitions
	when null compression is used, the record layer output can be at most		compression is used, the record layer output can be at most 805
	805 bytes: 5 bytes of headers, 512 bytes of application data, 256		bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes
	bytes of padding, and 32 bytes of MAC. This means that in this event		of padding, and 32 bytes of MAC. This means that in this event a TLS
	a TLS record layer peer receiving a TLS record layer message larger		record layer peer receiving a TLS record layer message larger than
	than 805 bytes MUST discard the message and send a "record_overflow"		805 bytes MUST discard the message and send a "record_overflow"
	alert, without decrypting the message. When this extension is used		alert, without decrypting the message. When this extension is used
	with DTLS implementations SHOULD NOT generate record_overflow alerts		with DTLS implementations SHOULD NOT generate record_overflow alerts
	unless the packet passes message authentication.		unless the packet passes message authentication.
	INTERNET-DRAFT TLS Extension Definitions		INTERNET-DRAFT TLS Extension Definitions
	5. Client Certificate URLs		5. Client Certificate URLs
	Without this extension, TLS specifies that when client authentication		Without this extension, TLS specifies that when client authentication
	is performed, client certificates are sent by clients to servers		is performed, client certificates are sent by clients to servers
	skipping to change at page 20, line 54		skipping to change at page 21, line 54
	enabled by a server administrator, rather than be enabled by default.		enabled by a server administrator, rather than be enabled by default.
	It is also RECOMMENDED that URI schemes be enabled by the		It is also RECOMMENDED that URI schemes be enabled by the
	administrator individually, and only a minimal set of schemes be		administrator individually, and only a minimal set of schemes be
	enabled. Unusual protocols that offer limited security or whose		enabled. Unusual protocols that offer limited security or whose
	security is not well understood SHOULD be avoided.		security is not well understood SHOULD be avoided.
	As discussed in [RFC3986], URLs that specify ports other than the		As discussed in [RFC3986], URLs that specify ports other than the
	default may cause problems, as may very long URLs (which are more		default may cause problems, as may very long URLs (which are more
	likely to be useful in exploiting buffer overflow bugs).		likely to be useful in exploiting buffer overflow bugs).
	Also note that HTTP caching proxies are common on the Internet, and		This extension continues to use SHA-1 (as in RFC 4366) and does not
	INTERNET-DRAFT TLS Extension Definitions		INTERNET-DRAFT TLS Extension Definitions
			provide algorithm agility. The property required of SHA-1 in this
			case is second pre-image resistance, not collision resistance.
			Furthermore, even if second pre-image attacks against SHA-1 are found
			in the future, an attack against client_certificate_url would require
			a second pre-image that is accepted as a valid certificate by the
			server, and contains the same public key.
			Also note that HTTP caching proxies are common on the Internet, and
	some proxies do not check for the latest version of an object		some proxies do not check for the latest version of an object
	correctly. If a request using HTTP (or another caching protocol) goes		correctly. If a request using HTTP (or another caching protocol) goes
	through a misconfigured or otherwise broken proxy, the proxy may		through a misconfigured or otherwise broken proxy, the proxy may
	return an out-of-date response.		return an out-of-date response.
	11.4 Security Considerations for trusted_ca_keys		11.4 Security Considerations for trusted_ca_keys
	It is possible that which CA root keys a client possesses could be		It is possible that which CA root keys a client possesses could be
	regarded as confidential information. As a result, the CA root key		regarded as confidential information. As a result, the CA root key
	indication extension should be used with care.		indication extension should be used with care.
	The use of the SHA-1 certificate hash alternative ensures that each		The use of the SHA-1 certificate hash alternative ensures that each
	certificate is specified unambiguously. As for the previous		certificate is specified unambiguously. This context does not require
	extension, it was not believed necessary to use both MD5 and SHA-1		a cryptographic hash function, so the use of SHA-1 is considered
	hashes.		acceptable, and no algorithm agility is provided.
	11.5 Security Considerations for truncated_hmac		11.5 Security Considerations for truncated_hmac
	It is possible that truncated MACs are weaker than "un-truncated"		It is possible that truncated MACs are weaker than "un-truncated"
	MACs. However, no significant weaknesses are currently known or		MACs. However, no significant weaknesses are currently known or
	expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.		expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
	Note that the output length of a MAC need not be as long as the		Note that the output length of a MAC need not be as long as the
	length of a symmetric cipher key, since forging of MAC values cannot		length of a symmetric cipher key, since forging of MAC values cannot
	be done off-line: in TLS, a single failed MAC guess will cause the		be done off-line: in TLS, a single failed MAC guess will cause the
	skipping to change at page 21, line 44		skipping to change at page 23, line 5
	Since the MAC algorithm only takes effect after all handshake		Since the MAC algorithm only takes effect after all handshake
	messages that affect extension parameters have been authenticated by		messages that affect extension parameters have been authenticated by
	the hashes in the Finished messages, it is not possible for an active		the hashes in the Finished messages, it is not possible for an active
	attacker to force negotiation of the truncated HMAC extension where		attacker to force negotiation of the truncated HMAC extension where
	it would not otherwise be used (to the extent that the handshake		it would not otherwise be used (to the extent that the handshake
	authentication is secure). Therefore, in the event that any security		authentication is secure). Therefore, in the event that any security
	problem were found with truncated HMAC in the future, if either the		problem were found with truncated HMAC in the future, if either the
	client or the server for a given session were updated to take the		client or the server for a given session were updated to take the
	problem into account, it would be able to veto use of this extension.		problem into account, it would be able to veto use of this extension.
			INTERNET-DRAFT TLS Extension Definitions
	11.6 Security Considerations for status_request		11.6 Security Considerations for status_request
	If a client requests an OCSP response, it must take into account that		If a client requests an OCSP response, it must take into account that
	an attacker's server using a compromised key could (and probably		an attacker's server using a compromised key could (and probably
	would) pretend not to support the extension. In this case, a client		would) pretend not to support the extension. In this case, a client
	that requires OCSP validation of certificates SHOULD either contact		that requires OCSP validation of certificates SHOULD either contact
	the OCSP server directly or abort the handshake.		the OCSP server directly or abort the handshake.
	INTERNET-DRAFT TLS Extension Definitions
	Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may		Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
	improve security against attacks that attempt to replay OCSP		improve security against attacks that attempt to replay OCSP
	responses; see Section 4.4.1 of [RFC2560] for further details.		responses; see Section 4.4.1 of [RFC2560] for further details.
	INTERNET-DRAFT TLS Extension Definitions		INTERNET-DRAFT TLS Extension Definitions
	12. Normative References		12. Normative References
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104, February 1997.		Hashing for Message Authentication", RFC 2104, February 1997.
	skipping to change at page 23, line 47		skipping to change at page 24, line 47
	May 2008		May 2008
	13. Informative References		13. Informative References
	[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher		[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
	Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.		Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
	[RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
	for Transport Layer Security (TLS)", RFC 3268, June 2002.
	[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,		[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
	and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366,		and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366,
	INTERNET-DRAFT TLS Extension Definitions
	April 2006.		April 2006.
	[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,		[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
			INTERNET-DRAFT TLS Extension Definitions
	"Information Systems - Open Systems Interconnection - The Directory:		"Information Systems - Open Systems Interconnection - The Directory:
	Public key and attribute certificate frameworks."		Public key and attribute certificate frameworks."
	[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |		[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
	ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC		ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC
	9594:8:2001.		9594:8:2001.
	INTERNET-DRAFT TLS Extension Definitions		INTERNET-DRAFT TLS Extension Definitions
	Annex A: pkipath MIME Type Registration		Annex A: pkipath MIME Type Registration
	skipping to change at page 27, line 23		skipping to change at page 28, line 23
	handshake and client and server hellos) as well as specific		handshake and client and server hellos) as well as specific
	extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The		extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The
	client and server Hello extension mechanisms have been moved into RFC		client and server Hello extension mechanisms have been moved into RFC
	5246, TLS 1.2, so this document, which is associated with RFC 5246,		5246, TLS 1.2, so this document, which is associated with RFC 5246,
	includes only the handshake extension mechanisms and the specific		includes only the handshake extension mechanisms and the specific
	extensions from RFC 4366. RFC 5246 also specifies the unknown		extensions from RFC 4366. RFC 5246 also specifies the unknown
	extension error and new extension specification considerations so		extension error and new extension specification considerations so
	that material has been removed from this document.		that material has been removed from this document.
	The Server Name extension now specifies only ASCII representation,		The Server Name extension now specifies only ASCII representation,
	eliminating UTF-8.		eliminating UTF-8. It is provided that the ServerNameList can contain
			more only one name of any particular name_type.
	The Client Certificate URLs extension has been changed to make the		The Client Certificate URLs extension has been changed to make the
	presence of a hash mandatory.		presence of a hash mandatory.
	For the case of DTLS, the requirement to report an overflow of the		For the case of DTLS, the requirement to report an overflow of the
	negotiated maximum fragment length is made conditional on passing		negotiated maximum fragment length is made conditional on passing
	authentication.		authentication.
	The material was also re-organized in minor ways. For example,		The material was also re-organized in minor ways. For example,
	information as to which errors are fatal is moved from the one "Error		information as to which errors are fatal is moved from the one "Error
	skipping to change at page 29, line 9		skipping to change at page 30, line 9
	155 Beaver Street		155 Beaver Street
	Milford, MA 01757 USA		Milford, MA 01757 USA
	Tel: +1-508-634-2066		Tel: +1-508-634-2066
	Email: d3e3e3@gmail.com		Email: d3e3e3@gmail.com
	INTERNET-DRAFT TLS Extension Definitions		INTERNET-DRAFT TLS Extension Definitions
	Copyright and IPR Provisions		Copyright and IPR Provisions
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	The definitive version of an IETF Document is that published by, or		include Simplified BSD License text as described in Section 4.e of
	under the auspices of, the IETF. Versions of IETF Documents that are		the Trust Legal Provisions and are provided without warranty as
	published by third parties, including those that are translated into		described in the BSD License. The definitive version of an IETF
	other languages, should not be considered to be definitive versions		Document is that published by, or under the auspices of, the IETF.
	of IETF Documents. The definitive version of these Legal Provisions		Versions of IETF Documents that are published by third parties,
	is that published by, or under the auspices of, the IETF. Versions of		including those that are translated into other languages, should not
	these Legal Provisions that are published by third parties, including		be considered to be definitive versions of IETF Documents. The
	those that are translated into other languages, should not be		definitive version of these Legal Provisions is that published by, or
	considered to be definitive versions of these Legal Provisions. For		under the auspices of, the IETF. Versions of these Legal Provisions
	the avoidance of doubt, each Contributor to the IETF Standards		that are published by third parties, including those that are
	Process licenses each Contribution that he or she makes as part of		translated into other languages, should not be considered to be
	the IETF Standards Process to the IETF Trust pursuant to the		definitive versions of these Legal Provisions. For the avoidance of
	provisions of RFC 5378. No language to the contrary, or terms,		doubt, each Contributor to the IETF Standards Process licenses each
	conditions or rights that differ from or are inconsistent with the		Contribution that he or she makes as part of the IETF Standards
	rights and licenses granted under RFC 5378, shall have any effect and		Process to the IETF Trust pursuant to the provisions of RFC 5378. No
	shall be null and void, whether published or posted by such		language to the contrary, or terms, conditions or rights that differ
	Contributor, or included with or in such Contribution.		from or are inconsistent with the rights and licenses granted under
			RFC 5378, shall have any effect and shall be null and void, whether
			published or posted by such Contributor, or included with or in such
			Contribution.
End of changes. 30 change blocks.
	67 lines changed or deleted		79 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/