moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

RFC 6189

This commit is contained in:
stpeter 2011-04-12 07:53:47 -06:00
parent e5e5e4a862
commit e19a14e9ba
4 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0167.xml
View File

@ -1669,7 +1669,7 @@ Romeo Juliet
<section1 topic='Security Considerations' anchor='security'>
<p>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 <link url='#srtp'>Negotiation of SRTP</link> 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.</p>
<p>While it is also possible to use native RTP methods, such as &zrtp; as described at &lt;<link url='http://xmpp.org/extensions/inbox/jingle-zrtp.html'>http://xmpp.org/extensions/inbox/jingle-zrtp.html</link>&gt;, this specification does not actively encourage or discourage the use of such methods.</p>
<p>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.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>

2
xep-0188.xml
View File

@ -66,7 +66,7 @@
<p>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 <cite>RFC 3920</cite>. 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.</p>
<p>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;.</p>
<p>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.</p>
<p>Note: In order to gain a thorough understanding of this document, it is recommended that the <cite>Off-the-Record Communication</cite> paper and the &zrtp; Internet-Draft are read first.</p>
<p>Note: In order to gain a thorough understanding of this document, it is recommended that the <cite>Off-the-Record Communication</cite> paper and &rfc6189; are read first.</p>
</section1>
<section1 topic="Dramatis Personae" anchor='personae'>

2
xep-0210.xml
View File

@ -38,7 +38,7 @@
<section1 topic='Introduction' anchor='intro'>
<p>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 <cite>Current Jabber OpenPGP Usage</cite> uses "old-style" PGP object encryption and <cite>RFC 3923</cite> 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.</p>
<p>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 <link url='#reqs-forward'>Perfect Forward Secrecy</link> and <link url='#reqs-id-protect'>Identity Protection</link>.</p>
<p>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.</p>
<p>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.</p>
<p>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;).</p>
<p>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.</p>
</section1>

2
xep.ent
View File

@ -596,6 +596,7 @@ THE SOFTWARE.
<!ENTITY rfc6120 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6120'>RFC 6120</link></span> <note>RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core &lt;<link url='http://tools.ietf.org/html/rfc6120'>http://tools.ietf.org/html/rfc6120</link>&gt;.</note>" >
<!ENTITY rfc6121 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6121'>RFC 6121</link></span> <note>RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence &lt;<link url='http://tools.ietf.org/html/rfc6121'>http://tools.ietf.org/html/rfc6121</link>&gt;.</note>" >
<!ENTITY rfc6122 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6122'>RFC 6122</link></span> <note>RFC 6122: Extensible Messaging and Presence Protocol (XMPP): Address Format &lt;<link url='http://tools.ietf.org/html/rfc6122'>http://tools.ietf.org/html/rfc6122</link>&gt;.</note>" >
<!ENTITY rfc6189 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6189'>RFC 6189</link></span> <note>ZRTP: Media Path Key Agreement for Unicast Secure RTP &lt;<link url='http://tools.ietf.org/html/rfc6189'>http://tools.ietf.org/html/rfc6189</link>&gt;.</note>" >
<!-- Internet-Drafts -->
@ -625,7 +626,6 @@ THE SOFTWARE.
<!ENTITY vcardrev "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev'>vCard4</link></span> <note>vCard Format Specification &lt;<link url='http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev'>http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev</link>&gt;. Work in progress.</note>" >
<!ENTITY vcardthing "<span class='ref'><link url='http://tools.ietf.org/html/draft-saintandre-vcard-thing'>vCard KIND:thing</link></span> <note>vCard KIND:thing &lt;<link url='http://tools.ietf.org/html/draft-saintandre-vcard-thing'>http://tools.ietf.org/html/draft-saintandre-vcard-thing</link>&gt;. Work in progress.</note>" >
<!ENTITY vcardxml "<span class='ref'><link url='http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml'>vCard4 XML</link></span> <note>vCard XML Representation &lt;<link url='http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml'>http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml</link>&gt;. Work in progress.</note>" >
<!ENTITY zrtp "<span class='ref'><link url='http://tools.ietf.org/html/draft-zimmermann-avt-zrtp'>ZRTP</link></span> <note>ZRTP: Media Path Key Agreement for Secure RTP &lt;<link url='http://tools.ietf.org/html/draft-zimmermann-avt-zrtp'>http://tools.ietf.org/html/draft-zimmermann-avt-zrtp</link>&gt;. Work in progress.</note>" >
<!-- IANA registries -->