< draft-ietf-tls-rfc3546bis-00.txt		draft-ietf-tls-rfc3546bis-01.txt >
	TLS Working Group S. Blake-Wilson		TLS Working Group S. Blake-Wilson
	Internet-Draft BCI		Internet-Draft BCI
	Obsoletes: 3546 (if approved) M. Nystrom		Obsoletes: 3546 (if approved) M. Nystrom
	Updates: 2246 RSA Security		Updates: 2246 RSA Security
	Category: Standards Track D. Hopwood		Category: Standards Track D. Hopwood
	Expires: May 2005 Independent Consultant		Expires: November 2005 Independent Consultant
	J. Mikkelsen		J. Mikkelsen
	Transactionware		Transactionware
	T. Wright		T. Wright
	Vodafone		Vodafone
	November 2004		May 2005
	Transport Layer Security (TLS) Extensions		Transport Layer Security (TLS) Extensions
	<draft-ietf-tls-rfc3546bis-00.txt>		<draft-ietf-tls-rfc3546bis-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667.
	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		By submitting this Internet-Draft, each author represents that any
	which he or she become aware will be disclosed, in accordance with		applicable patent or other IPR claims of which he or she is aware
	RFC 3668.		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		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 in May 2005.		This Internet-Draft will expire in November 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	Abstract		Abstract
	This document describes extensions that may be used to add		This document describes extensions that may be used to add
	functionality to Transport Layer Security (TLS). It provides both		functionality to Transport Layer Security (TLS). It provides both
	generic extension mechanisms for the TLS handshake client and server		generic extension mechanisms for the TLS handshake client and server
	hellos, and specific extensions using these generic mechanisms.		hellos, and specific extensions using these generic mechanisms.
	The extensions may be used by TLS clients and servers. The		The extensions may be used by TLS clients and servers. The
	extensions are backwards compatible - communication is possible		extensions are backwards compatible - communication is possible
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	Wireless environments often suffer from a number of constraints not		Wireless environments often suffer from a number of constraints not
	commonly present in wired environments. These constraints may		commonly present in wired environments. These constraints may
	include bandwidth limitations, computational power limitations,		include bandwidth limitations, computational power limitations,
	memory limitations, and battery life limitations.		memory limitations, and battery life limitations.
	The extensions described here focus on extending the functionality		The extensions described here focus on extending the functionality
	provided by the TLS protocol message formats. Other issues, such as		provided by the TLS protocol message formats. Other issues, such as
	the addition of new cipher suites, are deferred.		the addition of new cipher suites, are deferred.
	Specifically, the extensions described in this document are designed		Specifically, the extensions described in this document:
	to:
	- Allow TLS clients to provide to the TLS server the name of the		- Allow TLS clients to provide to the TLS server the name of the
	server they are contacting. This functionality is desirable to		server they are contacting. This functionality is desirable to
	facilitate secure connections to servers that host multiple		facilitate secure connections to servers that host multiple
	'virtual' servers at a single underlying network address.		'virtual' servers at a single underlying network address.
	- Allow TLS clients and servers to negotiate the maximum fragment		- Allow TLS clients and servers to negotiate the maximum fragment
	length to be sent. This functionality is desirable as a result of		length to be sent. This functionality is desirable as a result of
	memory constraints among some clients, and bandwidth constraints		memory constraints among some clients, and bandwidth constraints
	among some access networks.		among some access networks.
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 20 ¶
	the server does not "understand" the extension.		the server does not "understand" the extension.
	- For the specific extensions described here, no mandatory server		- For the specific extensions described here, no mandatory server
	response is required when clients request extended functionality.		response is required when clients request extended functionality.
	Note however, that although backwards compatibility is supported,		Note however, that although backwards compatibility is supported,
	some constrained clients may be forced to reject communications with		some constrained clients may be forced to reject communications with
	servers that do not support the extensions as a result of the limited		servers that do not support the extensions as a result of the limited
	capabilities of such clients.		capabilities of such clients.
			This document is a revision of the RFC3546 [RFC3546]. The only
			major change concerns the definition of new extensions. New
			extensions can now be defined via the IETF Consensus Process (rather
			than requiring a standards track RFC). In addition, a few minor
			clarifications and editorial improvements were made.
	The remainder of this document is organized as follows. Section 2		The remainder of this document is organized as follows. Section 2
	describes general extension mechanisms for the client hello and		describes general extension mechanisms for the client hello and
	server hello handshake messages. Section 3 describes specific		server hello handshake messages. Section 3 describes specific
	extensions to TLS 1.0. Section 4 describes new error alerts for use		extensions to TLS 1.0. Section 4 describes new error alerts for use
	with the TLS extensions. The final sections of the document address		with the TLS extensions. The final sections of the document address
	IPR, security considerations, registration of the application/pkix-		IPR, security considerations, registration of the
	pkipath MIME type, acknowledgements, and references.		application/pkix-pkipath MIME type, acknowledgements, and references.
	2. General Extension Mechanisms		2. General Extension Mechanisms
	This section presents general extension mechanisms for the TLS		This section presents general extension mechanisms for the TLS
	handshake client hello and server hello messages.		handshake client hello and server hello messages.
	These general extension mechanisms are necessary in order to enable		These general extension mechanisms are necessary in order to enable
	clients and servers to negotiate whether to use specific extensions,		clients and servers to negotiate whether to use specific extensions,
	and how to use specific extensions. The extension formats described		and how to use specific extensions. The extension formats described
	are based on [MAILING LIST].		are based on [MAILING LIST].
	skipping to change at page 7, line 6 ¶		skipping to change at page 7, line 6 ¶
	8 for more information on how new values are added.		8 for more information on how new values are added.
	Note that for all extension types (including those defined in		Note that for all extension types (including those defined in
	future), the extension type MUST NOT appear in the extended server		future), the extension type MUST NOT appear in the extended server
	hello unless the same extension type appeared in the corresponding		hello unless the same extension type appeared in the corresponding
	client hello. Thus clients MUST abort the handshake if they receive		client hello. Thus clients MUST abort the handshake if they receive
	an extension type in the extended server hello that they did not		an extension type in the extended server hello that they did not
	request in the associated (extended) client hello.		request in the associated (extended) client hello.
	Nonetheless "server initiated" extensions may be provided in the		Nonetheless "server initiated" extensions may be provided in the
	future within this framework by requiring the client to first send an		future within this framework - such an extension, say of type x,
	empty extension to indicate that it supports a particular extension.		would require the client to first send an extension of type x in the
			(extended) client hello with empty extension_data to indicate that it
			supports the extension type.
	Also note that when multiple extensions of different types are		Also note that when multiple extensions of different types are
	present in the extended client hello or the extended server hello,		present in the extended client hello or the extended server hello,
	the extensions may appear in any order. There MUST NOT be more than		the extensions may appear in any order. There MUST NOT be more than
	one extension of the same type.		one extension of the same type.
	Finally note that an extended client hello may be sent both when		Finally note that an extended client hello may be sent both when
	starting a new session and when requesting session resumption.		starting a new session and when requesting session resumption.
	Indeed a client that requests resumption of a session does not in		Indeed a client that requests resumption of a session does not in
	general know whether the server will accept this request, and		general know whether the server will accept this request, and
	therefore it SHOULD send an extended client hello if it would normally		therefore it SHOULD send an extended client hello if it would
	do so for a new session. In general the specification of each		normally do so for a new session. In general the specification of
	extension type must include a discussion of the effect of the		each extension type must include a discussion of the effect of the
	extension both during new sessions and during resumed sessions.		extension both during new sessions and during resumed sessions.
	2.4. Extensions to the handshake protocol		2.4. Extensions to the handshake protocol
	This document suggests the use of two new handshake messages,		This document suggests the use of two new handshake messages,
	"CertificateURL" and "CertificateStatus". These messages are		"CertificateURL" and "CertificateStatus". These messages are
	described in Section 3.3 and Section 3.6, respectively. The new		described in Section 3.3 and Section 3.6, respectively. The new
	handshake message structure therefore becomes:		handshake message structure therefore becomes:
	enum {		enum {
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 34 ¶
	This section describes the specific TLS extensions specified in this		This section describes the specific TLS extensions specified in this
	document.		document.
	Note that any messages associated with these extensions that are sent		Note that any messages associated with these extensions that are sent
	during the TLS handshake MUST be included in the hash calculations		during the TLS handshake MUST be included in the hash calculations
	involved in "Finished" messages.		involved in "Finished" messages.
	Note also that all the extensions defined in this Section are		Note also that all the extensions defined in this Section are
	relevant only when a session is initiated. When a client includes		relevant only when a session is initiated. When a client includes
	one or more of the defined extension types in an extended client hello		one or more of the defined extension types in an extended client
	while requesting session resumption:		hello while requesting session resumption:
	- If the resumption request is denied, the use of the extensions		- If the resumption request is denied, the use of the extensions
	is negotiated as normal.		is negotiated as normal.
	- If, on the other hand, the older session is resumed, then the server		- If, on the other hand, the older session is resumed, then the
	MUST ignore the extensions and send a server hello containing none		server MUST ignore the extensions and send a server hello containing
	of the extension types; in this case the functionality of these		none of the extension types; in this case the functionality of these
	extensions negotiated during the original session initiation is applied		extensions negotiated during the original session initiation is
	to the resumed session.		applied to the resumed session.
	Section 3.1 describes the extension of TLS to allow a client to		Section 3.1 describes the extension of TLS to allow a client to
	indicate which server it is contacting. Section 3.2 describes the		indicate which server it is contacting. Section 3.2 describes the
	extension to provide maximum fragment length negotiation. Section		extension to provide maximum fragment length negotiation. Section
	3.3 describes the extension to allow client certificate URLs.		3.3 describes the extension to allow client certificate URLs.
	Section 3.4 describes the extension to allow a client to indicate		Section 3.4 describes the extension to allow a client to indicate
	which CA root keys it possesses. Section 3.5 describes the extension		which CA root keys it possesses. Section 3.5 describes the extension
	to allow the use of truncated HMAC. Section 3.6 describes the		to allow the use of truncated HMAC. Section 3.6 describes the
	extension to support integration of certificate status information		extension to support integration of certificate status information
	messages into TLS handshakes.		messages into TLS handshakes.
	skipping to change at page 24, line 10 ¶		skipping to change at page 24, line 10 ¶
	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
	immediate termination of the TLS session.		immediate termination of the TLS session.
	Since the MAC algorithm only takes effect after the handshake		Since the MAC algorithm only takes effect after all handshake
	messages have been authenticated by the hashes in the Finished		messages that affect extension parameters have been authenticated by
	messages, it is not possible for an active attacker to force		the hashes in the Finished messages, it is not possible for an active
	negotiation of the truncated HMAC extension where it would not		attacker to force negotiation of the truncated HMAC extension where it
	otherwise be used (to the extent that the handshake authentication is		would not otherwise be used (to the extent that the handshake
	secure). Therefore, in the event that any security problem were		authentication is secure). Therefore, in the event that any security
	found with truncated HMAC in future, if either the client or the		problem were found with truncated HMAC in future, if either the client
	server for a given session were updated to take into account the		or the server for a given session were updated to take into account
	problem, they would be able to veto use of this extension.		the problem, they would be able to veto use of this extension.
	6.6. Security of status_request		6.6. Security of 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. A client that requires		would) pretend not to support the extension. A client that requires
	OCSP validation of certificates SHOULD either contact the OCSP server		OCSP validation of certificates SHOULD either contact the OCSP server
	directly in this case, or abort the handshake.		directly in this case, or abort the handshake.
	Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may		Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
	skipping to change at page 26, line 23 ¶		skipping to change at page 26, line 23 ¶
	Magnus Nystrom <magnus@rsasecurity.com>		Magnus Nystrom <magnus@rsasecurity.com>
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller:		Author/Change controller:
	Magnus Nystrom <magnus@rsasecurity.com>		Magnus Nystrom <magnus@rsasecurity.com>
	9. Intellectual Property Rights		9. Intellectual Property Rights
	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 or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed
	pertain to the implementation or use of the technology described in		to pertain to the implementation or use of the technology
	this document or the extent to which any license under such rights		described in this document or the extent to which any license
	might or might not be available; neither does it represent that it		under such rights might or might not be available; nor does it
	has made any effort to identify any such rights. Information on the		represent that it has made any independent effort to identify any
	IETF's procedures with respect to rights in standards-track and		such rights. Information on the procedures with respect to rights
	standards-related documentation can be found in RFC 2028. Copies of		in RFC documents can be found in BCP 78 and BCP 79.
	claims of rights made available for publication and any 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 such
	proprietary rights by implementors or users of this specification can
	be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		Copies of IPR disclosures made to the IETF Secretariat and any
	copyrights, patents or patent applications, or other proprietary		assurances of licenses to be made available, or the result of an
	rights which may cover technology that may be required to practice		attempt made to obtain a general license or permission for the use
	this document. Please address the information to the IETF Executive		of such proprietary rights by implementers or users of this
	Director.		specification can be obtained from the IETF on-line IPR repository
			at http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention
			any copyrights, patents or patent applications, or other
			proprietary rights that may cover technology that may be required
			to implement this standard. Please address the information to the
			IETF at ietf-ipr@ietf.org.
	10. Acknowledgments		10. Acknowledgments
	The authors wish to thank the TLS Working Group and the WAP Security		The authors wish to thank the TLS Working Group and the WAP Security
	Group. This document is based on discussion within these groups.		Group. This document is based on discussion within these groups.
	11. Normative References		11. Normative References
	[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:		[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
	Keyed-hashing for message authentication", RFC 2104,		Keyed-hashing for message authentication", RFC 2104,
	skipping to change at page 28, line 11 ¶		skipping to change at page 28, line 11 ¶
	8:2001, "Information Systems - Open Systems		8:2001, "Information Systems - Open Systems
	Interconnection - The Directory: Public key and		Interconnection - The Directory: Public key and
	attribute certificate frameworks."		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		ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum
	1 to ISO/IEC 9594:8:2001.		1 to ISO/IEC 9594:8:2001.
	12. Informative References		12. Informative References
			[AESSUITES] Chown, P., "Advanced Encryption Standard (AES)
			Ciphersuites for Transport Layer Security (TLS)", RFC
			3268, June 2002.
	[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.
	[MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General		[MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General
	ClientHello extension mechanism and virtual hosting,"		ClientHello extension mechanism and virtual hosting,"
	ietf-tls mailing list posting, August 14, 2000.		ietf-tls mailing list posting, August 14, 2000.
	[AESSUITES] Chown, P., "Advanced Encryption Standard (AES)		[RFC3546] S. Blake-Wilson, M.Nystrom, D. Hopwood, J. Mikkelsen,
	Ciphersuites for Transport Layer Security (TLS)", RFC		and T. Wright, "Transport Layer Security (TLS)
	3268, June 2002.		Extensions", RFC 3546, June 2003.
	13. Authors' Addresses		13. Authors' Addresses
	Simon Blake-Wilson		Simon Blake-Wilson
	BCI		BCI
	EMail: sblakewilson@bcisse.com		EMail: sblakewilson@bcisse.com
	Magnus Nystrom		Magnus Nystrom
	RSA Security		RSA Security
	EMail: magnus@rsasecurity.com		EMail: magnus@rsasecurity.com
	skipping to change at page 29, line 7 ¶		skipping to change at page 29, line 7 ¶
	Jan Mikkelsen		Jan Mikkelsen
	Transactionware		Transactionware
	EMail: janm@transactionware.com		EMail: janm@transactionware.com
	Tim Wright		Tim Wright
	Vodafone		Vodafone
	EMail: timothy.wright@vodafone.com		EMail: timothy.wright@vodafone.com
	14. Full Copyright Statement		14. Full Copyright Statement
	Copyright (C) The Internet Society (year). This document is subject		Copyright (C) The Internet Society (2005). This document is
	to the rights, licenses and restrictions contained in BCP 78, and		subject to the rights, licenses and restrictions contained in BCP
	except as set forth therein, the authors retain all their rights."		78, and except as set forth therein, the authors retain all their
			rights.
	This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
			PARTICULAR PURPOSE.
	Acknowledgement		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. 20 change blocks.
	82 lines changed or deleted		81 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/