[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 05 06 07

Network Working Group                                          M. Miller
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                        January 10, 2013
Expires: July 14, 2013


 End-to-End Object Encryption for the Extensible Messaging and Presence
                            Protocol (XMPP)
                        draft-miller-xmpp-e2e-03

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 July 14, 2013.

Copyright Notice

   Copyright (c) 2013 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 July 14, 2013                 [Page 1]


Internet-Draft                  XMPP E2E                    January 2013


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  . . . . . . . . . . . . . . . . . . .  9
     5.1.  Protocol Not Understood  . . . . . . . . . . . . . . . . .  9
     5.2.  Process  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.3.  Insufficient Information . . . . . . . . . . . . . . . . . 11
     5.4.  Failed Decryption  . . . . . . . . . . . . . . . . . . . . 11
     5.5.  Timestamp Not Acceptable . . . . . . . . . . . . . . . . . 12
     5.6.  Successful Decryption  . . . . . . . . . . . . . . . . . . 13
   6.  Requesting Session Keys  . . . . . . . . . . . . . . . . . . . 13
     6.1.  Request Process  . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Accept Process . . . . . . . . . . . . . . . . . . . . . . 14
     6.3.  Error Conditions . . . . . . . . . . . . . . . . . . . . . 14
     6.4.  Example of Successful Key Request  . . . . . . . . . . . . 15
   7.  Inclusion and Checking of Timestamps . . . . . . . . . . . . . 17
   8.  Interaction with Stanza Semantics  . . . . . . . . . . . . . . 18
   9.  Mandatory-to-Implement Cryptographic Algorithms  . . . . . . . 19
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     10.1. Storage of Encrypted Stanzas . . . . . . . . . . . . . . . 19
     10.2. Re-use of Session Master Keys  . . . . . . . . . . . . . . 19
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
     11.1. XML Namespace Name for e2e Data in XMPP  . . . . . . . . . 19
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     12.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Appendix A.  Schema for urn:ietf:params:xml:ns:xmpp-e2e:4  . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24

















Miller                    Expires July 14, 2013                 [Page 2]


Internet-Draft                  XMPP E2E                    January 2013


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 the 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 XMPP-related terminology from [RFC6120], JSON
   Web Algorithms (JWA)-related terminology from [JOSE-JWA], JSON Web
   Encryption (JWE)-related terminology from [JOSE-JWE], and JSON Web
   Key (JWK)-related terminology from [JOSE-JWK].  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:4".

   <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:4'/>
       ...
     </query>



Miller                    Expires July 14, 2013                 [Page 3]


Internet-Draft                  XMPP E2E                    January 2013


   </iq>

   To help facilitate discovery, an agent SHOULD also include [XEP-0115]
   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 Session Master Key (SMK).  The SMK MUST have a length at least
      equal to that required by the key wrapping algorithm in use and
      MUST be generated randomly.  See [RFC4086] for considerations on
      generating random values.

   o  A SMK identifier (SID).  The SID MUST be unique for a given
      (sender, recipient, SMK) tuple, and MUST NOT be derived from SMK
      itself.


4.2.  Process

   For a given plaintext stanza (S), the sending agent performs the
   following:

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

   2.  Notes the current UTC date and time N when this stanza is
       constructed, formatted as described under Section 7.

   3.  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 July 14, 2013                 [Page 4]


Internet-Draft                  XMPP E2E                    January 2013


       *  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

   4.  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.  M' = UTF8-
       encode(M).  We call M' 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).

   5.  Generates a Content Master Key (CMK).  The CMK MUST have a length
       at least equal to that required by the content encryption
       algorithm in use and MUST be generated randomly.  See [RFC4086]
       for considerations on generating random values.

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

   7.  Performs the message encryption steps from [JOSE-JWE] to generate
       the JWE Header H, JWE Encrypted Key E, JWE Ciphertext C, and JWE
       Integrity Value I; using the following inputs:

       *  The 'alg' property is set to an appropriate key wrapping
          algorithm (e.g.  "A256KW" or "A128KW"); recipients use
          'keyreq' in Section 6 to obtain the SMK.

       *  The 'enc' property is set to the intended content encryption
          algorithm.

       *  SMK as the key for CMK Encryption.

       *  CMK as the JWE Content Master Key.

       *  IV as the JWE Initialization Vector.

       *  M' as the plaintext content to encrypt.

   8.  Constructs an <e2e/> element qualified by the
       "urn:ietf:params:xml:ns:xmpp-e2e:4" namespace as follows:






Miller                    Expires July 14, 2013                 [Page 5]


Internet-Draft                  XMPP E2E                    January 2013


       *  The attribute 'id' set to the identifier value SID.

       *  The child element <header/> qualified by the
          "urn:ietf:params:xml:ns:xmpp-e2e:4" 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:4" namespace and with XML
          character as E, encoded base64url as per [RFC4684].

       *  The child element <iv/> qualified by the
          "urn:ietf:params:xml:ns:xmpp-e2e:4" namespace and with XML
          character as IV, encoded base64url as per [RFC4684].

       *  The child element <data/> qualified by the
          "urn:ietf:params:xml:ns:xmpp-e2e:4" namespace and with XML
          character data as C, encoded base64url as per [RFC4684].

       *  The child element <mac/> qualified by the "urn"ietf:params:
          xml:ns:xmpp-e2e:4" namespace and with XML character data as I,
          encoded base64url as per [RFC4684].

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














Miller                    Expires July 14, 2013                 [Page 6]


Internet-Draft                  XMPP E2E                    January 2013


   <message xmlns='jabber:client'
            from='juliet@capulet.lit/balcony'
            to='romeo@montegue.lit'
            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/balcony"

   o  Recipient JID as "romeo@montegue.lit"

   o  Session Master Key 'SMK' as (base64 encoded)
      "xWtdjhYsH4Va_9SfYSefsJfZu03m5RrbXo_UavxxeU8="

   o  SMK identifier SID as "835c92a8-94cd-4e96-b3f3-b2e75a438f92"


   The sending agent performs steps 1, 2, and 3 to generate the
   envelope:

   <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'
              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 4 through 7 (with Content
   Master Key as "-ElMo6FndEkMxWP3TIkp1dDfVKqmqAAgrlcvVnUVpOc=", base64



Miller                    Expires July 14, 2013                 [Page 7]


Internet-Draft                  XMPP E2E                    January 2013


   encoded) to generate the [JOSE-JWE] outputs:

   JWE Header

   {
     "alg":"A256KW",
     "enc":"A256CCM",
     "kid":"835c92a8-94cd-4e96-b3f3-b2e75a438f92"
   }

   JWE Content Encryption Key

   XvySjpkqv6m-hUrG2VSEwIM9wZqVcdP037trOMpqFbK_i2AvHLqiNA

   JWE Initialization Vector

   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 [RFC3610], 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 8 and 9, and sends the
   following:













Miller                    Expires July 14, 2013                 [Page 8]


Internet-Draft                  XMPP E2E                    January 2013


   <message xmlns='jabber:client'
            from='juliet@capulet.lit/balcony'
            id='fJZd9WFIIwNjFctT'
            to='romeo@montegue.lit'
            type='chat'>
     <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e:4'
          id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
       <header>
         eyJlbmMiOiJBMjU2Q0NNIiwiaXYiOiJCN3dhQ2oydkZfc0xhSmZlLTFHS
         HJBPT0iLCJhZGF0YSI6IjQ5Mi0wNS0xMlQyMDowNzozNy4wMTJaIiwibX
         NpemUiOiIxNiJ9
       </header>
       <cmk>
         XvySjpkqv6m-hUrG2VSEwIM9wZqVcdP037trOMpqFbK_i2AvHLqiNA
       </cmk>
       <iv>
         B7waCj2vF_sLaJfe-1GHrA
       </iv>
       <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



Miller                    Expires July 14, 2013                 [Page 9]


Internet-Draft                  XMPP E2E                    January 2013


   return an error to the sending agent, to comply with the exchanging
   of IQ stanzas in [RFC6121].

5.2.  Process

   Upon receipt of an encrypted stanza, the receiving agent performs the
   following:
   1.  Determines if a valid SMK is available, associated with the SID
       specified by the 'id' attribute value of the <e2e/&gtl; 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 Content Encryption Key from the <cmk/> element's
          character data content.

       *  The JWE Initialization Vector/Nonce from the <iv/> 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.

       .






Miller                    Expires July 14, 2013                [Page 10]


Internet-Draft                  XMPP E2E                    January 2013


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/>:

   <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:4'
          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:4'/>
     </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]):











Miller                    Expires July 14, 2013                [Page 11]


Internet-Draft                  XMPP E2E                    January 2013


   <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:4'
          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:4'/>
     </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.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:4'
          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:4'/>
     </error>
   </message>





Miller                    Expires July 14, 2013                [Page 12]


Internet-Draft                  XMPP E2E                    January 2013


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 Session Keys

   Because of the dynamic nature of XMPP stanza routing, the protocol
   does not exchange session keys as part of the encrypted stanza.
   Instead, a separate protocol is used by receiving agents to request a
   particular session key from the sending agent.

6.1.  Request Process

   Before a SMK can be requested, the receiving agent MUST have at least
   one public key for which it also has the private key.

   To request a SMK, 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:4" namespace as follows:

       *  The attribute 'id' set to the SMK identifier value SID.

       *  The child element <pkey/> qualified by the
          "urn:ietf:params:xml:ns:xmpp-e2e:4" 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.





Miller                    Expires July 14, 2013                [Page 13]


Internet-Draft                  XMPP E2E                    January 2013


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

       *  The property 'kid' set to the identifier matching PK.


   3.  Encrypts the content master key SMK using the key PK, i.e.  SMK'
       = pki-encrypt(PK, SMK).

   4.  Constructs a <keyreq/> element qualified by the
       "urn:ietf:params:xml:ns:xmpp-e2e:4" namespace as follows:

       *  The attribute 'id' set to the SMK identifier SID.

       *  The child element <header/> qualified by the
          "urn:ietf:params:xml:ns:xmpp-e2e:4" 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:4" namespace and with XML
          character data as SMK', 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 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 SID.




Miller                    Expires July 14, 2013                [Page 14]


Internet-Draft                  XMPP E2E                    January 2013


   o  <item-not-found/>: the requested SID 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
   Section 6.1 to generate the [JOSE-JWK]:

   {
     "keys": [{
       "alg":"RSA-OAEP",
       "mod":"vtqejkMF01h8oKEaHfHEYO0C2jM7eISbbSvNs0SNItYWO6GbjpJf
       N4ldXw2vpVRdysnwU3zk6o2_SD0YCH1WgeuI0QK1knMTDdNSXx52e1c4BTw
       hlA8iHuutTWmpBqesn1GNZmqB3jYsJOkVBYwCJtkB9APaBvk0itlRtizjCf
       1HHnau7nGStyshgu8-srxi_d8rC5TTLSB_zT1i6fP8fwDloemXOtC0U65by
       5P-1ZHxaf_bD8fpjps6gwSgdkZKMJAI0bOWZWuMpp2ntqa0wLB7Ndxb2Ijr
       eog_s5ssAoSiXDVdoswSbp36ZP-1lnCk2j-vZ4qbhaFg5bZtgt-gwQ==",
       "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:4'
           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 July 14, 2013                [Page 15]


Internet-Draft                  XMPP E2E                    January 2013


   <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:4'
             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 SMK:

   DsLfaD3ZPtE4k1wnhsHNsYyFi3spey8NNNMeYQ6L-sdLJrcWIwfOYNPK-Sb
   oLvsSiXB7yw1MLtKhhrAiRovEmMnTgoLvcuzX8PIBcDbSP3ie0aMynXqStb
   Rk-LwijdSY7NqD_WB1tP4dhqo3OwlXf4bSWlBnUDEzGh8giF6KYeRzw181m
   vMIJ6BCjwnvqTKBNlMDUX3cTfXSAFi9j8MkkS3wLbc2MM4RzP4ESyiZZQJn
   z_zkg1enjAbJ_fpwJ-E4a14EyWhwYpCNW3Tb5IhyhhgBsiLB6kulm9RMYwc
   TCGIDCUsfTo5vzDOKX7DBF6KtwSY8bF1AiOiGlsGo2SlrSg==

   Then the sending agent performs step 4 to generate the <keyreq/>
   response:










Miller                    Expires July 14, 2013                [Page 16]


Internet-Draft                  XMPP E2E                    January 2013


   <keyreq xmlns='urn:ietf:params:xml:ns:xmpp-e2e:4'
           id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
     <header>
       eyJhbGciOiJSU0EtT0VBUCIsImtpZCI6InJvbWVvQG1vbnRlZ3VlLmxpc3Q
       vZ2FyZGVuIn0=
     </header>
     <smk>
       DsLfaD3ZPtE4k1wnhsHNsYyFi3spey8NNNMeYQ6L-sdLJrcWIwfOYNPK-Sb
       oLvsSiXB7yw1MLtKhhrAiRovEmMnTgoLvcuzX8PIBcDbSP3ie0aMynXqStb
       Rk-LwijdSY7NqD_WB1tP4dhqo3OwlXf4bSWlBnUDEzGh8giF6KYeRzw181m
       vMIJ6BCjwnvqTKBNlMDUX3cTfXSAFi9j8MkkS3wLbc2MM4RzP4ESyiZZQJn
       z_zkg1enjAbJ_fpwJ-E4a14EyWhwYpCNW3Tb5IhyhhgBsiLB6kulm9RMYwc
       TCGIDCUsfTo5vzDOKX7DBF6KtwSY8bF1AiOiGlsGo2SlrSg==
     </smk>
   </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:4'
             id='835c92a8-94cd-4e96-b3f3-b2e75a438f92'>
       <header>
         eyJhbGciOiJSU0EtT0VBUCIsImtpZCI6InJvbWVvQG1vbnRlZ3VlLmxpc
         3QvZ2FyZGVuIn0=
       </header>
       <smk>
         DsLfaD3ZPtE4k1wnhsHNsYyFi3spey8NNNMeYQ6L-sdLJrcWIwfOYNPK-
         SboLvsSiXB7yw1MLtKhhrAiRovEmMnTgoLvcuzX8PIBcDbSP3ie0aMynX
         qStbRk-LwijdSY7NqD_WB1tP4dhqo3OwlXf4bSWlBnUDEzGh8giF6KYeR
         zw181mvMIJ6BCjwnvqTKBNlMDUX3cTfXSAFi9j8MkkS3wLbc2MM4RzP4E
         SyiZZQJnz_zkg1enjAbJ_fpwJ-E4a14EyWhwYpCNW3Tb5IhyhhgBsiLB6
         kulm9RMYwcTCGIDCUsfTo5vzDOKX7DBF6KtwSY8bF1AiOiGlsGo2SlrSg
         ==
       </smk>
     </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 July 14, 2013                [Page 17]


Internet-Draft                  XMPP E2E                    January 2013


   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 July 14, 2013                [Page 18]


Internet-Draft                  XMPP E2E                    January 2013


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 Session Master Keys

   A sender SHOULD NOT use the same SMK for stanzas intended for
   different recipients, as determined by the localpart and domainpart
   of the recipient's JID.

   A sender MAY re-use a SMK for several stanzas to the same recipient.
   In this case, the SID remains the same, but the sending agent MUST
   generate a new CMK and IV for each encrypted stanza.  The sender
   SHOULD periodically generate a new SMK; however, this specification
   does not mandate any specific algorithms or processes.

   In the case of <message/> stanzas, a sending agent might generate a
   new SMK 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:4
   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 July 14, 2013                [Page 19]


Internet-Draft                  XMPP E2E                    January 2013


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-JWA]
              Jones, M., "JSON Web Algorithms (JWA)",
              draft-ietf-jose-json-web-algorithms-08 (work in progress),
              December 2012.

   [JOSE-JWE]
              Jones, M., Rescola, E., and J. Hildebrand, "JSON Web
              Encryption (JWE)", draft-ietf-jose-json-web-encryption-08
              (work in progress), December 2012.

   [JOSE-JWK]
              Jones, M., "JSON Web Key (JWK)",
              draft-ietf-jose-json-web-key-08 (work in progress),
              December 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



Miller                    Expires July 14, 2013                [Page 20]


Internet-Draft                  XMPP E2E                    January 2013


              Capabilities", XSF XEP 0115, February 2008.

   [XEP-0203]
              Saint-Andre, P., "Delayed Delivery", XSF XEP 0203,
              September 2009.

   [XEP-0297]
              Wild, M. and K. Smith, "Stanza Forwarding", XSF XEP 0297,
              July 2012.

12.2.  Informative References

   [RFC3610]  Whiting, D., Housley, R., and N. Ferguson, "Counter with
              CBC-MAC (CCM)", RFC 3923, September 2003.

   [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:4

   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:4'
       xmlns='urn:ietf:params:xml:ns:xmpp-e2e:4'
       elementFormDefault='qualified'>

     <xs:element name='e2e'>
       <xs:complexType>
         <xs:attribute name='id' type='xs:string' use='required'/>
         <xs:sequence>



Miller                    Expires July 14, 2013                [Page 21]


Internet-Draft                  XMPP E2E                    January 2013


           <xs:element ref='header' minOccurs='1' maxOccurs='1'/>
           <xs:element ref='cmk' minOccurs='1' maxOccurs='1'/>
           <xs:element ref='iv' 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>
         <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='smk' 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='iv'>
       <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'>



Miller                    Expires July 14, 2013                [Page 22]


Internet-Draft                  XMPP E2E                    January 2013


       <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>
           <xs:extension base='xs:string'>
           </xs:extension>
         </xs:simpleType>
       </xs:complexType>
     </xs:element>

     <xs:element name='smk'>
       <xs:complexType>
         <xs:simpleType>
           <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>





Miller                    Expires July 14, 2013                [Page 23]


Internet-Draft                  XMPP E2E                    January 2013


Author's Address

   Matthew Miller
   Cisco Systems, Inc.
   1899 Wynkoop Street, Suite 600
   Denver, CO  80202
   USA

   Phone: +1-303-308-3204
   Email: mamille2@cisco.com









































Miller                    Expires July 14, 2013                [Page 24]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/