idnits 2.17.1
draft-miller-xmpp-e2e-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (July 4, 2014) is 3578 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Downref: Normative reference to an Informational draft:
draft-saintandre-xmpp-e2e-requirements (ref. 'E2E-REQ')
== Outdated reference: A later version (-40) exists of
draft-ietf-jose-json-web-algorithms-11
== Outdated reference: A later version (-40) exists of
draft-ietf-jose-json-web-encryption-11
== Outdated reference: A later version (-41) exists of
draft-ietf-jose-json-web-key-11
== Outdated reference: A later version (-41) exists of
draft-ietf-jose-json-web-signature-11
== Outdated reference: A later version (-02) exists of
draft-miller-jose-jwe-protected-jwk-00
** Downref: Normative reference to an Informational RFC: RFC 4949
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0030'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0082'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0115'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0203'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0297'
Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 XMPP M. Miller
3 Internet-Draft Cisco Systems, Inc.
4 Intended status: Standards Track C. Wallace
5 Expires: January 5, 2015 Red Hound Software, Inc.
6 July 4, 2014
8 End-to-End Object Encryption and Signatures for the Extensible Messaging
9 and Presence Protocol (XMPP)
10 draft-miller-xmpp-e2e-07
12 Abstract
14 This document defines two methods for securing objects (often
15 referred to as stanzas) for the Extensible Messaging and Presence
16 Protocol (XMPP), which allows for efficient asynchronous
17 communication between two entities, each with might have multiple
18 devices operating simultaneously. One is a method to encrypt stanzas
19 to provide confidentiality protection; another is a method to sign
20 stanzas to provide authentication and integrity protection. This
21 document also defines a related protocol for entities to request the
22 ephemeral session keys in use.
24 Status of This Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on January 5, 2015.
41 Copyright Notice
43 Copyright (c) 2014 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
60 3. Changes to existing clients . . . . . . . . . . . . . . . . . 4
61 3.1. End-point procedures . . . . . . . . . . . . . . . . . . 4
62 3.2. End-point state . . . . . . . . . . . . . . . . . . . . . 5
63 4. Key distribution . . . . . . . . . . . . . . . . . . . . . . 6
64 5. Key table . . . . . . . . . . . . . . . . . . . . . . . . . . 8
65 6. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 10
66 6.1. Determining Support . . . . . . . . . . . . . . . . . . . 10
67 6.2. Encrypting XMPP Stanzas . . . . . . . . . . . . . . . . . 10
68 6.2.1. Prerequisites . . . . . . . . . . . . . . . . . . . . 10
69 6.2.2. Process . . . . . . . . . . . . . . . . . . . . . . . 11
70 6.3. Decrypting XMPP Stanzas . . . . . . . . . . . . . . . . . 13
71 6.3.1. Protocol Not Understood . . . . . . . . . . . . . . . 13
72 6.3.2. Process . . . . . . . . . . . . . . . . . . . . . . . 13
73 6.3.3. Insufficient Information . . . . . . . . . . . . . . 15
74 6.3.4. Failed Decryption . . . . . . . . . . . . . . . . . . 15
75 6.3.5. Timestamp Not Acceptable . . . . . . . . . . . . . . 16
76 6.3.6. Successful Decryption . . . . . . . . . . . . . . . . 17
77 6.4. Example - Securing a Message . . . . . . . . . . . . . . 17
78 7. Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 21
79 7.1. Determining Support . . . . . . . . . . . . . . . . . . . 21
80 7.2. Signing XMPP Stanzas . . . . . . . . . . . . . . . . . . 22
81 7.2.1. Process . . . . . . . . . . . . . . . . . . . . . . . 22
82 7.3. Verifying Signed XMPP Stanzas . . . . . . . . . . . . . . 24
83 7.3.1. Protocol Not Understood . . . . . . . . . . . . . . . 24
84 7.3.2. Process . . . . . . . . . . . . . . . . . . . . . . . 24
85 7.3.3. Insufficient Information . . . . . . . . . . . . . . 25
86 7.3.4. Failed Verification . . . . . . . . . . . . . . . . . 26
87 7.3.5. Timestamp Not Acceptable . . . . . . . . . . . . . . 26
88 7.3.6. Successful Verification . . . . . . . . . . . . . . . 27
89 7.4. Example - Signing a Message . . . . . . . . . . . . . . . 27
90 8. Requesting Session Keys . . . . . . . . . . . . . . . . . . . 30
91 8.1. Request Process . . . . . . . . . . . . . . . . . . . . . 30
92 8.2. Accept Process . . . . . . . . . . . . . . . . . . . . . 31
93 8.3. Error Conditions . . . . . . . . . . . . . . . . . . . . 33
94 8.4. Example of Successful Key Request . . . . . . . . . . . . 34
95 9. Mulitple Operations . . . . . . . . . . . . . . . . . . . . . 38
96 10. Inclusion and Checking of Timestamps . . . . . . . . . . . . 38
97 11. Interaction with Stanza Semantics . . . . . . . . . . . . . . 39
98 12. Interaction with Offline Storage . . . . . . . . . . . . . . 40
99 13. Mandatory-to-Implement Cryptographic Algorithms . . . . . . . 40
100 14. Security Considerations . . . . . . . . . . . . . . . . . . . 40
101 14.1. Storage of Encrypted Stanzas . . . . . . . . . . . . . . 40
102 14.2. Re-use of Session Master Keys . . . . . . . . . . . . . 40
103 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
104 15.1. XML Namespaces Name for e2e Data in XMPP . . . . . . . . 41
105 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
106 16.1. Normative References . . . . . . . . . . . . . . . . . . 42
107 16.2. Informative References . . . . . . . . . . . . . . . . . 43
108 Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e:6 . . . . 43
109 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 46
110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
112 1. Introduction
114 End-to-end protection and authentication of traffic sent over the
115 Extensible Messaging and Presence Protocol [RFC6120] is a desirable
116 goal. Requirements and a threat analysis for XMPP encryption are
117 provided in [E2E-REQ]. Many possible approaches to meet those (or
118 similar) requirements have been proposed over the years, including
119 methods based on PGP, S/MIME, SIGMA, and TLS.
121 Most proposals have not been able to support multiple end-points for
122 a given recipient. As more devices support XMPP, it becomes more
123 desirable to allow an entity to communicate with another in a more
124 secure manner, regardless of the number of agents the entity is
125 employing. This document specifies an approach for encrypting and
126 signing communications between two entities which each might have
127 multiple end-points.
129 A primary challenge with supporting multiple end-points is key
130 distribution. This is complicated by the fact that some end points
131 for a given recipient may share keys, some may use different keys,
132 some may have no keys and some may not support encryption or
133 signature verification at all. To address these differences, this
134 specification defines a symmetric key table that is managed via three
135 mechanisms that enable a key to be pushed to an end point, to be
136 pulled from an originator or negotiated. The key table contains
137 named master keys along with meta data describing usage of the key.
138 Encrypted XMPP messages use a named master key to encrypt a content
139 encryption key. Prior to decrypting a message, recipients of an
140 encrypted message will either find the named key present in their key
141 table (as the result of an earlier operation) or obtain the key from
142 the sender.
144 Comments are solicited and should be addressed to XMPP mailing list.
145 Information about the XMPP mailing list can be found here:
146 https://www.ietf.org/mailman/listinfo/xmpp.
148 2. Terminology
150 This document inherits XMPP-related terminology from [RFC6120], JSON
151 Web Algorithms (JWA)-related terminology from [JOSE-JWA], JSON Web
152 Encryption (JWE)-related terminology from [JOSE-JWE], and JSON Web
153 Key (JWK)-related terminology from [JOSE-JWK]. Security-related
154 terms are to be understood in the sense defined in [RFC4949].
156 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
157 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
158 "OPTIONAL" in this document are to be interpreted as described in
159 [RFC2119].
161 3. Changes to existing clients
163 3.1. End-point procedures
165 Existing XMPP clients will need to implement some new procedures in
166 order to support end-to-end encryption and authentication. Changes
167 for sending clients include:
169 o Generating session master keys (SMKs)
171 o Storing SMKs for use during active sessions
173 o Storing SMKs to provide to peers and to support reading of saved
174 messages (may require use of storage key)
176 o Accepting requests for SMKs
178 o Releasing SMKs to authorized requestors (where requests may be
179 received from multiple different resources associated with a
180 single peer with each resource using a different means to
181 authenticate)
183 o Generating content encryption keys (CEK)
185 o Using SMK and CEK values to encrypt XMPP stanzas
187 o Generating a signing key (optional)
189 o Using a signing key to sign XMPP stanzas
191 o Generating and using a long term storage key (optional)
192 Changes for receiving clients include:
194 o Sending requests for SMKs to peers
196 o Accepting public key to use when encrypting an SMK from peers
198 o Storing SMKs for use when decrypting XMPP stanzas during active
199 session
201 o Using an SMK to decrypt a CEK used to decrypt XMPP stanzas
203 o Storing SMKs retrieved from peers to support reading of saved
204 messages (may require use of storage key)
206 o Providing indication to users when encryption is in use
208 o Retrieving keys required to verify signatures on signed XMPP
209 stanzas
211 o Verifying signatures and displaying indication of success/failure
212 to user
214 o Storing keys required to verify signature to support reading of
215 saved messages (may require use of storage key)
217 o Generating and using a long term storage key (optional)
219 3.2. End-point state
221 End points utilizing end-to-end encryption and signatures are
222 required to maintain some new state information, and may find some
223 additional information helpful to maintain. New state information
224 includes:
226 o Session master key table (required)
228 o Public/private key store (required)
230 o Trust anchor store (optional)
232 o Intermediate certification authority (CA) store (optional)
234 o Long-term storage key (optional)
236 Session master keys (SMKs) are used to encrypt XMPP stanzas. An end-
237 point may have many active SMKs at any given point in time, but only
238 one SMK active per bare JID (TODO: or should this be per full JID?).
239 Each SMK has a name generated by the entity who generated the key.
241 The name MUST be unique from the generator's perspective (i.e., full
242 JID + SMK name MUST uniquely identify a specific SMK). When a new
243 SMK is received, any previous SMK stored for the full JID of the
244 entity providing the SMK may be destroyed. Alternatively, previous
245 SMKs may be preserved to support future decryption of stored
246 messages. This specification places no requirements on handling of
247 stored messages. Clients may re-encrypt messages under a long-term
248 storage key, store messages as-is encrypted using an SMK or store
249 plaintext messages.
251 Each end-point must have at least one public/private key pair used
252 for SMK distribution.
254 A trust anchor store or intermediate CA store may be useful to
255 support automated release of encrypted SMKs or to verify signed XMPP
256 stanzas.
258 A long-term storage key may be used to either encrypt data stored in
259 the key table or to re-encrypt encrypted messages prior to storing
260 the message for future review.
262 4. Key distribution
264 Several different types of keys are used to support end-to-end
265 encryption and signatures. These keys may be distinct from any keys
266 used to authenticate to XMPP servers and include the following:
268 o Session master key (SMK)
270 o Content encryption keys (CEKs) for XMPP stanzas
272 o Public/private key pair for SMK distribution
274 o Content encryption keys for SMK distribution
276 o Public/private key pair for signature generation
278 o Trust anchor and intermediate certification authority (CA) public
279 keys
281 o Long-term storage key
283 SMKs are symmetric keys generated by an end-point prior to utilizing
284 end-to-end encryption (see Section 6.2.1). SMKs are used to encrypt
285 the CEK used to encrypt an XMPP stanza. SMKs are stored in the SMK
286 table and may be distributed using one of the following mechanisms:
288 o Manually pre-placed at some point prior to using end-to-end
289 encryption
291 o Released to an end-point upon request after receiving an encrypted
292 XMPP stanza
294 o Provided to an end-point using an IQ stanza sent prior to sending
295 encrypted XMPP stanzas
297 CEKs for XMPP stanzas are symmetric keys generated by an end-point to
298 encrypt an XMPP stanza (see item 5 in Section 6.2.2). CEKs are
299 encrypted using the SMK and included with encrypted XMPP data.
301 Public/private key pairs for SMK distribution are asymmetric keys
302 that may be generated by an end point, imported into an end point or
303 used via a hardware cryptographic module. The public key is
304 distributed to XMPP peers for use when distributing SMKs (see step 1
305 in Section 8.1). The public key is formatted as a JWK, which may
306 include an X.509 certificate. An end-point MUST establish trust in a
307 public key prior to releasing an SMK value. Trust establishment
308 mechanisms include checking a key thumbprint provided via a trusted
309 channel or by validating an X.509 certificate to a trust anchor. The
310 public keys may be distributed using one of the following mechanisms:
312 o Manually pre-placed prior to using for SMK release (details for
313 manual pre-placement are not defined by this specification)
315 o Presented when requesting an SMK from a peer after receiving an
316 encrypted XMPP stanza from the peer (the peer may store the public
317 key for use in providing future encrypted SMK values prior to
318 using the SMK to encrypt XMPP stanzas see Section 8.1)
320 o Provided upon request in response to an IQ get request in
321 preparation for receiving encrypted XMPP stanzas (TODO: define IQ
322 for pushing SMK)
324 CEKs for SMK distribution are symmetric keys generated by an end-
325 point to encrypt an SMK (see item 3 in Section 8.2). CEKs are
326 encrypted using the public key used for SMK distribution and included
327 with encrypted SMK data.
329 Public/private key pairs for SMK distribution are asymmetric keys
330 that may be generated by an end point, imported into an end point or
331 used via a hardware cryptographic module (see bullet 4 of section 5.1
332 in [JOSE-JWE]). The public key is distributed to XMPP peers for use
333 when verifying signatures. Trust establishment may be performed by
334 checking a key thumbprint provided via a trusted channel or by
335 validating an X.509 certificate to a trust anchor.
337 Trust anchor and intermediate CA public keys may be used to validate
338 X.509 certificates in support of SMK release or verification of
339 signatures on signed XMPP stanzas.
341 A long-term storage key may be used to encrypt information stored in
342 the key table or to re-encrypt encrypted messages prior to storing
343 the message for future review. The long-term storage key may be a
344 public/private key pair or a symmetric key.
346 5. Key table
348 The conceptual database for long-lived cryptographic keys described
349 in [Key-Table] may be suitable for use in storing the SMKs described
350 above for use in supporting end-to-end XMPP encryption. The columns
351 that the table consists of are listed as follows:
353 TODO: figure out whether to read time values from JWKs. If so,
354 augment section 8.2.
356 AdminKeyName: The AdminKeyName field contains a human-readable
357 string meant to identify the key for the user. Implementations
358 can use this field to uniquely identify rows in the key table.
359 The same string can be used on the local system and peer
360 systems, but this is not required.
362 LocalKeyName: The LocalKeyName field contains a string identifying
363 the key. It can be used to retrieve the key in the local
364 database when received in a message. For SMKs, this is the
365 value of the 'id' attribute value of the element (see
366 Section 6.3).
368 PeerKeyName: PeerKeyName is not used as the name is the same at each
369 end point.
371 Peers: This field lists the full JID of each peer systems that has
372 this key in their database. The peer name is read from the
373 'from' attribute of the wrapping stanza (see Section 6.3).
375 Interfaces: This field is not used and must be set to "all".
377 Protocol: The Protocol field identifies XMPP the protocol where this
378 key may be used to provide cryptographic protection. (TODO:
379 registry entry for the protocol?)
381 ProtocolSpecificInfo: This field is not used and must be be empty.
383 KDF: The KDF field is not used and must be set to "none". (TODO:
384 define a use for this field?)
386 AlgID: The AlgID field indicates which cryptographic algorithm to be
387 used with the security protocol for the specified peer or
388 peers. Such an algorithm can be an encryption algorithm and
389 mode (e.g., AES-128-CBC), an authentication algorithm (e.g.,
390 HMAC-SHA1-96 or AES-128-CMAC), or any other symmetric
391 cryptographic algorithm needed by a security protocol. (TODO:
392 identify source for algorithm strings)
394 Key: The Key field contains a long-lived symmetric cryptographic key
395 in the format of a lower-case hexadecimal string. The size of
396 the Key depends on the KDF and the AlgID. For instance, a
397 KDF=none and AlgID=AES128 requires a 128-bit key, which is
398 represented by 32 hexadecimal digits.
400 Direction: The Direction field indicates whether this key may be
401 used for inbound traffic, outbound traffic, both, or whether
402 the key has been disabled and may not currently be used at all.
403 The supported values are "in", "out", "both", and "disabled",
404 respectively.
406 SendLifetimeStart: The SendLifetimeStart field specifies the
407 earliest date and time in Coordinated Universal Time (UTC) at
408 which this key should be considered for use when sending
409 traffic. The format is YYYYMMDDHHSSZ, where four digits
410 specify the year, two digits specify the month, two digits
411 specify the day, two digits specify the hour, two digits
412 specify the minute, and two digits specify the second. The "Z"
413 is included as a clear indication that the time is in UTC.
415 SendLifeTimeEnd: The SendLifeTimeEnd field specifies the latest date
416 and time at which this key should be considered for use when
417 sending traffic. The format is the same as the
418 SendLifetimeStart field.
420 AcceptLifeTimeStart: The AcceptLifeTimeStart field specifies the
421 earliest date and time in Coordinated Universal Time (UTC) at
422 which this key should be considered for use when processing
423 received traffic. The format is YYYYMMDDHHSSZ, where four
424 digits specify the year, two digits specify the month, two
425 digits specify the day, two digits specify the hour, two digits
426 specify the minute, and two digits specify the second. The "Z"
427 is included as a clear indication that the time is in UTC.
429 AcceptLifeTimeEnd: The AcceptLifeTimeEnd field specifies the latest
430 date and time at which this key should be considered for use
431 when processing the received traffic. The format of this field
432 is identical to the format of AcceptLifeTimeStart.
434 6. Encryption
436 6.1. Determining Support
438 If an agent supports receiving end-to-end object encryption, it MUST
439 advertise that fact in its responses to [XEP-0030] information
440 ("disco#info") requests by returning a feature of
441 "urn:ietf:params:xml:ns:xmpp-e2e:6:encryption".
443
447
448 ...
449
450 ...
451
452
454 To facilitate discovery, an agent SHOULD also include [XEP-0115]
455 information in any directed or broadcast presence updates.
457 6.2. Encrypting XMPP Stanzas
459 The process that a sending agent follows for securing stanzas is the
460 same regardless of the form of stanza (i.e., , , or
461 ).
463 6.2.1. Prerequisites
465 First, the sending agent prepares and retains the following:
467 o The JID of the sender (i.e. its own JID). This SHOULD be the bare
468 JID (localpart@domainpart).
470 o The JID of the recipient. This SHOULD be the bare JID
471 (localpart@domainpart).
473 o A Session Master Key (SMK). The SMK MUST have a length at least
474 equal to that required by the key wrapping algorithm in use and
475 MUST be generated randomly. See [RFC4086] for considerations on
476 generating random values.
478 o A SMK identifier (SID). The SID MUST be unique for a given
479 (sender, recipient, SMK) tuple, and MUST NOT be derived from SMK
480 itself.
482 6.2.2. Process
484 For a given plaintext stanza (S), the sending agent performs the
485 following:
487 1. Ensures the plaintext stanza is fully qualified, including the
488 proper namespace declarations (e.g., contains the attribute
489 'xmlns' set to the value "jabber:client" for 'jabber:client'
490 stanzas defined in [RFC6120]).
492 2. Notes the current UTC date and time (N) when this stanza is
493 constructed, formatted as described under Section 10.
495 3. Constructs a forwarding envelope (M) using a element
496 qualified by the "urn:xmpp:forward:0" namespace (as defined in
497 [XEP-0297]) as follows:
499 * The child element qualified by the "urn:xmpp:delay"
500 namespace (as defined in [XEP-0203]) with the attribute
501 'stamp' set to the UTC date and time value N
503 * The plaintext stanza S
505 4. Converts the forwarding envelope (M) to a UTF-8 encoded string
506 (M'), optionally removing line breaks and other insignificant
507 whitespace between elements and attributes, i.e. M' =
508 UTF8-encode(M). We call M' a "stanza-string" because for
509 purposes of encryption and decryption it is treated not as XML
510 but as an opaque string (this avoids the need for complex
511 canonicalization of the XML input).
513 5. Generates a Content Master Key (CMK). The CMK MUST have a length
514 at least equal to that required by the content encryption
515 algorithm in use and MUST be generated randomly. See [RFC4086]
516 for considerations on generating random values.
518 6. Generates any additional unprotected block cipher factors (IV);
519 e.g., initialization vector/nonce. A sending agent MUST ensure
520 that no two sets of factors are used with the same CMK, and
521 SHOULD NOT reuse such factors for other stanzas.
523 7. Performs the message encryption steps from [JOSE-JWE] to generate
524 the JWE Header (H), JWE Encrypted Key (E), JWE Ciphertext (C),
525 and JWE Integrity Value (I); using the following inputs:
527 * The 'alg' property is set to an appropriate key wrapping
528 algorithm (e.g., "A256KW" or "A128KW"); recipients use the key
529 request process in Section 8 to obtain the SMK.
531 * The 'enc' property is set to the intended content encryption
532 algorithm.
534 * SMK as the key for CMK Encryption.
536 * CMK as the JWE Content Master Key.
538 * IV as the JWE Initialization Vector.
540 * M' as the plaintext content to encrypt.
542 8. Constructs an element qualified by the
543 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace as follows:
545 * The attribute 'type' set to the value "enc".
547 * The attribute 'id' set to the identifier value SID.
549 * The child element qualified by the
550 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
551 character data as H, encoded base64url as per [RFC4648].
553 * The child element qualified by the
554 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
555 character as E, encoded base64url as per [RFC4648].
557 * The child element qualified by the
558 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
559 character as IV, encoded base64url as per [RFC4648].
561 * The child element qualified by the
562 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
563 character data as C, encoded base64url as per [RFC4648].
565 * The child element qualified by the
566 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
567 character data as I, encoded base64url as per [RFC4648].
569 9. Sends the element as the payload of a stanza that SHOULD
570 match the stanza from step 1 in kind (e.g., ), type
571 (e.g., "chat"), and addressing (e.g., to="romeo@montague.net"
572 from="juliet@capulet.net/balcony"). If the original stanza (S)
573 has a value for the 'id' attribute, this stanza MUST NOT use the
574 same value for its 'id' attribute.
576 6.3. Decrypting XMPP Stanzas
578 6.3.1. Protocol Not Understood
580 If the receiving agent does not understand the protocol, it MUST do
581 one and only one of the following: (1) ignore the extension,
582 (2) ignore the entire stanza, or (3) return a
583 error to the sender, as described in [RFC6120].
585 NOTE: If the inbound stanza is an , the receiving agent MUST
586 return an error to the sending agent, to comply with the exchanging
587 of IQ stanzas in [RFC6121].
589 6.3.2. Process
591 Upon receipt of an encrypted stanza, the receiving agent performs the
592 following:
594 1. Determines if a valid SMK is available, associated with the SID
595 specified by the 'id' attribute value of the element and
596 the sending agent JID specified by the 'from' attribute of the
597 wrapping stanza. If the receiving agent does not already have
598 the SMK, it requests it according to Section 8.
600 2. Performs the message decryption steps from [JOSE-JWE] to generate
601 the plaintext forwarding envelope string M', using the following
602 inputs:
604 * The JWE Header (H) from the element's character
605 data content.
607 * The JWE Encrypted Key (E) from the element's character
608 data content.
610 * The JWE Initialization Vector/Nonce (I) from the
611 element's character data content.
613 * The JWE Ciphertext (C) from the element's character
614 data content.
616 * The JWE Integrity Value (I) from the element's
617 character data content.
619 3. Converts the forwarding envelope UTF-8 encoded string M' into XML
620 element (M).
622 4. Obtains the UTC date and time (N) from the child
623 element, and verifies it is within the accepted range, as
624 specified in Section 10.
626 5. Obtains the plaintext stanza (S), which is a child element node
627 of M; the stanza MUST be fully qualified with proper namespace
628 declarations for XMPP stanzas, to help distinguish it from other
629 content within M.
631 .
633 6.3.3. Insufficient Information
635 At step 1, if the receiving agent is unable to obtain the CMK, or the
636 receiving agent could not otherwise determine the additional
637 information, it MAY return a error to the sending
638 agent (as described in [RFC6120]), optionally supplemented by an
639 application-specific error condition element of :
642
647
649 [XML character data]
650 [XML character data]
651 [XML character data]
652 [XML character data]
653 [XML character data]
654
655
656
658
660
661
663 In addition to returning an error, the receiving agent SHOULD NOT
664 present the stanza to the intended recipient (human or application)
665 and SHOULD provide some explicit alternate processing of the stanza
666 (which MAY be to display a message informing the recipient that it
667 has received a stanza that cannot be decrypted).
669 6.3.4. Failed Decryption
671 At step 2, if the receiving agent is unable to successfully decrypt
672 the stanza, the receiving agent SHOULD return a error
673 to the sending agent (as described in [RFC6120]), optionally
674 supplemented by an application-specific error condition element of
675 (previously defined in [RFC3923]):
677
682
684 [XML character data]
685 [XML character data]
686 [XML character data]
687 [XML character data]
688 [XML character data]
689
690
691
692
693
694
696 In addition to returning an error, the receiving agent SHOULD NOT
697 present the stanza to the intended recipient (human or application)
698 and SHOULD provide some explicit alternate processing of the stanza
699 (which MAY be to display a message informing the recipient that it
700 has received a stanza that cannot be decrypted).
702 6.3.5. Timestamp Not Acceptable
704 At step 4, if the stanza is successfully decrypted but the timestamp
705 fails the checks outlined in Section 10, the receiving agent MAY
706 return a error to the sender (as described in
707 [RFC6120]), optionally supplemented by an application-specific error
708 condition element of (previously defined in
709 [RFC3923]):
711
716
718 [XML character data]
719 [XML character data]
720 [XML character data]
721 [XML character data]
722 [XML character data]
723
724
725
726
727
728
730 6.3.6. Successful Decryption
732 If the receiving agent successfully decrypted the payload, it MUST
733 NOT return a stanza error.
735 If the payload is an of type "get" or "set", and the response
736 to this is of type "error", the receiving agent MUST send the
737 encrypted response wrapped in an of type "result", to prevent
738 exposing information about the payload.
740 6.4. Example - Securing a Message
742 NOTE: unless otherwise indicated, all line breaks are included for
743 readability.
745 The sending agent begins with the plaintext version of the
746 stanza 'S':
748
752 35740be5-b5a4-4c4e-962a-a03b14ed92f4
753
754 But to be frank, and give it thee again.
755 And yet I wish but for the thing I have.
756 My bounty is as boundless as the sea,
757 My love as deep; the more I give to thee,
758 The more I have, for both are infinite.
759
760
762 and the following prerequisites:
764 o Sender JID as "juliet@capulet.lit/balcony"
766 o Recipient JID as "romeo@montegue.lit"
768 o Session Master Key (SMK) as (base64 encoded)
769 "xWtdjhYsH4Va_9SfYSefsJfZu03m5RrbXo_UavxxeU8"
771 o SMK identifier (SID) as "835c92a8-94cd-4e96-b3f3-b2e75a438f92"
773 The sending agent performs steps 1, 2, and 3 from Section 6.2.2 to
774 generate the envelope:
776
777
779
783 35740be5-b5a4-4c4e-962a-a03b14ed92f4
784
785 But to be frank, and give it thee again.
786 And yet I wish but for the thing I have.
787 My bounty is as boundless as the sea,
788 My love as deep; the more I give to thee,
789 The more I have, for both are infinite.
790
791
792
794 Then the sending agent performs steps 4 through 7 (with Content
795 Master Key as "LViSXX0Jx-I3v1zY1-KcGeivmWKuq0QE_71ywQGU6OhlM2NoQo1zHi
796 77zI3ieIUh7Wb1S3kXmNily0_FZoIG7A", base64url encoded) to generate the
797 [JOSE-JWE] outputs:
799 JWE Header
801 {
802 "alg":"A256KW",
803 "enc":"A256CBC+HS512",
804 "kid":"835c92a8-94cd-4e96-b3f3-b2e75a438f92"
805 }
807 JWE Encrypted Key
809 2tsmGH-WQdBxxJEs3d6LB2ovK6e1_9C1ogizJ9c6OvLmC6IeilHZ2Mimq2AElgI
810 ploz0VQv5LOH9ST93WvvhVzMHSfx0Cwl0
812 JWE Initialization Vector
814 ncOH4MsHT9HlJxnirx4qwg
815 JWE Ciphertext
817 FkFc4xGTVkjn7ojtS0SUY8IWfqsQKEIAlvLaBKieqVX1PAlq1ZjPp4TZC2I2eh7
818 01Lef3iRuNZd1nlgP2aREyHYCpE3FAelUoVG90B1FrJMnDUKAka7eb6GImamWPf
819 9onV-m5-GcUpejO9f1oPi-rwHzp475UPdAeKq5Z4zds8yXhQP-XyJbCPTtM-UQC
820 2-_q-3EKBHC4jM3qWDxVJ0JbIif3fCVRowzJh4AOB84YrfvkgUjMItqQPg2H6QB
821 NqGUspLI634lM8R-mhGciDZX2Jh_nKoXLAf5GCnvL9PlI7OdFqocPBIIPpjNrgX
822 _Z4PFjeq7ILx98GhVkryLYU9HVOFPCYci-lF9nfw1geliLfkoj5QZyi4J2SOtYa
823 O_zPmQvCXaUREqPf5UDAlgvc50a4ByYnNbkWSbhZ5Z388s8ELzPSE9XypdgP-1c
824 SyRke7V8iGe4eHNsm01TgWILYOFK4mYAM52OTitJxmQtmRp6izY5ZFdH9f_WdoB
825 1RXmGEZydvL-estcjx5ghsV3gktedIl0HA4R_M_N5TFIwv7hiisyRLi2aQtyFbE
826 7pZ6Oz-cYsLc4qFfXbb13U9a2-Byul8hm_E2b3m4GMhmsCiROm-uht9Ek4h9BIx
827 FhDKPr-htOXc93-uQNZlAQfkITAKlJfQ
829 JWE Integrity Value
831 Aj8lKdPMDE4U82UAhDJBaRrl3USmuzS2hfFOe_OBEv8
833 Then the sending agent performs steps 8 and 9, and sends the
834 following:
836
841
844
845 eyJhbGciOiJBMjU2S1ciLCJlbmMiOiJBMjU2Q0JDK0hTNTEyIiwia2lkI
846 joiODM1YzkyYTgtOTRjZC00ZTk2LWIzZjMtYjJlNzVhNDM4ZjkyIn0
847
848
849 2tsmGH-WQdBxxJEs3d6LB2ovK6e1_9C1ogizJ9c6OvLmC6IeilHZ2Mimq
850 2AElgIploz0VQv5LOH9ST93WvvhVzMHSfx0Cwl0
851
852
853 ncOH4MsHT9HlJxnirx4qwg
854
855
856 FkFc4xGTVkjn7ojtS0SUY8IWfqsQKEIAlvLaBKieqVX1PAlq1ZjPp4TZC
857 2I2eh701Lef3iRuNZd1nlgP2aREyHYCpE3FAelUoVG90B1FrJMnDUKAka
858 7eb6GImamWPf9onV-m5-GcUpejO9f1oPi-rwHzp475UPdAeKq5Z4zds8y
859 XhQP-XyJbCPTtM-UQC2-_q-3EKBHC4jM3qWDxVJ0JbIif3fCVRowzJh4A
860 OB84YrfvkgUjMItqQPg2H6QBNqGUspLI634lM8R-mhGciDZX2Jh_nKoXL
861 Af5GCnvL9PlI7OdFqocPBIIPpjNrgX_Z4PFjeq7ILx98GhVkryLYU9HVO
862 FPCYci-lF9nfw1geliLfkoj5QZyi4J2SOtYaO_zPmQvCXaUREqPf5UDAl
863 gvc50a4ByYnNbkWSbhZ5Z388s8ELzPSE9XypdgP-1cSyRke7V8iGe4eHN
864 sm01TgWILYOFK4mYAM52OTitJxmQtmRp6izY5ZFdH9f_WdoB1RXmGEZyd
865 vL-estcjx5ghsV3gktedIl0HA4R_M_N5TFIwv7hiisyRLi2aQtyFbE7pZ
866 6Oz-cYsLc4qFfXbb13U9a2-Byul8hm_E2b3m4GMhmsCiROm-uht9Ek4h9
867 BIxFhDKPr-htOXc93-uQNZlAQfkITAKlJfQ
868
869
870 Aj8lKdPMDE4U82UAhDJBaRrl3USmuzS2hfFOe_OBEv8
871
872
873
875 7. Signatures
877 7.1. Determining Support
879 If an agent supports receiving end-to-end object signatures, it MUST
880 advertise that fact in its responses to [XEP-0030] information
881 ("disco#info") requests by returning a feature of
882 "urn:ietf:params:xml:ns:xmpp-e2e:6:signatures".
884
888
889 ...
890
891 ...
892
893
895 To facilitate discovery, an agent SHOULD also include [XEP-0115]
896 information in any directed or broadcast presence updates.
898 7.2. Signing XMPP Stanzas
900 The basic process that a sending agent follows for authenticating
901 stanzas is the same regardless of the kind of stanza (i.e., ,
902 , or ).
904 7.2.1. Process
906 For a given plaintext stanza (S), the sending agent performs the
907 following:
909 1. Ensures the plaintext stanza is fully qualified, including the
910 proper namespace declarations (e.g., contains the attribute
911 'xmlns' set to the value "jabber:client" for 'jabber:client'
912 stanzas defined in [RFC6120]).
914 2. Notes the current UTC date and time (N) when this stanza is
915 constructed, formatted as described under Section 10.
917 3. Constructs a forwarding envelope (M) using a element
918 qualified by the "urn:xmpp:forward:0" namespace (as defined in
919 [XEP-0297]) as follows:
921 * The child element qualified by the "urn:xmpp:delay"
922 namespace (as defined in [XEP-0203]) with the attribute
923 'stamp' set to the UTC date and time value N
925 * The plaintext stanza S
927 4. Converts the forwarding envelope (M) to a UTF-8 encoded string
928 (M'), optionallly removing line breaks and other insignificant
929 whitespace between elements and attributes, i.e. M' =
930 UTF8-encode(M). We call M' a "stanza-string" because for
931 purposes of encryption and decryption it is treated not as XML
932 but as an opaque string (this avoids the need for complex
933 canonicalization of the XML input).
935 5. Chooses a private asymmetric key (PK) for which the sending agent
936 has published the corresponding public key to the intended
937 recipients.
939 6. Performs the message signatures steps from [JOSE-JWS] to generate
940 the JWS Header (H) and JWS Signature (I); using the following
941 inputs:
943 * The 'alg' property is set to an appropriate signature
944 algorithm for PK (e.g., "R256").
946 * M' as the JWS Payload.
948 7. Constructs an element qualified by the
949 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace as follows:
951 * The attribute 'type' set to the value "sig"
953 * The child element qualified by the
954 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
955 character data as H, encoded base64url as per [RFC4648].
957 * The child element qualified by the
958 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
959 character data as M', encoded base64url as per [RFC4648].
961 * The child element qualified by the
962 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
963 character data as I, encoded base64url as per [RFC4648].
965 8. Sends the element as the payload of a stanza that SHOULD
966 match the stanza from step 1 in kind (e.g., ), type
967 (e.g., "chat"), and addressing (e.g., to="romeo@montegue.lit"
968 from="juliet@capulet.lit/balcony"). If the original stanza (S)
969 has a value for the 'id' attribute, this stanza SHOULD NOT use
970 the same value for its "id" attribute.
972 7.3. Verifying Signed XMPP Stanzas
974 7.3.1. Protocol Not Understood
976 If the receiving agent does not understand the protocol, it MUST do
977 one and only one of the following: (1) ignore the extension,
978 (2) ignore the entire stanza, or (3) return a
979 error to the sender, as described in [RFC6120].
981 NOTE: If the inbound stanza is an , the receiving agent MUST
982 return an error to the sending agent, to comply with the exchanging
983 of IQ stanzas in [RFC6121].
985 7.3.2. Process
987 Upon receipt of a signed stanza, the receiving agent performs the
988 following:
990 1. Ensures it has appropriate materials to verify the signature,
991 which generally means ensuring that it possesses one or more
992 public keys for the sending agent (if one is not provided as part
993 of the JWS Header).
995 2. Performs the message validation steps from [JOSE-JWS], with the
996 following inputs:
998 * The JWS Header H from the element's character
999 data content.
1001 * The JWS payload M' from the element's character data
1002 content.
1004 * The JWS Signature from the element's character data
1005 content.
1007 3. Converts the forwarding envelope UTF-encoded string M' into XML
1008 element M.
1010 4. Obtains the UTC date and time N from the child element,
1011 and verifies it is within the accepted range, as specified in
1012 Section 10.
1014 5. Obtains the plaintext stanza S, which is a child element node of
1015 M; the stanza MUST be fully qualified with the proper namespace
1016 declrations from XMPP stanzas, to help distinguish it from other
1017 content within M.
1019 7.3.3. Insufficient Information
1021 At step 1, if the receiving agent does not have the key used to sign
1022 the stanza, or the receiving agent could not otherwise determine it,
1023 it MAY return a error to the sending agent (as
1024 described in [RFC6120]), optionally supplemented by an application-
1025 specific error condition element of :
1027
1032
1034 [XML character data]
1035 [XML character data]
1036 [XML character data]
1037
1038
1039
1041
1043
1044
1046 In addition to returning an error, the receiving agent SHOULD NOT
1047 present the stanza to the intended recipient (human or application)
1048 and SHOULD provide some explicit alternate processing of the stanza
1049 (which MAY be to display a message informing the recipient that it
1050 has received a stanza that cannot be verified).
1052 7.3.4. Failed Verification
1054 At step 2, if the receiving agent is unable to successfully verify
1055 the stanza, the receiving agent SHOULD return a error
1056 to the sending agent (as described in [RFC6120]), optionally
1057 supplemented by an application-specific error condition element of
1058 :
1060
1065
1067 [XML character data]
1068 [XML character data]
1069 [XML character data]
1070
1071
1072
1074
1076
1077
1079 In addition to returning an error, the receiving agent SHOULD NOT
1080 present the stanza to the intended recipient (human or application)
1081 and SHOULD provide some explicit alternate processing of the stanza
1082 (which MAY be to display a message informing the recipient that it
1083 has received a stanza that cannot be verified).
1085 7.3.5. Timestamp Not Acceptable
1087 At step 4, if the stanza is successfully verified but the timestamp
1088 fails the checks outlined in Section 10, the receiving agent MAY
1089 return a error to the sender (as described in
1090 [RFC6120]), optionally supplemented by an application-specific error
1091 condition element of (previously defined in
1092 [RFC3923]):
1094
1099
1101 [XML character data]
1102 [XML character data]
1103 [XML character data]
1104
1105
1106
1108
1110
1111
1113 7.3.6. Successful Verification
1115 If the receiving agent successfully verified the payload, it SHOULD
1116 NOT return a stanza error. However, if the signed stanza is an
1117 of type "get" or "set", the response MAY be sent unsigned if the
1118 receiving agent does not have an appropriate public-private key-pair.
1120 Otherwise, the receiving agent SHOULD send the response signed
1121 as per Section 7.2.1, with the 'type' attribute set to the value
1122 "result", even if the response to the signed stanza is of type
1123 "error". The error applies to the signed stanza, not the wrapping
1124 stanza.
1126 7.4. Example - Signing a Message
1128 NOTE: unless otherwise indicated, all line breaks are included for
1129 readability.
1131 The sending agent beings with the plaintext version of
1132 stanza 'S':
1134
1138 35740be5-b5a4-4c4e-962a-a03b14ed92f4
1139
1140 But to be frank, and give it thee again.
1141 And yet I wish but for the thing I have.
1142 My bounty is as boundless as the sea,
1143 My love as deep; the more I give to thee,
1144 The more I have, for both are infinite.
1145
1146
1148 Then the sending agent performs steps 1, 2, and 3 from Section 7.2.1
1149 generate the envelope M:
1151
1152
1154
1158 35740be5-b5a4-4c4e-962a-a03b14ed92f4
1159
1160 But to be frank, and give it thee again.
1161 And yet I wish but for the thing I have.
1162 My bounty is as boundless as the sea,
1163 My love as deep; the more I give to thee,
1164 The more I have, for both are infinite.
1165
1166
1167
1169 Then the sending agent performs steps 4, 5, and 6 to generate the
1170 [JOSE-JWS] outputs:
1172 JWS Header (before base64url encoding)
1174 {
1175 "alg":"RS512",
1176 "kid":"juliet@capulet.lit"
1177 }
1178 JWS Payload
1180 PGZvcndhcmRlZCB4bWxucz0idXJuOnhtcHA6Zm9yd2FyZDowIj48ZGVsYXkgeG1
1181 sbnM9InVybjp4bXBwOmRlbGF5IiBzdGFtcD0iMTQ5Mi0wNS0xMlQyMDowNzozNy
1182 4wMTJaIi8-PG1lc3NhZ2UgeG1sbnM9ImphYmJlcjpjbGllbnQiIGZyb209Imp1b
1183 GlldEBjYXB1bGV0LmxpdC9iYWxjb255IiB0bz0icm9tZW9AbW9udGVndWUubGl0
1184 IiB0eXBlPSJjaGF0Ij48dGhyZWFkPjM1NzQwYmU1LWI1YTQtNGM0ZS05NjJhLWE
1185 wM2IxNGVkOTJmNDwvdGhyZWFkPjxib2R5PkJ1dCB0byBiZSBmcmFuaywgYW5kIG
1186 dpdmUgaXQgdGhlZSBhZ2Fpbi4gQW5kIHlldCBJIHdpc2ggYnV0IGZvciB0aGUgd
1187 GhpbmcgSSBoYXZlLiBNeSBib3VudHkgaXMgYXMgYm91bmRsZXNzIGFzIHRoZSBz
1188 ZWEsIE15IGxvdmUgYXMgZGVlcDsgdGhlIG1vcmUgSSBnaXZlIHRvIHRoZWUsIFR
1189 oZSBtb3JlIEkgaGF2ZSwgZm9yIGJvdGggYXJlIGluZmluaXRlLjwvYm9keT48L2
1190 1lc3NhZ2U-PC9mb3J3YXJkZWQ-
1192 JWS Signature
1194 YPfGouD50j0C_C-RneawG0jxXWDXgBkN3FJz6eaBFIPCh3hopiwtwKir7Yamvgt
1195 OrqhXx2pcu-70caGi6mKKLWvpdwdJ3nEnhdjPOd3CmLdaK_PBAMtIt8d3155hdl
1196 qNxSMsJN7PxmNLNwJhbksAsI-2TcCQsuxdIPXh6hcqBm44BpVio6AoRPqwF06XZ
1197 MMBMOMnEFcV6Ht20wCK1BEGgOmN3KYPbwKeTctG8HKPAh25_K66aEXT66lI19uW
1198 j1fGFJ79QQHUhc5y9pSKmpK7HKruPMRyrvpzBSfUhcb62nLXhM-LzY5taaDECzi
1199 fCi-IxySBtJJtPCqYAYW_IbrRFg
1201 Then the sending agent performs steps 7 and 8 and sends the
1202 following:
1204
1209
1211
1212 eyJhbGciOiJSUzUxMiIsImtpZCI6Imp1bGlldEBjYXB1bGV0LmxpdCJ9
1213
1214
1215 PGZvcndhcmRlZCB4bWxucz0idXJuOnhtcHA6Zm9yd2FyZDowIj48ZGVsY
1216 XkgeG1sbnM9InVybjp4bXBwOmRlbGF5IiBzdGFtcD0iMTQ5Mi0wNS0xMl
1217 QyMDowNzozNy4wMTJaIi8-PG1lc3NhZ2UgeG1sbnM9ImphYmJlcjpjbGl
1218 lbnQiIGZyb209Imp1bGlldEBjYXB1bGV0LmxpdC9iYWxjb255IiB0bz0i
1219 cm9tZW9AbW9udGVndWUubGl0IiB0eXBlPSJjaGF0Ij48dGhyZWFkPjM1N
1220 zQwYmU1LWI1YTQtNGM0ZS05NjJhLWEwM2IxNGVkOTJmNDwvdGhyZWFkPj
1221 xib2R5PkJ1dCB0byBiZSBmcmFuaywgYW5kIGdpdmUgaXQgdGhlZSBhZ2F
1222 pbi4gQW5kIHlldCBJIHdpc2ggYnV0IGZvciB0aGUgdGhpbmcgSSBoYXZl
1223 LiBNeSBib3VudHkgaXMgYXMgYm91bmRsZXNzIGFzIHRoZSBzZWEsIE15I
1224 GxvdmUgYXMgZGVlcDsgdGhlIG1vcmUgSSBnaXZlIHRvIHRoZWUsIFRoZS
1225 Btb3JlIEkgaGF2ZSwgZm9yIGJvdGggYXJlIGluZmluaXRlLjwvYm9keT4
1226 8L21lc3NhZ2U-PC9mb3J3YXJkZWQ-
1227
1228
1229 YPfGouD50j0C_C-RneawG0jxXWDXgBkN3FJz6eaBFIPCh3hopiwtwKir7
1230 YamvgtOrqhXx2pcu-70caGi6mKKLWvpdwdJ3nEnhdjPOd3CmLdaK_PBAM
1231 tIt8d3155hdlqNxSMsJN7PxmNLNwJhbksAsI-2TcCQsuxdIPXh6hcqBm4
1232 4BpVio6AoRPqwF06XZMMBMOMnEFcV6Ht20wCK1BEGgOmN3KYPbwKeTctG
1233 8HKPAh25_K66aEXT66lI19uWj1fGFJ79QQHUhc5y9pSKmpK7HKruPMRyr
1234 vpzBSfUhcb62nLXhM-LzY5taaDECzifCi-IxySBtJJtPCqYAYW_IbrRFg
1235
1236
1237
1239 8. Requesting Session Keys
1241 Because of the dynamic nature of XMPP stanza routing, the protocol
1242 does not exchange session keys as part of the encrypted stanza.
1243 Instead, a separate protocol is used by receiving agents to request a
1244 particular session key from the sending agent.
1246 8.1. Request Process
1248 Before a SMK can be requested, the receiving agent MUST have at least
1249 one public key for which it also has the private key. The public
1250 key(s) are provided to the sending agent as part of this process.
1252 To request a SMK, the receiving agent performs the following:
1254 1. Constructs a [JOSE-JWK] JWK Set (KS), containing information
1255 about each public key the requesting agent wishes to use. Each
1256 key SHOULD include a value for the property 'kid' which uniquely
1257 identifies it within the context of all provided keys. Each key
1258 MUST include a value for the property 'kid' if any two keys use
1259 the same algorithm.
1261 2. Constructs a element qualified by the
1262 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace as follows:
1264 * The attribute 'id' set to the SMK identifier value SID.
1266 * The child element qualified by the
1267 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
1268 character data as KS, encoded base64url as per [RFC4648].
1270 3. Sends the element as the payload of an stanza
1271 with the attribute 'type' set to "get", the attribute 'to' set to
1272 the full JID of the original encrypted stanza's sender, and the
1273 attribute 'id' set to an opaque string value the receiving agent
1274 uses to track the response.
1276 8.2. Accept Process
1278 If the sending agent approves the request, it performs the following
1279 steps:
1281 1. Generate a JSON Web Key (JWK) representing the symmetric SMK
1282 (according to [JOSE-JWK]):
1284 * The "kty" parameter MUST be "oct".
1286 * The "kid" parameter MUST be the SID.
1288 * The "k" parameter MUST be the SMK, encoded as base64url.
1290 * The "alg" parameter, if present, MUST be set to the algorithm
1291 in use for encrypting messages from Section 6.2.
1293 * The "use" parameter, if present, MUST be set to "enc".
1295 2. Chooses a key (PK) from the keys provided via KS, and notes its
1296 identifier value 'kid'.
1298 3. Protects the SMK using the process outlined in [JOSE-KEYPROTECT]
1299 to generate the JWE Header (H), JWE Encrypted Key (E), JWE
1300 Initialization Vector (IV), JWE Ciphertext (C), and JWE Integrity
1301 Value (I); using the following inputs:
1303 * The 'alg' property is set to an algorithm appropriate for the
1304 chosen PK (e.g., "RSA-OAEP" for a "RSA" key).
1306 * The 'enc' property is set to the intended content encryption
1307 algorithm.
1309 * A randomly generated CMK. See [RFC4086] for considerations on
1310 generating random values.
1312 * A randomly generated initialization vector. See [RFC4086] for
1313 considerations on generating random values.
1315 * SMK, formatted as a JWK as above.
1317 4. Constructs a element qualified by the
1318 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace as follows:
1320 * The attribute 'id' set to the SMK Identifier (SID).
1322 * The child element qualified by the
1323 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
1324 character data as H, encoded base64url as per [RFC4648].
1326 * The child element qualified by the
1327 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
1328 character data as E, encoded base64url as per [RFC4648].
1330 * The child element qualified by the
1331 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
1332 character data as IV, encoded base64url as per [RFC4648].
1334 * The child element qualified by the
1335 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
1336 character data as C, encoded base64url as per [RFC4648].
1338 * The child element qualified by the
1339 "urn:ietf:params:xml:ns:xmpp-e2e:6" namespace and with XML
1340 character data as I, encoded base64url as per [RFC4648].
1342 5. Sends the element as the payload of an stanza
1343 with the attribute 'type' set to "result", the attribute 'to' set
1344 to the full JID from the request 's 'from' attribute, and
1345 the attribute 'id' set to the value of the request 's 'id'
1346 attribute.
1348 8.3. Error Conditions
1350 If the sending agent does not approve the request, it sends an
1351 stanza of type "error" and containing the reason for denying the
1352 request:
1354 o : the key request is made by an entity that is not
1355 authorized to decrypt stanzas from the sending agent and/or for
1356 the indicated SID.
1358 o : the requested SID is no longer valid.
1360 o : the key request did not contain any keys the
1361 sending agent understands.
1363 8.4. Example of Successful Key Request
1365 NOTE: unless otherwise indicated, all line breaks are included for
1366 readability.
1368 To begin a key request, the receiving agent performs step 1 from
1369 Section 8.1 to generate the [JOSE-JWK]:
1371 {
1372 "keys": [{
1373 "kty":"RSA",
1374 "kid":"romeo@montegue.lit/garden",
1375 "n":"vtqejkMF01h8oKEaHfHEYO0C2jM7eISbbSvNs0SNItYWO6GbjpJf
1376 N4ldXw2vpVRdysnwU3zk6o2_SD0YCH1WgeuI0QK1knMTDdNSXx52e1c4BTw
1377 hlA8iHuutTWmpBqesn1GNZmqB3jYsJOkVBYwCJtkB9APaBvk0itlRtizjCf
1378 1HHnau7nGStyshgu8-srxi_d8rC5TTLSB_zT1i6fP8fwDloemXOtC0U65by
1379 5P-1ZHxaf_bD8fpjps6gwSgdkZKMJAI0bOWZWuMpp2ntqa0wLB7Ndxb2Ijr
1380 eog_s5ssAoSiXDVdoswSbp36ZP-1lnCk2j-vZ4qbhaFg5bZtgt-gwQ",
1381 "e":"AQAB"
1382 }]
1383 }
1385 Then the receiving agent performs step 2 to generate the :
1387
1389
1390 eyJrZXlzIjpbeyJrdHkiOiJSU0EiLCJraWQiOiJyb21lb0Btb250ZWd1ZS5
1391 saXQvZ2FyZGVuIiwibiI6InZ0cWVqa01GMDFoOG9LRWFIZkhFWU8wQzJqTT
1392 dlSVNiYlN2TnMwU05JdFlXTzZHYmpwSmZONGxkWHcydnBWUmR5c253VTN6a
1393 zZvMl9TRDBZQ0gxV2dldUkwUUsxa25NVERkTlNYeDUyZTFjNEJUd2hsQThp
1394 SHV1dFRXbXBCcWVzbjFHTlptcUIzallzSk9rVkJZd0NKdGtCOUFQYUJ2azB
1395 pdGxSdGl6akNmMUhIbmF1N25HU3R5c2hndTgtc3J4aV9kOHJDNVRUTFNCX3
1396 pUMWk2ZlA4ZndEbG9lbVhPdEMwVTY1Ynk1UC0xWkh4YWZfYkQ4ZnBqcHM2Z
1397 3dTZ2RrWktNSkFJMGJPV1pXdU1wcDJudHFhMHdMQjdOZHhiMklqcmVvZ19z
1398 NXNzQW9TaVhEVmRvc3dTYnAzNlpQLTFsbkNrMmotdlo0cWJoYUZnNWJadGd
1399 0LWd3USIsImUiOiJBUUFCIn1dfQ
1400
1401
1403 Then the receiving agent performs step 3 and sends the following:
1405
1410
1412
1413 eyJrZXlzIjpbeyJrdHkiOiJSU0EiLCJraWQiOiJyb21lb0Btb250ZWd1Z
1414 S5saXQvZ2FyZGVuIiwibiI6InZ0cWVqa01GMDFoOG9LRWFIZkhFWU8wQz
1415 JqTTdlSVNiYlN2TnMwU05JdFlXTzZHYmpwSmZONGxkWHcydnBWUmR5c25
1416 3VTN6azZvMl9TRDBZQ0gxV2dldUkwUUsxa25NVERkTlNYeDUyZTFjNEJU
1417 d2hsQThpSHV1dFRXbXBCcWVzbjFHTlptcUIzallzSk9rVkJZd0NKdGtCO
1418 UFQYUJ2azBpdGxSdGl6akNmMUhIbmF1N25HU3R5c2hndTgtc3J4aV9kOH
1419 JDNVRUTFNCX3pUMWk2ZlA4ZndEbG9lbVhPdEMwVTY1Ynk1UC0xWkh4YWZ
1420 fYkQ4ZnBqcHM2Z3dTZ2RrWktNSkFJMGJPV1pXdU1wcDJudHFhMHdMQjdO
1421 ZHhiMklqcmVvZ19zNXNzQW9TaVhEVmRvc3dTYnAzNlpQLTFsbkNrMmotd
1422 lo0cWJoYUZnNWJadGd0LWd3USIsImUiOiJBUUFCIn1dfQ
1423
1424
1425
1427 If the sending agent accepts this key request, it performs step 1
1428 from Section 8.2 to generate JWK representation of the SMK:
1430 {
1431 "kty":"oct",
1432 "kid":"835c92a8-94cd-4e96-b3f3-b2e75a438f92",
1433 "k":"xWtdjhYsH4Va_9SfYSefsJfZu03m5RrbXo_UavxxeU8"
1434 }
1436 Then the sending agent performs steps 2 and 3 to generate the
1437 protected SMK:
1439 JWE Header (before base64url encoding)
1441 {
1442 "alg":"RSA-OAEP",
1443 "kid":"romeo@montegue.lit/garden",
1444 "enc":"A256CBC+HS512",
1445 "cty":"application/jwk+json"
1446 }
1447 JWE Encrypted Key
1449 hKUOpAif76c-hmRwEphVB9wXjloLpwu75x98MSWyCBtfUgmopk93ttUXoZ4AAIk
1450 rZJOtrPUqPZwYHjay3ggfgjVljJ_KGhgqI5cScIzaAQs0Pxep6FnrsnUrw09Sjv
1451 2VRXOay4guMQnbQo0ibpifBxeuL9MJ_vdeb_BdSE8YZ4iTfMb7GT35gZC9NgweX
1452 3fiTEo2LjY8hEV3DHud5LlNZzYp9kLmAUZNIwGu7LtYyI4F7NnOv9oLx1HtmfE3
1453 _skkYtQoKMvMewLkIO88h325qCpWFdrLwPp63betCmewDJPaBdrp91rLchkXVo-
1454 d2ueKkb59TxWjMx7esBdaxCAcDQ
1456 JWE Initialization Vector
1458 Ggiego8UiSsj7GgY94qOng
1460 JWE Ciphertext
1462 4vIGDz9Hm6X4lSo9JoA6ZzS0KitztLGAiMUs3RTviFO09choPhxJNlOj8KX8QIL
1463 u4zZ-ytCnG-yzNx5SsT8KEQJhIf6_9yWplxpX173k6ZJV-sXGd4Mj9u7N0IqWQL
1464 K5DMytv7XopsZsR9QFCDNGew
1466 JWE Integrity Value
1468 3GuaasWV0XGTBbRtNP6OQ14_cHL-ZJC1naDtU6EIecw
1470 Then the sending agent performs step 4 to generate the
1471 response:
1473
1475
1476 eyJhbGciOiJSU0EtT0FFUCIsImtpZCI6InJvbWVvQG1vbnRlZ3VlLmxpdC9
1477 nYXJkZW4iLCJlbmMiOiJBMjU2Q0JDK0hTNTEyIiwiY3R5IjoiYXBwbGljYX
1478 Rpb24vandrK2pzb24ifQ
1479
1480
1481 hKUOpAif76c-hmRwEphVB9wXjloLpwu75x98MSWyCBtfUgmopk93ttUXoZ4
1482 AAIkrZJOtrPUqPZwYHjay3ggfgjVljJ_KGhgqI5cScIzaAQs0Pxep6Fnrsn
1483 Urw09Sjv2VRXOay4guMQnbQo0ibpifBxeuL9MJ_vdeb_BdSE8YZ4iTfMb7G
1484 T35gZC9NgweX3fiTEo2LjY8hEV3DHud5LlNZzYp9kLmAUZNIwGu7LtYyI4F
1485 7NnOv9oLx1HtmfE3_skkYtQoKMvMewLkIO88h325qCpWFdrLwPp63betCme
1486 wDJPaBdrp91rLchkXVo-d2ueKkb59TxWjMx7esBdaxCAcDQ
1487
1488
1489 Ggiego8UiSsj7GgY94qOng
1490
1491
1492 4vIGDz9Hm6X4lSo9JoA6ZzS0KitztLGAiMUs3RTviFO09choPhxJNlOj8KX
1493 8QILu4zZ-ytCnG-yzNx5SsT8KEQJhIf6_9yWplxpX173k6ZJV-sXGd4Mj9u
1494 7N0IqWQLK5DMytv7XopsZsR9QFCDNGew
1495
1496
1497 3GuaasWV0XGTBbRtNP6OQ14_cHL-ZJC1naDtU6EIecw
1498
1499
1501 Then the sending agent performs step 5 and sends the following:
1503
1508
1510
1511 eyJhbGciOiJSU0EtT0FFUCIsImtpZCI6InJvbWVvQG1vbnRlZ3VlLmxpdC9
1512 nYXJkZW4iLCJlbmMiOiJBMjU2Q0JDK0hTNTEyIiwiY3R5IjoiYXBwbGljYX
1513 Rpb24vandrK2pzb24ifQ
1514
1515
1516 hKUOpAif76c-hmRwEphVB9wXjloLpwu75x98MSWyCBtfUgmopk93ttUXoZ4
1517 AAIkrZJOtrPUqPZwYHjay3ggfgjVljJ_KGhgqI5cScIzaAQs0Pxep6Fnrsn
1518 Urw09Sjv2VRXOay4guMQnbQo0ibpifBxeuL9MJ_vdeb_BdSE8YZ4iTfMb7G
1519 T35gZC9NgweX3fiTEo2LjY8hEV3DHud5LlNZzYp9kLmAUZNIwGu7LtYyI4F
1520 7NnOv9oLx1HtmfE3_skkYtQoKMvMewLkIO88h325qCpWFdrLwPp63betCme
1521 wDJPaBdrp91rLchkXVo-d2ueKkb59TxWjMx7esBdaxCAcDQ
1522
1523
1524 Ggiego8UiSsj7GgY94qOng
1525
1526
1527 4vIGDz9Hm6X4lSo9JoA6ZzS0KitztLGAiMUs3RTviFO09choPhxJNlOj8KX
1528 8QILu4zZ-ytCnG-yzNx5SsT8KEQJhIf6_9yWplxpX173k6ZJV-sXGd4Mj9u
1529 7N0IqWQLK5DMytv7XopsZsR9QFCDNGew
1530
1531
1532 3GuaasWV0XGTBbRtNP6OQ14_cHL-ZJC1naDtU6EIecw
1533
1534
1535
1537 9. Mulitple Operations
1539 The individual processes for encrypting and signing can be nested;
1540 the output of each process a complete stanza that could then be
1541 performed with the other. An implementation MUST be able to process
1542 one level of nesting (e.g., an encrypted stanza nested within a
1543 signed stanza), and SHOULD handle multiple levels within reasonable
1544 limits for the receiving agent.
1546 10. Inclusion and Checking of Timestamps
1548 Timestamps are included to help prevent replay attacks. All
1549 timestamps MUST conform to [XEP-0082] and be presented as UTC with no
1550 offset, and SHOULD include the seconds and fractions of a second to
1551 three digits. Absent a local adjustment to the sending agent's
1552 perceived time or the underlying clock time, the sending agent MUST
1553 ensure that the timestamps it sends to the receiver increase
1554 monotonically (if necessary by incrementing the seconds fraction in
1555 the timestamp if the clock returns the same time for multiple
1556 requests). The following rules apply to the receiving agent:
1558 o It MUST verify that the timestamp received is within an acceptable
1559 range of the current time. It is RECOMMENDED that implementations
1560 use an acceptable range of five minutes, although implementations
1561 MAY use a smaller acceptable range.
1563 o It SHOULD verify that the timestamp received is greater than any
1564 timestamp received in the last 10 minutes which passed the
1565 previous check.
1567 o If any of the foregoing checks fails, the timestamp SHOULD be
1568 presented to the receiving entity (human or application) marked as
1569 "old timestamp", "future timestamp", or "decreasing timestamp",
1570 and the receiving entity MAY return a stanza error to the sender.
1572 Note the foregoing assumes the stanza is received while the receiving
1573 agent is online; see Section 12 for offline storage considerations.
1575 11. Interaction with Stanza Semantics
1577 The following limitations and caveats apply:
1579 o Undirected stanzas SHOULD NOT be encrypted. Such
1580 stanzas are delivered to anyone the sender has authorized, and can
1581 generate a large volume of key requests.
1583 o Undirected stanzas MAY be signed. However, note that
1584 signatures significantly increase the size of a stanza kind that
1585 is often multiplexed across to many XMPP entities; this could have
1586 large impacts on bandwidth and latency.
1588 o Stanzas directed to multiplexing services (e.g., multi-user chat)
1589 SHOULD NOT be encrypted, unless the sender has established an
1590 acceptable trust relationship with the multiplexing service.
1592 12. Interaction with Offline Storage
1594 The server makes its best effort to deliver stanzas. When the
1595 receiving agent is offline at the time of delivery, the server might
1596 store the message until the recipient is next online (offline storage
1597 does not apply to or stanzas, only
1598 stanzas). The following need to be considered:
1600 o If the sending agent is not also online when the message is
1601 delivered to the receiving agent from offline storage, then the
1602 decryption process fails for insufficient information as described
1603 in Section 6.3.3.
1605 o When performing the timestamp checks in Section 10, if the server
1606 includes delayed delivery data as specified in [XEP-0203] for when
1607 the server received the message, then the receiving agent SHOULD
1608 use the delayed delivery timestmap rather than the current time.
1610 13. Mandatory-to-Implement Cryptographic Algorithms
1612 All algorithms that MUST be implemented for [JOSE-JWE] and [JOSE-JWS]
1613 also MUST be implemented for this specification. However, this
1614 specification further mandates the use of the following:
1616 o MUST implement the "RSA1_5" JWE algorithm.
1618 o MUST implement the "RS256" JWS algorithm.
1620 14. Security Considerations
1622 14.1. Storage of Encrypted Stanzas
1624 The recipient's server might store any stanzas received
1625 until the recipient is next available; this duration could be
1626 anywhere from a few minutes to several months.
1628 14.2. Re-use of Session Master Keys
1630 A sender SHOULD NOT use the same SMK for stanzas intended for
1631 different recipients, as determined by the localpart and domainpart
1632 of the recipient's JID.
1634 A sender MAY re-use a SMK for several stanzas to the same recipient.
1635 In this case, the SID remains the same, but the sending agent MUST
1636 generate a new CMK and IV for each encrypted stanza. The sender
1637 SHOULD periodically generate a new SMK (and its associated SID);
1638 however, this specification does not mandate any specific algorithms
1639 or processes.
1641 In the case of stanzas, a sending agent might generate a
1642 new SMK each time it generates a new ThreadID, as outlined in
1643 [XEP-0201].
1645 15. IANA Considerations
1647 15.1. XML Namespaces Name for e2e Data in XMPP
1649 A number of URN sub-namespaces of encrypted and/or signed content for
1650 the Extensible Messaging and Presence Protocol (XMPP) is defined as
1651 follows.
1653 URI: urn:ietf:params:xml:ns:xmpp-e2e:6
1655 Specification: RFC XXXX
1657 Description: This is an XML namespace name of encrypted and/or
1658 signed content for the Extensible Messaging and Presence Protocol
1659 as defined [[ this document ]].
1661 Registrant Contact: IESG,
1663 URI: urn:ietf:params:xml:ns:xmpp-e2e:6:encryption
1665 Specification: RFC XXXX
1667 Description: This is an XML namespace name signalling support for
1668 encrypted content for the Extensible Messaging and Presence
1669 Protocol as defined [[ this document ]].
1671 Registrant Contact: IESG,
1673 URI: urn:ietf:params:xml:ns:xmpp-e2e:6:signatures
1675 Specification: RFC XXXX
1677 Description: This is an XML namespace name signalling support for
1678 signed content for the Extensible Messaging and Presence Protocol
1679 as defined [[ this document ]].
1681 Registrant Contact: IESG,
1683 16. References
1685 16.1. Normative References
1687 [E2E-REQ] Saint-Andre, P., "Requirements for End-to-End Encryption
1688 in the Extensible Messaging and Presence Protocol (XMPP)",
1689 draft-saintandre-xmpp-e2e-requirements-01 (work in
1690 progress), March 2010.
1692 [JOSE-JWA]
1693 Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
1694 json-web-algorithms-11 (work in progress), May 2013.
1696 [JOSE-JWE]
1697 Jones, M., Rescola, E., and J. Hildebrand, "JSON Web
1698 Encryption (JWE)", draft-ietf-jose-json-web-encryption-11
1699 (work in progress), May 2013.
1701 [JOSE-JWK]
1702 Jones, M., "JSON Web Key (JWK)", draft-ietf-jose-json-web-
1703 key-11 (work in progress), December 2012.
1705 [JOSE-JWS]
1706 Jones, M., Bradley, J., and N. Sakimura, "JSON Web
1707 Signature (JWS)", draft-ietf-jose-json-web-signature-11
1708 (work in progress), May 2013.
1710 [JOSE-KEYPROTECT]
1711 Miller, M., "Using JSON Web Encryption (JWE) for
1712 Protecting JSON Web Key (JWK) Objects", draft-miller-jose-
1713 jwe-protected-jwk-00 (work in progress), February 2013.
1715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1716 Requirement Levels", BCP 14, RFC 2119, March 1997.
1718 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
1719 Encodings", RFC 4648, October 2006.
1721 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
1722 4949, August 2007.
1724 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
1725 Protocol (XMPP): Core", RFC 6120, March 2011.
1727 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
1728 Protocol (XMPP): Instant Messaging and Presence", RFC
1729 6121, March 2011.
1731 [XEP-0030]
1732 Eatmon, R., Hildebrand, J., Millard, P., and P. Saint-
1733 Andre, "Service Discovery", XSF XEP 0030, June 2006.
1735 [XEP-0082]
1736 Saint-Andre, P., "XMPP Date and Time Profiles", XSF XEP
1737 0082, May 2003.
1739 [XEP-0115]
1740 Hildebrand, J., Troncon, R., and P. Saint-Andre, "Entity
1741 Capabilities", XSF XEP 0115, February 2008.
1743 [XEP-0203]
1744 Saint-Andre, P., "Delayed Delivery", XSF XEP 0203,
1745 September 2009.
1747 [XEP-0297]
1748 Wild, M. and K. Smith, "Stanza Forwarding", XSF XEP 0297,
1749 July 2012.
1751 16.2. Informative References
1753 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
1754 for the Extensible Messaging and Presence Protocol
1755 (XMPP)", RFC 3923, October 2004.
1757 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
1758 Requirements for Security", RFC 4086, June 2005.
1760 [XEP-0201]
1761 Saint-Andre, P., Paterson, I., and K. Smith, "Best
1762 Practices for Message Threads", XSF XEP 0203, November
1763 2010.
1765 [Key-Table]
1766 Housley, R., Polk, T., Hartman, S., and D. Zhang,
1767 "Database of Long-Lived Symmetric Cryptographic Keys",
1768 December 2013.
1770 Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e:6
1772 The following XML schema is descriptive, not normative.
1774
1776
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1817
1818
1819
1820
1821
1822
1823
1824
1826
1827
1828
1829
1830
1831
1832
1833
1835
1836
1837
1838
1839
1840
1841
1842
1844
1845
1846
1847
1848
1849
1850
1851
1853
1854
1855
1856
1857
1858
1859
1860
1862
1863
1864
1865
1866
1867
1868
1869
1871
1872
1873
1874
1875
1876
1877
1878
1880
1881
1882
1883
1885
1886
1887
1888
1889
1891
1893 Appendix B. Acknowledgements
1895 Thanks to Richard Barnes, Andrew Biggs, and Ben Schumacher for their
1896 feedback.
1898 Authors' Addresses
1900 Matthew Miller
1901 Cisco Systems, Inc.
1902 1899 Wynkoop Street, Suite 600
1903 Denver, CO 80202
1904 USA
1906 Phone: +1-303-308-3204
1907 Email: mamille2@cisco.com
1909 Carl Wallace
1910 Red Hound Software, Inc.
1912 Email: carl@redhoundsoftware.com