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