One document matched: draft-miller-3923bis-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-miller-3923bis-00" ipr="trust200902" obsoletes="3923">
<front>
<title abbrev="XMPP E2E">End-to-End Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco</organization>
<address>
<email>mamille2@cisco.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<date day="1" month="March" year="2010"/>
<area>Applications</area>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<abstract>
<t>This document defines a method of end-to-end object encryption for the Extensible Messaging and Presence Protocol (XMPP). The protocol defined herein is a simplified version of the protocol defined in RFC 3923.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>End-to-end encryption of traffic sent over the Extensible Messaging and Presence Protocol <xref target='XMPP-CORE'/> is a desirable goal. Requirements and a threat analysis for XMPP encryption are provided in <xref target='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.</t>
<t>The S/MIME approach defined in RFC 3923 has never been implemented in XMPP clients to the best of our knowledge, but has some attractive features, especially the ability to store-and-forward an encrypted message at a user's server if the user is not online when the message is received (in the XMPP community this is called "offline storage" and the message is referred to as an "offline message"). The authors surmise that RFC 3923 has not been implemented mainly because it adds several new dependencies to XMPP clients, especially MIME (along with the CPIM and MSGFMT media types). Therefore this document explores the possibility of an approach that is similar to but simpler than RFC 3923, but that retains the same basic object encryption model.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits terminology defined in <xref target="XMPP-CORE"/>.</t>
<t>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 <xref target="TERMS">BCP 14, RFC 2119</xref>.</t>
</section>
<section title='Securing XMPP Stanzas' anchor='stanza'>
<t>The process a sending agent follows for securing stanzas is very similar regardless of the form of stanza (i.e., <iq/>, <message/>, or <presence/>).</t>
<t><list style="numbers">
<t>Constructs a cleartext version of the stanza, S.</t>
<t>Notes the current UTC date and time N when this stanza is constructed, formatted as per <xref target="DATETIME"/> and always including the seconds (resulting in a datetime string 20 characters in length).</t>
<t>Converts the stanza to a UTF-8 encoded string, optionally removing line breaks and other insignificant whitespace between elements and attributes, i.e., UTF8-encode(S) = S'. We call S' a "stanza-string" because for purposes of encryption and decryption it is not treated as XML but as an opaque string (this avoids the need for complex canonicalization of the XML input).</t>
<t>Creates a Message Authentication Code "M" for the stanza-string S' using <xref target="HMAC"/>. The algorithm is SHA256 and the sender's public key (R) is the secret. The input to HMAC-SHA256 MUST be the timestamp from step 2 (conforming to <xref target='DATETIME'/> and always including seconds) appended by the cleartext sanza-string S', as follows:
<figure>
<artwork><![CDATA[
HMAC-SHA256( SHA256(R), UTF8-encode(N+S') )
]]></artwork>
</figure></t>
<t>Prepends M (which will be 32 octets in length) to the stanza-string S' to create a bytestring B.</t>
<t>Encrypts the bytestring B using the recipient's public key to produce encrypted data T. (Note: This step is under-specified and will be expanded in the next version of this document.)</t>
<t>Base64-encodes T to produce the encrypted data T'.</t>
<t>Constructs an <e2e/> element qualified by the "urn:ietf:params:xml:ns:xmpp-objenc" namespace, with the attribute 'stamp' set to the timestamp N from step 2, and with the XML character data as T' from step 7.</t>
<t>Sends the <e2e/> element as the payload of a stanza that matches the stanza from step 1 in both kind (e.g., <message/>) and type (e.g., "chat").</t>
</list></t>
<section title='Example of Securing Messages' anchor="message">
<t>The sender begins with the cleartext version of the <message/> stanza "S":</t>
<figure>
<artwork><![CDATA[
<message xmlns='jabber:client'
from='juliet@capulet.net/balcony'
id='183ef129'
to='romeo@montegue.net'
type='chat'>
<thread>8996aef0-061d-012d-347a-549a200771aa</thread>
<body>Wherefore art thou, Romeo?</body>
</message>
]]></artwork>
</figure>
<t>The Message Authentication Code is constructed from (line endings are included only for the sake of readability):</t>
<figure>
<artwork><![CDATA[
2010-02-28T18:00:00Z<message xmlns='jabber:client'
from='juliet@capulet.net/balcony' id='183ef129'
to='romeo@montegue.net' type='chat'><thread>
8996aef0-061d-012d-347a-549a200771aa</thread>
<body>Wherefore art thou, Romeo?</body></message>
]]></artwork>
</figure>
<t>The sender then performs the steps from above, and sends the following:</t>
<figure>
<artwork><![CDATA[
<message xmlns='jabber:client'
from='juliet@capulet.net/balcony'
id='6410ed123'
to='romeo@montegue.net'
type='chat'>
<thread>460f0da0-0628-012d-347b-549a200771aa</thread>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-objenc'
stamp='2010-02-28T18:00:00Z'>
oOb/huFlvC17+XxZdye4BAj4jN2yWiSQZts7BctqZB+wo1tCfHE0w
BMQlof4\nC7KLn6+ktILqX6k5/IgQrwGF0hxKjFk44R01RcVmzlUS
0HaSEIQVQk/3r33c\n3/NKzN8Cq+yzZKfP/p3KkpHMixCUTEe7B38
Eu9h5hfs8PgXkb/GAdw7Ea/qW\nQgRjYcNl7jcplYY/FQQTEEfQoc
fKCbm/RaOsRSMnqGjkqGGt6+yQGWtvzSS2\nHD4/EHGV62IGz/sQH
5cAvloA9LqfiNh/oEm/UD2iLTAVj1BBS+WJZqMRznAJ\nNM4gF8vF
nDdLAMyeMZedlrHCS4lp6PzeblDD0Jk2HQ==
</e2e>
</message>
]]></artwork>
</figure>
<t>NOTE: The sender SHOULD include a <thread/> with each chat to maintain conversation continuity.</t>
</section>
</section>
<section title="Handling of Inbound Stanzas" anchor="inbound">
<t>Several scenarios are possible when an entity receives an encrypted stanza:</t>
<t><list style='hanging'>
<t hangText='Case #1:'>The receiving application does not understand the protocol.</t>
<t hangText='Case #2:'>The receiving application understands the protocol and is able to decrypt the payload.</t>
<t hangText='Case #3:'>The receiving application understands the protocol and is able to decrypt the payload, but the timestamps fail the checks specified under <xref target="timestamps">Checking of Timestamps</xref>.</t>
<t hangText='Case #4:'>The receiving application understands the protocol but is unable to decrypt the payload.</t>
</list></t>
<t>In Case #1, the receiving application 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 <xref target="XMPP-CORE"/>.</t>
<t>In Case #2, the receiving application MUST NOT return a stanza error to the sender, since this is the success case.</t>
<t>In Case #3, the receiving application MAY return a <not-acceptable/> error to the sender (as described in <xref target="XMPP-CORE"/>), optionally supplemented by an application-specific error condition element <bad-timestamp/> as shown below:</t>
<figure>
<artwork><![CDATA[
<message from='romeo@example.net/orchard' type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-objenc'>
XML-character-data-here
</e2e>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<bad-timestamp xmlns='urn:ietf:params:xml:xmpp-e2e'/>
</error>
</message>
]]></artwork>
</figure>
<t>In Case #4, the receiving application SHOULD return a <bad-request/> error to the sender (as described in <xref target="XMPP-CORE"/>), optionally supplemented by an application-specific error condition element <decryption-failed/> as shown below:</t>
<figure>
<artwork><![CDATA[
<message from='romeo@example.net/orchard' type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-objenc'>
XML-character-data-here
</e2e>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<decryption-failed xmlns='urn:ietf:params:xml:xmpp-e2e'/>
</error>
</message>
]]></artwork>
</figure>
<t>In addition to returning an error in Case #4 the receiving application 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).</t>
</section>
<section title="Inclusion and Checking of Timestamps" anchor="timestamps">
<t>Timestamps are included to help prevent replay attacks. All timestamps MUST conform to <xref target='DATETIME'/> and be presented as UTC with no offset, including fractions of a second as appropriate. Absent a local adjustment to the sending agent's 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 application:</t>
<t><list style="symbols">
<t>It MUST verify that the timestamp received is within five minutes of the current time, except as described below for offline messages.</t>
<t>It SHOULD verify that the timestamp received is greater than any timestamp received in the last 10 minutes which passed the previous check.</t>
<t>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.</t>
</list></t>
<t>The foregoing checks assume that the recipient is online when the message is received. However, if the recipient is offline then the server will probably 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 <xref target='OFFLINE'/>, when sending an offline message to the recipient, the server SHOULD include delayed delivery data as specified in <xref target='DELAY'/> 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.</t>
</section>
<section title="Mandatory-to-Implement Cryptographic Algorithms" anchor="mti">
<t>All implementations MUST support the following algorithms. Implementations MAY support other algorithms as well.</t>
<t><list style='symbols'>
<t>The RSA (PKCS #1 v1.5) key transport, as specified in <xref target="CMS-ALG"/> section 4.2.1.</t>
<t>The AES-128 encryption algorithm in CBC mode, as specified in <xref target="CMS-AES"/>.</t>
<t>The SHA-256 hashing algorithm, as specified in <xref target='X509-ALGO'/>.</t>
</list></t>
</section>
<section title="Certificates" anchor="certs">
<t>To participate in end-to-end encryption using the methods defined in this document, a client needs to possess an X.509 certificate. It is expected that many clients will generate their own (self-signed) certificates rather than obtain a certificate issued by a certification authority (CA). In any case the certificate MUST include an XMPP address that is represented using the ASN.1 Object Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of <xref target="XMPP-CORE"/>.</t>
</section>
<section title='Security Considerations' anchor='security'>
<t>To follow.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<section title="XML Namespace Name for e2e Data in XMPP" anchor="iana-ns-e2e">
<t>A URN sub-namespace of signed and encrypted content for the Extensible Messaging and Presence Protocol (XMPP) is defined as follows.</t>
<t><list style='hanging'>
<t hangText='URI:'>urn:ietf:params:xml:ns:xmpp-objenc</t>
<t hangText='Specification:'>RFC XXXX</t>
<t hangText='Description:'>This is an XML namespace name of signed and encrypted content for the Extensible Messaging and Presence Protocol as defined by RFC XXXX.</t>
<t hangText='Registrant Contact:'>IESG, <iesg@ietf.org></t>
</list></t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='CMS-AES'>
<front>
<title>Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)</title>
<author initials='J.' surname='Schaad' fullname='J. Schaad'>
<organization /></author>
<date year='2003' month='July' /></front>
<seriesInfo name='RFC' value='3565' />
<format type='TXT' octets='26773' target='ftp://ftp.isi.edu/in-notes/rfc3565.txt' />
</reference>
<reference anchor='CMS-ALG'>
<front>
<title>Cryptographic Message Syntax (CMS) Algorithms</title>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<date month='August' year='2002' />
</front>
<seriesInfo name='RFC' value='3370' />
<format type='TXT' octets='51001' target='ftp://ftp.isi.edu/in-notes/rfc3370.txt' />
</reference>
<reference anchor='DATETIME'>
<front>
<title>Date and Time on the Internet: Timestamps</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'>
<organization /></author>
<author initials='C.' surname='Newman' fullname='C. Newman'>
<organization /></author>
<date month='July' year='2002' /></front>
<seriesInfo name='RFC' value='3339' />
<format type='TXT' octets='35064' target='ftp://ftp.isi.edu/in-notes/rfc3339.txt' />
</reference>
<reference anchor='E2E-REQ'>
<front>
<title>Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='June' day='29' year='2009' />
<abstract><t>This document describes requirements for end-to-end encryption in the Extensible Messaging and Presence Protocol (XMPP).</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-saintandre-xmpp-e2e-requirements-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-e2e-requirements-01.txt' />
</reference>
<reference anchor='TERMS'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>-</email>
</address>
</author>
<date month='March' year='1997'></date>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
<list>
<t>The 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 RFC 2119.</t>
</list>
</t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
</reference>
<reference anchor='X509-ALGO'>
<front>
<title>Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</title>
<author initials='J.' surname='Jonsson' fullname='J. Jonsson'>
<organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'>
<organization /></author>
<date year='2003' month='February' />
<abstract>
<t>This memo represents a republication of PKCS #1 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='3447' />
<format type='TXT' octets='143173' target='ftp://ftp.isi.edu/in-notes/rfc3447.txt' />
</reference>
<reference anchor='XMPP-CORE'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization>Jabber Software Foundation</organization>
</author>
<date year='2004' month='October' />
</front>
<seriesInfo name='RFC' value='3920' />
<format type='TXT' octets='194313' target='ftp://ftp.isi.edu/in-notes/rfc3920.txt' />
</reference>
</references>
<references title="Informative References">
<reference anchor="DELAY">
<front>
<title>Delayed Delivery</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="15" month="September" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0203"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0203.html"/>
</reference>
<reference anchor="HMAC">
<front>
<title>The Keyed-Hash Message Authentication Code (HMAC): Federal Information Processing Standards Publication 198</title>
<author/>
</front>
</reference>
<reference anchor="OFFLINE">
<front>
<title>Best Practices for Handling Offline Messages</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="24" month="January" year="2006"/>
</front>
<seriesInfo name="XSF XEP" value="0160"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0160.html"/>
</reference>
</references>
<section title="Schema for urn:ietf:params:xml:ns:xmpp-objenc" anchor="schemas-e2e">
<t>The following XML schema is descriptive, not normative.</t>
<figure>
<artwork><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-objenc'
xmlns='urn:ietf:params:xml:ns:xmpp-objenc'
elementFormDefault='qualified'>
<xs:element name='e2e' type='xs:string'/>
<xs:element name='decryption-failed' type='empty'/>
<xs:element name='bad-timestamp' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:36:19 |