idnits 2.17.1 draft-meyer-xmpp-e2e-encryption-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (June 29, 2009) is 5414 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') ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'IBB' -- Possible downref: Non-RFC (?) normative reference: ref. 'JINGLE' == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-3920bis-00 -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. 'DTLS') (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5081 (Obsoleted by RFC 6091) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Meyer 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track P. Saint-Andre 5 Expires: December 31, 2009 Cisco 6 June 29, 2009 8 XTLS: End-to-End Encryption for the Extensible Messaging and Presence 9 Protocol (XMPP) Using Transport Layer Security (TLS) 10 draft-meyer-xmpp-e2e-encryption-02 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 31, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document specifies "XTLS", a protocol for end-to-end encryption 49 of Extensible Messaging and Presence Protocol (XMPP) traffic. XTLS 50 is an application-level usage of Transport Layer Security (TLS) that 51 is set up using the XMPP Jingle extension for session negotiation and 52 transported using any streaming transport as the data delivery 53 mechanism. Thus XTLS treats the end-to-end exchange of XML stanzas 54 as a virtual transport and uses TLS to secure that transport, 55 enabling XMPP entities to communicate in a way that is designed to 56 ensure the confidentiality and integrity XML stanzas. The protocol 57 can be used for secure end-to-end messaging as well as other XMPP 58 applications, such as file transfer. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. XTLS Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4 65 4. End-to-End Streams over XTLS Protocol Flow . . . . . . . . . . 11 66 5. Bootstrapping Trust on First Communication . . . . . . . . . . 15 67 5.1. Exchanging Certificates . . . . . . . . . . . . . . . . . 16 68 5.2. Verification of Non-Human Parties . . . . . . . . . . . . 17 69 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 18 70 7. Determining Support . . . . . . . . . . . . . . . . . . . . . 18 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 72 8.1. Mandatory-to-Implement Technologies . . . . . . . . . . . 19 73 8.2. Certificates . . . . . . . . . . . . . . . . . . . . . . . 19 74 8.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 20 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 79 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 22 80 Appendix B. Copying Conditions . . . . . . . . . . . . . . . . . 22 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 End-to-end encryption of traffic sent over the Extensible Messaging 86 and Presence Protocol (XMPP) is a desirable goal. Requirements and a 87 threat analysis for XMPP encryption are provided in [E2E-REQ]. This 88 document explores the possibility of using the Transport Layer 89 Security [TLS] to meet those requirements. 91 TLS is the most widely implemented protocol for securing network 92 traffic. In addition to applications in the email infrastructure, 93 the World Wide Web [HTTP-TLS], and datagram transport for multimedia 94 session negotiation [DTLS], TLS is used in XMPP to secure TCP 95 connections from client to server and from server to server, as 96 specified in [XMPP-CORE]. Therefore TLS is already familiar to XMPP 97 developers. 99 This specification, called "XTLS", defines a method whereby any XMPP 100 entity that supports the XMPP Jingle negotiation framework [JINGLE] 101 can use TLS semantics for end-to-end encryption, whether the 102 application data is sent over a streaming transport (like TCP) or a 103 datagram transport (like UDP). The basic use case is to tunnel XMPP 104 stanzas between two IM users for end-to-end secure chat using end-to- 105 end XML streams. However, XTLS is not limited to encryption of one- 106 to-one text chat, since it can be used between two XMPP clients for 107 encryption of any XMPP payloads, between an XMPP client and a remote 108 XMPP service (i.e., a service with which a client does not have a 109 direct XML stream, such as a [MUC] chatroom), or between two remote 110 XMPP services. Furthermore, XTLS can be used for encrypted file 111 transfer using [JINGLE-FILE], for encrypted voice or video sessions 112 using [JINGLE-RTP] and [DTLS-SRTP], and other applications. 114 Note: The following capitalized keywords are to be interpreted as 115 described in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL 116 NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; 117 "MAY", "OPTIONAL". 119 2. Approach 121 In broad outline, XTLS takes the following approach to end-to-end 122 encryption of XMPP traffic: 124 1. We assume that all XMPP entities will have X.509 certificates; 125 realistically these certificates are likely to be self-signed and 126 automatically generated by an XMPP client, however certificates 127 issued by known certification authorities are encouraged to 128 overcome problems with self-signed certificates. 130 2. We use the XMPP Jingle extensions as the negotiation framework 131 (see [JINGLE]). 132 3. We use the concept of Jingle security preconditions to ensure 133 that the negotiated transport will be encrypted before used for 134 sending application data. 135 4. When an entity wishes to encrypt its communications with a second 136 entity, it sends a Jingle session-initiate request that specifies 137 the desired application type, a possible transport, and a TLS 138 security precondition that includes the sender's X.509 139 fingerprint and optionally hints about the sender's supported TLS 140 methods. 141 5. If both parties support XTLS, the first data sent over the 142 negotiated transport is TLS handshake data, not application data. 143 Once the TLS handshake has finished, the parties can then send 144 application data over the now-encrypted transport (called an 145 "XTLS tunnel"). 146 6. The simplest scenario is end-to-end encryption of traditional 147 XMPP text chat using end-to-end XML streams as the application 148 and in-band bytestreams [IBB] as the transport. 149 7. If the parties have previously negotiated an XTLS tunnel, during 150 the TLS negotiation each party simply needs to verify that the 151 other party is presenting the same certificate as used in 152 previous sessions. 153 8. If the parties have not previously negotiated an XTLS tunnel, 154 they need to bootstrap trust in their certificates; to do so, it 155 is encouraged to use secure remote passwords rather than leap-of- 156 faith. 158 We expand on this approach in the following section. 160 More complex scenarios are theoretically supported (e.g., encrypted 161 file transfer using SOCKS5 bytestreams and encrypted voice chat using 162 DTLS-SRTP) but have not yet been fully defined. 164 XTLS theoretically can be used to establish a TLS-encrypted streaming 165 transport or a DTLS-encrypted datagram transport, but integration 166 with DTLS [DTLS] has not yet been prototyped so use with streaming 167 transports is the more stable scenario. 169 3. XTLS Protocol Flow 171 The basic flow for an XTLS session is as follows, where traffic 172 represented by single dashes (---) is sent over the XMPP signalling 173 channel and traffic represented by double lines (===) is sent over 174 the negotiated transport. 176 Initiator Responder 177 | | 178 | session-initiate | 179 | (with security info) | 180 |--------------------------->| 181 | ack | 182 |<---------------------------| 183 | session-accept | 184 |<---------------------------| 185 | ack | 186 |--------------------------->| 187 | open transport | 188 |<==========================>| 189 | TLS ClientHello | 190 |===========================>| 191 | TLS ServerHello, [...] | 192 |<===========================| 193 | TLS [...], Finished | 194 |===========================>| 195 | TLS [...], Finished | 196 |<===========================| 197 | application data | 198 |<==========================>| 199 | session-terminate | 200 |<---------------------------| 201 | ack | 202 |--------------------------->| 203 | | 205 To simplify the description we assume here that the parties already 206 trust each other's certificates. See discussion under Section 5 for 207 information about bootstrapping of certificate trust when the parties 208 first negotiate the use of an XTLS tunnel. 210 First the initiator sends a Jingle session-initiate request (here the 211 simple case of an end-to-end text chat session using in-band 212 bytestreams [IBB]). This request includes a element that 213 contains the fingerprint of the certificate that the initiator will 214 use during the TLS negotiation and a list of TLS methods the 215 initiator supports (here certificate-based authentication [X509] and 216 TLS with Secure Remote Passwords [TLS-SRP]). Note that this 217 information is exchanged over the insecure server-based connection. 218 The purpose of the exchange is to gather information about which TLS 219 method should be used in the TLS handshake, e.g. if a client cannot 220 verify the fingerprint of the peer it MAY omit the X.509 method. If 221 both clients can verify the fingerprint of the other, it is likely 222 that X.509 certificate-based authentication will succeed (unless the 223 data is altered); if one client cannot verify the fingerprint the 224 client MAY prompt the user for a password for TLS-SRP based 225 authentication (see Section 5 for details). 227 231 232 action='session-initiate' 233 initiator='romeo@montague.lit/orchard' 234 sid='a73sjjvkla37jfea'> 235 236 237 240 241 RomeoX509CertSHA1Hash 242 243 244 245 246 247 249 The responder immediately acknowledges receipt of the session- 250 initiate by sending an IQ stanza of type "result" (not shown here). 252 Depending on the application type, a user agent controlled by a human 253 user might need to wait for the user to affirm a desire to proceed 254 with the session before continuing. When the user agent has received 255 such affirmation (or if the user agent can automatically proceed for 256 any reason, e.g. because no human intervention is expected or because 257 a human user has configured the user agent to automatically accept 258 sessions with a given entity), it returns a Jingle session-accept 259 message. This message will typically contain the offered application 260 type, transport method, and a element that includes the 261 fingerprint of the responder's X.509 certificate as well as the 262 responder's supported TLS methods. 264 268 269 action='session-accept' 270 initiator='romeo@montague.lit/orchard' 271 sid='a73sjjvkla37jfea'> 272 273 274 277 278 JulietX509CertSHA1Hash 279 280 281 282 283 284 286 The following rules apply to the responder's handling of the session- 287 initiate message: 289 1. If the responder does not support XTLS it will silently ignore 290 the element in the offer and therefore will return a 291 session-accept message without a element. 292 2. If the responder supports XTLS it MUST return a session-accept 293 message that contains a element. 294 3. If the responder thinks it will be able to verify the initiator's 295 certificate, it MUST include the fingerprint for the responder's 296 certificate in the element of the session-accept 297 message. This is the "happy path" and will occur when the 298 parties have already verified each other's certificates. 299 4. If the responder thinks it will not be able to verify the 300 initiator's certificate, it MAY omit the fingerprint for the 301 responder's certificate in the element of the 302 session-accept message. This indicates that certificate-based 303 authentication is not possible. In this case the responder 304 SHOULD signal that it wishes to use some other authentication 305 method, such as secure remote passwords (see discussion under 306 Section 5). 307 5. If the responding client cannot verify the initiator's 308 certificate, it SHOULD ask the responding user if a password was 309 exchanged between the parties that can be used for TLS-SRP. If 310 this is not the case, setting up a mutually-authenticated link 311 will fail and the responder MAY terminate the session. 313 Alternatively it could send its own fingerprint knowing it cannot 314 authenticate the initiator, in which case the responder has to 315 trust that there is no man-in-the-middle (see discussion under 316 Section 5). 318 When the responder sends the session-accept message, the initiator 319 acknowledges receipt by sending an IQ stanza of type "result" (not 320 shown here). 322 The following rules apply to the initiator's handling of the session- 323 accept message: 325 1. If the initiator receives a session-accept without a 326 element, setting up a secure transport layer has failed. The 327 initiator MAY terminate the session at this point or instead 328 proceed without securing the transport. The client SHOULD ask 329 the initiating user how to processed. This depends on the Jingle 330 application and the initiator's preferences: it makes no sense to 331 use end-to-end XML streams without encryption, but the initiator 332 might continue a file transfer without encryption. 333 2. If the initiating client cannot verify the responder's 334 certificate it SHOULD ask the initiating user if a password was 335 exchanged between the parties that can be used for TLS-SRP. If 336 this is not the case, setting up a mutually-authenticated link 337 will fail and the responder MAY terminate the session or proceed 338 with leap-of-faith (see discussion under Section 5). 340 The initiator can now determine if X.509 certificate-based 341 authentication will work or if TLS-SRP will be used. It sends an 342 additional security-info message to the responder to signal its 343 choice. This step is not really necessary because the responder will 344 see the initiator's choice in the first message of the TLS handshake, 345 but it can assist an implementation in setting up its TLS library 346 properly. Because in this section we assume that the parties already 347 have validated each other's certificates, the security method 348 signalled here is "x509". 350 354 355 action='security-info' 356 initiator='romeo@montague.lit/orchard' 357 sid='a73sjjvkla37jfea'> 358 359 360 361 362 363 364 366 The responder acknowledges receipt by sending an IQ stanza of type 367 "result" (not shown here). 369 Parallel to the security-info exchange, the clients negotiate a 370 transport for the Jingle session (here the transport is an in-band 371 bytestream as defined in [IBB], for which the Jingle negotiation 372 process is specified in [XEP-0261]; however other transports could be 373 used, for example SOCKS5 bytestreams as defined in [XEP-0065] and 374 negotiated for Jingle as specified in [XEP-0260]). Because the 375 parties wish to establish end-to-end encryption, they do not send 376 application data over the transport until the transport has been 377 secured. Therefore the first data that they exchange over the 378 transport consists of the standard four-way TLS handshake, encoded in 379 accordance with the negotiated transport method. 381 Note: Each transport MUST define a specific time when both clients 382 know that the transport is secured. When XTLS is not used, the 383 Jingle implementation would signal to the using application that 384 the transport is open when the session-accept is sent or received, 385 or when connectivity checks determine media can flow over one of 386 the transport candidates. When XTLS is used, the Jingle 387 implementation starts a TLS handshake on the transport and signals 388 to the using application that the transport is open only after the 389 TLS handshake has finished successfully. 391 During the TLS handshake, the responder MUST take the role of the TLS 392 server and the initiator MUST take the role of the TLS client. 393 Because the transport is an in-band bytestream, the TLS handshake 394 data is prepared as described in [IBB] (i.e., Base64-encoded). First 395 the initiator (acting as the TLS client) constructs a TLS 396 ClientHello, encodes it according to IBB, and sends it to the 397 responder. 399 403 406 Base64-encoded-TLS-data 407 408 410 The responder (acting as the TLS server) then acknowledges receipt by 411 sending an IQ stanza of type "result" (not shown here). 413 The responder then constructs an appropriate TLS message or messages, 414 such as a ServerHello and a CertificateRequest. 416 Note: The responder MUST send a CertificateRequest to the 417 initiator. 419 423 426 Base64-encoded-TLS-data 427 428 430 (Because in-band bytestreams are bidirectional and this data is sent 431 from the responder to the initiator, the IBB 'seq' attribute has a 432 value of zero, not 1.) 434 The initiator then acknowledges receipt by sending an IQ stanza of 435 type "result" (not shown here). 437 After some number of TLS messages, the initiator eventually sends a 438 TLS Finished message to the responder. 440 444 447 Base64-encoded-TLS-data 448 449 451 The responder then acknowledges receipt by sending an IQ stanza of 452 type "result" (not shown here). 454 The responder then also sends a TLS Finished message. 456 460 463 Base64-encoded-TLS-data 464 465 467 The initiator then acknowledges receipt by sending an IQ stanza of 468 type "result" (not shown here). 470 If the TLS negotiation has finished successfully, then the Jingle 471 implementation shall signal to the using application that the 472 transport has been secured and is ready to be used. The parties now 473 have a secure channel for the end-to-end exchange of application data 474 using XMPP as the virtual transport; we call such a channel an XTLS 475 TUNNEL. 477 4. End-to-End Streams over XTLS Protocol Flow 479 For end-to-end encryption of XMPP stanzas (, , 480 and ), the application data is an end-to-end XML stream. After 481 the XTLS tunnel is established, the peers open an XML stream over the 482 tunnel to exchange stanzas. In this example, the tunnel is 483 established using a transport of IBB, but any streaming transport 484 could be used. 486 First the initiator constructs an initial stream header. 488 495 Note: In accordance with [XMPP-CORE], the initial stream header 496 SHOULD include the 'to' and 'from' attributes, which SHOULD specify 497 the full JIDs of the clients. The initiator SHOULD include the 498 version='1.0' flag as shown in the previous example. 500 The initiator then transforms the stream header into TLS data, 501 encodes the data into IBB, and sends an IQ-set to the responder. 503 507 510 Base64-TLS-data-of-the-stream-header 511 512 514 The responder then acknowledges receipt by sending an IQ stanza of 515 type "result" (not shown here). 517 The responder then constructs a response stream header back to the 518 initiator. 520 528 The responder then sends the response stream header over the XTLS 529 tunnel. 531 535 538 Base64-TLS-data-of-the-responce-stream-header 539 540 542 The initiator then acknowledges receipt by sending an IQ stanza of 543 type "result" (not shown here). 545 Once the XML stream is established over the XTLS tunnel, either 546 entity then can send XMPP message, presence, and IQ stanzas, with or 547 without 'to' and 'from' addresses. 549 For example, the initiator could construct an XMPP message. 551 553 554 M'lady, I would be pleased to make your acquaintance. 555 556 558 The initiator then sends the message over the XTLS tunnel. 560 564 567 Base64-TLS-data 568 569 571 The responder then acknowledges receipt by sending an IQ stanza of 572 type "result" (not shown here). 574 The responder could then construct a reply. 576 578 Art thou not Romeo, and a Montague? 580 582 The responder then sends the reply over the XTLS tunnel. 584 588 591 Base64-TLS-data 592 593 595 The initiator then acknowledges receipt by sending an IQ stanza of 596 type "result" (not shown here). 598 To close the end-to-end XML stream, either party (here the responder) 599 constructs a closing element. 601 603 The client sends the closing element to the peer over the XTLS 604 tunnel. 606 610 613 Base64-TLS-data 614 615 617 The peer then acknowledges receipt by sending an IQ stanza of type 618 "result" (not shown here). 620 However, even after the end-to-end XML stream is terminated, the 621 negotiated Jingle transport (here an in-band bytestream) continues 622 and could be re-used. To completely terminate the Jingle session, 623 the terminating party would then also send a Jingle session-terminate 624 message. 626 630 634 636 The other party then acknowledges the Jingle session-terminate by 637 sending an IQ stanza of type "result" (not shown here). 639 5. Bootstrapping Trust on First Communication 641 When two parties first attempt to use XTLS, their certificates might 642 not be accepted (e.g., because they are self-signed or issued by 643 unknown certification authorities). Therefore each party needs to 644 accept the other's certificate for use in future communication 645 sessions. There are several ways to do so: 647 o Leap of faith. The recipient can hope that there is no man-in- 648 the-middle during the first communication session. If the 649 certificate does not change in future sessions, the recipient at 650 least knows that it is talking with the same entity it talked with 651 during the first session. However, that entity might be a man-in- 652 the-middle rather than the assumed communication partner. 653 Therefore, leap of faith is discouraged. 654 o Check fingerprints. The parties could validate the certificate 655 fingerprints via some trusted means outside the XMPP band, such as 656 in person, via encrypted email, or over the phone. This is not 657 user-friendly because certificate fingerprints consist of long 658 strings of letters and numbers. As a result, few humans routinely 659 check certificate fingerprints in protocols such as Secure Shell 660 (ssh). 661 o One-time password. The parties can exchange a user-friendly 662 password known only to themselves and verify it out of band before 663 the TLS handshake finishes. For this purpose, it is REQUIRED for 664 implementations to support at least one TLS cipher that uses 665 Secure Remote Password (SRP) as defined in [TLS-SRP]. 666 o Channel binding. It is possible that a future version of this 667 specification will describe how to use an appropriate Simple 668 Authentication and Security Layer (SASL) mechanism, such as 669 [SCRAM], to authenticate the XTLS tunnel after the TLS handshake 670 finishes; such a method would use the concept of channel bindings 671 as described in [RFC5056]. 673 If the parties use a password or SASL channel binding to bootstrap 674 trust, the process needs to be completed only once. After the 675 clients have authenticated with the shared secret, they can exchange 676 their certificates for future communication. 678 5.1. Exchanging Certificates 680 To retrieve the certificate of the peer for future communications, a 681 client SHOULD request the certificate according to [XEP-0189] over 682 the secure connection. This works only if XTLS was used to set up an 683 end-to-end secure XML stream; exchanging certificates if XTLS was 684 used for other purposes like file transfer is not possible. A client 685 MUST NOT request the certificate over the insecure stream-based on 686 the connection to the XMPP server. 688 692 693 695 The peer MUST return its own client certificate. If the user has 696 different clients with different client certificates and one user 697 certificate, the user certificate SHOULD also be returned. The user 698 certificate allows it to verify other client certificates using 699 public key retrieval as described in [XEP-0189]. 701 705 706 707 708 MIICCTCCAXKgAwIBAgIJALhU0Id6xxwQMA0GCSqGSIb3DQEBBQUAMA4xDDAKBgNV 709 BAMTA2ZvbzAeFw0wNzEyMjgyMDA1MTRaFw0wODEyMjcyMDA1MTRaMA4xDDAKBgNV 710 BAMTA2ZvbzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0DPcfeJzKWLGE22p 711 RMINLKr+CxqozF14DqkXkLUwGzTqYRi49yK6aebZ9ssFspTTjqa2uNpw1U32748t 712 qU6bpACWHbcC+eZ/hm5KymXBhL3Vjfb/dW0xrtxjI9JRFgrgWAyxndlNZUpN2s3D 713 hKDfVgpPSx/Zp8d/ubbARxqZZZkCAwEAAaNvMG0wHQYDVR0OBBYEFJWwFqmSRGcx 714 YXmQfdF+XBWkeML4MD4GA1UdIwQ3MDWAFJWwFqmSRGcxYXmQfdF+XBWkeML4oRKk 715 EDAOMQwwCgYDVQQDEwNmb2+CCQC4VNCHesccEDAMBgNVHRMEBTADAQH/MA0GCSqG 716 SIb3DQEBBQUAA4GBAIhlUeGZ0d0msNVxYWAXg2lRsJt9INHJQTCJMmoUeTtaRjyp 717 ffJtuopguNNBDn+MjrEp2/+zLNMahDYLXaTVmBf6zvY0hzB9Ih0kNTh23Fb5j+yK 718 QChPXQUo0EGCaODWhfhKRNdseUozfNWOz9iTgMGw8eYNLllQRL//iAOfOr/8 719 720 721 722 724 5.2. Verification of Non-Human Parties 726 If one of the parties is a "bot" (e.g., an automated service or a 727 device such as a set-top box), the password exchange is a bit more 728 complicated. It is similar to Bluetooth peering if the user has 729 access to both clients at the same time. One of the following 730 scenarios might apply: 732 o The bot can be controlled via a remote control input device. The 733 human user can enter the same password or "PIN" on both the bot 734 and the XMPP client. 735 o If the bot has no user input but does have a small display, it 736 could display a random password. The human user can then enter 737 the provided password on the XMPP client. 738 o The bot might not have enough buttons for input and might not have 739 an output screen. In that case the password is fixed. Similar to 740 Bluetooth peering with simple devices such as a headset, the 741 password will be written in the manual or printed on the device. 742 For security reasons the device SHOULD NOT use password-based 743 authentication without any user input. Many Bluetooth devices 744 have at least one button to set the device into peering mode. 745 o A bot may be associated with a web service and could display a 746 random password when the user has logged in to the web site using 747 HTTPS. This assumes that an attacker cannot at the same time both 748 control over the web server and perform a man-in-the-middle attack 749 on the XMPP channel. If the web service knows the GPG key of the 750 user it could send an encrypted email. 752 A user might have different X.509 certificates for each device. 753 [XEP-0189] can be used to manage the user's certificates. A client 754 SHOULD check the peer's PubSub node for certificates. This makes it 755 possible to use the password method only once between two users even 756 if one or both users switch clients. A user can also communicate 757 with a friend's bots: they first open a secure link between two chat 758 clients with a password and exchange the user certificates. After 759 that each device of a user can verify all devices of the other 760 without the need of a password. 762 The retrieved certificate from the PubSub node might be signed by a 763 certification authority that the client can verify. In that case the 764 client MAY skip the password authentication and rely on the X.509 765 certificate chain. The client SHOULD ask the user if the certificate 766 is acceptable or if a password exchange is desired. 768 6. Session Termination 770 If either client cannot verify the certificate of the peer or 771 receives an invalid message on the TLS layer, it MUST terminate the 772 Jingle session immediately by sending a Jingle session-terminate 773 message that includes a Jingle reason of . 775 779 783 784 785 787 The other party then acknowledges the session-terminate by sending an 788 IQ stanza of type "result" (not shown here), and the Jingle session 789 is finished. 791 7. Determining Support 793 If an entity wishes to request the use of XTLS, it SHOULD first 794 determine whether the intended responder supports the protocol. This 795 can be done directly via [XEP-0030] or indirectly via [XEP-0115]. 797 If an entity supports XTLS, it MUST report that by including a 798 service discovery feature of "urn:xmpp:jingle:security:xtls:1" in 799 response to disco#info requests. 801 805 806 808 812 813 814 815 816 818 Both service discovery and entity capabilities information could be 819 corrupted or intercepted; for details, see under Section 8.3. 821 8. Security Considerations 823 This entire document addresses security. Particular security-related 824 issues are discussed in the following sections. 826 8.1. Mandatory-to-Implement Technologies 828 An implementation MUST at a minimum support the "srp" and "x509" 829 methods. A future version of this specification will document 830 mandatory-to-implement TLS ciphers. 832 8.2. Certificates 834 As noted, XTLS can be used between XMPP clients, between an XMPP 835 client and a remote XMPP service (i.e., a service with which a client 836 does not have a direct XML stream), or between remote XMPP services. 837 Therefore, a party to an XTLS bytestream will present either a client 838 certificate or a server certificate as appropriate. Such 839 certificates MUST be generated and validated in accordance with the 840 certificate guidelines guidelines provided in [XMPP-CORE]. 842 A future version of this specification might provide additional 843 guidelines regarding certificate validation in the context of client- 844 to-client encryption. 846 8.3. Denial of Service 848 Currently XMPP stanzas such as Jingle negotiation messages and 849 service discovery exchanges are not encrypted or signed. As a 850 result, it is possible for an attacker to intercept these stanzas and 851 modify them, thus convincing one party that the other party does not 852 support XTLS and therefore denying the parties an opportunity to use 853 XTLS. 855 This is a more general problem with XMPP technologies and needs to be 856 addressed at the core XMPP layer. 858 9. IANA Considerations 860 It might be helpful to create a registry of TLS methods that can be 861 used in the context of XTLS (e.g., "openpgp" for use of [RFC5081], 862 "srp" for use of [TLS-SRP], and "x509" for use of [TLS] with 863 certificates). The registry could be maintained by the IANA or by 864 the XMPP Registrar (see [XEP-0053]). A future version of this 865 specification will provide more detailed information about the 866 registration requirements. 868 10. References 870 10.1. Normative References 872 [E2E-REQ] Saint-Andre, P., "Requirements for End-to-End Encryption 873 in the Extensible Messaging and Presence Protocol (XMPP)", 874 draft-saintandre-xmpp-e2e-requirements-01 (work in 875 progress), June 2009. 877 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, March 1997. 880 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 881 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 883 [IBB] Karneges, J., "In-Band Bytestreams (IBB)", XSF XEP 0047, 884 March 2009. 886 [JINGLE] Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 887 S., and J. Hildebrand, "Jingle", XSF XEP 0166, June 2009. 889 [XMPP-CORE] 890 Saint-Andre, P., "Extensible Messaging and Presence 891 Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-00 (work 892 in progress), June 2009. 894 10.2. Informative References 896 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 897 Security", RFC 4347, April 2006. 899 [DTLS-SRTP] 900 McGrew, D. and E. Rescorla, "Datagram Transport Layer 901 Security (DTLS) Extension to Establish Keys for Secure 902 Real-time Transport Protocol (SRTP)", 903 draft-ietf-avt-dtls-srtp-07 (work in progress), 904 February 2009. 906 [HTTP-TLS] 907 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 909 [JINGLE-FILE] 910 Saint-Andre, P., "Jingle File Transfer", XSF XEP 0234, 911 February 2009. 913 [JINGLE-RTP] 914 Ludwig, S., Saint-Andre, P., Egan, S., McQueen, R., and D. 915 Cionoiu, "Jingle RTP Sessions", XSF XEP 0167, June 2009. 917 [MUC] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 918 July 2008. 920 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 921 Channels", RFC 5056, November 2007. 923 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 924 Layer Security (TLS) Authentication", RFC 5081, 925 November 2007. 927 [TLS-SRP] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 928 "Using the Secure Remote Password (SRP) Protocol for TLS 929 Authentication", RFC 5054, November 2007. 931 [SCRAM] Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, 932 "Salted Challenge Response (SCRAM) SASL Mechanism", 933 draft-newman-auth-scram-13 (work in progress), May 2009. 935 [X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 936 Housley, R., and W. Polk, "Internet X.509 Public Key 937 Infrastructure Certificate and Certificate Revocation List 938 (CRL) Profile", RFC 5280, May 2008. 940 [XEP-0030] 941 Hildebrand, J., Millard, P., Eatmon, R., and P. Saint- 942 Andre, "Service Discovery", XSF XEP 0030, June 2008. 944 [XEP-0053] 945 Saint-Andre, P., "XMPP Registrar Function", XSF XEP 0053, 946 October 2008. 948 [XEP-0065] 949 Smith, D., Miller, M., and P. Saint-Andre, "SOCKS5 950 Bytestreams", XSF XEP 0065, May 2007. 952 [XEP-0115] 953 Hildebrand, J., Saint-Andre, P., Troncon, R., and J. 954 Konieczny, "Entity Capabilities", XSF XEP 0115, 955 February 2008. 957 [XEP-0189] 958 Paterson, I., Saint-Andre, P., and D. Meyer, "Public Key 959 Publishing", XSF XEP 0189, March 2009. 961 [XEP-0260] 962 Saint-Andre, P. and D. Meyer, "Jingle SOCKS5 Bytestreams 963 Transport Method", XSF XEP 0260, February 2009. 965 [XEP-0261] 966 Saint-Andre, P., "Jingle In-Band Bytestreams Transport", 967 XSF XEP 0261, February 2009. 969 Appendix A. XML Schema 971 The XML schema will be provided in a later version of this document. 973 Appendix B. Copying Conditions 975 Regarding this entire document or any portion of it, the authors make 976 no guarantees and are not responsible for any damage resulting from 977 its use. The authors grant irrevocable permission to anyone to use, 978 modify, and distribute it in any way that does not diminish the 979 rights of anyone else to use, modify, and distribute it, provided 980 that redistributed derivative works do not contain misleading author 981 or version information. Derivative works need not be licensed under 982 similar terms. 984 Authors' Addresses 986 Dirk Meyer 987 Universitaet Bremen TZI 989 Email: dmeyer@tzi.de 991 Peter Saint-Andre 992 Cisco 994 Email: psaintan@cisco.com