From e19a14e9bafb4cd1375f23c197fe57e2996fb272 Mon Sep 17 00:00:00 2001 From: stpeter Date: Tue, 12 Apr 2011 07:53:47 -0600 Subject: [PATCH] RFC 6189 --- xep-0167.xml | 2 +- xep-0188.xml | 2 +- xep-0210.xml | 2 +- xep.ent | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/xep-0167.xml b/xep-0167.xml index 20cdadea..61c21c2d 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -1669,7 +1669,7 @@ Romeo Juliet

In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the RTP data transport. It is RECOMMENDED to use SRTP as defined in the Negotiation of SRTP section of this document. The SRTP keying material SHOULD (1) be tied to a separate, secure connection such as provided by DTLS (&rfc4347;) where the keys are established as described in &dtlssrtp; and/or (2) protected by sending the Jingle signalling over a secure channel that protects the confidentiality and integrity of the SRTP-related signalling data.

-

While it is also possible to use native RTP methods, such as &zrtp; as described at <http://xmpp.org/extensions/inbox/jingle-zrtp.html>, this specification does not actively encourage or discourage the use of such methods.

+

While it is also possible to use native RTP methods, such as &rfc6189; as described in &xep0262;, this specification does not actively encourage or discourage the use of such methods.

 diff --git a/xep-0188.xml b/xep-0188.xml index bb3e0737..ba9fe42c 100644 --- a/xep-0188.xml +++ b/xep-0188.xml @@ -66,7 +66,7 @@

XMPP is a session-oriented communication technology: normally, a client authenticates with a server and maintains a long-lived connection that defines the client's XMPP session. Such stream-level sessions may be secured via channel encryption using Transport Level Security (&rfc2246;), as specified in Section 5 of RFC 3920. However, there is no guarantee that all hops will implement or enforce channel encryption (or that intermediate servers are trustworthy), which makes end-to-end encryption desirable.

This document specifies a method for encrypted sessions ("ESessions") that takes advantage of the inherent possibilities and strengths of session encryption as opposed to object encryption. The detailed requirements for encrypted sessions are defined in &xep0210;.

The conceptual model for the approach specified in this document was inspired by "off-the-record" (OTR) communication, as implemented in the Gaim encryption plugin and described in &otr;. The basic concept is that of an encrypted session which acts as a secure tunnel between two endpoints. Once the tunnel is established, the content of all one-to-one XML stanzas exchanged between the endpoints will be encrypted and then transmitted within a "wrapper" protocol element.

-

Note: In order to gain a thorough understanding of this document, it is recommended that the Off-the-Record Communication paper and the &zrtp; Internet-Draft are read first.

+

Note: In order to gain a thorough understanding of this document, it is recommended that the Off-the-Record Communication paper and &rfc6189; are read first.

 diff --git a/xep-0210.xml b/xep-0210.xml index 97d3269b..38555e69 100644 --- a/xep-0210.xml +++ b/xep-0210.xml @@ -38,7 +38,7 @@

Existing approaches to encryption of XMPP communications have generally assumed that each stanza to be encrypted is a standalone storeable object; the term "object encryption" well captures this assumption. Both &xep0027; and &rfc3923; assume that no interactive session exists, and that XMPP communications are similar to the exchange of files or email messages - where the receiver is typically not connected to its server at the time the message is sent. Although Current Jabber OpenPGP Usage uses "old-style" PGP object encryption and RFC 3923 uses "new-style" S/MIME object encryption, both specify the use of object encryption. Any new protocol based on &w3xmlenc; and &w3xmlsig;, would also be an "object encryption" protocol.

However, encryption schemes that are appropriate for less dynamic Internet technologies are not appropriate for session-oriented communication technologies like XMPP. With XMPP the receiver is typically connected to its server at the time the message is sent, so XMPP can take advantage of much more secure session-oriented approaches to encryption - approaches that are not feasible for less dynamic technologies like email. Most importantly, XMPP can benefit from Perfect Forward Secrecy and Identity Protection.

-

Therefore, for XMPP, the focus should be on "session encryption" rather than "object encryption". The paradigm should be something closer to the widely-deployed Secure Shell technology (see &rfc4253;) or &zrtp; (an acclaimed SRTP - &rfc3711; - key agreement protocol) or TLS (see &rfc4346;) or IPsec (see &rfc4301;) than to the traditional encryption of files and email messages.

+

Therefore, for XMPP, the focus should be on "session encryption" rather than "object encryption". The paradigm should be something closer to the widely-deployed Secure Shell technology (see &rfc4253;) or &rfc6189; (an acclaimed SRTP - &rfc3711; - key agreement protocol) or TLS (see &rfc5246;) or IPsec (see &rfc4301;) than to the traditional encryption of files and email messages.

The session metaphor applies to communication between any two XMPP endpoints. For instance, in IM applications, most instant messaging exchanges occur in bursts within limited time periods (e.g., two people may send a fairly large number of messages during a five-minute chat and then not exchange messages again for hours or even days). The XML stanzas exchanged during such a session may not be limited to &MESSAGE; stanzas; for instance, the session may be triggered by a change in one of the parties' presence status (e.g., changing from away to available) and the session may involve the exchange of &IQ; stanzas (e.g., to transfer a file as specified in &xep0096;).

Note: The encryption of archived messages is necessarily less secure than session encryption. The encryption of such stored messages is described in &xep0136; and is therefore out-of-scope for this document.

 diff --git a/xep.ent b/xep.ent index 25b05807..8ed0a8ba 100644 --- a/xep.ent +++ b/xep.ent @@ -596,6 +596,7 @@ THE SOFTWARE. RFC 6120 RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>." > RFC 6121 RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>." > RFC 6122 RFC 6122: Extensible Messaging and Presence Protocol (XMPP): Address Format <http://tools.ietf.org/html/rfc6122>." > +RFC 6189 ZRTP: Media Path Key Agreement for Unicast Secure RTP <http://tools.ietf.org/html/rfc6189>." > @@ -625,7 +626,6 @@ THE SOFTWARE. vCard4 vCard Format Specification <http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev>. Work in progress." > vCard KIND:thing vCard KIND:thing <http://tools.ietf.org/html/draft-saintandre-vcard-thing>. Work in progress." > vCard4 XML vCard XML Representation <http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml>. Work in progress." > -ZRTP ZRTP: Media Path Key Agreement for Secure RTP <http://tools.ietf.org/html/draft-zimmermann-avt-zrtp>. Work in progress." >