URN namespace and added reference to XEP-0200

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@207 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0187.xml

@@ -52,6 +52,7 @@
   <jig>Standards JIG</jig>
   <dependencies>
     <spec>XMPP Core</spec>
+    <spec>XMPP IM</spec>
     <spec>RFC 2104</spec>
     <spec>RFC 2409</spec>
     <spec>RFC 3526</spec>
@@ -73,7 +74,7 @@
     <version>0.4</version>
     <date>2006-11-16</date>
     <initials>ip</initials>
-    <remark><p>Added disclosure field</p></remark>
+    <remark><p>Added disclosure field; changed namespace</p></remark>
   </revision>
   <revision>
     <version>0.3</version>
@@ -101,9 +102,9 @@
   <ul>
     <li>Perfect Forward Secrecy <note>Long-lived keys are typically used for a few years, whereas Offline ESession decryption keys typically exist for just a few hours. So the Perfect Forward Secrecy feature significantly enhances the security of Offline ESessions.</note></li>
     <li>Other security features described in <cite>Cryptographic Design of Encrypted Sessions</cite></li>
-    <li>Most of the code can be borrowed from implementations of <cite>Encrypted Sessions</cite></li>
+    <li>Most of the code can be borrowed from implementations of <cite>Encrypted Session Negotiation</cite></li>
   </ul>
-  <p>The requirements and the consequent cryptographic design that underpin this protocol are described in <cite>Cryptographic Design of Encrypted Sessions</cite>. The basic concept is that of an encrypted session which acts as a secure tunnel between the online endpoint and the offline endpoint. The offline endpoint completes its part of the tunnel "negotiation" by publishing its preferences before it goes offline. Once the tunnel is established by the online endpoint, the content of each one-to-one XML stanza sent by the online endpoint is encrypted and then transmitted within a "wrapper" stanza.</p>
+  <p>The requirements and the consequent cryptographic design that underpin this protocol are described in <cite>Cryptographic Design of Encrypted Sessions</cite>. The basic concept is that of an encrypted session which acts as a secure tunnel between the online endpoint and the offline endpoint. The offline endpoint completes its part of the tunnel "negotiation" by publishing its preferences before it goes offline. Once the tunnel is established by the online endpoint, the content of each one-to-one XML stanza sent by the online endpoint is encrypted and then transmitted within a "wrapper" stanza using &xep0200;.</p>
 </section1>
 
 <section1 topic="Dramatis Personae" anchor='personae'>
@@ -116,12 +117,12 @@
 </section1>
 
 <section1 topic="Offline ESession Negotiation" anchor='init'>
-  <p>The approach to establishing a secure session with an entity that is offline is in essence a special case of 3-message negotiation employed for online ESessions (see <cite>Encrypted Sessions</cite>).</p>
+  <p>The approach to establishing a secure session with an entity that is offline is in essence a special case of 3-message negotiation employed for online ESessions (see <cite>Encrypted Session Negotiation</cite>).</p>
   <p>Alice MAY publish a set of offline ESession options just before she goes offline. If Bob subscribes to Alice's presence and wishes to establish an online ESession with her, but he finds that she is offline, then if she published her offline ESession options before going offline, he may use the protocol described below to perform the initial Diffie-Hellman key exchange, establish an offline ESession and send encrypted stanzas to her while she is offline. Note: Bob MUST NOT initiate a new ESession with Alice if he already has an ESession established with her.</p>
   <p>Note: Alice MAY also publish <em>another</em> similar set of relatively long-lived <note>The more often Alice changes her published ESession options, the shorter the Perfect Forward Secrecy window of vulnerability. However, whenever she changes them she divulges her presence to all the entities that are monitoring them.</note> offline ESession options that any entity MAY use for the same purpose.</p>
 
     <section2 topic="Publishing Offline ESession Options" anchor='init-offline-publish'>
-      <p>In order to publish either set of her offline ESession options Alice MUST create an options data form in exactly the same way as she would create an online ESession request data form (see the ESession Request section in <cite>Encrypted Sessions</cite>) except she MUST omit The 'accept' and 'pk_hash' fields. Note: The list of stanza types she is willing to decrypt MUST NOT include the value 'iq'.</p>
+      <p>In order to publish either set of her offline ESession options Alice MUST create an options data form in exactly the same way as she would create an online ESession request data form (see the ESession Request section in <cite>Encrypted Session Negotiation</cite>) except she MUST omit The 'accept' and 'pk_hash' fields. Note: The list of stanza types she is willing to decrypt MUST NOT include the value 'iq'.</p>
       <p>Alice MUST append to the content of the form an 'expires' field containing the UTC time (see &xep0082;) that she decides her offline ESession options will expire (see <link url='#sec-expire'>Options Expiry Time</link> Security Considerations).</p>
       <p>Alice MUST store her value of &NsubA; (her ESession ID), all her values of x (one for each MODP group) and the time she decides her offline ESession options will expire in a secure way, so that she can retrieve them when she comes back online (idealy even if that is using a different client and/or a different machine).</p>
       <p>If Alice would not be able to decrypt stanzas if she came back online using a different client and/or a different machine then she SHOULD also encapsulate the resource of her client in a 'match_resource' field and append it to her options data form. In this case, the list of stanza types she is willing to decrypt MUST include only 'message'.</p>
@@ -131,7 +132,7 @@
   <example caption='Alice Creates PEP Node for ESession Options for Presence Subscribers'><![CDATA[
 <iq from='alice@example.org/pda' type='set' id='create1'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <create node='http://jabber.org/protocol/esession#subscription'/>
+    <create node='urn:xmpp:esession#subscription'/>
     <configure>
       <x xmlns='jabber:x:data' type='form'>
         <field var='FORM_TYPE' type='hidden'>
@@ -154,7 +155,7 @@
   <example caption='Alice Creates PEP Node for ESession Options for All Entities'><![CDATA[
 <iq from='alice@example.org/pda' type='set' id='create2'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <create node='http://jabber.org/protocol/esession'/>
+    <create node='urn:xmpp:esession'/>
     <configure>
       <x xmlns='jabber:x:data' type='form'>
         <field var='FORM_TYPE' type='hidden'>
@@ -178,11 +179,11 @@
   <example caption='Alice Publishes Her ESession Options for Her Presence Subscribers'><![CDATA[
 <iq from='alice@example.org/pda' type='set' id='pub1'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <publish node='http://jabber.org/protocol/esession#subscription'>
+    <publish node='urn:xmpp:esession#subscription'>
       <item>
         <x type='form' xmlns='jabber:x:data'>
           <field type="hidden" var="FORM_TYPE">
-            <value>http://jabber.org/protocol/chatneg</value>
+            <value>urn:xmpp:chatneg</value>
           </field>
           <field type="list-single" var="otr">
             <option><value>false</value></option>
@@ -253,7 +254,7 @@
   <example caption='Alice Publishes Her ESession Options for All Entities'><![CDATA[
 <iq type='set' from='alice@example.org/pda' id='pub2'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <publish node='http://jabber.org/protocol/esession'>
+    <publish node='urn:xmpp:esession'>
       ...
     </publish>
   </pubsub>
@@ -269,7 +270,7 @@
     to='alice@example.org'
     id='es4'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <items node='http://jabber.org/protocol/esession#subscription'/>
+    <items node='urn:xmpp:esession#subscription'/>
   </pubsub>
 </iq>
   ]]></example>
@@ -280,7 +281,7 @@
     to='alice@example.org'
     id='es4'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <items node='http://jabber.org/protocol/esession'/>
+    <items node='urn:xmpp:esession'/>
   </pubsub>
 </iq>
   ]]></example>
@@ -289,22 +290,22 @@
     </section2>
 
     <section2 topic="Starting an Offline ESession" anchor='init-offline-start'>
-      <p>Bob MUST now continue as if Alice had requested an online ESession, performing the steps described in three of the sections of <cite>Encrypted Sessions</cite>:</p>
+      <p>Bob MUST now continue as if Alice had requested an online ESession, performing the steps described in three of the sections of <cite>Encrypted Session Negotiation</cite>:</p>
       <ol start='1'>
         <li><p><cite>Diffie-Hellman Preparation (Bob)</cite> Note: If the value of e he selected is not valid, Bob SHOULD terminate the ESession <em>without</em> sending an error.</p></li>
         <li><p><cite>Generating Session Keys</cite></p></li>
         <li><p><cite>Hiding Identity</cite> Note: Since Bob did not receive a 'pk_hash' field, he MUST assume its value is false. Bob SHOULD NOT include a 'pk_hash' field in &formB; since Alice has already proved her identity.</p></li>
       </ol>
       <p>As with 3-message ESession negotiation, Bob should encapsulate the Base64 encoded values of &IDB; and &MsubB; in data form fields ('identity' and 'mac'), and append the new fields to &formB;.</p>
-      <p>Bob MAY also send encrypted content (see the Exchanging Stanzas section of <cite>Encrypted Sessions</cite>) in the same stanza. Note: If he also includes a field named "terminate" set to a value of "1" or "true" within the data form (see the ESession Termination section of <cite>Encrypted Sessions</cite>) then the ESession is terminated immediately. This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified) and offers several significant advantages over non-session approaches - including perfect forward secrecy.</p>
+      <p>Bob MAY also send encrypted content (see the Exchanging Stanzas section of <cite>Encrypted Session Negotiation</cite>) in the same stanza. Note: If he also includes a field named "terminate" set to a value of "1" or "true" within the data form (see the ESession Termination section of <cite>Encrypted Session Negotiation</cite>) then the ESession is terminated immediately. This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified) and offers several significant advantages over non-session approaches - including perfect forward secrecy.</p>
       <p>If Alice included a 'match_resource' field in her ESession options, then Bob MUST address all the stanzas he sends within the offline ESession to the specified resource and use the <cite>Advanced Message Processing</cite> protocol to ensure that they are not delivered to any other resource.</p>
       <p>After sending &formB; to Alice, Bob can assume that the ESession negotiation is complete.</p>
       <example caption='Bob Establishes an ESession Without Negotiation'><![CDATA[
 <message from='bob@example.com/laptop' to='alice@example.org/pda' type='chat'>
-  <init xmlns='http://jabber.org/protocol/esession#init'>
+  <init xmlns='urn:xmpp:esession#init'>
     <x type='submit' xmlns='jabber:x:data'>
       <field var="FORM_TYPE">
-        <value>http://jabber.org/protocol/chatneg</value>
+        <value>urn:xmpp:chatneg</value>
       </field>
       <field var="otr"><value>true</value></field>
       <field var="disclosure"><value>never</value></field>
@@ -337,7 +338,7 @@
       </field>
     </x>
   </init>
-  <encrypted xmlns='http://jabber.org/protocol/esession'>
+  <encrypted xmlns='urn:xmpp:crypt'>
     <data> ** Base64 encoded m_final ** </data>
     <mac> ** Base64 encoded a_mac ** </mac>
   </encrypted>
@@ -354,7 +355,7 @@
             <example caption='Alice Stops Publishing Her ESession Options'><![CDATA[
 <iq type='set' from='alice@example.org/pda' id='es5'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
-    <publish node='http://jabber.org/protocol/esession#subscription'>
+    <publish node='urn:xmpp:esession#subscription'>
       <item/>
     </publish>
   </pubsub>
@@ -366,8 +367,8 @@
       <p>If the current time is after her offline ESession options expiry time then she MUST discard all stanzas from offline ESessions without decrypting them. Otherwise, when Alice receives an offline ESession request stanza from Bob then she MUST perform the following steps:</p>
       <ol>
         <li><p>Select her value of x that corresponds to the 'nonce' and 'modp' fields she received from Bob. <note>Alice may not be able to find the specified value of x if, for example, she went offline using a different client and/or a different machine without publishing a 'match_resource' field. In this case Alice cannot decrypt the offline ESession!</note></p></li>
-        <li><p>Confirm that she has not already received a key exchange stanza from Bob with the same value of d or &NsubB; ('my_nonce' field) since she published her ESession options (see the Replay Attacks subsection of the Security Considerations section of <cite>Encrypted Sessions</cite>). If the options were for subscribers, that means since she came online.</p></li>
+        <li><p>Confirm that she has not already received a key exchange stanza from Bob with the same value of d or &NsubB; ('my_nonce' field) since she published her ESession options (see the Replay Attacks subsection of the Security Considerations section of <cite>Encrypted Session Negotiation</cite>). If the options were for subscribers, that means since she came online.</p></li>
-        <li><p>Alice MUST now continue as if Bob had responded to her online ESession request, performing the steps described in two of the sections of <cite>Encrypted Sessions</cite>:</p>
+        <li><p>Alice MUST now continue as if Bob had responded to her online ESession request, performing the steps described in two of the sections of <cite>Encrypted Session Negotiation</cite>:</p>
         <ul>
           <li><p><cite>Diffie-Hellman Preparation (Alice)</cite> Note: If she is not prepared to support any of the ESession options specified by Bob, or if the value of d she selected is not valid, then Alice SHOULD terminate the ESession <em>without</em> sending an error.</p></li>
           <li><p><cite>Verifying Bob's Identity</cite> Note: Since Alice did not send a 'pk_hash' field to Bob, she MUST assume its value is false. If the value of &MsubB; she calculated does not match the one she received, or if she cannot confirm that &pubKeyB; really is Bob's public key, or if she cannot confirm that &signB; is the signature of the HMAC result, then Alice SHOULD terminate the ESession <em>without</em> sending an error.</p></li>
@@ -411,7 +412,7 @@
 
 
 <section1 topic='Security Considerations' anchor='sec'>
-  <p>For more security considerations refer to the Security Considerations section of <cite>Encrypted Sessions</cite></p>
+  <p>For more security considerations refer to the Security Considerations section of <cite>Encrypted Session Negotiation</cite></p>
   <section2 topic='Replay Attacks' anchor='sec-replay'>
     <p>Since Alice supplies the same set of values of e for all offline ESessions, to prevent complete offline ESessions being replayed to her, she MUST take care to securely store <em>new</em> values (or destroy existing values) of &NsubA; and x for subscribers whenever she goes offline (see <link url='#init-publish'>Publishing ESession Options</link>). Also, when Alice comes online again, she MUST remember all the values of d he receives in offline ESession negotiation stanzas, and reject any offline ESessions that specify a value of d she has already received (see <link url='#init-accept'>Accepting an Offline ESession</link>).</p>
     <p>Note: If Alice publishes ESession options for non-subscribers, and if she does not update them whenever she comes online then, until she updates the options, she MUST save all the values of d she receives to secure persistent storage (along with the values of &NsubA; and x).</p>
@@ -433,7 +434,7 @@
 </section1>
 
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
-  <p>The &REGISTRAR; shall add 'http://jabber.org/protocol/esession#subscription' to its registry of protocol namespaces.</p>
+  <p>The &REGISTRAR; shall add 'urn:xmpp:esession#subscription' to its registry of protocol namespaces.</p>
 </section1>
 
 </xep>