idnits 2.17.1 draft-thomson-xmpp-secure-00.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 date (September 29, 2015) is 3133 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0045' -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0085' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft A. Roach 4 Intended status: Standards Track Mozilla 5 Expires: April 1, 2016 September 29, 2015 7 Secure Messaging in XMPP 8 draft-thomson-xmpp-secure-00 10 Abstract 12 The history of secure messaging in XMPP is spotty. The long-running 13 de facto scheme, OTR, enjoys fairly wide implementation and use, but 14 OTR suffers from some serious usability and security shortcomings 15 that make it unsuitable as a basis for encryption. 17 This document describes an architecture that provides end-to-end 18 confidentiality and integrity for XMPP messaging. Solutions for both 19 multi-user and one-to-one messaging are provided. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 1, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 58 3.1. The New Pieces . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. One-to-One Messaging . . . . . . . . . . . . . . . . . . 4 60 3.2.1. Publishing Key Exchange Data . . . . . . . . . . . . 4 61 3.2.2. Establishing Pairwise Keying Material . . . . . . . . 5 62 3.2.3. Message Encryption . . . . . . . . . . . . . . . . . 5 63 3.3. Multi-User Chat . . . . . . . . . . . . . . . . . . . . . 5 64 3.3.1. Inviting Other Clients . . . . . . . . . . . . . . . 7 65 4. Identity Assertions . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Acquiring Identity Assertions . . . . . . . . . . . . . . 9 67 4.2. Validating Identity Assertions . . . . . . . . . . . . . 10 68 5. Message Encryption Details . . . . . . . . . . . . . . . . . 11 69 5.1. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 11 70 5.2. Symmetric Encryption . . . . . . . . . . . . . . . . . . 13 71 5.2.1. Nonces . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.2.2. Symmetric Algorithm Agility . . . . . . . . . . . . . 13 73 5.2.3. Message Drop Attacks . . . . . . . . . . . . . . . . 13 74 5.3. Signature . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5.4. Decryption and Validation . . . . . . . . . . . . . . . . 14 76 5.5. Presence Encryption . . . . . . . . . . . . . . . . . . . 15 77 5.6. Chat State Notifications . . . . . . . . . . . . . . . . 15 78 5.7. Layers of Encryption . . . . . . . . . . . . . . . . . . 15 79 6. Key Advertisement . . . . . . . . . . . . . . . . . . . . . . 15 80 6.1. Asymmetric Key Advertisement . . . . . . . . . . . . . . 16 81 6.2. Symmetric Key Advertisement . . . . . . . . . . . . . . . 16 82 6.3. Key Identifiers . . . . . . . . . . . . . . . . . . . . . 17 83 6.4. Key Lifetime . . . . . . . . . . . . . . . . . . . . . . 18 84 7. User and MUC Rosters . . . . . . . . . . . . . . . . . . . . 18 85 7.1. Roster Entries . . . . . . . . . . . . . . . . . . . . . 19 86 7.1.1. Tracking Affiliations and States . . . . . . . . . . 21 87 7.1.2. MUC Invitation Tickets . . . . . . . . . . . . . . . 21 88 7.1.3. User Roster Management . . . . . . . . . . . . . . . 22 89 7.1.4. Roster Update Protocol . . . . . . . . . . . . . . . 22 90 7.2. Roster State . . . . . . . . . . . . . . . . . . . . . . 23 91 7.3. Roster Security Limitations . . . . . . . . . . . . . . . 23 92 7.4. Mitigating Attacks . . . . . . . . . . . . . . . . . . . 24 93 8. Pseudonymity . . . . . . . . . . . . . . . . . . . . . . . . 24 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 95 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 99 12.2. Informative References . . . . . . . . . . . . . . . . . 26 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 102 1. Introduction 104 The history of secure messaging in XMPP is spotty. The long-running 105 de facto scheme, OTR, enjoys fairly wide implementation and use, but 106 OTR suffers from some serious usability and security shortcomings 107 that make it unsuitable as a basis for encryption. It also has a 108 number of limitations that make it unsuitable for advanced scenarios, 109 such as multi-user conferences. 111 This document describes an architecture that provides end-to-end 112 confidentiality and integrity for XMPP messaging. Solutions for both 113 multi-user and one-to-one messaging are provided. 115 2. Goals 117 This is a very simple proposition with a somewhat involved solution: 119 o one-to-one messaging is secured end-to-end 121 o multi-user chats are secured end-to-end 123 o messages can be sent to offline users 125 o the set of entities that can decrypt a message can be audited 127 o users are able to control whether their communications can be 128 correlated across different venues 130 3. Architectural Overview 132 This system aims to achieve the above goals by adding encryption to 133 chat-related XMPP functions. 135 This only aims to protect chat-related messaging. It provides only 136 limited protection for presence information. The key agreement parts 137 of this protocol are intended to be generically applicable, but the 138 application to file transfer, jingle, and myriad other XMPP features 139 is left for future efforts. 141 3.1. The New Pieces 143 Identity assertions (Section 4) allow users to strongly authenticate 144 others. The identity assertion mechanism is also used as the basis 145 of public key distribution, which underpins several of the other 146 building blocks. 148 Encrypting a message (Section 5) is rather straightforward once the 149 symmetric encryption key is chosen. Establishing the key used in 150 message encryption is more difficult. This design uses a scheme 151 whereby encryption keys are advertised (Section 6) prior to use. How 152 this is done varies only slightly between one-to-one messaging and 153 MUC. 155 Ensuring proper key distribution of the message-encrypting keys to a 156 potentially large and changing set of users is the most challenging 157 and involved piece of infrastructure to design and build. This 158 architecture uses a secure roster (Section 7) that makes and verifies 159 strong cryptographic assertions about participation. 161 Finally, pseudonymity functions allow a user to safeguard their 162 privacy. The addition of strong cryptography makes it easier for 163 passive observers to correlate activity, but pseudonymity (Section 8) 164 allows users to minimize what information about their activity is 165 leaked to others. 167 3.2. One-to-One Messaging 169 Message encryption for one-to-one messaging uses a unilateral key 170 declaration for key management. 172 3.2.1. Publishing Key Exchange Data 174 Clients that wish to participate in encrypted messaging publish 175 keying material to their presence. This includes a signing public 176 key that is used to authenticate messages and a Diffie-Hellman (DH) 177 share used for exchanging the symmetric keys used in encryption. 178 Each client generates new keying material that is bound to the full 179 JID that they use (that is, each client has its own keying material; 180 there is no key associated with a user's bare JID). 182 Keys are published under a randomly generated identifier that is 183 consequently used to identify the key when it is used to encipher a 184 message. 186 New clients can only be added if an existing client attests to the 187 addition. This is intended to stop a subverted server from adding 188 clients. This uses a form of the same roster log (Section 7) that is 189 used for multi-party chats. 191 ISSUE: does this represent a UX issue? Five years ago, we might 192 have been concerned about users forgetting a password or losing 193 their last device. Today, this is less of a concern, especially 194 if we subscribe to the principal device theory (NOTE: The 195 principal device here is a smartphone. That device goes with 196 users everywhere and can serve as an anchor for security 197 operations, like adding a new client to the set of authorized 198 clients for a JID.). 200 3.2.2. Establishing Pairwise Keying Material 202 Prior to sending a message, a client first retrieves and validates 203 the presence of the intended recipient. A client that supports 204 encryption will include a valid DH share in their presence 205 information. 207 The sending client then generates new symmetric keys that it will use 208 with this peer. This key is enciphered toward all the clients in the 209 recipient's presence. 211 The key is also enciphered toward other authorized clients for the 212 sender's JID. This allows other clients to decipher the messages 213 that other clients have sent. It also allows those clients to reuse 214 the key. 216 It is also necessary for clients to re-send this information if a 217 client is added by sender or recipient. Otherwise, clients that 218 reuse symmetric keys will generate messages that new clients are 219 unable to decrypt. 221 3.2.3. Message Encryption 223 Once keying material has been selected or new keying material has 224 been advertised, messages are encrypted and decrypted (Section 5) 225 using that symmetric key. 227 Recipients of the message recover the advertised keying material by 228 retrieving the presence of the sender and decrypting the enciphered 229 key. 231 3.3. Multi-User Chat 232 +--------+ +--------+ +--------+ 233 | | | | | | 234 | Server |____| Server |____| Server | 235 | x | | muc@z | | y | 236 | | | | | | 237 +--------+ +--------+ +--------+ 238 | Roster | 239 | Log | 240 +--------+ +--------+ 241 | | | | 242 | Client | | Client | 243 | a@x/1 | | b@y/1 | 244 | | | | 245 +--------+ +--------+ 246 Alias Alias 247 xxx@x yyy@y 248 (w/keys) (w/keys) 250 A user founds a MUC in the usual fashion (see [XEP-0045], section 251 10.1). Two changes are made: 253 1. The client creates a a temporary JID (Section 8) that is unique 254 for the room, and matching keying material that it will use 255 exclusively with that temporary JID. 257 2. The message that founds the room includes a founding entry for 258 the secure roster log (Section 7) for the room. This is an 259 element that establishes the creating user as an owner in a 260 manner that can be independently verified. 262 Client Server x Server 263 a@x muc@z 264 | | | 265 |getalias for a@x | | 266 |------------------>| | 267 |presence for xxx@x | | 268 |<------------------| | 269 | | | 270 |xxx@x is a single-use JID: no presence?| 271 | | | 272 |create muc(xxx@x, first log entry) | 273 |-------------------------------------->| 274 |room created | | 275 |<--------------------------------------| 276 |configure | | 277 |-------------------------------------->| 278 |room open | | 279 |<--------------------------------------| 281 All subsequent changes to the roster of the MUC need to be 282 accompanied by a message that authorizes the change. This message is 283 signed by the user that proposes the change. All users verify the 284 resulting series of changes that accumulate to build up the room 285 roster. 287 Unauthorized changes to the roster are therefore detectable. Keying 288 material is only shared with users that have been legitimately added 289 to the roster. 291 3.3.1. Inviting Other Clients 293 In order to invite a user to a chat, two pieces of identifying 294 information for the invited client need to be retrieved: a temporary 295 JID and the keying material for that client. 297 The inviting client generates a signed invitation and sends this to 298 the bare JID of the offline user. This invitation is a bearer token 299 that can be exercised by any client that has it. The invitation must 300 be encrypted using one-to-one message encryption, or servers can 301 steal and use it. A user with the bearer token includes that in a 302 signed roster log entry when they join the room. The room adds the 303 entry to the roster log if it can be validated. 305 Client Server Server y Client 306 a@x muc@z b@y 307 | | | | 308 |getalias for b@y | | | 309 |-------------------------------------->| | 310 |presence for yyy@y | | | 311 |<--------------------------------------| | 312 |invite yyy@y to muc@z (token) | | 313 |-------------------------------------->| | 314 | | |connect | 315 | | |<------------------| 316 | | |invitation | 317 | | |------------------>| 318 | | |get alias for b@y | 319 | | |<------------------| 320 | | |presence for yyy@y | 321 | | |------------------>| 322 | |join (presence, token) | 323 | |<--------------------------------------| 324 | |ok | | 325 | |-------------------------------------->| 327 4. Identity Assertions 329 The identity of users is one of the most important pieces of 330 confidential information in the context of a chat. Identity 331 information need to be confidentiality protected if they transit more 332 than one server hop. 334 Client Server x Client 335 a@x b@y 336 | | | 337 |get assertion | | 338 |------------------>| | 339 |assertion | | 340 |<------------------| | 341 |assertion | | 342 |-------------------------------------->| 343 | |get identity | 344 | |<------------------| 345 | |identity | 346 | |------------------>| 348 A new payload is defined to carry identity assertions. 349 That assertion binds a bare JID to the signing public key used by a 350 client to send messages. 352 The identity assertion contains only a single piece of public 353 information: the domain name of the asserting entity. The remainder 354 is an opaque blob of data that is consumed by the identity provider. 356 357 358 example.com 359 360 Gv3JuuWcMW0NZZib8pk+ZMPS4jnkmT0cFZQTPOTUM0yAktmseWAk2w 361 362 363 365 4.1. Acquiring Identity Assertions 367 An identity assertion is acquired from the domain that is responsible 368 for the JID (that is usually the client's own server) by sending a 369 query to that server. The server uses the client's authentication 370 credentials, which are usually bound to a connection, to determine if 371 the client owns the identifier. 373 375 376 ... 377 378 380 The information that is signed is the signing key that the client 381 intends to bind to their identity. 383 The assertion that the server generates will ultimately be consumed 384 by the server that generated it, so it can be completely opaque. 385 However, it should contain enough information for the server to 386 identify the JID of the client that it relates to, as well as verify 387 its authenticity. 389 391 392 example.com 393 394 Gv3JuuWcMW0NZZib8pk+ZMPS4jnkmT0cFZQTPOTUM0yAktmseWAk2w 395 396 397 398 The assertion might also include limits on validity, such as an 399 expiration time, as dictated by server policy. 401 4.2. Validating Identity Assertions 403 ISSUE: This validation mechanism relies on transitive trust in the 404 server of the client making the query. Confidentiality protection 405 seems like the right thing here. Which is a second case for 406 server-to-client confidentiality. 408 Clients that receive the identity assertion can then query the server 409 that issued it and request the identity that it contains. The server 410 validates the assertion, and either generates an error, or a message 411 containing the identity. 413 The query includes the assertion: 415 417 418 example.com 419 420 Gv3JuuWcMW0NZZib8pk+ZMPS4jnkmT0cFZQTPOTUM0yAktmseWAk2w 421 422 423 425 A successful response includes the identity of the client, and the 426 public key that was asserted. 428 431 432 user@example.com 433 ... 434 435 437 A client receiving this response checks that the domain part of the 438 identifier matches the server identity. Once this check is complete, 439 the identity can be associated with the public key. All messages 440 sent with that public key can thereafter be attributed to the 441 identifier. Clients might also provide indicators that the sender of 442 authenticated messages has been verified. 444 5. Message Encryption Details 446 A simple combination of symmetric encryption and asymmetric signing 447 are used to protect messages. 449 This wrapping scheme takes an unencrypted, serialized XMPP stanza. 450 The process adds a signature over this data. Then the signed content 451 is encrypted. 453 content = cleartext || sender.sign(cleartext) 454 ciphertext = encrypt(keys[keyid].key, nonce, content) 456 The routing and message handling information from the cleartext 457 (element basename plus to, from, and type attributes) is added to a 458 new stanza of the same basename as the original. That is, 459 stanzas produce encrypted stanzas; stanzas result in 460 encrypted stanzas. Unfortunately, these attributes govern 461 message delivery in ways that could cause compatibility issues if 462 they were encrypted. 464 ISSUE: The potential variations in these values leaks information; 465 a future study might identify mappings that allow for reductions 466 in this leakage. This might include identifying cases where 467 removing the resource identifier from routing attributes is safe; 468 or finding ways to map the range of stanza elements and type 469 attributes to a reduced set. If there was a consistent set of 470 policies with respect to handling the different stanzas and types, 471 this would be easier. 473 A new element is added to the encrypted element. The content of 474 this element is a base64 encoded string that contains the encrypted 475 message. 477 This element includes attributes for a key identifier (Section 6.3) 478 and sequence number. The key identifier provides the information a 479 recipient needs to decrypt the message. The sequence number 480 increases by one for every message sent, allowing a receiver to 481 detect when messages are dropped or lost. 483 5.1. Encapsulation 485 Encrypted messages always use either the stanza or the 486 stanza based solely on the nature of the exchange. Messages that 487 require a response from a specific client use the stanza; all 488 other messages use . 490 Presence information can be encrypted, but this is necessarily mixed 491 with unencrypted data. An extension to the element 492 includes confidential presence information. Note that presence 493 information is effectively broadcast; but any encrypted information 494 will need a limited audience, and all that audience will need to 495 receive the same encryption key. 497 For example, the following message from [RFC6121] section 5.2.1: 499 505 Art thou not Romeo, and a Montague? 506 508 Might be encrypted into a message of the form: 510 515 516 Ume+BIoftGYSA2Z2yJMyycNvMJmpysdfQY2wcrCiK0AtsrqWZR6KcTTEkewfepW 517 1FGIYpmZFLGSybwRZ+VcOHdlOl9aYVzdSPDmXrM2mrJGhz7sxphlKfPlw6ZrJ7Dt 518 Gq9IM0epBu6E4hb9DDb4+ORR2Ap7+cAD+ICMJQMySuq/mVE7ybxxWzloU30Lb 519 Gn/lzU9cmUww3yCI98WZAcHoeTQXJ0b/qjUpqYjJwCshaCH_HH7daks0TS3IojH 520 OancJmsBd5RYqMHekrpD9RpuWGGzR-ro0ScRbdsLnzXmYl62qSnyw1qCMNuJE 521 5o5_uraBRgEkCDlXas 522 523 525 This removes the language indicator from the unencrypted stanza. 527 ISSUE: What do existing clients do when they see an encrypted 528 message? The addition of one client that supports encryption 529 causes encrypted messages to be sent to that user. Other clients 530 that haven't yet been upgraded will have to deal with the 531 encrypted messages somehow. It might be possible to add a 532 element with a generic message, but that would need to be 533 internationalized and repeating that block in every message seems 534 wasteful. Ideally, encrypted messages would just be discarded. 535 To do: check with someone who might know. 537 5.2. Symmetric Encryption 539 Authenticated Encryption with Additional Data (AEAD) [RFC5116] is 540 used to provide confidentiality of messages, as well as integrity 541 against unauthorized recipients. 543 The AEAD key is either advertised (Section 6) or reused from a prior 544 advertisement. The advertisement of the key establishes the scheme 545 that is used. 547 5.2.1. Nonces 549 The sequence number on each message determines the nonce that is used 550 with the AEAD. For a given combination of sender and key identifier, 551 sequence numbers cannot repeat without risking compromise of the 552 confidentiality and integrity provided by authenticated encryption. 553 The following nonce derivation method is used (using HKDF as defined 554 in [RFC5869]): 556 nonce = HKDF(0, sender.fullJID, 'nonce', N_MAX) XOR seqno 558 This nonce selection ensures a negligible probability of nonce reuse 559 as long as each sender correctly increments the sequence number. 560 Recipients can verify that sequence numbers are not reused. 562 5.2.2. Symmetric Algorithm Agility 564 Key identifiers also identify the AEAD algorithm that is used to 565 encipher a message. That information is carried in the key 566 advertisement. 568 Messages may be enciphered multiple times with different keys. This 569 allows new encryption schemes to be deployed, at the cost of sending 570 some messages multiple times. This is only necessary if some 571 potential recipients only support old AEAD algorithms. 573 This presents a downgrade attack vector if an attacker can convince a 574 sender that a legitimate client supports a weaker cipher suite. 575 However, key advertisements are authenticated, so the only point for 576 a potential downgrade is a break in the signing key that a recipient 577 uses, which is much more serious a problem than a mere downgrade. 579 5.2.3. Message Drop Attacks 581 Selectively dropping messages can be used by an attacker to disrupt 582 communications. Even without visibility into the contents of 583 messages, side channels might be used to learn of the timing of 584 important messages. 586 For this reason, the sequence number of messages is integral to the 587 encryption of messages. Sequence numbers increase at a constant 588 interval for messages sent by the same client, allowing dropped 589 messages to be detected. Since there is an expectation of 590 reliability and in-order message delivery, clients should highlight 591 where message are missing. 593 5.3. Signature 595 A signature on messages is necessary to prevent impersonation of 596 other MUC participants. This means that repudiation of the form that 597 OTR claims to provide is not offered, because that requirement is 598 incompatible. Note however that a temporary MUC using a temporary 599 JID (Section 8) and no identity assertion (Section 4) provides only 600 circumstantial means of attributing activity to a user. 602 5.4. Decryption and Validation 604 The reverse of this process is used to decrypt messages. Encrypted 605 information is authenticated and the signature validated. The 606 decrypted and verified stanza is then parsed as though it were in 607 place of the current stanza. 609 A client only needs to decrypt one element, since each is 610 required to include the same content. All unencrypted content in the 611 stanza is removed and consequently ignored. 613 It is important that the receiver check that the stanza is whole and 614 valid before allowing it to be processed further. A server that is 615 unable to decrypt a message cannot be relied upon to ensure that 616 messages are valid. 618 In the cleartext protocol, framing issues do not propagate easily, 619 since they directly affect stanza processing. Encrypted stanzas 620 allow a malicious peer to generate invalid - especially unterminated 621 - XML. Extraneous bogus frames resulting from unchecked XML might be 622 exploited to impersonate a server toward a receiving client. 623 Matching the enciphered *from* attribute against the included 624 signature is also necessary to prevent other forms of impersonation. 626 Additional checks might be necessary for specific stanzas, types, or 627 content. In general, any checks that might have been possible on a 628 server need to be carried out by clients that received encrypted 629 stanzas. 631 5.5. Presence Encryption 633 Some presence information might be confidential. For instance, many 634 users include a status message that is shared with their friends. 635 Encrypting status is highly desirable. 637 Direct children of the presence stanza may be encrypted in an 638 element. These necessarily use a different key than those used for 639 other types of messaging to avoid problems with controlling key 640 disclosure. 642 ISSUE: we need to expand on the definition of presence. This 643 could require new messaging arrangements to support retrieval of 644 encrypted presence information. It definitely needs more 645 expansion on key management. At its core, this might reuse the 646 same systems used for one-to-one messaging, but the broadcast 647 nature of presence means that there is a larger audience for any 648 given message, which increases the potential for keys to be 649 unavailable to valid recipients. 651 5.6. Chat State Notifications 653 Clients are required to encrypt chat state notifications [XEP-0085]. 654 However, these messages are useless to an offline client. A server 655 that can see these messages is required to drop them (see [XEP-0160], 656 section 3), but encrypted messages can't be distinguished from other 657 more important messages. 659 Thus, clients are required to suppress chat state notifications when 660 a peer is offline. This allows a server to fake presence for a user 661 in order to filter out chat state notifications, or suppress the 662 feature, but the value of this information isn't great and this 663 causes an attacker to actively modify or suppress messages to mount 664 the attack. 666 5.7. Layers of Encryption 668 A group chat might use one-to-one message encryption to send messages 669 to a user. There's a question about what advantage that provides. 670 Removing the nick from messages might be of some advantage, but that 671 advantage is better managed with Section 8. 673 6. Key Advertisement 675 Users publish the encryption keys that they use for one-to-one 676 messaging to their presence. In an MUC, they instead use the 677 presence that they advertise to the room. 679 6.1. Asymmetric Key Advertisement 681 Two forms of asymmetric keys are used by clients: a signing key that 682 is used to authenticate all forms of messages sent by that client, 683 and a Diffie-Hellman (likely elliptic curve) share that is used in 684 symmetric key advertisements. 686 Asymmetric signing keys are added to and form the basis of the roster 687 log (Section 7) maintained for each user or MUC. Diffie-Hellman 688 shares are added to presence information. 690 Diffie-Hellman shares are added to a presence document as JWS-signed 691 [RFC7515] JWK Set [RFC7517]. Each JWK in the set includes a key 692 identifier that other clients use to identify the key. 694 695 696 { 697 "payload": 698 "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9le 699 GFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ", 700 "signatures":\[ 701 {"protected":"eyJhbGciOiJSUzI1NiJ9", 702 "header": {"jwk": { \xe2\x80\xa6 } }, 703 "signature": 704 "cC4hiUPoj9Eetdgtv3hF80EGrhuB__dzERat0XF9g2VtQgr9PJbu3XOiZj5 705 RZmh7AAuHIm4Bh-0Qc_lF5YKt_O8W2Fp5jujGbds9uJdbF9CUAr7t1dnZcA 706 cQjbKBYNX4BAynRFdiuB--f_nZLgrnbyTyWzO75vRK5h6xBArLIARNPvkSj 707 tQBMHlb1L07Qe7K0GarZRmB_eSN9383LcOLn6_dO--xi12jzDwusC-eOkHW 708 EsqtFZESc6BfI7noOPqvhJ1phCnvWh6IeYI2w9QOYEUipUTI8np6LbgGY9F 709 s98rqVt5AXLIhWkWywlVmtVrBp0igcN_IoypGlUPQGe77Rw"}\] 710 } 711 712 714 Each key that is encrypted toward this client uses the "kid" 715 parameter on the JWK to identify the key that they are encrypting 716 towards. 718 Diffie-Hellman advertisements are signed to ensure that they are only 719 provided by authorized clients. This allows these advertisements to 720 be generated prior to a client becoming authorized. 722 6.2. Symmetric Key Advertisement 724 A key advertisement contains the following information: 726 o A key identifier 727 o An encryption scheme identifier 729 o The full JID of the advertising client (a temporary JID for MUC) 731 o The full JID of the key recipient (a temporary JID for MUC) 733 o A key identifier for the DH share for the advertising client 735 o A key identifier for the DH share for the key recipient 737 o A symmetric key, encrypted using a key derived from the DH 738 exchange 740 o An expiration date and time, after which the key must not be used 741 for enciphering new messages, though it may be used to decipher 742 old messages 744 o A key identifier for the signing key 746 o A signature over this entire structure, generated using the 747 private signing key 749 Open Issue: Rather than use key identifiers for DH shares it might 750 be easier to exchange the share itself, since that is unambiguous 751 and likely not significantly different in size. That makes the 752 advertisement self-contained. Note that this would not absolve 753 the key recipient of the need to check that the DH share (or 754 signature key) is from a valid and authorized entity. The use of 755 a key identifier makes that check implicit and avoids some types 756 of mistake. 758 The signature is required to ensure that a key is not replayed and 759 consequently reused. A message with a signing key that is either not 760 known or from an entity that is not permitted to participate in a 761 conversation must be discarded. 763 A complete key advertisement includes the same information repeated 764 for each recipient. Common information, and the signature, don't 765 need to be repeated. A single signature has implications for key 766 lifetime. 768 6.3. Key Identifiers 770 Key identifiers are used to select the key that is used for 771 encryption and decryption. Each key advertisement has an associated 772 key identifier. 774 Care needs to be taken to ensure that key identifiers are unique 775 within the context that they are created. Since keys are proposed 776 and used by multiple actors without synchronization, identifying keys 777 with a large identifier (such as a GUID) is advised. 779 6.4. Key Lifetime 781 Keys are advertised with an expiration time that limits the time when 782 they can be used for encryption. However, offline clients need to be 783 able to read messages that are generated while they are offline. 784 Clients that are offline for extended periods need to be able to 785 recover the keys that were used to encrypt those messages. 787 Keys advertised to user presence are therefore persisted until their 788 intended recipients have retrieved and acknowledged keys. Since each 789 key is encrypted toward a specific client, once that client retrieves 790 the key it can be removed, though explicit acknowledgment might be 791 desirable. Note that the set of recipients includes all client 792 instances of the intended recipient, plus all client instances of the 793 sender. 795 Once the complete set of potential recipients have acknowledged a 796 key, then it can be removed. This might use implicit acknowledgment 797 for client instances of the sender, since the server can track 798 message delivery to those clients. Explicit acknowledgment is 799 necessary for remote clients of the recipient. 801 Keys advertised within an MUC enter the chat transcript. New 802 messages to the chat are expected to use the latest key, so old keys 803 only need to be maintained to account for race conditions where 804 messages might be sent without knowledge of the most recent key. 805 Keys that are superseded by a newer key can therefore be disposed of 806 after a short duration. 808 Here, the ordering of messages to the MUC is used to determine which 809 key is used. That ordering allows clients to remove and discard 810 older keys. 812 7. User and MUC Rosters 814 All efforts to encipher messages are largely pointless if the 815 architecture permits servers to add themselves to the set of clients 816 and thereby acquire keying material. The roster of clients that are 817 authorized to represent a user, or which are part of an MUC, is a 818 resource that needs strong integrity protection to prevent a 819 malicious server from becoming part of conversations. 821 The canonical form of each roster takes the form of a log. A roster 822 log is a verifiable chain of changes to the roster. The log can be 823 validated by any entity and the set of participants validated. 825 Each entry in the log identifies the entry that immediately precedes 826 it by including a cryptographic hash of that entry. This ensures 827 that a valid log cannot include divergent or conflicting changes 828 (this does not prevent certain forms of manipulation (Section 7.3) by 829 servers). Each entry is signed by the entity that generated the 830 entry, allowing changes to be attributed and validated. 832 A successfully validated roster log can be used by a client to 833 determine the set of clients that a key advertisement (Section 6) 834 needs to be enciphered toward. In ensuring that a validated roster 835 log is used prior to advertising new keys, clients can ensure that 836 only authorized clients receive those keys. 838 7.1. Roster Entries 840 There are several types of entry that can be recorded into the roster 841 log. The following table summarizes the different types of log 842 entry. 844 +-------------+-------------+------------+--------------------------+ 845 | Entry Type | Parameters | Who can | Notes | 846 | | | add | | 847 +-------------+-------------+------------+--------------------------+ 848 | Set Room | Room Owner, | Room Owner | This entry must be the | 849 | Type | Room Type | | first entry in a MUC | 850 | | | | roster log. This also | 851 | | | | establishes the signer | 852 | | | | as a room owner. (MUC | 853 | | | | only) | 854 | | | | | 855 | Set Room | Permissions | Room Owner | The set of permissions | 856 | Permissions | | | are taken from | 857 | | | | [XEP-0045], limited to | 858 | | | | those that can change. | 859 | | | | (MUC only) | 860 | | | | | 861 | Set | Subject, | Authorized | The maximum role that | 862 | Affiliation | Affiliation | Client | the subject can assume | 863 | | | | might be included, or it | 864 | | | | might be determined | 865 | | | | based on [XEP-0045] | 866 | | | | affiliation. (MUC only) | 867 | | | | | 868 | Set Client | Subject, | Authorized | This determines whether | 869 | State | State | Client | the identified client is | 870 | | | | authorized or not. (One- | 871 | | | | to-one only) | 872 | | | | | 873 | Redeem | Subject, | Subject | This in effect allows | 874 | Ticket | Invitation | | for a Set Affiliation | 875 | | Ticket | | entry to be generated in | 876 | | | | two parts. | 877 | | | | | 878 | Rekey | Old Key, | Subject | Used by a client to | 879 | | New Key | | replace the keying | 880 | | | | material it uses without | 881 | | | | changing the affiliation | 882 | | | | of the client. This | 883 | | | | entry is signed with the | 884 | | | | old key. This | 885 | | | | invalidates the old key | 886 | | | | for future use. | 887 +-------------+-------------+------------+--------------------------+ 889 Subjects are identified in the roster log by their signing public 890 key. 892 Each log entry includes a hash of the message that precedes it. This 893 ensures that a log entry cannot be replayed on top of a different 894 roster state. 896 The owner (see [XEP-0045], section 5.2) affiliation is required to 897 perform important tasks, like setting the room type or altering 898 configuration options. For setting the affiliation or state of other 899 clients, a combination of factors determine whether an operation is 900 valid: the affiliation of the user performing the change, the room 901 type, and the room permissions. 903 7.1.1. Tracking Affiliations and States 905 The roster log becomes the source of truth for affiliations (or for 906 client state). This has a range of consequences, some of which 907 result in divergence from unprotected chat or MUC. 909 The roster log is public information. This means that affiliations 910 and states can be seen by any client. This information is advertised 911 to room participants in the presence advertisements, but rooms can be 912 configured to suppress presence. Access to affiliation information 913 for offline users (member, admin, and owner lists) is controlled. 915 The design to this point assumes that there is some functional 916 distinction between an affiliation of Member and an affiliation of 917 None. This is not the case in an Open or Unmoderated room. For 918 those room types, the roster log does not need to track affiliation 919 transitions between Member and None, though it may if the room type 920 could change. 922 ISSUE: Is there any sense in encrypting communications when a room 923 is open or unmoderated? Since anyone can join, the main value is 924 in having some knowledge about the set of clients that might have 925 received a message. Given the high level of pseudonymity used, is 926 even that much achievable? 928 The Outcast affiliation cannot be tracked, which makes it impossible 929 to ban a user from an MUC. That is not a consequence of the roster 930 log design, but a result of requiring the use of pseudonyms 931 (Section 8) in MUC. 933 7.1.2. MUC Invitation Tickets 935 An offline client or user is invited to an MUC by sending them an 936 invitation ticket. 938 An invitation ticket contains all the information that a Set 939 Affiliation roster log entry might have, without a subject. That 940 subject is provided when the ticket is redeemed. 942 o Affiliation (and role) 944 o GUID (or equivalent randomness) 946 o A signature from a client that is authorized to make the change 948 Invitation tickets are bearer tokens. That means that distribution 949 of these messages needs to use confidentiality protection, such as 950 that provided by secure one-to-one messaging. 952 A client can revoke any unused tickets that they have sent by 953 rekeying. Consequently, new invitations have to be issued if a 954 client updates their keys. 956 7.1.3. User Roster Management 958 It might seem obvious that an equivalent ticket mechanism could be 959 used for managing user rosters. A user that has a new device, could 960 send that device an invitation to join their list of clients. 962 However, offline invitations for alternative clients don't have a 963 confidentiality protection mechanism available: MUC invitations can 964 be one-to-one encrypted because the user roster exists and provides 965 for that confidentiality protection. The same capability is not 966 available for the client roster, which introduces a bootstrapping 967 problem. 969 The safest option here is to leave this unspecified and require that 970 clients add other clients to the user roster directly. That means 971 that new clients need to come online and advertise keys before they 972 can be invited to represent a client. 974 7.1.4. Roster Update Protocol 976 A simple IQ protocol is defined for updating the roster. A client 977 sends a new roster element (a JWS signed JSON structure) to the 978 server that maintains the roster as follows: 980 983 984 ... a JWS-signed blob ... 985 986 988 The server can validate this and add it or not based on that 989 validation. Note that this exposes clients to various forms of 990 denial of service mounted by the browser, primarily a refusal to take 991 valid updates. 993 7.2. Roster State 995 Clients process a roster log to produce their own view of the state 996 of the roster. This ultimately results in a set of clients that are 997 authorized to receive key advertisements. 999 Each client maintains their own view of the state of the roster for 1000 other clients and each MUC that they participate in. This state can 1001 be recovered at any time by re-processing the roster log. Clients 1002 use this state to select the clients that keying material can be 1003 shared with. Clients also use roster state in determining whether a 1004 new roster log entry is valid. 1006 A roster log can enter a broken state if an invalid entry is added. 1007 Servers are expected to validate new entries and ensure that this 1008 doesn't happen, but it is possible that errors or malice could cause 1009 invalid entries to be recorded and distributed. Clients are required 1010 to freeze the state of a roster at the point where the last valid 1011 entry is found. 1013 7.3. Roster Security Limitations 1015 We have to assume that an attacker (in particular, the server that 1016 maintains and distributes a roster log) can affect how a roster log 1017 makes progress. 1019 This can be used to an attacker's advantage. An attacker can 1020 withhold new changes from clients, or from a subset of clients. By 1021 preventing some subset of clients from learning about changes, an 1022 attacker can freeze the state of a roster from the perspective of 1023 those clients. 1025 This could potentially be used to stimulate the creation of multiple 1026 different changes from the same starting state. The attacker might 1027 then choose to allow changes only that are favorable to it. 1029 In general, this means that the progress of a roster state has to be 1030 viewed as a directed graph, not a linear sequence. The nodes of the 1031 graph correspond to states of the roster. The outbound edges from 1032 any node are the valid set of changes that might be made from that 1033 state by any agent that is currently present. 1035 Given sufficient time, a server can direct progress along any edge 1036 that is presented to it. Also, the server can freeze the node that 1037 an individual client sees by refusing to forward entries to that 1038 client. 1040 More opportunities are available to the server if clients rely on the 1041 server to maintain the entirety of the log state. A client that 1042 maintains no state about a roster opens itself to the possibility 1043 that the server could set the state of the roster to any node in the 1044 directed graph, including old states. 1046 7.4. Mitigating Attacks 1048 The obvious protection clients can use to limit the potential for 1049 unconstrained state manipulation is remembering the state of a log. 1050 This can be limited to the last entry (or the hash of that entry), 1051 even if clients need to discard other state. This prevents roster 1052 progress from being rewound, but it cannot do anything about a server 1053 withholding entries that a client hasn't seen. 1055 The potential for attacks based on withholding log entries is a 1056 potentially serious concern. The design of XMPP naturally provides a 1057 single central controller: the server. That central controller can 1058 provide excellent consistency, if we assume that the server chooses 1059 to present the same view of the roster log to all clients. However, 1060 if the server is malicious, then it represents a single point of 1061 failure. 1063 ISSUE: It might be that this is an acceptable condition, given the 1064 limited opportunity that the server has to affect change. An 1065 alternative design would decouple the roster management function 1066 from the message delivery function, which would allow this to be 1067 independent of the XMPP server. That opens other options, like 1068 distributed or redundant roster stores, though a decoupled design 1069 adds new error conditions for every problem it aims to address. 1071 8. Pseudonymity 1073 Providing end-to-end confidentiality and integrity greatly improves 1074 the privacy profile of XMPP. However, exposure of a user's JID to a 1075 group chat server allows for a greater degree of traffic analysis. 1077 This proposes the use of a pseudonym to minimize the information that 1078 is made available to a group chat server. 1080 A new service is added whereby a client can request the creation of 1081 an unlinked pseudonym. That pseudonym is a temporary JID. A 1082 temporary JID is a bare JID that is aliased to another bare JID. 1083 Resource identifiers can then be selected by the client so that 1084 messages routed to pseudonym can't be linked to their primary 1085 identifier. 1087 A pseudonym allows a client to join a group chat without exposing 1088 their identity to the group chat. 1090 A pseudonym request is simple: 1092 1095 1096 1098 The response is equally simple: 1100 1103 7ee6df7a831198624131@example.com 1104 1106 Clients are able to include the new pseudonym in any interaction that 1107 they initiate and other servers and users will be unable to 1108 distinguish that user from any other user at the same server. 1110 Messages for a pseudonym will be routed to the bare JID of the user, 1111 subject to the normal rules for routing of messages to a bare JID, 1112 even if the message contains a resource identifier. 1114 9. Acknowledgements 1116 TBD 1118 10. Security Considerations 1120 The entire contents of this document deal with matters of security. 1122 11. IANA Considerations 1124 This document makes no requests of IANA 1126 12. References 1128 12.1. Normative References 1130 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1131 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1132 . 1134 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 1135 Protocol (XMPP): Instant Messaging and Presence", RFC 1136 6121, DOI 10.17487/RFC6121, March 2011, 1137 . 1139 [XEP-0045] 1140 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 1141 2012. 1143 [XEP-0085] 1144 Saint-Andre, P. and D. Smith, "Chat State Notifications", 1145 XSF XEP 0085, September 2009. 1147 12.2. Informative References 1149 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1150 Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/ 1151 RFC5869, May 2010, 1152 . 1154 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1155 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1156 2015, . 1158 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/ 1159 RFC7517, May 2015, 1160 . 1162 [XEP-0160] 1163 Saint-Andre, P., "Best Practices for Handling Offline 1164 Messages", XSF XEP 0160, January 2006. 1166 Authors' Addresses 1168 Martin Thomson 1169 Mozilla 1170 \ 1171 Mountain View, CA 1172 US 1174 Phone: +1 650 903 0800 1175 Email: martin.thomson@gmail.com 1177 Adam Roach 1178 Mozilla 1179 \ 1180 Dallas 1181 US 1183 Phone: +1 650 903 0800 x863 1184 Email: adam@nostrum.com