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/