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