%ents; y"> x"> x"> y"> A"> B"> A"> B"> A"> B"> A"> B"> A"> B"> A"> B"> 32"> 2n-1"> n-1"> A"> B"> A"> B"> A"> B"> A"> B"> A"> B"> A"> B"> A"> B"> A"> A"> 1...xZ"> 1...eZ"> ]>
Offline Encrypted Sessions This document specifies an end-to-end encryption protocol for offline XMPP communication sessions. &LEGALNOTICE; 0187 Experimental Standards Track Standards XMPP Core XMPP IM RFC 2104 RFC 2409 RFC 3526 RFC 3548 xml-c14n XEP-0004 XEP-0020 XEP-0068 XEP-0079 XEP-0116 XEP-0155 XEP-0163 None None offlineesession &ianpaterson; 0.4 2006-11-27 ip

Added disclosure field; changed namespace

 0.3 2006-10-05 ip

Replaced secure field with security field; changed otr field to list-single

 0.2 2006-07-19 ip

Removed public key IDs from Offline options; harmonised session termination with the protocol added to XEP-0155; renamed logging field to otr

 0.1 2006-07-18 ip

Initial version (extracted from XEP-0116 version 0.9).

The convenience of sending stanzas to other entities that are offline ("offline messages") is an important and popular feature of most XMPP implementations (see &xep0160;). Without offline messages delivery would have to wait until both entities managed to be online at the same time. So many urgent messages could not be delivered in time. For example, the sender might want to send an urgent message before jumping on a flight.

End-to-end encryption is another desirable feature for any communication technology. Unfortunately it is not possible to make offline encryption quite so secure as online encryption (see Security Considerations). However, offline encryption has a long history and is certainly preferable to having no encryption at all. This protocol does not stop paranoid users avoiding sending offline messages. Unfortunately, for reasons described in &xep0188;, the existing proposals (including &xep0027; and &rfc3923;) have not been widely implemented and deployed. This document describes a different approach to offline end-to-end encryption for use by entities that communicate using XMPP. It builds on the existing online &xep0116; protocol. As a result it offers important advantages over the existing "Object Encryption" proposals:

The requirements and the consequent cryptographic design that underpin this protocol are described in &xep0210; and Cryptographic Design of Encrypted Sessions. 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;.

This document introduces two characters to help the reader follow the necessary exchanges:

  1. "Bob" is the name of the online participant in the offline ESession. Within the scope of this document, his fully-qualified JID is: <bob@example.com/laptop>.
  2. "Alice" is the name of the offline participant in the offline ESession started by Bob. Within the scope of this document, we stipulate that her fully-qualified JID is: <alice@example.org/pda>.

While Bob and Alice are introduced as "end users", they are simply meant to be examples of Jabber entities. Any directly addressable Jabber entity may participate in an offline ESession.

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 Encrypted Session Negotiation).

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.

Note: Alice MAY also publish another similar set of relatively long-lived 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. offline ESession options that any entity MAY use for the same purpose.

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 Session Negotiation) except she MUST omit The 'accept' and 'pubkey' 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 &xep0082;) that she decides her offline ESession options will expire (see Options Expiry Time Security Considerations).

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

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 a list of signatures (see Signature Generation) of the content of the data form (excluding the 'signs' field). The list SHOULD include one signature for each of the public signature-verification keys that other entities may use to authenticate her.

Alice MUST publish the ESession options data form through her own server using &xep0163;.

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 access to her identity (see Identity Protection 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.

http://jabber.org/protocol/pubsub#node_config ]]> http://jabber.org/protocol/pubsub#node_config ]]>

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

urn:xmpp:ssn 1 2006-06-09T02:56:15Z ** Base64 encoded ESession ID ** ** Base64 encoded value of e5 ** ** Base64 encoded value of e14 ** ** Base64 encoded value of e2 ** pda ** signature of form ** ** signature of form ** ]]>

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

... ]]>

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, her long-term public signature-verification keys from her server using Personal Eventing via Pubsub (see &xep0189;). There is no need for Bob to discover Alice's support for the Offline ESessions protocol via &xep0030;.

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

]]>

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.

]]>

If, after receiving Alice's offline ESession options, Bob is unable to verify any of Alice's signatures of her options data form (see Signature Verification) with any of her public keys already in his possession (or with any of her keys he is able to acquire and trust) 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.

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

  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 'pubkey' field, he MUST assume its value is 'key'. Bob SHOULD NOT include a 'pubkey' 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 &MsubB; 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 Session Negotiation) 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 Encrypted Session Negotiation) 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.

urn:xmpp:ssn true never e2e 5 aes256-ctr sha256 rsa none message 1.3 50 ** Base64 encoded ESession ID ** ** Base64 encoded value of d ** ** Base64 encoded ESession ID ** ** Base64 encoded block counter ** ** Encrypted identity ** ** Integrity of identity ** ** Base64 encoded m_final ** ** Base64 encoded a_mac ** ]]>

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.

    ]]>

  2. Retrieve any values of &NsubA;, x (one for each MODP group for each &NsubA;) 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. 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!

  2. 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 Encrypted Session Negotiation). 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 Session Negotiation:

    • 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 'pubkey' field to Bob, she MUST assume its value is 'key'. 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 without sending an error.

Alice MUST NOT send encrypted content within an offline ESession started by Bob. If Bob is conducting an offline ESession with Alice when she is online (e.g., if he is not subscribing to her presence), then if Alice wants to send a stanza to Bob, she MUST terminate the offline ESession and start a new online ESession first.

For Offline ESessions, Bob SHOULD include a 'Created' SHIM header in the encrypted content. Assuming she trusts Bob, Alice SHOULD trust this header and ignore the unencrypted &xep0203; element inserted by her server.

Hello, Alice!
2005-02-10T03:01:52Z
 ]]> Hello, Alice!
2005-02-10T03:01:52Z
 ]]>

If Bob notices that Alice comes online during his offline ESession with her then he MUST terminate the ESession immediately. If required he may then negotiate a new (more secure) online ESession.

When Alice receives the offline ESession termination stanza from Bob, she SHOULD NOT send a termination stanza back to him.

For more security considerations refer to the Security Considerations section of Encrypted Session Negotiation

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 &NsubA; 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 &NsubA; and x).

If Alice's offline private Diffie-Hellman keys are compromised before she destroys them, 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.

Alice's Offline ESession options include her signatures. Although the signatures are public information, any entity that possesses one of Alice's corresponding public keys may confirm whether or not she is the entity using the JID. If it is important for Alice to protect her identity (i.e. hide the fact that she is the user of the JID), then she MUST carefully control who has access to her public keys.

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, &x1xZ;, to local disk or to a server (perhaps symmetrically encrypted with a password). It is really hard to securely erase something from a disk. Note: Once compromised, her private Diffie-Hellman keys could only be used to decrypt messages sent to her within offline Esessions until her offline ESession options expire. They could not be used to negotiate online ESessions The online ESessions protocol forces both Alice and Bob to produce a signature of both their Diffie-Hellman keys together., or to send messages that appear to be from Alice. This is a significant benefit when compared to the existing "object encryption" schemes.

Alice could decide not to support Offline ESessions since they are less secure than online ESessions. However, if Alice does that then, while she is offline, Bob, or Aunt Tillie, will probably send her completely unprotected messages!

This document requires no interaction with &IANA;.

The ®ISTRAR; shall add 'urn:xmpp:esession#subscription' to its registry of protocol namespaces.