0.5 published

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@785 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-04-21 03:35:11 +00:00
parent bea4cca3ac
commit d113668bd8
1 changed files with 3 additions and 3 deletions

View File

@ -69,9 +69,9 @@
&ianpaterson;
<revision>
<version>0.5</version>
<date>2007-03-28</date>
<date>2007-04-20</date>
<initials>ip</initials>
<remark><p>Moved requirements, approach and scope to new XEP-0207</p></remark>
<remark><p>Moved requirements, approach and scope to new XEP-0210</p></remark>
</revision>
<revision>
<version>0.4</version>
@ -103,7 +103,7 @@
<p><em>Note: The protocols developed according to the cryptographic design described in this document are described in &xep0116;, &xep0187; and &xep0200;. The information in those documents should be sufficient for implementors. This purely informative document is primarily for people interested in the design and analysis of those protocols.</em></p>
<p>As specified in &rfc3920;, XMPP is an XML streaming protocol that enables the near-real-time exchange of XML fragments between any two (or more) network endpoints. To date, the main application built on top of the core XML streaming layer is instant messaging (IM) and presence, the base extensions for which are specified in &rfc3921;. There are three first-level elements of XML streams (&MESSAGE;, &PRESENCE;, and &IQ;); each of these "XML stanza" types has different semantics, which can complicate the task of defining a generalized approach to end-to-end encryption for XMPP. In addition, XML stanzas can be extended (via properly-namespaced child elements) for a wide variety of functionality.</p>
<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 &xep0207;.</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>
</section1>