idnits 2.17.1
draft-miller-3923bis-02.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 :
----------------------------------------------------------------------------
-- The draft header indicates that this document obsoletes RFC3923, but the
abstract doesn't seem to directly say this. It does mention RFC3923
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 192 has weird spacing: '...message xml...'
== Line 204 has weird spacing: '... , , or
109 ).
111 1. Constructs a cleartext version of the stanza, S.
113 2. Generates a session key R appropriate for the intended block
114 cipher (e.g. AES-SHA-256).
116 3. Notes the current UTC date and time N when this stanza is
117 constructed, formatted as described under Section 6.
119 4. Converts the stanza to a UTF-8 encoded string, optionally
120 removing line breaks and other insignificant whitespace between
121 elements and attributes, i.e., S' = UTF8-encode(S). We call S'
122 a "stanza-string" because for purposes of encryption and
123 decryption it is treated not as XML but as an opaque string
124 (this avoids the need for complex canonicalization of the XML
125 input).
127 5. Constructs a plaintext envelope (E) as follows:
129 * The attribute 'timestamp' set to the UTC date and time value
130 N
132 * The XML character data set to the base64-encoded form of S'
133 (where the encoding adheres to the definition in Section 4 of
134 [BASE64] and where the padding bits are set to zero). This
135 encoding is necessary to preserve a canonicalized form of S'.
137 6. Converts the envelope (E) to a UTF-8 encoded string, optionally
138 removing line breaks and other insignificant whitespace between
139 elements and attributes, i.e., E' = UTF8-encode(E).
141 7. Encrypts the UTF8-encoded enveloped (E') using the intended
142 block cipher, i.e. T = block-encrypt(R, E').
144 8. Generates a message authentication code (MAC) with a
145 cryptographic hashing algorithm (e.g. HMACSHA256) using the
146 encrypted data T as the salt and the session block cipher key R
147 as the message, i.e., M = mac-hash(T, R)
149 9. Encrypts the session key (R) using the recipient's public key to
150 produce encrypted data K. (Known issue: This step is under-
151 specified and will be expanded in a later version of this
152 document.)
154 10. Constructs an element qualified by the
155 "urn:ietf:params:xml:ns:xmpp-objenc:0" namespace as follows:
157 * The child element (implicitly qualified by the
158 "urn:ietf:params:xml:ns:xmpp-objenc:0" namespace) as follows:
160 + The attribute 'cipher-algo' set to the asynchronous
161 encryption scheme used in step 9;
163 + The XML character data set to the base64-encoded form of
164 K.
166 * The child element qualified by the
167 "urn:ietf:params:xml:ns:xmpp-objenc:0" namespace as follows:
169 + The attribute 'mac-algo' set to the cryptographic hashing
170 algorithm used to generate M in step 8;
172 + The attribute 'mac-hash' set to the base64-encoded result
173 of the MAC, M;
175 + The attribute 'cipher-algo' set to the block encryption
176 scheme used to generate the encrypted data T in step 7;
178 + The XML character data as the base64-encoded form of T.
180 11. Sends the element as the payload of a stanza that SHOULD
181 match the stanza from step 1 in kind (e.g., ), type
182 (e.g., "chat"), and addressing (e.g. to="romeo@montague.net"
183 from="juliet@capulet.net/balcony"). If the original stanza (S)
184 has a value for the "id" attribute, this stanza MUST NOT use the
185 same value for its "id" attribute.
187 3.1. Example of Securing Messages
189 The sender begins with the cleartext version of the stanza
190 "S":
192
197 8996aef0-061d-012d-347a-549a200771aa
198 Wherefore art thou, Romeo?
199
201 The sender then performs the steps 1 through 5 from above to
202 generate:
204
206 PG1lc3NhZ2UgeG1sbnM9ImphYmJlcjpjbGllbnQiIGZyb209Imp1bGlldEBjYXB
207 1bGV0Lm5ldC9iYWxjb255IiB0bz0icm9tZW9AbW9udGVndWUubmV0IiB0eXBlPS
208 JjaGF0Ij48dGhyZWFkPmM2MzczODI0LWEzMDctNDBkZC04ZmUwLWJhZDZlNzI5O
209 WFkMDwvdGhyZWFkPjxib2R5PldoZXJlZm9yZSBhcnQgdGhvdSwgUm9tZW8/PC9i
210 b2R5PjwvbWVzc2FnZT4=
211
213 Then performs steps 6 through 10, and sends the following:
215
220
221
222 OPfr4zudqiEeLcOQazZJIB6B9gx3zrVbyHKTU8a/aDb0wiZevztxxCi8hto0+Qw
223 Foyhcupj547WbFZJNlB2dsAPhlJzeH9SuGLJShjhbkOyKjmqZLLCZr3OQtJjcTU
224 sAVj7IZZsOOPDmwsb4Dxv5sz+icsDpi5l+5APfthDaoHbcrvz2pA1CJ5IFQoob4
225 a0i0WevcAFyB+vWXsRqQCxjn5sHdb6G4vjQ/m1lzTWahzKvi56pNUm7ll18oI8L
226 mPi1VWUEqH3aayGLVlJ9fhBDSSpW4jTQ/ts1nzPJwVlKdTqdgNBusFEhrRMhJD5
227 1JdLOhxx+Ov2Xbs22++XQ1tS8/A==
228
229
232 a8zpjgRcO1VHZ9CoqU19/jB7nn58Gzu5/sQm8YQe4F9zz+YKUfqTS9LaHcqdAwa
233 z8BG1a24Z72VYb5Ptjh7nQ19f5QQdA/P4lZ3oqeTJTsA4DkhvJaSUhrjYib/NOk
234 3lkMoatR/OSbfvhPdqXQ/dutLuRFjkilXGVwNWkgLm3iSnKUiYSdUzWvj88RgR3
235 ldVHFeyrdgufU9qu/FyO6MZXjfEtD80O+3ZBbESqllzmYFXnfkzBrhfi14iCba6
236 /b5Io5zhFUyWaq5e6qq2z72a+1bjeWkG8F9XBiMkyaxkB64wAS0o6aDpWdir5Oi
237 +Rnms4LV/wxL4Is/oe8Fo9xR3UmrdlAiaehdGBh+EnJGqprKa9eccOKqSu7/lJQ
238 ObAdJGEOeAVs8JEkQkxw+qR8edkEDuv6ZXN7JCWQx9LNaiiwsfAzApJJbqfrtDx
239 koQ3JaBbxQ+8FE3TM0E4Tbr9V8NDZC8abgBramlpUBfgknJvLYMTzx1lnsiCUxo
240 6ezC0xqV
241
242
243
245 3.2. Example of Securing IQs
247 The sender begins with the cleartext version of the stanza "S":
249
254
255
256
257 Romeo, what's here? Poison? Drunk all, and
258 left no friendly drop to help me after?
259
260
261
263 The sender then performs the steps 1 through 5 from above to
264 generate:
266
268 PGlxIHhtbG5zPSJqYWJiZXI6aXEiIGZyb209Imp1bGlldEBjYXB1bGV0Lm5ldC9
269 jcnlwdCIgaWQ9ImE1NDNiYzNlZSIgdG89InJvbWVvQG1vbnRlZ3VlLm5ldC9jcn
270 lwdCIgdHlwZT0icmVzdWx0Ij48bW9vZCB4bWxucz0iaHR0cDovL2phYmJlci5vc
271 mcvcHJvdG9jb2wvbW9vZCI+PGRlamVjdGVkIC8+PHRleHQ+Um9tZW8sIHdoYXQn
272 cyBoZXJlPyBQb2lzb24/IERydW5rIGFsbCwgYW5kIGxlZnQgbm8gZnJlbmRseSB
273 kcm9wIHRvIGhlbHAgbWUgYWZ0ZXI/PC90ZXh0PjwvbW9vZD48L2lxPg==
274
276 Then performs steps 6 through 10, and sends the following:
278
283
284
285 hOU+BRkEcCY0+eKTX9hzCbP30Ij0q5zZ9buFgkOWu4LsVkI92OiH65SvYL/XCB6
286 12sb9fhjkiAIeR0AySGiid+AeS7KZDzpcZ+ORg8j9CkEX/LeTYszBfZFiHzDFkh
287 qtwu3s7QMAR0Bzxj9NVE7W8fSdleusvyOOP5c0scrpRkXDMVO2Z3/rTjC0xInx3
288 XQUP+RlqFE7g1HCr01BjoPjI4p3N+fONVv0U9mwtt1I5tJ4EXgTofUM0GMNGX1i
289 NoNNjPDb9XsihpLvDIjMblXVHvYAIyPwCs2ZdDv7L5kmZ6U+35b7Qx8TdWUN2I4
290 5fBbxczvkFN6+cx2h5uapOTxBkw==
291
292
295 ksCAkoJeoymtf3ygzBJkrJYQV+g04CkAs5oSmej60GU89mRN3rKSX5FVfWo558W
296 Bcn8mVUxFxWhSdNBrsW5GQS1EyygDT+yfJe6OqzLTCqZn4iqaCyIPWM7XB/PolA
297 fvELw7y3hf8JrEAM4JXIfxrcOYDqewr7zmamwuuos4B6qzgiNN9ZW2AfTyKL3+l
298 twcmFvF/nWF1YN8CquGmBm83WFn7Ik9R+Nqq54+QNCABjSFPT25ZYquEhxk/RIS
299 CDAIXFOaFBozGjC20M3UDqnuwLsUF+P4ucjybysxhHQlqLOffX0Vhb1YesWaZac
300 pvsj8Ovfpv+ESrWGptXr+8GMK1og69GHRrd2k2TonPFp1KwS5MkbEpP2tS7R+nT
301 b9oGFojr6waNKhhhVmP/9FWRMi7C2KfLCHggAatLWDjBG8k7yd5DWdSqY7LwkwB
302 hT6+iErRfhdvk1EVxn2TVqjfhsFh33XDqkRT4BhPJUjJPkwLZkQ03PVgHKluMsE
303 JoUBS0OxD7gE5q808hy3qA+r5PDowy6nQ9zbUaCu4JbvKV2moql7fgHUy8MZLIe
304 DFVJ5A5z8Te6K4pFaQGAzxEOouS2A+BmvPAFczFeL+QGy58RSNMiXJ9ZMpb+N2C
305 1iDzPD8OL
306
307
308
310 4. Interaction with Stanza Semantics
312 The following limitations and caveats apply:
314 o Undirected stanzas MUST NOT be encrypted. Such
315 stanzas are delivered to anyone the sender has authorized, and
316 therefore it is highly unlikely that the sender can find an
317 appropriate certificate.
319 o Stanzas directed to multiplexing services (e.g. multi-user chat)
320 SHOULD NOT be encrypted, unless the sender has established an
321 acceptable trust relationship with the multiplexing service.
323 5. Handling of Inbound Stanzas
325 Several scenarios are possible when an entity receives an encrypted
326 stanza:
328 o The receiving application does not understand the protocol.
330 o The receiving application understands the protocol and is able to
331 decrypt the payload.
333 o The receiving application understands the protocol and is able to
334 decrypt the payload, but the timestamps fail the checks specified
335 under Checking of Timestamps (Section 6).
337 o The receiving application understands the protocol but is unable
338 to decrypt the payload.
340 In Case #1, the receiving application MUST do one and only one of the
341 following: (1) ignore the extension, (2) ignore the entire
342 stanza, or (3) return a error to the sender,
343 as described in [XMPP-CORE].
345 In Case #2, the receiving application MUST NOT return a stanza error
346 to the sender, since this is the success case.
348 In Case #3, the receiving application MAY return a
349 error to the sender (as described in [XMPP-CORE]), optionally
350 supplemented by an application-specific error condition element of
351 (previously defined in [RFC3923]):
353
357
358 XML-character-data-here
359
360
361
362
363
364
366 In Case #4, the receiving application SHOULD return a
367 error to the sender (as described in [XMPP-CORE]), optionally
368 supplemented by an application-specific error condition element of
369 (previously defined in [RFC3923]):
371
375
376 XML-character-data-here
377
378
379
380
381
382
384 In addition to returning an error in Case #4, the receiving
385 application SHOULD NOT present the stanza to the intended recipient
386 (human or application) and SHOULD provide some explicit alternate
387 processing of the stanza (which MAY be to display a message informing
388 the recipient that it has received a stanza that cannot be
389 decrypted).
391 6. Inclusion and Checking of Timestamps
393 Timestamps are included to help prevent replay attacks. All
394 timestamps MUST conform to [DATETIME] and be presented as UTC with no
395 offset, and SHOULD include the seconds and fractions of a second to
396 three digits. Absent a local adjustment to the sending agent's
397 perceived time or the underlying clock time, the sending agent MUST
398 ensure that the timestamps it sends to the receiver increase
399 monotonically (if necessary by incrementing the seconds fraction in
400 the timestamp if the clock returns the same time for multiple
401 requests). The following rules apply to the receiving application:
403 o It MUST verify that the timestamp received is within five minutes
404 of the current time, except as described below for offline
405 messages.
407 o It SHOULD verify that the timestamp received is greater than any
408 timestamp received in the last 10 minutes which passed the
409 previous check.
411 o If any of the foregoing checks fails, the timestamp SHOULD be
412 presented to the receiving entity (human or application) marked as
413 "old timestamp", "future timestamp", or "decreasing timestamp",
414 and the receiving entity MAY return a stanza error to the sender.
416 The foregoing timestamp checks assume that the recipient is online
417 when the message is received. However, if the recipient is offline
418 then the server will probably store the message for delivery when the
419 recipient is next online (offline storage does not apply to or
420 stanzas, only stanzas). As described in
421 [OFFLINE], when sending an offline message to the recipient, the
422 server SHOULD include delayed delivery data as specified in [DELAY]
423 so that the recipient knows that this is an offline message and also
424 knows the original time of receipt at the server. In this case, the
425 recipient SHOULD verify that the timestamp received in the encrypted
426 message is within five minutes of the time stamped by the recipient's
427 server in the element.
429 7. Mandatory-to-Implement Cryptographic Algorithms
431 All implementations MUST support the following algorithms.
432 Implementations MAY support other algorithms as well.
434 o The RSA (PKCS #1 v2.1) key transport, as specified in [X509-ALGO].
436 o The AES-128 encryption algorithm in CBC mode, as specified in
437 [CMS-AES].
439 o The HMACSHA256 hashing algorithm, as specified in [HMAC].
441 8. Certificates
443 To participate in end-to-end encryption using the methods defined in
444 this document, a client needs to possess an X.509 certificate [PKIX].
445 It is expected that many clients will generate their own (self-
446 signed) certificates rather than obtain a certificate issued by a
447 certification authority (CA). In any case the certificate MUST
448 include an XMPP address that is represented using the ASN.1 Object
449 Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of
450 [XMPP-CORE].
452 9. Security Considerations
454 The recipient's server might store any stanzas received
455 until the recipient is next available; this duration could be
456 anywhere from a few minutes to several months.
458 10. IANA Considerations
459 10.1. XML Namespace Name for e2e Data in XMPP
461 A URN sub-namespace of encrypted content for the Extensible Messaging
462 and Presence Protocol (XMPP) is defined as follows.
464 URI: urn:ietf:params:xml:ns:xmpp-objenc:0
465 Specification: RFC XXXX
466 Description: This is an XML namespace name of signed and encrypted
467 content for the Extensible Messaging and Presence Protocol as
468 defined by RFC XXXX.
469 Registrant Contact: IESG,
471 11. References
473 11.1. Normative References
475 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
476 Encodings", RFC 4648, October 2006.
478 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES)
479 Encryption Algorithm in Cryptographic Message Syntax
480 (CMS)", RFC 3565, July 2003.
482 [DATETIME]
483 Klyne, G. and C. Newman, "Date and Time on the Internet:
484 Timestamps", RFC 3339, July 2002.
486 [DELAY] Saint-Andre, P., "Delayed Delivery", XSF XEP 0203,
487 September 2009.
489 [E2E-REQ] Saint-Andre, P., "Requirements for End-to-End Encryption
490 in the Extensible Messaging and Presence Protocol (XMPP)",
491 draft-saintandre-xmpp-e2e-requirements-01 (work in
492 progress), March 2010.
494 [KEYWORDS]
495 Bradner, S., "Key words for use in RFCs to Indicate
496 Requirement Levels", BCP 14, RFC 2119, March 1997.
498 [HMAC] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
499 (SHA and HMAC-SHA)", RFC 4634, July 2006.
501 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
502 Housley, R., and W. Polk, "Internet X.509 Public Key
503 Infrastructure Certificate and Certificate Revocation List
504 (CRL) Profile", RFC 5280, May 2008.
506 [SECTERMS]
507 Shirey, R., "Internet Security Glossary, Version 2",
508 RFC 4949, August 2007.
510 [X509-ALGO]
511 Jonsson, J. and B. Kaliski, "Public-Key Cryptography
512 Standards (PKCS) #1: RSA Cryptography Specifications
513 Version 2.1", RFC 3447, February 2003.
515 [XMPP-CORE]
516 Saint-Andre, P., "Extensible Messaging and Presence
517 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-08 (work
518 in progress), May 2010.
520 11.2. Informative References
522 [OFFLINE] Saint-Andre, P., "Best Practices for Handling Offline
523 Messages", XSF XEP 0160, January 2006.
525 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
526 for the Extensible Messaging and Presence Protocol
527 (XMPP)", RFC 3923, October 2004.
529 Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-objenc:0
531 The following XML schema is descriptive, not normative.
533
535
541
542
543
544
545
546
547
548
550
551
552
553
554
556
557
558
559
561
562
563
564
565
567
569
571
572
573
574
576
577
578
579
580
582
583
584
585
587
588
590
591
592
593
594
596
598 Authors' Addresses
600 Matthew Miller
601 Cisco Systems, Inc.
602 1899 Wyknoop Street, Suite 600
603 Denver, CO 80202
604 USA
606 Phone: +1-303-308-3204
607 Email: mamille2@cisco.com
609 Peter Saint-Andre
610 Cisco Systems, Inc.
611 1899 Wyknoop Street, Suite 600
612 Denver, CO 80202
613 USA
615 Phone: +1-303-308-3282
616 Email: psaintan@cisco.com