End-to-End Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
draft-miller-xmpp-e2e-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Matthew A. Miller | ||
| Last updated | 2012-06-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-miller-xmpp-e2e-01
Network Working Group M. Miller
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track June 21, 2012
Expires: December 23, 2012
End-to-End Object Encryption for the Extensible Messaging and Presence
Protocol (XMPP)
draft-miller-xmpp-e2e-01
Abstract
This document defines a method of end-to-end object encryption for
the Extensible Messaging and Presence Protocol (XMPP).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 23, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Miller Expires December 23, 2012 [Page 1]
Internet-Draft XMPP E2E June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Determining Support . . . . . . . . . . . . . . . . . . . . . 3
4. Encrypting XMPP Stanzas . . . . . . . . . . . . . . . . . . . 4
4.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Process . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Example - Securing a Message . . . . . . . . . . . . . . . 6
5. Decrypting XMPP Stanzas . . . . . . . . . . . . . . . . . . . 8
5.1. Protocol Not Understood . . . . . . . . . . . . . . . . . 8
5.2. Process . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Insufficient Information . . . . . . . . . . . . . . . . . 9
5.4. Failed Decryption . . . . . . . . . . . . . . . . . . . . 10
5.5. Timestamp Not Acceptable . . . . . . . . . . . . . . . . . 11
5.6. Successful Decryption . . . . . . . . . . . . . . . . . . 11
6. Requesting Content Keys . . . . . . . . . . . . . . . . . . . 11
6.1. Request Process . . . . . . . . . . . . . . . . . . . . . 12
6.2. Accept Process . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Error Conditions . . . . . . . . . . . . . . . . . . . . . 13
6.4. Example of Successful Key Request . . . . . . . . . . . . 13
7. Inclusion and Checking of Timestamps . . . . . . . . . . . . . 16
8. Interaction with Stanza Semantics . . . . . . . . . . . . . . 17
9. Mandatory-to-Implement Cryptographic Algorithms . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.1. Storage of Encrypted Stanzas . . . . . . . . . . . . . . . 18
10.2. Re-use of Content Master Keys . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11.1. XML Namespace Name for e2e Data in XMPP . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e:2 . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Miller Expires December 23, 2012 [Page 2]
Internet-Draft XMPP E2E June 2012
1. Introduction
End-to-end encryption of traffic sent over the Extensible Messaging
and Presence Protocol [RFC6120] is a desirable goal. Requirements
and a threat analysis for XMPP encryption are provided in [E2E-REQ].
Many possible approaches to meet those (or similar) requirements have
been proposed over the years, including methods based on PGP, S/MIME,
SIGMA, and TLS.
Most proposals have not been able to support multiple end-points for
a given recipient. As more devices support XMPP, it becomes more
desirable to allow an entity to communicate with another in a more
secure manner, regardless of the number of agents th entity is
employing. This document specifies an approach for encrypting
communications between two entities which each might have multiple
end-points.
2. Terminology
This document inherits terminology defined in [RFC6120].
Security-related terms are to be understood in the sense defined in
[RFC4949].
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Determining Support
If an agent supports end-to-end object encryption, it MUST advertiset
that fact in its responses to [XEP-0030] information ("disco#info")
requests by returning a feature of
"urn:ietf:params:xml:ns:xmpp-e2e:2:encrypt".
<iq xmlns='jabber:client'
id='disco1'
to='romeo@montegue.lit/garden'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2:encrypt'/>
</query>
</iq>
To help facilitate discovery, an agent SHOULD also include [XEP-0115]
Miller Expires December 23, 2012 [Page 3]
Internet-Draft XMPP E2E June 2012
information in any directed or broadcast presence updates.
4. Encrypting XMPP Stanzas
The process that a sending agent follows for securing stanzas is the
same regardless of the form of stanza (i.e., <iq/>, <message/>, or
<presence/>).
4.1. Prerequisites
First, the sending agent prepares and retains the following:
o The JID of the sender (i.e. its own JID). This SHOULD be the bare
JID (localpart@domainpart).
o The JID of the recipient. This SHOULD be the bare JID
(localpart@domainpart).
o A Content Master Key (CMK). The CMK MUST have a length at least
equal to that of the required encryption keys and MUST be
generated randomly. See [RFC4086] for considerations on
generating random values.
o A CMK identifier (CID). The CID MUST be unique for a given
(sender, recipient, CMK) tuple, and MUST NOT be derived from CMK
itself.
o Ensures the plaintext stanza is fully qualified, including the
proper namespace declarations (e.g. contains the attribute 'xmlns'
set to the value "jabber:client" for 'jabber:client' stanzas
defined in [RFC6120]).
4.2. Process
For a given plaintext stanza (S), the sending agent performs the
following:
1. Notes the current UTC date and time N when this stanza is
constructed, formatted as described under Section 7.
2. Constructs a forwarding envelope M using a <forwarded/> element
qualified by the "urn:xmpp:forward:0" namespace (as defined in
[XEP-0297]) as follows:
Miller Expires December 23, 2012 [Page 4]
Internet-Draft XMPP E2E June 2012
* The child element <delay/> qualified by the "urn:xmpp:delay"
namespace (as defined in [XEP-0203]) with the attribute
'stamp' set to the UTC date and time value N
* The plaintext stanza S
3. Convert the forwarding envelope M to a UTF-8 encoded string (M'),
optionallly removing line breaks and other insignificant
whitespace between elements and attributes, i.e. P' = UTF8-
encode(P). We call P' a "stanza-string" because for purposes of
encryption and decryption it is treated not as XML but as an
opaque string (this avoids the need for complex canonicalization
of the XML input).
4. Generates any additional unprotected block cipher factors (IV);
e.g. initialization vector/nonce. A sending agent MUST ensure
that no two sets of factors are used with the same CMK, and
SHOULD NOT reuse such factors for other stanzas.
5. Performs the message encryption steps from [JOSE-JWE] to generate
the JWE Header H, JWE Ciphertext C, and JWE Integrity Value I;
using the following inputs:
* The 'alg' property is set to "none"; recipients use 'keyreq'
in Section 6 to obtain the CMK.
* The 'enc' property is set to the intended content encryption
algorithm.
* CMK as the Content Master Key.
* M' as the plaintext content to encrypt.
6. Constructs an <e2e/> element qualified by the
"urn:ietf:params:xml:ns:xmpp-e2e:2" namespace as follows:
* The attribute 'id' set to the identifier value CID.
* The child element <header/> qualified by the
"urn:ietf:params:xml:ns:xmpp-e2e:2" namespace and with XML
character data as H, encoded base64url as per [RFC4684].
* The child element <data/> qualified by the
"urn:ietf:params:xml:ns:xmpp-e2e:2" namespace and with XML
character data as C, encoded base64url as per [RFC4684].
Miller Expires December 23, 2012 [Page 5]
Internet-Draft XMPP E2E June 2012
* The child element <mac/> qualified by the "urn"ietf:params:
xml:ns:xmpp-e2e:2" namespace and with XML character data as I,
encoded base64url as per [RFC4684].
7. Sends the <e2e/> element as the payload of a stanza that SHOULD
match the stanza from step 1 in kind (e.g., <message/>), type
(e.g., "chat"), and addressing (e.g. to="romeo@montague.net"
from="juliet@capulet.net/balcony"). If the original stanza (S)
has a value for the "id" attribute, this stanza MUST NOT use the
same value for its "id" attribute.
4.3. Example - Securing a Message
NOTE: unless otherwise indicated, all line breaks are included for
readability.
The sending agent begins with the plaintext version of the <message/>
stanza 'S':
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
to='romeo@montegue.lit/garden'
type='chat'>
<thread>35740be5-b5a4-4c4e-962a-a03b14ed92f4</thread>
<body>
But to be frank, and give it thee again.
And yet I wish but for the thing I have.
My bounty is as boundless as the sea,
My love as deep; the more I give to thee,
The more I have, for both are infinite.
</body>
</message>
and the following prerequisites:
o Sender JID as "juliet@capulet.lit"
o Recipient JID as "romeo@montegue.lit"
o Content master key 'CMK' as (base64 encoded)
"-ElMo6FndEkMxWP3TIkp1dDfVKqmqAAgrlcvVnUVpOc="
o CMK identifier CID as "835c92a8-94cd-4e96-b3f3-b2e75a438f92"
The sending agent performs steps 1 and 2 to generate the envelope:
Miller Expires December 23, 2012 [Page 6]
Internet-Draft XMPP E2E June 2012
<forwarded xmlns='urn:xmpp:forward:0'>
<delay xmlns='urn:xmpp:delay'
stamp='1492-05-12T20:07:37.012Z'/>
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
to='romeo@montegue.lit/garden'
type='chat'>
<thread>35740be5-b5a4-4c4e-962a-a03b14ed92f4</thread>
<body>
But to be frank, and give it thee again.
And yet I wish but for the thing I have.
My bounty is as boundless as the sea,
My love as deep; the more I give to thee,
The more I have, for both are infinite.
</body>
</message>
</forwarded>
Then the sending agent performs steps 3, 4, and 5 to generate the
[JOSE-JWE] outputs:
JWE Header
{
"alg":"none",
"enc":"A256CCM",
"iv":"B7waCj2vF_sLaJfe-1GHrA=="
}
JWE Ciphertext
7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO9YZ-jHl
1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41wqqVvV62gad_OB
Dd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzMEKqpVnPbYQDkWQNrtxPs2b
lE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftkRVDuiF1yVh2xNRPa-TQxDegZh1D_
u_c2mwPLO6ED_1ZlvL7075_VL0DT01YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx
9kjWjxLYNLLGxbMOtwF45OLCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICt
nLonaM1e5mRPnRgg5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL
74Xm4CtiJMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr
7TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBDMjrkXj
y7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_gE_HalWUL0HoqL
93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo-eCGP
NOTE: For CCM, the integrity value is encoded as part of the
ciphertext, therefore the resulting Integrity Value is an octet
string of length 0.
Then the sending agent performs steps 6 and 7, and sends the
Miller Expires December 23, 2012 [Page 7]
Internet-Draft XMPP E2E June 2012
following:
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='fJZd9WFIIwNjFctT'
to='romeo@montegue.lit/garden'
type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>
eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS
HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX
NpemUiOiIxNiJ9
</header>
<data>
7LlMXd-qqPAQ_LZm6u9AR2csyDgT09z5DWdn8K5GLr_qbWRDKw2ufZrmO
9YZ-jHl1IDeXeQ9azbNNViv8gpa-prDYkXOo3QoqYOJiA0RAkPU-UjN41
wqqVvV62gad_OBDd9q2xsNnK1PI5frIGTCZSexOIeSD3EcP0cDI_0MzME
KqpVnPbYQDkWQNrtxPs2blE15KcQXbHVxA9rEz7y0a-ITXruV_fOXGftk
RVDuiF1yVh2xNRPa-TQxDegZh1D_u_c2mwPLO6ED_1ZlvL7075_VL0DT0
1YGtDDQeyzrQWnQNEBJ4G5jFpCyqtCszbgx9kjWjxLYNLLGxbMOtwF45O
LCd8JFUIQAHoLeKp4aIWr5yp7aATX8dKvQm5_TFICtnLonaM1e5mRPnRg
g5zNeMErx6FFkqowOI1h7hVl_QHF8Ofoy99CmWKiVT3Nq5ngL74Xm4Cti
JMHnAEn2Q-10-fWuIHIEA0u4GwBaXo0ToBw4uCM4ZhG1SFSKyCKkjXmr7
TL-5jwSuuQHX6efS8Hhi7fujmqw9VXekeubsY2btl5put0SWT8_0S8ZBD
MjrkXjy7iI5NUOhQMms3ou1r01NZdzNVKcqiX5q3z1eB1FLWmGymnnj_g
E_HalWUL0HoqL93Fr1nfFLNhXLCZYhZ7By6T9NN8omp4ZYE92HMpPzgo-
eCGP
</data>
<mac/>
</e2e>
</message>
5. Decrypting XMPP Stanzas
5.1. Protocol Not Understood
If the receiving agent does not understand the protocol, it MUST do
one and only one of the following: (1) ignore the <e2e/> extension,
(2) ignore the entire stanza, or (3) return a <service-unavailable/>
error to the sender, as described in [RFC6120].
NOTE: If the inbound stanza is an <iq/>, the receiving agent MUST
return an error to the sending agent, to comply with the exchanging
of IQ stanzas in [RFC6121].
Miller Expires December 23, 2012 [Page 8]
Internet-Draft XMPP E2E June 2012
5.2. Process
Upon receipt of an encrypted stanza, the receiving agent performs the
following:
1. Determines if a valid CMK is available, associated with the CID
specified by the 'id' attribute value of the <e2e/>l; element
and the sending agent JID specified by the 'from' attribute of
the wrapping stanza. If the receiving agent does not already
have the CMK, it requests it according to Section 6.
2. Performs the message decryption steps from [JOSE-JWE] to generate
the plaintext forwarding envelope string M', using the following
inputs:
* The JWE Header H from the <header/> element's character data
content.
* The JWE Ciphertext C from the <data/> element's character data
content.
* The JWE Integrity Value I from the <mac/> element's character
data content.
3. Converts the forwarding envelope UTF-8 ecoded string M' into XML
element M.
4. Obtains the UTC date and time N from the <delay/> child element,
and verifies it is within the accepted range, as specified in
Section 7.
5. Obtains the plaintext stanza S, which is a child element node of
M; the stanza MUST be fully qualified with proper namespace
declarations for XMPP stanzas, to help distinguish it from other
content within M.
.
5.3. Insufficient Information
At step 1, if the receiving agent is unable to obtain the CMK, or the
receiving agent could not otherwise determine the additional
information, it MAY return a <bad-request/> error to the sending
agent (as described in [RFC6120]), optionally supplemented by an
application-specific error condition element of <insufficient-
information/>:
Miller Expires December 23, 2012 [Page 9]
Internet-Draft XMPP E2E June 2012
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='fJZd9WFIIwNjFctT'
to='romeo@montegue.lit/garden'
type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>[XML character data]</header>
<data>[XML character data]</header>
</e2e>
<error type='modify'>
<bad-request
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<insufficient-information
xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/>
</error>
</message>
In addition to returning an error, the receiving agent SHOULD NOT
present the stanza to the intended recipient (human or application)
and SHOULD provide some explicit alternate processing of the stanza
(which MAY be to display a message informing the recipient that it
has received a stanza that cannot be decrypted).
5.4. Failed Decryption
At step 2, if the receiving agent is unable to successfully decrypt
the stanza, the receiving agent SHOULD return a <bad-request/> error
to the sending agent (as described in [RFC6120]), optionally
supplemented by an application-specific error condition element of
<decryption-failed/> (previously defined in [RFC3923]):
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='fJZd9WFIIwNjFctT'
to='romeo@montegue.lit/garden'
type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>[XML character data]</header>
<data>[XML character data]</header>
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<decryption-failed xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/>
</error>
</message>
Miller Expires December 23, 2012 [Page 10]
Internet-Draft XMPP E2E June 2012
In addition to returning an error, the receiving agent SHOULD NOT
present the stanza to the intended recipient (human or application)
and SHOULD provide some explicit alternate processing of the stanza
(which MAY be to display a message informing the recipient that it
has received a stanza that cannot be decrypted).
5.5. Timestamp Not Acceptable
At step 4, if the stanza is successfully decrypted but the timestamp
fails the checks outlined in Section 7, the receiving agent MAY
return a <not-acceptable/> error to the sender (as described in
[RFC6120]), optionally supplemented by an application-specific error
condition element of <bad-timestamp/> (previously defined in
[RFC3923]):
<message xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='fJZd9WFIIwNjFctT'
to='romeo@montegue.lit/garden'
type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>[XML character data]</header>
<data>[XML character data]</header>
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<bad-timestamp xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/>
</error>
</message>
5.6. Successful Decryption
If the receiving agent successfully decrypted the payload, it MUST
NOT return a stanza error.
If the payload is an <iq/> of type "get" or "set", and the response
to this <iq/> is of type "error", the receiving agent MUST send the
encrypted response wrapped in an <iq/> of type "result", to prevent
exposing information about the payload.
6. Requesting Content Keys
Because of the dynamic nature of XMPP stanza routing, the protocol
does not exchange content keys as part of the encrypted stanza.
Instead, a separate content key protocol is used by receiving agents
to request a particular content key from the sending agent.
Miller Expires December 23, 2012 [Page 11]
Internet-Draft XMPP E2E June 2012
6.1. Request Process
Before a CMK can be requested, the receiving agent MUST have at least
one public key for which it also has the private key.
To request a CMK, the receiving agent performs the following:
1. Constructs a [JOSE-JWK] JWK Set (KS), containing information
about each public key the requesting agent wishes to use. Each
key SHOULD include a value for the property 'kid' which uniquely
identifies it within the context of all provided keys. Each key
MUST include a value for the property 'kid' if any two keys use
the same algorithm.
2. Constructs a <keyreq/> element qualified by the
"urn:ietf:params:xml:ns:xmpp-e2e:2" namespace as follows:
* The attribute 'id' set to the CMK identifier value CID.
* The child element <pkey/> qualified by the
"urn:ietf:params:xml:ns:xmpp-e2e:2" namespace and with XML
character data as KS, encoded base64url as pre [RFC4684].
3. Sends the <keyreq/> element as the payload of an <iq/> stanza
with the attribute 'type' set to "get", the attribute 'to' set to
the full JID of the original encrypted stanza's sender, and the
attribute 'id' set to an opaque string value the receiving agent
uses to track the <iq/> response.
6.2. Accept Process
If the sending agent approves the request, it performs the following:
1. Chooses a key (PK) from the keys provided via KS, and notes its
identifier value 'kid'.
2. Constructs a parial [JOSE-JWE] header (H) as follows:
* The property 'alg' set to the cryptographic algorithm for PK,
which is used to secure the content master key CMK.
* The property 'kid' set to the identifier matching PK.
NOTE: this header is intentionally lacking required attributes.
The receiving agent is responsible for assembling a final, valid
JWE header.
Miller Expires December 23, 2012 [Page 12]
Internet-Draft XMPP E2E June 2012
3. Encrypts the content master key CMK using the key PK, i.e. CMK'
= pki-encrypt(PK, CMK).
4. Constructs a <keyreq/> element qualified by the
"urn:ietf:params:xml:ns:xmpp-e2e:2" namespace as follows:
* The attribute 'id' set to the CMK identifier CID.
* The child element <header/> qualified by the
"urn:ietf:params:xml:ns:xmpp-e2e:2" namespace and with XML
character data as H, encoded base64url as per [RFC4684].
* The child element <cmk/> qualified by the
"urn:ietf:params:xml:ns:xmpp-e2e:2" namespace and with XML
character data as CMK', encoded base64url as per [RFC4684].
5. Sends the <keyreq/> element as the payload of an <iq/> stanza
with the attribute 'type' set to "result", the attribute 'to' set
to the full JID from the request <iq/>'s 'from' attribute, and
the attribute 'id' set to the value of the request <iq/>'s 'id'
attribute.
6.3. Error Conditions
If the sending agent does not approve of the request, it sends an
<iq/> stanza of type "error" and containing the reason for denying
the request:
o <forbidden/>: the key request is made by an entity that is not
authorized to decrypt stanzas from the sending agent and/or for
the indicated CID.
o <item-not-found/>: the requested CID is no longer valid.
o <not-acceptable/>: the key request did not contain any keys the
sending agent understands.
6.4. Example of Successful Key Request
NOTE: unless otherwise indicated, all line breaks are included for
readability.
To begin a key request, the receiving agent performs step 1 from
request process (Section 6.1) to generate the [JOSE-JWK]:
Miller Expires December 23, 2012 [Page 13]
Internet-Draft XMPP E2E June 2012
{
"keys": [{
"alg":"RSA-OAEP",
"mod":"AL7ano5DBdNYfKChGh3xxGDtAtozO3iEm20rzbNEjSLWFjuhm46S
XzeJXV8Nr6VUXcrJ8FN85OqNv0g9GAh9VoHriNECtZJzEw3TUl8e
dntXOAU8IZQPIh7rrU1pqQanrJ9RjWZqgd42LCTpFQWMAibZAfQD
2gb5NIrZUbYs4wn9Rx52ru5xkrcrIYLvPrK8Yv3fKwuU0y0gf809
Yunz_H8A5aHplzrQtFOuW8uT_tWR8Wn_2w_H6Y6bOoMEoHZGSjCQ
CNGzlmVrjKadp7amtMCwezXcW9iI63qIP7ObLAKEolw1XaLMEm6d
-mT_tZZwpNo_r2eKm4WhYOW2bYLfoME=",
"exp":"AQAB",
"kid":"romeo@montegue.lit/garden"
}]
}
Then the receiving agent performs step 2 to generate the <keyreq/>:
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<pkey>
W3siYWxnIjoiUlNBIiwibW9kIjoiQUw3YW5vNURCZE5ZZktDaEdoM3h4R0R
0QXRvek8zaUVtMjByemJORWpTTFdGanVobTQ2U1h6ZUpYVjhOcjZWVVhjck
o4Rk44NU9xTnYwZzlHQWg5Vm9IcmlORUN0Wkp6RXczVFVsOGVkbnRYT0FVO
ElaUVBJaDdyclUxcHFRYW5ySjlSaldacWdkNDJMQ1RwRlFXTUFpYlpBZlFE
MmdiNU5JclpVYllzNHduOVJ4NTJydTV4a3JjcklZTHZQcks4WXYzZkt3dVU
weTBnZjgwOVl1bnpfSDhBNWFIcGx6clF0Rk91Vzh1VF90V1I4V25fMndfSD
ZZNmJPb01Fb0haR1NqQ1FDTkd6bG1WcmpLYWRwN2FtdE1Dd2V6WGNXOWlJN
jNxSVA3T2JMQUtFb2x3MVhhTE1FbTZkLW1UX3RaWndwTm9fcjJlS200V2hZ
T1cyYllMZm9NRT0iLCJleHAiOiJBUUFCIiwia2lkIjoicm9tZW9AbW9udGV
ndWUubGl0L2dhcmRlbiJ9XQ==
</pkey>
</keyreq>
Then the receiving agent performs step 3 and sends the following:
Miller Expires December 23, 2012 [Page 14]
Internet-Draft XMPP E2E June 2012
<iq xmlns='jabber:client'
from='romeo@montegue.lit/garden'
id='xdJbWMA+'
to='juliet@capulet.lit/balcony'
type='get'>
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<pkey>
W3siYWxnIjoiUlNBIiwibW9kIjoiQUw3YW5vNURCZE5ZZktDaEdoM3h4R
0R0QXRvek8zaUVtMjByemJORWpTTFdGanVobTQ2U1h6ZUpYVjhOcjZWVV
hjcko4Rk44NU9xTnYwZzlHQWg5Vm9IcmlORUN0Wkp6RXczVFVsOGVkbnR
YT0FVOElaUVBJaDdyclUxcHFRYW5ySjlSaldacWdkNDJMQ1RwRlFXTUFp
YlpBZlFEMmdiNU5JclpVYllzNHduOVJ4NTJydTV4a3JjcklZTHZQcks4W
XYzZkt3dVUweTBnZjgwOVl1bnpfSDhBNWFIcGx6clF0Rk91Vzh1VF90V1
I4V25fMndfSDZZNmJPb01Fb0haR1NqQ1FDTkd6bG1WcmpLYWRwN2FtdE1
Dd2V6WGNXOWlJNjNxSVA3T2JMQUtFb2x3MVhhTE1FbTZkLW1UX3RaWndw
Tm9fcjJlS200V2hZT1cyYllMZm9NRT0iLCJleHAiOiJBUUFCIiwia2lkI
joicm9tZW9AbW9udGVndWUubGl0L2dhcmRlbiJ9XQ==
</pkey>
</keyreq>
</iq>
If the sending agent accepts this key request, it performs steps 1
and 2 from Section 6.2 to generate the partial [JOSE-JWE] header:
{
"alg":"RSA-OAEP",
"kid":"romeo@montegue.lit/garden"
}
Then the sending agent performs step 3 to generate the encrypted CMK:
DCKrJpLd8XYze7joNKsyvpzGD4MffVQF7apQMkPK8_vKx4J3xEqWB3tXxp6oxJF
4YHla4SFiMp44LccMEd6JchPp_23OXrBo8i7Fwo8jVH6QoQa71T_1rQj6CWQ1eF
vXiU4Qmp52F-gjuUhlKfe3qccdlFp3kLy8Mpq5mDdq6deOq0_qusqr8QTqrT5LN
IgsXYzrdiDdKx8KSKpI4FBB_H1x-A1C97DfJk9s5H7GzKVm2BRWVXWjJfO4lckE
Z45ZJkA3CKq86Yth3YBetoScPVLhoRoO2qqBg4gR9dDO5mXnOgPslVfXWvegexH
AyhHmJZsj3yV_pW1Rlb5jn5J4Rw==
Then the sending agent performs step 4 to generate the <keyreq/>
response:
Miller Expires December 23, 2012 [Page 15]
Internet-Draft XMPP E2E June 2012
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>
eyJhbGciOiJSU0EtT0VBUCIsImtpZCI6InJvbWVvQG1vbnRlZ3VlLmxpc3Q
vZ2FyZGVuIn0=
</header>
<cmk>
DCKrJpLd8XYze7joNKsyvpzGD4MffVQF7apQMkPK8_vKx4J3xEqWB3tXxp6
oxJF4YHla4SFiMp44LccMEd6JchPp_23OXrBo8i7Fwo8jVH6QoQa71T_1rQ
j6CWQ1eFvXiU4Qmp52F-gjuUhlKfe3qccdlFp3kLy8Mpq5mDdq6deOq0_qu
sqr8QTqrT5LNIgsXYzrdiDdKx8KSKpI4FBB_H1x-A1C97DfJk9s5H7GzKVm
2BRWVXWjJfO4lckEZ45ZJkA3CKq86Yth3YBetoScPVLhoRoO2qqBg4gR9dD
O5mXnOgPslVfXWvegexHAyhHmJZsj3yV_pW1Rlb5jn5J4Rw==
</cmk>
</keyreq>
Then the sending agent performs step 5 and sends the following:
<iq xmlns='jabber:client'
from='juliet@capulet.lit/balcony'
id='xdJbWMA+'
to='romeo@montegue.lit/garden'
type='result'>
<keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
<header>
eyJhbGciOiJSU0EtT0VBUCIsImtpZCI6InJvbWVvQG1vbnRlZ3VlLmxpc
3QvZ2FyZGVuIn0=
</header>
<cmk>
DCKrJpLd8XYze7joNKsyvpzGD4MffVQF7apQMkPK8_vKx4J3xEqWB3tXx
p6oxJF4YHla4SFiMp44LccMEd6JchPp_23OXrBo8i7Fwo8jVH6QoQa71T
_1rQj6CWQ1eFvXiU4Qmp52F-gjuUhlKfe3qccdlFp3kLy8Mpq5mDdq6de
Oq0_qusqr8QTqrT5LNIgsXYzrdiDdKx8KSKpI4FBB_H1x-A1C97DfJk9s
5H7GzKVm2BRWVXWjJfO4lckEZ45ZJkA3CKq86Yth3YBetoScPVLhoRoO2
qqBg4gR9dDO5mXnOgPslVfXWvegexHAyhHmJZsj3yV_pW1Rlb5jn5J4Rw
==
</cmk>
</keyreq>
</iq>
7. Inclusion and Checking of Timestamps
Timestamps are included to help prevent replay attacks. All
timestamps MUST conform to [XEP-0082] and be presented as UTC with no
offset, and SHOULD include the seconds and fractions of a second to
three digits. Absent a local adjustment to the sending agent's
Miller Expires December 23, 2012 [Page 16]
Internet-Draft XMPP E2E June 2012
perceived time or the underlying clock time, the sending agent MUST
ensure that the timestamps it sends to the receiver increase
monotonically (if necessary by incrementing the seconds fraction in
the timestamp if the clock returns the same time for multiple
requests). The following rules apply to the receiving agent:
o It MUST verify that the timestamp received is within five minutes
of the current time, except as described below for offline
messages.
o It SHOULD verify that the timestamp received is greater than any
timestamp received in the last 10 minutes which passed the
previous check.
o If any of the foregoing checks fails, the timestamp SHOULD be
presented to the receiving entity (human or application) marked as
"old timestamp", "future timestamp", or "decreasing timestamp",
and the receiving entity MAY return a stanza error to the sender.
The foregoing timestamp checks assume that the recipient is online
when the message is received. However, if the recipient is offline
then the server might store the message for delivery when the
recipient is next online (offline storage does not apply to <iq/> or
<presence/> stanzas, only <message/> stanzas). As described in
[XEP-0160], when sending an offline message to the recipient, the
server SHOULD include delayed delivery data as specified in
[XEP-0203] so that the recipient knows that this is an offline
message and also knows the original time of receipt at the server.
In this case, the recipient SHOULD verify that the timestamp received
in the encrypted message is within five minutes of the time stamped
by the recipient's server in the <delay/> element.
8. Interaction with Stanza Semantics
The following limitations and caveats apply:
o Undirected <presence/> stanzas SHOULD NOT be encrypted. Such
stanzas are delivered to anyone the sender has authorized, and can
generate a large volume of key requests.
o Stanzas directed to multiplexing services (e.g. multi-user chat)
SHOULD NOT be encrypted, unless the sender has established an
acceptable trust relationship with the multiplexing service.
Miller Expires December 23, 2012 [Page 17]
Internet-Draft XMPP E2E June 2012
9. Mandatory-to-Implement Cryptographic Algorithms
All algorithms that MUST be implemented for [JOSE-JWE] also MUST be
implemented for this specification.
10. Security Considerations
10.1. Storage of Encrypted Stanzas
The recipient's server might store any <message/> stanzas received
until the recipient is next available; this duration could be
anywhere from a few minutes to several months.
10.2. Re-use of Content Master Keys
A sender SHOULD NOT use the same CMK for stanzas intended for
different recipients, as determined by the localpart and domainpart
of the recipient's JID.
A sender MAY re-use a CMK for several stanzas to the same recpient.
In this case, the CID remains the same, but the sending agent MUST
generate a new IV for each encrypted stanza. The sender SHOULD
periodically generate a new CMK; however, this specification does not
mandate any specific algorithms or processes.
In the case of <message/> stanzas, a sending agent might generate a
new CMK each time it generates a new ThreadID, as outlined in
[XEP-0201].
11. IANA Considerations
11.1. XML Namespace Name for e2e Data in XMPP
A URN sub-namespace of encrypted content for the Extensible Messaging
and Presence Protocol (XMPP) is defined as follows.
URI: urn:ietf:params:xml:ns:xmpp-e2e:2
Specification: RFC XXXX
Description: This is an XML namespace name of encrypted content for
the Extensible Messaging and Presence Protocol as defined by RFC
XXXX.
Registrant Contact: IESG, <iesg@ietf.org>
12. References
Miller Expires December 23, 2012 [Page 18]
Internet-Draft XMPP E2E June 2012
12.1. Normative References
[E2E-REQ] Saint-Andre, P., "Requirements for End-to-End Encryption
in the Extensible Messaging and Presence Protocol (XMPP)",
draft-saintandre-xmpp-e2e-requirements-01 (work in
progress), March 2010.
[JOSE-JWE]
Jones, M., Rescola, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption-02
(work in progress), May 2012.
[JOSE-JWK]
Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key-02 (work in progress),
May 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4684] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 6121, March 2011.
[XEP-0030]
Eatmon, R., Hildebrand, J., Millard, P., and P. Saint-
Andre, "Service Discovery", XSF XEP 0030, June 2006.
[XEP-0082]
Saint-Andre, P., "XMPP Date and Time Profiles", XSF
XEP 0082, May 2003.
[XEP-0115]
Hildebrand, J., Troncon, R., and P. Saint-Andre, "Entity
Capabilities", XSF XEP 0115, February 2008.
[XEP-0203]
Saint-Andre, P., "Delayed Delivery", XSF XEP 0203,
September 2009.
Miller Expires December 23, 2012 [Page 19]
Internet-Draft XMPP E2E June 2012
[XEP-0297]
Wild, M. and K. Smith, "Message Forwarding", XSF XEP 0297,
July 2011.
12.2. Informative References
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
for the Extensible Messaging and Presence Protocol
(XMPP)", RFC 3923, October 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", RFC 4086, June 2005.
[XEP-0160]
Saint-Andre, P., "Best Practices for Handling Offline
Messages", XSF XEP 0160, January 2006.
[XEP-0201]
Saint-Andre, P., Paterson, I., and K. Smith, "Best
Practices for Message Threads", XSF XEP 0203,
November 2010.
Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e:2
The following XML schema is descriptive, not normative.
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e:2'
xmlns='urn:ietf:params:xml:ns:xmpp-e2e:2'
elementFormDefault='qualified'>
<xs:element name='e2e'>
<xs:complexType>
<xs:attribute name='id' type='xs:string' use='required'/>
<xs:sequence>
<xs:element ref='header' minOccurs='1' maxOccurs='1'/>
<xs:element ref='data' minOccurs='1' maxOccurs='1'/>
<xs:element ref='mac' minOccurs='1' maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='keyreq'>
<xs:complexType>
Miller Expires December 23, 2012 [Page 20]
Internet-Draft XMPP E2E June 2012
<xs:attribute name='id' type='xs:string' use='required'/>
<xs:sequence>
<xs:element ref='header' minOccurs='0' maxOccurs='1'/>
<xs:element ref='pkey' minOccurs='0' maxOccurs='1'/>
<xs:element ref='cmk' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='cmk'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='data'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='header'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='mac'>
<xs:complexType>
<xs:simpleType>
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='pkey'>
<xs:complexType>
<xs:simpleType>
Miller Expires December 23, 2012 [Page 21]
Internet-Draft XMPP E2E June 2012
<xs:extension base='xs:string'>
</xs:extension>
</xs:simpleType>
</xs:complexType>
</xs:element>
<xs:element name='bad-timestamp' type='empty'/>
<xs:element name='decryption-failed' type='empty'/>
<xs:element name='insufficient-information' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Author's Address
Matthew Miller
Cisco Systems, Inc.
1899 Wyknoop Street, Suite 600
Denver, CO 80202
USA
Phone: +1-303-308-3204
Email: mamille2@cisco.com
Miller Expires December 23, 2012 [Page 22]