--- 1/draft-ietf-uta-xmpp-01.txt 2014-09-22 21:14:39.373803010 -0700
+++ 2/draft-ietf-uta-xmpp-02.txt 2014-09-22 21:14:39.393803510 -0700
@@ -1,20 +1,20 @@
Network Working Group P. Saint-Andre
Internet-Draft &yet
Updates: 6120 (if approved) T. Alkemade
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
Presence Protocol (XMPP)
- draft-ietf-uta-xmpp-01
+ draft-ietf-uta-xmpp-02
Abstract
This document provides recommendations for the use of Transport Layer
Security (TLS) in the Extensible Messaging and Presence Protocol
(XMPP). This document updates RFC 6120.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
@@ -23,21 +23,21 @@
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
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."
- This Internet-Draft will expire on March 15, 2015.
+ This Internet-Draft will expire on March 26, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
@@ -105,47 +105,47 @@
:xmpp-tls'/> (thus indicating that it is an XMPP 1.0 server that
supports TLS), the initiating entity MUST NOT proceed with the stream
negotiation and MUST instead abort the connection attempt. Although
XMPP servers SHOULD include the child element to indicate
that negotiation of TLS is mandatory, clients and peer servers MUST
NOT depend on receiving the flag in determining whether
TLS will be enforced for the stream.
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
avoiding fallback to SSL.
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].
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].
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].
XMPP supports an application-layer compression technology [XEP-0138],
which might have slightly stronger security properties than TLS (at
least because it is enabled after SASL authentication, as described
in [XEP-0170]).
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].
Use of session IDs [RFC5246] is RECOMMENDED instead of session
tickets [RFC5077], since XMPP does not in general use state
management technologies such as tickets or "cookies" [RFC6265].
In XMPP, TLS session resumption can be used in concert with the XMPP
Stream Management extension; see [XEP-0198] for further details.
3.7. Authenticated Connections
@@ -175,23 +175,23 @@
3.9. Server Name Indication
Although there is no harm in supporting the TLS Server Name
Indication (SNI) extension [RFC6066], this is not necessary since the
same function is served in XMPP by the 'to' address of the initial
stream header as explained in Section 4.7.2 of [RFC6120].
3.10. Human Factors
- It is RECOMMENDED that XMPP clients provide ways for end users (and
- that XMPP servers provide ways for administrators) to complete the
- following tasks:
+ It is strongly encouraged that XMPP clients provide ways for end
+ users (and that XMPP servers provide ways for administrators) to
+ complete the following tasks:
o Determine if a client-to-server or server-to-server connection is
encrypted and authenticated.
o Determine the version of TLS used for a client-to-server or
server-to-server connection.
o Inspect the certificate offered by an XMPP server.
o Determine the cipher suite used to encrypt a connection.
@@ -230,21 +230,21 @@
encryption technologies will serve to protect XMPP communications to
a measurable degree, compared to the alternatives.
6. References
6.1. Normative References
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"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
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.