draft-ietf-xmpp-websocket-09.txt   draft-ietf-xmpp-websocket-10.txt 
XMPP Working Group L. Stout, Ed. XMPP Working Group L. Stout, Ed.
Internet-Draft &yet Internet-Draft &yet
Intended status: Standards Track J. Moffitt Intended status: Standards Track J. Moffitt
Expires: February 12, 2015 Mozilla Expires: March 14, 2015 Mozilla
E. Cestari E. Cestari
cstar industries cstar industries
August 11, 2014 September 10, 2014
An XMPP Sub-protocol for WebSocket An XMPP Sub-protocol for WebSocket
draft-ietf-xmpp-websocket-09 draft-ietf-xmpp-websocket-10
Abstract Abstract
This document defines a binding for the XMPP protocol over a This document defines a binding for the XMPP protocol over a
WebSocket transport layer. A WebSocket binding for XMPP provides WebSocket transport layer. A WebSocket binding for XMPP provides
higher performance than the current HTTP binding for XMPP. higher performance than the current HTTP binding for XMPP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2015. This Internet-Draft will expire on March 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
3.6.1. see-other-uri . . . . . . . . . . . . . . . . . . . . 8 3.6.1. see-other-uri . . . . . . . . . . . . . . . . . . . . 8
3.7. Stream Restarts . . . . . . . . . . . . . . . . . . . . . 9 3.7. Stream Restarts . . . . . . . . . . . . . . . . . . . . . 9
3.8. Pings and Keepalives . . . . . . . . . . . . . . . . . . 9 3.8. Pings and Keepalives . . . . . . . . . . . . . . . . . . 9
3.9. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . 9 3.9. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . 9
3.10. Stream Management . . . . . . . . . . . . . . . . . . . . 10 3.10. Stream Management . . . . . . . . . . . . . . . . . . . . 10
4. Discovering the WebSocket Connection Method . . . . . . . . . 10 4. Discovering the WebSocket Connection Method . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. WebSocket Subprotocol Name . . . . . . . . . . . . . . . 11 5.1. WebSocket Subprotocol Name . . . . . . . . . . . . . . . 11
5.2. URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . 11 5.2. URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Appendix B. XML Schema . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. XML Schema . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
To date, applications using the Extensible Messaging and Presence To date, applications using the Extensible Messaging and Presence
Protocol (XMPP) (see [RFC6120] and [RFC6121]) on the Web have made Protocol (XMPP) (see [RFC6120] and [RFC6121]) on the Web have made
use of BOSH (see [XEP-0124] and [XEP-0206]), an XMPP binding to HTTP. use of 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 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 high transport overhead compared to XMPP's native binding to TCP. In
addition, there are a number of other known issues with long polling addition, there are a number of other known issues with long polling
[RFC6202], which have an impact on BOSH-based systems. [RFC6202], which have an impact on BOSH-based systems.
skipping to change at page 11, line 9 skipping to change at page 11, line 9
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel="urn:xmpp:alt-connections:websocket" <Link rel="urn:xmpp:alt-connections:websocket"
href="wss://im.example.org:443/ws" /> href="wss://im.example.org:443/ws" />
</XRD> </XRD>
Servers MAY expose discovery information using host-meta documents, Servers MAY expose discovery information using host-meta documents,
and clients MAY use such information to determine the WebSocket and clients MAY use such information to determine the WebSocket
endpoint for a server. endpoint for a server.
In cases where the XMPP service domain does not match the web origin In cases where the XMPP service domain does not match the discovered
of the WebSocket endpoint, the Web-host metadata MAY be used to web origin of the WebSocket endpoint, the Web-host metadata SHOULD be
establish trust between the XMPP server domain and the WebSocket used to establish trust between the XMPP server domain and the
endpoint as long as the host-meta request and response occurred over WebSocket endpoint as long as the host-meta request and response
secure HTTP; this is especially relevant in multi-tenant situations occurred over secure HTTP; this is especially relevant in multi-
where the same WebSocket endpoint is serving multiple XMPP domains tenant situations where the same WebSocket endpoint is serving
(e.g., the XMPP service domains for both "example.com" and multiple XMPP domains (e.g., the XMPP service domains for both
"im.example.org" might be serviced by the same WebSocket endpoint at "example.com" and "im.example.org" might be serviced by the same
"hosting.example.net"). See Section 6 for related discussion. WebSocket endpoint at "hosting.example.net"). See Section 6 for
related discussion.
5. IANA Considerations 5. IANA Considerations
5.1. WebSocket Subprotocol Name 5.1. WebSocket Subprotocol Name
This specification requests IANA to register the WebSocket XMPP sub- This specification requests IANA to register the WebSocket XMPP sub-
protocol under the "WebSocket Subprotocol Name" Registry with the protocol under the "WebSocket Subprotocol Name" Registry with the
following data: following data:
Subprotocol Identifier: xmpp Subprotocol Identifier: xmpp
skipping to change at page 12, line 7 skipping to change at page 12, line 7
Specification: this document Specification: this document
Description: This is the XML namespace name for framing of Description: This is the XML namespace name for framing of
Extensible Messaging and Presence Protocol (XMPP) streams as Extensible Messaging and Presence Protocol (XMPP) streams as
defined by RFC XXXX. defined by RFC XXXX.
Registrant Contact: IESG <iesg@ietf.org> Registrant Contact: IESG <iesg@ietf.org>
6. Security Considerations 6. Security Considerations
The WebSocket binding for XMPP differs in several respects from the
TCP binding defined in [RFC6120]:
1. As described under 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 under 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 under 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 re-use 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.
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 Transport Layer Security ('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), Since application level TLS cannot be used (see Section 3.9),
applications need to protect the privacy of XMPP traffic at the applications need to protect the privacy of XMPP traffic at the
WebSocket or other appropriate layer. WebSocket or other appropriate layer.
Browser-based applications are not able to inspect and verify, at the Browser-based applications are not able to inspect and verify, at the
application layer, the certificate used for the WebSocket connection application layer, the certificate used for the WebSocket connection
to ensure that it corresponds to the domain specified as the 'to' to ensure that it corresponds to the domain specified as the 'to'
address of the XMPP stream. There are two cases: address of the XMPP stream. There are two cases:
1. If the XMPP service domain matches the origin for the WebSocket 1. If the XMPP service domain matches the origin for the WebSocket
skipping to change at page 12, line 31 skipping to change at page 13, line 31
"wss://foo.example/websocket". As long as the certificate "wss://foo.example/websocket". As long as the certificate
provided over WebSocket or HTTPS is verified according to the provided over WebSocket or HTTPS is verified according to the
rules defined for secure HTTP [RFC2818], then the browser will rules defined for secure HTTP [RFC2818], then the browser will
report the successful establishment of a secure connection to the report the successful establishment of a secure connection to the
application. (However, as noted, the application is still not application. (However, as noted, the application is still not
able to independently inspect and verify the certificate, and able to independently inspect and verify the certificate, and
needs to trust the browser; this is a limitation of existing needs to trust the browser; this is a limitation of existing
browser technologies, and thus cannot be worked around by browser technologies, and thus cannot be worked around by
WebSocket applications.) WebSocket applications.)
2. In situations where the domain of the XMPP server does not match 2. In situations where the user agent has to deal with delegation
the web origin of the WebSocket endpoint (such as multi-tenant and the domain of the XMPP server does not match the web origin
hosting situations, the host-meta process described under of the WebSocket endpoint (such as multi-tenant hosting
Section 4) MAY be used to delegate trust from the XMPP server situations), the host-meta process described under Section 4
domain to the WebSocket origin, as long as the host-meta request SHOULD be used to delegate trust from the XMPP server domain to
and response occurred over secure HTTP (with appropriate the WebSocket origin, as long as the host-meta request and
certificate verification as defined in [RFC2818]). 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' When presented with a new WebSocket endpoint via the 'see-other-uri'
attribute of a <close/> element, clients MUST NOT accept the attribute of a <close/> element, clients MUST NOT accept the
suggestion if the security context of the new endpoint is lower than suggestion if the security context of the new endpoint is lower than
the current one in order to prevent downgrade attacks from a 'wss://' the current one in order to prevent downgrade attacks from a 'wss://'
endpoint to 'ws://'. endpoint to 'ws://'.
The Security Considerations for both WebSocket (see Section 10 of The Security Considerations for both WebSocket (see Section 10 of
[RFC6455]) and XMPP (see Section 13 of [RFC6120]) apply to the [RFC6455]) and XMPP (see Section 13 of [RFC6120]) apply to the
WebSocket XMPP sub-protocol. WebSocket XMPP sub-protocol.
 End of changes. 8 change blocks. 
26 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/