JEP-0187: Offline Encrypted Sessions

Ian Paterson

Email: ian.paterson@clientside.co.uk
JID: ian@zoofy.com

1. Introduction

2. Dramatis Personae

3. Offline ESession Negotiation

3.1. Publishing Offline ESession Options

3.2. Requesting Offline ESession Options

3.3. Starting an Offline ESession

3.4. Accepting Offline ESessions

4. Exchanging Stanzas

5. ESession Termination

6. Security Considerations

6.1. Replay Attacks

6.2. Options Expiry Time

6.3. Identity Exposure

6.4. Conclusion

7. IANA Considerations

8. Jabber Registrar Considerations

Notes

Revision History

3.1 Publishing Offline ESession Options

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 Encrypted Sessions) 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'.

Alice MUST append to the content of the form an 'expires' field containing the UTC time (see Jabber Date and Time Profiles [9]) that she decides her offline ESession options will expire (see Options Expiry Time Security Considerations).

Alice MUST store her value of NA (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).

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'.

Alice MUST also append to the content of the form the list of the fingerprints (PKIDs) of all her public signature-verification keys that she can sign for in a 'pkids' field, and the corresponding list of signatures (see Signature Generation) of the content of the data form (excluding the 'signs' field).

Alice MUST publish the ESession options data form through her own server using Personal Eventing via Pubsub [10].

If the pubkey PEP node does not exist already then Alice MUST create it first. In this case, Alice SHOULD specify the "Presence" access model for the set of options for presence subscribers (or the "Open" model for the set for other entities), unless she wants greater control over trivial access to her identity (see Identity Exposure Security Considerations). Alice SHOULD specify that the options will never be pushed to subscribers (even when she publishes new options) - especially if she specifies the "Whitelist" access model.

Example 1. Alice Creates PEP Node for ESession Options for Presence Subscribers

<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'/>
    <configure>
      <x xmlns='jabber:x:data' type='form'>
        <field var='FORM_TYPE' type='hidden'>
          <value>http://jabber.org/protocol/pubsub#node_config</value>
        </field>
        <field var='pubsub#deliver_notifications'>
          <option><value>0</value></option>
        </field>
        <field var='pubsub#send_last_published_item'>
          <option><value>never</value></option>
        </field>
        <field var='pubsub#access_model'>
          <option><value>presence</value></option>
        </field>
      </x>
    </configure>
  </pubsub>
</iq>
  

Example 2. Alice Creates PEP Node for ESession Options for All Entities

<iq from='alice@example.org/pda' type='set' id='create2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <create node='http://jabber.org/protocol/esession'/>
    <configure>
      <x xmlns='jabber:x:data' type='form'>
        <field var='FORM_TYPE' type='hidden'>
          <value>http://jabber.org/protocol/pubsub#node_config</value>
        </field>
        <field var='pubsub#deliver_notifications'>
          <option><value>0</value></option>
        </field>
        <field var='pubsub#send_last_published_item'>
          <option><value>never</value></option>
        </field>
        <field var='pubsub#access_model'>
          <option><value>open</value></option>
        </field>
      </x>
    </configure>
  </pubsub>
</iq>
  

Once the publishing node has been created, Alice can update her options for subscribers to her presence whenever she goes offline:

Example 3. Alice Publishes Her ESession Options for Her Presence Subscribers

<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'>
      <item>
        <x type='form' xmlns='jabber:x:data'>
          <field type="hidden" var="FORM_TYPE">
            <value>http://jabber.org/protocol/chatneg</value>
          </field>
          <field type="boolean" var="logging">
            <value>1</value>
          </field>
          <field type="boolean" var="secure">
            <value>0</value>
          </field>
          <field type="list-single" var="modp">
            <option><value>5</value></option>
            <option><value>14</value></option>
            <option><value>2</value></option>
          </field>
          <field type="list-single" var="crypt_algs">
            <option><value>aes256-ctr</value></option>
            <option><value>twofish256-ctr</value></option>
            <option><value>aes128-ctr</value></option>
          </field>
          <field type="list-single" var="hash_algs">
            <option><value>whirlpool</value></option>
            <option><value>sha256</value></option>
          </field>
          <field type="list-single" var="sign_algs">
            <option><value>rsa</value></option>
            <option><value>dsa</value></option>
          </field>
          <field type="list-single" var="compress">
            <option><value>none</value></option>
          </field>
          <field type="list-multi" var="stanzas">
            <option><value>message</value></option>
          </field>
          <field type="list-single" var="ver">
            <option><value>1.3</value></option>
            <option><value>1.2</value></option>
          </field>
          <field type="text-single" var="rekey_freq">
            <value>1</value>
          </field>
          <field var="expires">
            <value>2006-06-09T02:56:15Z</value>
          </field>
          <field var="my_nonce">
            <value> ** Base64 encoded ESession ID ** </value>
          </field>
          <field var="keys">
            <value> ** Base64 encoded value of e5 ** </value>
            <value> ** Base64 encoded value of e14 ** </value>
            <value> ** Base64 encoded value of e2 ** </value>
          </field>
          <field var="match_resource">
            <value>pda</value>
          </field>
          <field var="pkids">
            <value> ** PKID ** </value>
            <value> ** PKID ** </value>
          </field>
          <field var="signs">
            <value> ** signature of form ** </value>
            <value> ** signature of form ** </value>
          </field>
        </x>
      </item>
    </publish>
  </pubsub>
</iq>
  

At the risk of divulging her presence, Alice MAY also update her options for all entities:

Example 4. Alice Publishes Her ESession Options for All Entities

<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>
  </pubsub>
</iq>
  

3.2 Requesting Offline ESession Options

If Bob believes Alice is offline he SHOULD request her ESession options and, if he does not have a local copy of any of her public keys specified therein, her long-term public signature-verification keys (see Public Key Publishing [11]) from her server using Personal Eventing via Pubsub. [12]

If Bob is subscribing to Alice's presence he MUST request her ESession Options exclusively for subscribers.

Example 5. Bob asks Alice's Server for her ESession Options (Subscribers)

<iq type='get'
    from='bob@example.com/laptop'
    to='alice@example.org'
    id='es4'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='http://jabber.org/protocol/esession#subscription'/>
  </pubsub>
</iq>
  

If Bob is not subscribing to Alice's presence (or if Alice has no ESession options exclusively for subscribers) he MUST use the following request instead.

Example 6. Bob asks Alice's Server for her ESession Options (All Entities)

<iq type='get'
    from='bob@example.com/laptop'
    to='alice@example.org'
    id='es4'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='http://jabber.org/protocol/esession'/>
  </pubsub>
</iq>
  

If, after receiving Alice's public keys and ESession options, Bob is unable to verify any of Alice's signatures of her offline options data form (see Signature Verification) then he MUST proceed no further, since he cannot be sure who will be able to decrypt his stanzas.

If Bob cannot acquire Alice's ESession options, or he does not support one or more of the options in each Alice's ESession fields, or if the 'expires' field indicates that Alice's options have expired, then he MUST NOT send encrypted stanzas to her while she is offline.

3.3 Starting an Offline ESession

Bob MUST now continue as if Alice had requested an online ESession, performing the steps described in three of the sections of Encrypted Sessions:

1. Diffie-Hellman Preparation (Bob) Note: If the value of e he selected is not valid, Bob SHOULD terminate the ESession without sending an error.

2. Generating Session Keys

3. Hiding Identity 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.

As with 3-message ESession negotiation, Bob should encapsulate the Base64 encoded values of IDB and MB in data form fields ('identity' and 'mac'), and append the new fields to formB.

Bob MAY also send encrypted content (see the Exchanging Stanzas section of Encrypted Sessions) in the same stanza. Note: If he also includes a <terminate/> element (see the ESession Termination section of Encrypted Sessions) within the <encrypted/> element 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.

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 Advanced Message Processing protocol to ensure that they are not delivered to any other resource.

After sending formB to Alice, Bob can assume that the ESession negotiation is complete.

Example 7. Bob Establishes an ESession Without Negotiation

<message from='bob@example.com/laptop' to='alice@example.org/pda' type='chat'>
  <init xmlns='http://jabber.org/protocol/esession#init'>
    <x type='submit' xmlns='jabber:x:data'>
      <field var="FORM_TYPE">
        <value>http://jabber.org/protocol/chatneg</value>
      </field>
      <field var="logging"><value>0</value></field>
      <field var="secure"><value>0</value></field>
      <field var="modp"><value>5</value></field>
      <field var="crypt_algs"><value>aes256-ctr</value></field>
      <field var="hash_algs"><value>sha256</value></field>
      <field var="sign_algs"><value>rsa</value></field>
      <field var="compress"><value>none</value></field>
      <field var="stanzas"><value>message</value></field>
      <field var="ver"><value>1.3</value></field>
      <field var="rekey_freq"><value>50</value></field>
      <field var="my_nonce">
        <value> ** Base64 encoded ESession ID ** </value>
      </field>
      <field var="keys">
        <value> ** Base64 encoded value of d ** </value>
      </field>
      <field var="nonce">
        <value> ** Base64 encoded ESession ID ** </value>
      </field>
      <field var="counter">
        <value> ** Base64 encoded block counter ** </value>
      </field>
      <field var="identity">
        <value> ** Encrypted identity ** </value>
      </field>
      <field var="mac">
        <value> ** Integrity of identity ** </value>
      </field>
    </x>
  </init>
  <encrypted xmlns='http://jabber.org/protocol/esession'>
    <data> ** Base64 encoded m_final ** </data>
    <mac> ** Base64 encoded a_mac ** </mac>
  </encrypted>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='??????' condition='match-resource' value='exact'/>
  </amp>
</message>
    

3.4 Accepting Offline ESessions

When Alice comes online she MUST perform the following steps:

1. Ensure she is no longer publishing offline ESession options exclusively for entities that are subscribing to her presence.

   Example 8. Alice Stops Publishing Her ESession Options

   <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'>
         <item/>
       </publish>
     </pubsub>
   </iq>
     

2. Retrieve any values of NA, x (one for each MODP group for each NA) and her offline ESession options expiry time that she stored before going offline, and destroy in a secure way any persistently stored copies that correspond to ESession options exclusively for subscribers.

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:

1. Select her value of x that corresponds to the 'nonce' and 'modp' fields she received from Bob. [14]

2. Confirm that she has not already received a key exchange stanza from Bob with the same value of d or NB ('my_nonce' field) since she published her ESession options (see the Replay Attacks subsection of the Security Considerations section of Encrypted Sessions). If the options were for subscribers, that means since she came online.

3. Alice MUST now continue as if Bob had responded to her online ESession request, performing the steps described in two of the sections of Encrypted Sessions:

   • Diffie-Hellman Preparation (Alice) 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 without sending an error.

   • Verifying Bob's Identity Note: Since Alice did not send a 'pk_hash' field to Bob, she MUST assume its value is false. If the value of MB 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 without sending an error.

<message from='bob@example.com/laptop'
         to='alice@example.org/pda'
         type='chat'>
  <body>Hello, Alice!</body>
  <amp xmlns='http://jabber.org/protocol/amp'>
    <rule action='error' condition='match-resource' value='exact'/>
  </amp>
  <headers xmlns='http://jabber.org/protocol/shim'>
    <header name='Created'>2005-02-10T03:01:52Z</header>
  </headers>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>

<body>Hello, Alice!</body>
<headers xmlns='http://jabber.org/protocol/shim'>
  <header name='Created'>2005-02-10T03:01:52Z</header>
</headers>
<active xmlns='http://jabber.org/protocol/chatstates'/>
  

6.1 Replay Attacks

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 new values (or destroy existing values) of NA and x for subscribers whenever she goes offline (see Publishing ESession Options). 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 Accepting an Offline ESession).

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 NA and x).

6.2 Options Expiry Time

If Alice's offline private Diffie-Hellman keys are compromised, and the attacker also controls communications between Bob and Alice's server, then the attacker could prevent Bob discovering if she comes online, and resend her compromised ESession options to Bob whenever he asks for them. This would allow the attacker to decrypt all messages sent to Alice before her offline ESession options expire. Alice would probably never receive the messages sent to her after she comes back online. If an attack is discovered before the compromised ESession options expire then Alice SHOULD change her long-term signing key. Alice SHOULD mitigate this attack by choosing an expiry time for her ESession options that is not too long after she expects to be online again.

6.3 Identity Exposure

Offline ESession options include public keys. By publishing her public keys Alice associates her identity with her JID. Although the public keys are public information, it may be critically important for Alice to keep her identity secret from all but a few specified people. Implementors MUST take great care to ensure the identity of Alice is never divulged to anyone except her (PEP) server and the entities who have been permitted by Alice to access her offline ESession options. However, even then, Alice will not be able to protect her identity being exposed by passive attacks!

6.4 Conclusion

Alice MAY decide not to support offline ESessions since they are less secure than online ESessions. In addition to the issues above, the Perfect Forward Secrecy window of vulnerability is longer. More seriously, Alice MUST store her private Diffie-Hellman keys, x1...xZ, to local disk or to a server (perhaps symmetrically encrypted with a password). It is really hard to securely erase something from a disk. However, if Alice does not support Offline ESessions then, while she is offline, Bob, or Aunt Tillie, will probably send her completely unprotected messages!

1. JEP-0160: Best Practices for Handling Offline Messages <http://www.jabber.org/jeps/jep-0160.html>.

2. This protocol does not stop paranoid users avoiding sending offline messages.

3. JEP-0188: Cryptographic Design of Encrypted Sessions <http://www.jabber.org/jeps/jep-0188.html>.

4. JEP-0027: Current Jabber OpenPGP Usage <http://www.jabber.org/jeps/jep-0027.html>.

5. RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc3923.txt>.

6. JEP-0116: Encrypted Sessions <http://www.jabber.org/jeps/jep-0116.html>.

7. 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.

8. 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.

9. JEP-0082: Jabber Date and Time Profiles <http://www.jabber.org/jeps/jep-0082.html>.

10. JEP-0163: Personal Eventing via Pubsub <http://www.jabber.org/jeps/jep-0163.html>.

11. JEP-0189: Public Key Publishing <http://www.jabber.org/jeps/jep-0189.html>.

12. There is no need for Bob to discover Alice's support for the Offline ESessions protocol via Service Discovery [13].

13. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.

14. 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!

15. JEP-0091: Delayed Delivery <http://www.jabber.org/jeps/jep-0091.html>.

16. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

17. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.

Version 0.1 (2006-07-18)