draft-ietf-uta-xmpp-01.txt		draft-ietf-uta-xmpp-02.txt
	Network Working Group P. Saint-Andre		Network Working Group P. Saint-Andre
	Internet-Draft &yet		Internet-Draft &yet
	Updates: 6120 (if approved) T. Alkemade		Updates: 6120 (if approved) T. Alkemade
	Intended status: Standards Track		Intended status: Standards Track
	Expires: March 15, 2015 September 11, 2014		Expires: March 26, 2015 September 22, 2014
	Use of Transport Layer Security (TLS) in the Extensible Messaging and		Use of Transport Layer Security (TLS) in the Extensible Messaging and
	Presence Protocol (XMPP)		Presence Protocol (XMPP)
	draft-ietf-uta-xmpp-01		draft-ietf-uta-xmpp-02
	Abstract		Abstract
	This document provides recommendations for the use of Transport Layer		This document provides recommendations for the use of Transport Layer
	Security (TLS) in the Extensible Messaging and Presence Protocol		Security (TLS) in the Extensible Messaging and Presence Protocol
	(XMPP). This document updates RFC 6120.		(XMPP). This document updates RFC 6120.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on March 15, 2015.		This Internet-Draft will expire on March 26, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 25		skipping to change at page 3, line 25
	:xmpp-tls'/> (thus indicating that it is an XMPP 1.0 server that		:xmpp-tls'/> (thus indicating that it is an XMPP 1.0 server that
	supports TLS), the initiating entity MUST NOT proceed with the stream		supports TLS), the initiating entity MUST NOT proceed with the stream
	negotiation and MUST instead abort the connection attempt. Although		negotiation and MUST instead abort the connection attempt. Although
	XMPP servers SHOULD include the <required/> child element to indicate		XMPP servers SHOULD include the <required/> child element to indicate
	that negotiation of TLS is mandatory, clients and peer servers MUST		that negotiation of TLS is mandatory, clients and peer servers MUST
	NOT depend on receiving the <required/> flag in determining whether		NOT depend on receiving the <required/> flag in determining whether
	TLS will be enforced for the stream.		TLS will be enforced for the stream.
	3.2. Protocol Versions		3.2. Protocol Versions
	Implementations MUST follow the recommendations in		Implementations MUST follow the recommendations in Section 4.1 of
	[I-D.ietf-uta-tls-bcp] as to supporting various TLS versions and		[I-D.ietf-uta-tls-bcp] as to supporting various TLS versions and
	avoiding fallback to SSL.		avoiding fallback to SSL.
	3.3. Cipher Suites		3.3. Cipher Suites
	Implementations MUST follow the recommendations in		Implementations MUST follow the recommendations in Section 5 of
	[I-D.ietf-uta-tls-bcp].		[I-D.ietf-uta-tls-bcp].
	3.4. Public Key Length		3.4. Public Key Length
	Implementations MUST follow the recommendations in		Implementations MUST follow the recommendations in Section 5.4 of
	[I-D.ietf-uta-tls-bcp].		[I-D.ietf-uta-tls-bcp].
	3.5. Compression		3.5. Compression
	Implementations MUST follow the recommendations in		Implementations MUST follow the recommendations in Section 4.5 of
	[I-D.ietf-uta-tls-bcp].		[I-D.ietf-uta-tls-bcp].
	XMPP supports an application-layer compression technology [XEP-0138],		XMPP supports an application-layer compression technology [XEP-0138],
	which might have slightly stronger security properties than TLS (at		which might have slightly stronger security properties than TLS (at
	least because it is enabled after SASL authentication, as described		least because it is enabled after SASL authentication, as described
	in [XEP-0170]).		in [XEP-0170]).
	3.6. Session Resumption		3.6. Session Resumption
	Implementations MUST follow the recommendations in		Implementations MUST follow the recommendations in Section 4.6 of
	[I-D.ietf-uta-tls-bcp].		[I-D.ietf-uta-tls-bcp].
	Use of session IDs [RFC5246] is RECOMMENDED instead of session		Use of session IDs [RFC5246] is RECOMMENDED instead of session
	tickets [RFC5077], since XMPP does not in general use state		tickets [RFC5077], since XMPP does not in general use state
	management technologies such as tickets or "cookies" [RFC6265].		management technologies such as tickets or "cookies" [RFC6265].
	In XMPP, TLS session resumption can be used in concert with the XMPP		In XMPP, TLS session resumption can be used in concert with the XMPP
	Stream Management extension; see [XEP-0198] for further details.		Stream Management extension; see [XEP-0198] for further details.
	3.7. Authenticated Connections		3.7. Authenticated Connections
	skipping to change at page 5, line 7		skipping to change at page 5, line 7
	3.9. Server Name Indication		3.9. Server Name Indication
	Although there is no harm in supporting the TLS Server Name		Although there is no harm in supporting the TLS Server Name
	Indication (SNI) extension [RFC6066], this is not necessary since the		Indication (SNI) extension [RFC6066], this is not necessary since the
	same function is served in XMPP by the 'to' address of the initial		same function is served in XMPP by the 'to' address of the initial
	stream header as explained in Section 4.7.2 of [RFC6120].		stream header as explained in Section 4.7.2 of [RFC6120].
	3.10. Human Factors		3.10. Human Factors
	It is RECOMMENDED that XMPP clients provide ways for end users (and		It is strongly encouraged that XMPP clients provide ways for end
	that XMPP servers provide ways for administrators) to complete the		users (and that XMPP servers provide ways for administrators) to
	following tasks:		complete the following tasks:
	o Determine if a client-to-server or server-to-server connection is		o Determine if a client-to-server or server-to-server connection is
	encrypted and authenticated.		encrypted and authenticated.
	o Determine the version of TLS used for a client-to-server or		o Determine the version of TLS used for a client-to-server or
	server-to-server connection.		server-to-server connection.
	o Inspect the certificate offered by an XMPP server.		o Inspect the certificate offered by an XMPP server.
	o Determine the cipher suite used to encrypt a connection.		o Determine the cipher suite used to encrypt a connection.
	skipping to change at page 6, line 14		skipping to change at page 6, line 14
	encryption technologies will serve to protect XMPP communications to		encryption technologies will serve to protect XMPP communications to
	a measurable degree, compared to the alternatives.		a measurable degree, compared to the alternatives.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[I-D.ietf-uta-tls-bcp]		[I-D.ietf-uta-tls-bcp]
	Sheffer, Y., Holz, R., and P. Saint-Andre,		Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of TLS and DTLS", draft-		"Recommendations for Secure Use of TLS and DTLS", draft-
	ietf-uta-tls-bcp-02 (work in progress), August 2014.		ietf-uta-tls-bcp-03 (work in progress), September 2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
	4949, August 2007.		4949, August 2007.
	[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,		[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
	"Transport Layer Security (TLS) Session Resumption without		"Transport Layer Security (TLS) Session Resumption without
	Server-Side State", RFC 5077, January 2008.		Server-Side State", RFC 5077, January 2008.
End of changes. 10 change blocks.
	12 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/