summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7395.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7395.txt')
-rw-r--r--doc/rfc/rfc7395.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc7395.txt b/doc/rfc/rfc7395.txt
new file mode 100644
index 0000000..9c182ff
--- /dev/null
+++ b/doc/rfc/rfc7395.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) L. Stout, Ed.
+Request for Comments: 7395 &yet
+Category: Standards Track J. Moffitt
+ISSN: 2070-1721 Mozilla
+ E. Cestari
+ cstar industries
+ October 2014
+
+
+ An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for
+ WebSocket
+
+Abstract
+
+ This document defines a binding for the Extensible Messaging and
+ Presence Protocol (XMPP) over a WebSocket transport layer. A
+ WebSocket binding for XMPP provides higher performance than the
+ current HTTP binding for XMPP.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7395.
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Stout, et al. Standards Track [Page 1]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Terminology .....................................................3
+ 3. XMPP Subprotocol ................................................3
+ 3.1. Handshake ..................................................3
+ 3.2. WebSocket Messages .........................................4
+ 3.3. XMPP Framing ...............................................5
+ 3.3.1. Framed XML Stream ...................................5
+ 3.3.2. Framed Stream Namespace .............................5
+ 3.3.3. Stream Frames .......................................5
+ 3.4. Stream Initiation ..........................................6
+ 3.5. Stream Errors ..............................................7
+ 3.6. Closing the Connection .....................................7
+ 3.6.1. see-other-uri .......................................8
+ 3.7. Stream Restarts ............................................9
+ 3.8. Pings and Keepalives .......................................9
+ 3.9. Use of TLS .................................................9
+ 3.10. Stream Management ........................................10
+ 4. Discovering the WebSocket Connection Method ....................10
+ 5. IANA Considerations ............................................11
+ 5.1. WebSocket Subprotocol Name ................................11
+ 5.2. URN Sub-namespace .........................................11
+ 6. Security Considerations ........................................12
+ 7. References .....................................................14
+ 7.1. Normative References ......................................14
+ 7.2. Informative References ....................................14
+ Appendix A. XML Schema ............................................16
+ Acknowledgements ..................................................17
+ Authors' Addresses ................................................18
+
+1. Introduction
+
+ To date, applications using the Extensible Messaging and Presence
+ Protocol (XMPP) (see [RFC6120] and [RFC6121]) on the Web have made
+ use of Bidirectional-streams Over Synchronous HTTP (BOSH) (see
+ [XEP-0124] and [XEP-0206]), an XMPP binding to HTTP. BOSH is based
+ on the HTTP "long polling" technique, and it suffers from high
+ transport overhead compared to XMPP's native binding to TCP. In
+ addition, there are a number of other known issues with long polling
+ [RFC6202] that have an impact on BOSH-based systems.
+
+ In most circumstances, it would be much better to avoid tunneling
+ XMPP over HTTP long-polled connections and instead use XMPP directly.
+ However, the APIs and sandbox that browsers have provided do not
+ allow this. The WebSocket protocol [RFC6455] exists to solve these
+
+
+
+
+
+Stout, et al. Standards Track [Page 2]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ kinds of problems and is a bidirectional protocol that provides a
+ simple message-based framing layer, allowing for more robust and
+ efficient communication in web applications.
+
+ The WebSocket protocol enables two-way communication between a client
+ and a server, effectively emulating TCP at the application layer and,
+ therefore, overcoming many of the problems with existing long-polling
+ techniques for bidirectional HTTP. This document defines a WebSocket
+ subprotocol for XMPP.
+
+ The WebSocket binding for XMPP is designed for use by browser-based
+ applications (e.g., XMPP clients written in JavaScript). Typically,
+ these applications are used to access the same information and
+ communication opportunities (e.g., the same XMPP "roster" of
+ contacts) as clients that connect to an XMPP server over the TCP
+ binding defined in [RFC6120]. Although the only essential difference
+ is the underlying transport binding, relevant implications (e.g.,
+ framing methods and discovery processes) are highlighted in this
+ specification.
+
+2. Terminology
+
+ The basic unit of framing in the WebSocket protocol is called a
+ "message". In XMPP, the basic unit is the stanza, which is a subset
+ of the first-level children of each document in an XMPP stream (see
+ Section 9 of [RFC6120]). XMPP also has a concept of messages, which
+ are stanzas with a top-level element of <message/>. In this
+ document, the word "message" will mean a WebSocket message, not an
+ XMPP message stanza (unless otherwise noted).
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+3. XMPP Subprotocol
+
+3.1. Handshake
+
+ The XMPP subprotocol is used to transport XMPP over a WebSocket
+ connection. The client and server agree to this protocol during the
+ WebSocket handshake (see Section 1.3 of [RFC6455]).
+
+ During the WebSocket handshake, the client MUST include the value
+ 'xmpp' in the list of protocols for the 'Sec-WebSocket-Protocol'
+ header. The reply from the server MUST also contain 'xmpp' in its
+ own 'Sec-WebSocket-Protocol' header in order for an XMPP subprotocol
+ connection to be established.
+
+
+
+Stout, et al. Standards Track [Page 3]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ If a client receives a handshake response that does not include
+ 'xmpp' in the 'Sec-WebSocket-Protocol' header, then an XMPP
+ subprotocol WebSocket connection was not established and the client
+ MUST close the WebSocket connection.
+
+ Once the handshake has successfully completed, WebSocket messages
+ sent or received MUST conform to the protocol defined in the rest of
+ this document.
+
+ The following is an example of a WebSocket handshake, followed by
+ opening an XMPP stream:
+
+ C: GET /xmpp-websocket HTTP/1.1
+ Host: example.com
+ Upgrade: websocket
+ Connection: Upgrade
+ Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
+ Origin: http://example.com
+ ...
+ Sec-WebSocket-Protocol: xmpp
+ Sec-WebSocket-Version: 13
+
+ S: HTTP/1.1 101 Switching Protocols
+ Upgrade: websocket
+ Connection: Upgrade
+ ...
+ Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
+ Sec-WebSocket-Protocol: xmpp
+
+ [WebSocket connection established]
+
+ C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
+ to="example.com"
+ version="1.0" />
+
+ S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
+ from="example.com"
+ id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
+ xml:lang="en"
+ version="1.0" />
+
+3.2. WebSocket Messages
+
+ Data frame messages in the XMPP subprotocol MUST be of the text type
+ and contain UTF-8 encoded data.
+
+
+
+
+
+
+Stout, et al. Standards Track [Page 4]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+3.3. XMPP Framing
+
+ The framing method for the binding of XMPP to WebSocket differs from
+ the framing method for the TCP binding as defined in [RFC6120]; in
+ particular, the WebSocket binding adopts the message framing provided
+ by WebSocket to delineate the stream open and close headers, stanzas,
+ and other top-level stream elements.
+
+3.3.1. Framed XML Stream
+
+ The start of a framed XML stream is marked by the use of an opening
+ "stream header", which is an <open/> element with the appropriate
+ attributes and namespace declarations (see Section 3.3.2). The
+ attributes of the <open/> element are the same as those of the
+ <stream/> element defined for the 'http://etherx.jabber.org/streams'
+ namespace [RFC6120] and with the same semantics and restrictions.
+
+ The end of a framed XML stream is denoted by the closing "stream
+ header", which is a <close/> element with its associated attributes
+ and namespace declarations (see Section 3.3.2).
+
+ The introduction of the <open/> and <close/> elements is motivated by
+ the parsable XML document framing restriction in Section 3.3.3. As a
+ consequence, note that a framed XML stream does not provide a
+ wrapping <stream:stream/> [RFC6120] element encompassing the entirety
+ of the XML stream.
+
+3.3.2. Framed Stream Namespace
+
+ The XML stream headers (the <open/> and <close/> elements) MUST be
+ qualified by the namespace 'urn:ietf:params:xml:ns:xmpp-framing' (the
+ "framed stream namespace"). If this rule is violated, the entity
+ that receives the offending stream header MUST close the stream with
+ an error, which MUST be <invalid-namespace> (see Section 4.9.3.10 of
+ [RFC6120]).
+
+3.3.3. Stream Frames
+
+ The individual frames of a framed XML stream have a one-to-one
+ correspondence with WebSocket messages and MUST be parsable as
+ standalone XML documents, complete with all relevant namespace and
+ language declarations. The inclusion of XML declarations, however,
+ is NOT RECOMMENDED, as WebSocket messages are already mandated to be
+ UTF-8 encoded. Including declarations in each message would only
+ increase the framing overhead of each message.
+
+ The first character of each frame MUST be a '<' character.
+
+
+
+
+Stout, et al. Standards Track [Page 5]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ Every XMPP stanza or other XML element (including the stream open and
+ close headers) sent directly over the XML stream MUST be sent in its
+ own frame.
+
+ Example of a WebSocket message that contains an independently
+ parsable XML document:
+
+ <message xmlns="jabber:client" xml:lang="en">
+ <body>Every WebSocket message is parsable by itself.</body>
+ </message>
+
+ Note that for stream features and errors, there is no parent context
+ element providing the "stream" namespace prefix as in [RFC6120], and
+ thus the stream prefix MUST be declared or use an unprefixed form:
+
+ <stream:features xmlns:stream="http://etherx.jabber.org/streams">
+ <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
+ </stream:features>
+
+ -- OR --
+
+ <error xmlns="http://etherx.jabber.org/streams">
+ <host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
+ </error>
+
+3.4. Stream Initiation
+
+ The first message sent after the WebSocket opening handshake MUST be
+ from the initiating entity and MUST be an <open/> element qualified
+ by the 'urn:ietf:params:xml:ns:xmpp-framing' namespace and with the
+ same attributes mandated for the <stream> opening tag as described in
+ Section 4.7 of [RFC6120].
+
+ The receiving entity MUST respond with either an <open/> element
+ (whose attributes match those described in Section 4.7 of [RFC6120])
+ or a <close/> element (see Section 3.6.1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stout, et al. Standards Track [Page 6]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ An example of a successful stream initiation exchange:
+
+ C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
+ to="example.com"
+ version="1.0" />
+
+ S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
+ from="example.com"
+ id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
+ xml:lang="en"
+ version="1.0" />
+
+ Clients MUST NOT multiplex XMPP streams over the same WebSocket.
+
+3.5. Stream Errors
+
+ Stream-level errors in XMPP are fatal. Should such an error occur,
+ the server MUST send the stream error as a complete element in a
+ message to the client.
+
+ If the error occurs during the opening of a stream, the server MUST
+ send the initial open element response, followed by the stream-level
+ error in a second WebSocket message frame. The server MUST then
+ close the connection as specified in Section 3.6.
+
+3.6. Closing the Connection
+
+ The closing process for the XMPP subprotocol mirrors that of the XMPP
+ TCP binding as defined in Section 4.4 of [RFC6120], except that a
+ <close/> element is used instead of the ending </stream:stream> tag.
+
+ Either the server or the client may close the connection at any time.
+ Before closing the connection, the closing party is expected to first
+ close the XMPP stream (if one has been opened) by sending a message
+ with the <close/> element, qualified by the
+ "urn:ietf:params:xml:ns:xmpp-framing" namespace. The stream is
+ considered closed when a corresponding <close/> element is received
+ from the other party, and the XMPP session is ended.
+
+ To then close the WebSocket connection, the closing party MUST
+ initiate the WebSocket closing handshake (see Section 7.1.2 of
+ [RFC6455]).
+
+
+
+
+
+
+
+
+
+Stout, et al. Standards Track [Page 7]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ An example of ending an XMPP-over-WebSocket session by first closing
+ the XMPP stream layer and then the WebSocket connection layer:
+
+ Client (XMPP WSS) Server
+ | | | |
+ | | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
+ | |------------------------------------------------------------>| |
+ | | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
+ | |<------------------------------------------------------------| |
+ | | | |
+ | | (XMPP Stream Closed) | |
+ | +-------------------------------------------------------------+ |
+ | |
+ | WS CLOSE FRAME |
+ |------------------------------------------------------------------>|
+ | WS CLOSE FRAME |
+ |<------------------------------------------------------------------|
+ | |
+ | (Connection Closed) |
+ +-------------------------------------------------------------------+
+
+ If the WebSocket connection is closed or broken without the XMPP
+ stream having been closed first, then the XMPP stream is considered
+ implicitly closed and the XMPP session ended; however, if the use of
+ stream management resumption was negotiated (see [XEP-0198]), the
+ server SHOULD consider the XMPP session still alive for a period of
+ time based on server policy as specified in [XEP-0198].
+
+3.6.1. see-other-uri
+
+ At any point, if the server wishes to instruct the client to move to
+ a different WebSocket endpoint (e.g., for load-balancing purposes),
+ then a <close/> element is sent with the 'see-other-uri' attribute
+ set to the URI of the new connection endpoint (which MAY be for a
+ different transport method, such as BOSH (see [XEP-0124] and
+ [XEP-0206])).
+
+ Clients MUST NOT accept suggested endpoints with a lower security
+ context (e.g., moving from a 'wss://' endpoint to a 'ws://' or
+ 'http://' endpoint).
+
+ An example of the server closing a stream and instructing the client
+ to connect at a different WebSocket endpoint:
+
+ S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing"
+ see-other-uri="wss://otherendpoint.example/xmpp-bind" />
+
+
+
+
+
+Stout, et al. Standards Track [Page 8]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+3.7. Stream Restarts
+
+ Whenever a stream restart is mandated (see Section 4.3.3 of
+ [RFC6120]), both the server and client streams are implicitly closed
+ and new streams MUST be opened, using the same process as in
+ Section 3.4.
+
+ The client MUST send a new stream <open/> element and MUST NOT send a
+ closing <close/> element.
+
+ An example of restarting the stream after successful Simple
+ Authentication and Security Layer (SASL) negotiation:
+
+ S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />
+
+ [Streams implicitly closed]
+
+ C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
+ to="example.com"
+ version="1.0" />
+
+3.8. Pings and Keepalives
+
+ Traditionally, XMPP servers and clients often send "whitespace
+ keepalives" (see Section 4.6.1 of [RFC6120]) between stanzas to
+ maintain an XML stream. However, for the XMPP subprotocol each
+ message is required to start with a '<' character, and, as such,
+ whitespace keepalives MUST NOT be used.
+
+ As alternatives, the XMPP Ping extension [XEP-0199] and the XMPP
+ Stream Management extension [XEP-0198] provide pinging mechanisms.
+ Either of these extensions (or both) MAY be used to determine the
+ state of the connection.
+
+ Clients and servers MAY also use WebSocket ping control frames for
+ this purpose, but note that some environments, such as browsers, do
+ not provide access for generating or monitoring ping control frames.
+
+3.9. Use of TLS
+
+ Transport Layer Security (TLS) cannot be used at the XMPP subprotocol
+ layer because the subprotocol does not allow for raw binary data to
+ be sent. Instead, when TLS is used, it MUST be enabled at the
+ WebSocket layer using secure WebSocket connections via the 'wss' URI
+ scheme. (See Section 10.6 of [RFC6455].)
+
+
+
+
+
+
+Stout, et al. Standards Track [Page 9]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ Because TLS is to be provided outside of the XMPP subprotocol layer,
+ a server MUST NOT advertise TLS as a stream feature (see Section 4.6
+ of [RFC6120]) when using the XMPP subprotocol. Likewise, a client
+ MUST ignore any advertised TLS stream feature when using the XMPP
+ subprotocol.
+
+3.10. Stream Management
+
+ In order to alleviate the problems of temporary disconnections, the
+ client MAY use the XMPP Stream Management extension [XEP-0198] to
+ confirm when stanzas have been received by the server.
+
+ In particular, the client MAY use session resumption as described in
+ [XEP-0198] to recreate the same stream session state after a
+ temporary network unavailability or after navigating to a new URL in
+ a browser.
+
+4. Discovering the WebSocket Connection Method
+
+ Section 3 of [RFC6120] defines a procedure for connecting to an XMPP
+ server, including ways to discover the TCP/IP address and port of the
+ server using Domain Name System service (DNS SRV) records [RFC2782].
+ When using the WebSocket binding as specified in this document
+ (instead of the TCP binding as specified in [RFC6120]), a client
+ needs an alternative way to discover information about the server's
+ connection methods, since web browsers and other WebSocket-capable
+ software applications typically cannot obtain such information from
+ the DNS.
+
+ The alternative lookup process uses Web-host Metadata [RFC6415] and
+ Web Linking [RFC5988], where the link relation type is
+ "urn:xmpp:alt-connections:websocket" as described in "Discovering
+ Alternative XMPP Connection Methods" [XEP-0156]. Conceptually, the
+ host-meta lookup process used for the WebSocket binding is analogous
+ to the DNS SRV lookup process used for the TCP binding. The process
+ is as follows.
+
+ 1. Send a request over secure HTTP to the path
+ "/.well-known/host-meta" at an HTTP origin [RFC6454] that matches
+ the XMPP service domain (e.g., a URL of
+ "https://im.example.org/.well-known/host-meta" if the XMPP
+ service domain is "im.example.org").
+
+
+
+
+
+
+
+
+
+Stout, et al. Standards Track [Page 10]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ 2. Retrieve a host-meta document specifying a link relation type of
+ "urn:xmpp:alt-connections:websocket", such as:
+
+ <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
+ <Link rel="urn:xmpp:alt-connections:websocket"
+ href="wss://im.example.org:443/ws" />
+ </XRD>
+
+ Servers MAY expose discovery information using host-meta documents,
+ and clients MAY use such information to determine the WebSocket
+ endpoint for a server.
+
+ In cases where the XMPP service domain does not match the discovered
+ web origin of the WebSocket endpoint, the Web-host Metadata SHOULD be
+ used to establish trust between the XMPP server domain and the
+ WebSocket endpoint as long as the host-meta request and response
+ occurred over secure HTTP; this is especially relevant in multi-
+ tenant situations where the same WebSocket endpoint is serving
+ multiple XMPP domains (e.g., the XMPP service domains for both
+ "example.com" and "im.example.org" might be serviced by the same
+ WebSocket endpoint at "hosting.example.net"). See Section 6 for
+ related discussion.
+
+5. IANA Considerations
+
+5.1. WebSocket Subprotocol Name
+
+ IANA has registered the WebSocket XMPP subprotocol in the "WebSocket
+ Subprotocol Name Registry", with the following data:
+
+ Subprotocol Identifier: xmpp
+
+ Subprotocol Common Name: WebSocket Transport for the Extensible
+ Messaging and Presence Protocol (XMPP)
+
+ Subprotocol Definition: this document
+
+5.2. URN Sub-namespace
+
+ A URN sub-namespace for framing of Extensible Messaging and Presence
+ Protocol (XMPP) streams is defined as follows.
+
+ URI: urn:ietf:params:xml:ns:xmpp-framing
+
+ Specification: this document
+
+
+
+
+
+
+Stout, et al. Standards Track [Page 11]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ Description: This is the XML namespace name for framing of
+ Extensible Messaging and Presence Protocol (XMPP) streams as
+ defined by RFC 7395.
+
+ Registrant Contact: IESG <iesg@ietf.org>
+
+6. Security Considerations
+
+ The WebSocket binding for XMPP differs in several respects from the
+ TCP binding defined in [RFC6120]:
+
+ 1. As described in Section 4 of this document, the method for
+ discovering a connection endpoint does not use DNS SRV records as
+ in the TCP binding but instead uses Web-host Metadata files
+ retrieved via HTTPS from a URL at the XMPP service domain. From
+ a security standpoint, this is functionally equivalent to
+ resolution via DNS SRV records (and still relies on the DNS for
+ resolution of the XMPP source domain).
+
+ 2. The method for authenticating a connection endpoint uses TLS
+ (typically with PKIX certificates) as in the TCP binding, but the
+ identity to be authenticated is the connection endpoint address
+ instead of the XMPP service domain; delegation from the XMPP
+ service domain to the connection endpoint address (if any) is
+ accomplished via the discovery method described in Section 4.
+ Thus, the connection endpoint is still authenticated, and the
+ delegation is secure as long as the Web-host Metadata file is
+ retrieved via HTTPS. However, note that, in practice, this
+ option might not be employed when user agents are configured or
+ deployed for a particular delegated domain.
+
+ 3. The framing method described in Section 3.3 follows the WebSocket
+ pattern by sending one top-level XML element per WebSocket
+ message, instead of using streaming XML as in the TCP binding.
+ However, the framing method has no impact on the security
+ properties of an XMPP session (e.g., end-to-end encryption of XML
+ stanzas can be accomplished just as easily with WebSocket framing
+ as with streaming XML).
+
+ 4. In all other respects (e.g., user authentication via SASL,
+ allowable characters in XMPP addresses, and reuse of various
+ technologies such as Base 64, SASL mechanisms, UTF-8, and XML),
+ the WebSocket binding does not differ from the TCP binding and,
+ thus, does not modify the security properties of the protocol.
+ In all these respects, the security considerations of [RFC6120]
+ apply directly to the WebSocket binding.
+
+
+
+
+
+Stout, et al. Standards Track [Page 12]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ In order to ensure that communications over the WebSocket binding are
+ as secure as communications over the TCP binding, an operator needs
+ to (1) serve the Web-host Metadata file for the XMPP service domain
+ over secure HTTP ('https' URIs) only, (2) configure the WebSocket
+ connection endpoint to use TLS ('wss' URIs) only, and (3) deploy
+ certificates that properly identify the XMPP service domain and
+ WebSocket connection endpoint for usages (1) and (2), respectively.
+
+ Since application-level TLS cannot be used (see Section 3.9),
+ applications need to protect the privacy of XMPP traffic at the
+ WebSocket or other appropriate layer.
+
+ Browser-based applications are not able to inspect and verify, at the
+ application layer, the certificate used for the WebSocket connection
+ to ensure that it corresponds to the domain specified as the 'to'
+ address of the XMPP stream. There are two cases:
+
+ 1. If the XMPP service domain matches the origin for the WebSocket
+ connection, the relevant check is already performed by the
+ browser. For example, the XMPP service domain might be
+ "foo.example", and the WebSocket endpoint discovered for the link
+ relation type of "urn:xmpp:alt-connections:websocket" might be
+ "wss://foo.example/websocket". As long as the certificate
+ provided over WebSocket or HTTPS is verified according to the
+ rules defined for secure HTTP [RFC2818], then the browser will
+ report the successful establishment of a secure connection to the
+ application. (However, as noted, the application is still not
+ able to independently inspect and verify the certificate, and
+ needs to trust the browser; this is a limitation of existing
+ browser technologies and thus cannot be worked around by
+ WebSocket applications.)
+
+ 2. In situations where the user agent has to deal with delegation
+ and the domain of the XMPP server does not match the web origin
+ of the WebSocket endpoint (such as multi-tenant hosting
+ situations), the host-meta process described in Section 4 SHOULD
+ be used to delegate trust from the XMPP server domain to the
+ WebSocket origin, as long as the host-meta request and response
+ occurred over secure HTTP (with appropriate certificate
+ verification as defined in [RFC2818]).
+
+ When presented with a new WebSocket endpoint via the 'see-other-uri'
+ attribute of a <close/> element, clients MUST NOT accept the
+ suggestion if the security context of the new endpoint is lower than
+ the current one in order to prevent downgrade attacks from a 'wss://'
+ endpoint to 'ws://'.
+
+
+
+
+
+Stout, et al. Standards Track [Page 13]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ The security considerations for both WebSocket (see Section 10 of
+ [RFC6455]) and XMPP (see Section 13 of [RFC6120]) apply to the
+ WebSocket XMPP subprotocol.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000,
+ <http://www.rfc-editor.org/info/rfc2818>.
+
+ [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010,
+ <http://www.rfc-editor.org/info/rfc5988>.
+
+ [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
+ Protocol (XMPP): Core", RFC 6120, March 2011,
+ <http://www.rfc-editor.org/info/rfc6120>.
+
+ [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC
+ 6415, October 2011,
+ <http://www.rfc-editor.org/info/rfc6415>.
+
+ [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
+ 6455, December 2011,
+ <http://www.rfc-editor.org/info/rfc6455>.
+
+7.2. Informative References
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000, <http://www.rfc-editor.org/info/rfc2782>.
+
+ [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
+ Protocol (XMPP): Instant Messaging and Presence", RFC
+ 6121, March 2011,
+ <http://www.rfc-editor.org/info/rfc6121>.
+
+ [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
+ "Known Issues and Best Practices for the Use of Long
+ Polling and Streaming in Bidirectional HTTP", RFC 6202,
+ April 2011, <http://www.rfc-editor.org/info/rfc6202>.
+
+ [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
+ December 2011, <http://www.rfc-editor.org/info/rfc6454>.
+
+
+
+Stout, et al. Standards Track [Page 14]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ [XEP-0124] Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J.,
+ Stout, L., and W. Tilanus, "Bidirectional-streams Over
+ Synchronous HTTP (BOSH)", XSF XEP 0124, April 2014.
+
+ [XEP-0156] Hildebrand, J., Saint-Andre, P., and L. Stout,
+ "Discovering Alternative XMPP Connection Methods",
+ XSF XEP 0156, January 2014.
+
+ [XEP-0198] Karneges, J., Saint-Andre, P., Hildebrand, J., Forno, F.,
+ Cridland, D., and M. Wild, "Stream Management",
+ XSF XEP 0198, June 2011.
+
+ [XEP-0199] Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009.
+
+ [XEP-0206] Paterson, I., Saint-Andre, P., Stout, L., and W. Tilanus,
+ "XMPP Over BOSH", XSF XEP 0206, April 2014.
+
+ [XML-SCHEMA]
+ Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
+ "XML Schema Part 1: Structures Second Edition", World Wide
+ Web Consortium Recommendation REC-xmlschema-1-20041028,
+ October 2004,
+ <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stout, et al. Standards Track [Page 15]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+Appendix A. XML Schema
+
+ The following schema formally defines the
+ 'urn:ietf:params:xml:ns:xmpp-framing' namespace used in this
+ document, in conformance with W3C XML Schema [XML-SCHEMA]. Because
+ validation of XML streams and stanzas is optional, this schema is not
+ normative and is provided for descriptive purposes only.
+
+ <?xml version='1.0' encoding='UTF-8'?>
+
+ <xs:schema
+ xmlns:xs='http://www.w3.org/2001/XMLSchema'
+ targetNamespace='urn:ietf:params:xml:ns:xmpp-framing'
+ xmlns='urn:ietf:params:xml:ns:xmpp-framing'
+ elementFormDefault='unqualified'>
+
+ <xs:element name='open'>
+ <xs:complexType>
+ <xs:simpleContent>
+ <xs:extension base='empty'>
+ <xs:attribute name='from' type='xs:string'
+ use='optional'/>
+ <xs:attribute name='id' type='xs:string'
+ use='optional'/>
+ <xs:attribute name='to' type='xs:string'
+ use='optional'/>
+ <xs:attribute name='version' type='xs:decimal'
+ use='optional'/>
+ <xs:attribute ref='xml:lang'
+ use='optional'/>
+ </xs:extension>
+ </xs:simpleContent>
+ </xs:complexType>
+ </xs:element>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stout, et al. Standards Track [Page 16]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+ <xs:element name='close'>
+ <xs:complexType>
+ <xs:simpleContent>
+ <xs:extension base='empty'>
+ <xs:attribute name='from' type='xs:string'
+ use='optional'/>
+ <xs:attribute name='id' type='xs:string'
+ use='optional'/>
+ <xs:attribute name='see-other-uri' type='xs:anyURI'
+ use='optional'/>
+ <xs:attribute name='to' type='xs:string'
+ use='optional'/>
+ <xs:attribute name='version' type='xs:decimal'
+ use='optional'/>
+ <xs:attribute ref='xml:lang'
+ use='optional'/>
+ </xs:extension>
+ </xs:simpleContent>
+ </xs:complexType>
+ </xs:element>
+
+ <xs:simpleType name='empty'>
+ <xs:restriction base='xs:string'>
+ <xs:enumeration value=''/>
+ </xs:restriction>
+ </xs:simpleType>
+
+ </xs:schema>
+
+Acknowledgements
+
+ The authors wish to thank the following individuals for their
+ feedback: Andreas Guth, Bjoern Hoerhmann, Dave Cridland, Florian
+ Zeitz, Kurt Zeilenga, Matt Miller, Matthew Wild, Paul Aurich, Sergey
+ Dobrov, and Waqas Hussain.
+
+ Dan Romascanu reviewed the document on behalf of the General Area
+ Review Team.
+
+ During IESG review, Barry Leiba, Benoit Claise, Dan Romascanu, Jari
+ Arkko, Juergen Schoenwaelder, Spencer Dawkins, Stephen Farrell, Ted
+ Lemon, Kathleen Moriarty, and Pete Resnick caught several issues that
+ needed to be addressed.
+
+ The authors gratefully acknowledge the assistance of Peter Saint-
+ Andre as document shepherd, Ben Campbell and Joe Hildebrand as the
+ working group chairs, and Richard Barnes as the sponsoring Area
+ Director.
+
+
+
+Stout, et al. Standards Track [Page 17]
+
+RFC 7395 XMPP over WebSocket October 2014
+
+
+Authors' Addresses
+
+ Lance Stout (editor)
+ &yet
+
+ EMail: lance@andyet.net
+
+
+ Jack Moffitt
+ Mozilla
+
+ EMail: jack@metajack.im
+
+
+ Eric Cestari
+ cstar industries
+
+ EMail: eric@cstar.io
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stout, et al. Standards Track [Page 18]
+