This JEP defines a protocol that enables verification of an HTTP request via Jabber.
WARNING: Consideration of this JEP has been Deferred by the Jabber Software Foundation. Implementation of the protocol described herein is not recommended.
Status: Deferred
Type: Standards Track
Number: 0070
Version: 0.5
Last Updated: 2004-04-27
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, RFC 2616, RFC 2617, JEP-0030
Supersedes: None
Superseded By: None
Short Name: http-auth
Email: linuxwolf@outer-planes.net
JID: linuxwolf@outer-planes.net
Email: jhildebrand@jabber.com
JID: hildjj@jabber.org
Email: dizzyd@jabber.org
JID: dizzyd@jabber.org
Email: stpeter@jabber.org
JID: stpeter@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "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 RFC 2119.
HTTP is a nearly-ubiquitous mechanism for the publication of information. This includes current mechanisms used to share "out-of-band" information in Jabber applications (see Out-of-Band Data [1]).
In many cases, some form of authentication between the HTTP request and the Jabber entity making the request is desired or required (e.g., to require acknowledgement of the request in Jabber band to take advantage of the user authentication provided therein). To accomplish this, an HTTP authentication scheme is proposed to tie together the Jabber and HTTP communications. This JEP describes the processes and structure for such an HTTP authentication scheme.
Additionally, web-based, Jabber-aware applications may wish to utilize known information about a JID, without prompting the user for yet another username/password combination (the first being provided through their Jabber client). An automated or "single-signon" login facility would be preferable in this case.
This JEP inherits terminology about the HyperText Transfer Protocol from RFC 2616 [2] and RFC 2617 [3].
Table 1: Terms for Entities Described Herein
| Term | Definition |
|---|---|
| HTTP Client | A client that implements the HyperText Transfer Protocol (HTTP) |
| HTTP Server | A server that implements the HyperText Transfer Protocol (HTTP) |
| Jabber Client | A client that implements the Extensible Messaging and Presence Protocol (XMPP) or its antecedents |
| Jabber Server | A server that implements the Extensible Messaging and Presence Protocol (XMPP) or its antecedents |
Note well that a Jabber Client can simultaneously be an HTTP Client (or vice-versa), and that a Jabber Server can simultaneously be an HTTP Server (or vice-versa); in fact the latter usually will be the case in order to provide a bridge between HTTP and XMPP communications. However, for the purposes of this discussion, we assume that these entities are logically if not physically separate and distinct.
The motivations for this JEP are:
The process flow for this protocol is as follows:
Error cases:
This process flow is described in more detail in the following sections.
Let us stipulate that a user (say, <juliet@capulet.com>) learns of a URL (e.g., <http://files.shakespeare.lit:9345/missive.html>). The user then attempts to retrieve the URL using her HTTP Client, which opens a TCP connection to the appropriate port of the host and sends an HTTP request as defined in RFC 2616. The request method MAY be any valid HTTP request method, including user-defined methods. In addition, the initial request MAY contain authorization credentials (as described below) in order to avoid a round trip.
If the user did not provide authorization credentials in the initial request, the HTTP Server then responds with a WWW-Authenticate response as defined in RFC 2616. The response MUST contain an HTTP 401 error and a comma-separated list of authorization schemes recognized by the HTTP Server, which SHOULD include the "x-xmpp-auth" method. Authentication schemes that do not include usernames SHOULD NOT be offered by the HTTP Server if the "x-xmpp-auth" scheme is offered. The WWW-Authenticate response SHOULD also include a realm of "xmpp" (case-sensitive).
The HTTP Client responds with an Authorization Request as defined in RFC 2616. The request MUST include the Jabber Identifier (JID) of the user making the request, preferably a full JID (<user@host/resource>), although a bare JID (<user@host>) may also be provided. Descriptions of the syntax for doing so are provided in the following subsections; however, the reader must refer to the appropriate RFCs for full details regarding authentication schemes other than "x-xmpp-auth", since they are not defined herein.
The Basic Access Authorization scheme is defined in RFC 2617. This scheme specifies that the authorization information shall consist of a userid and password, separated by a ':' character and then encoded using Base64. The profile defined herein further specifies that the userid MUST be a valid JID as described above, that the password entity SHOULD be empty, that Base64 encoding MUST adhere to Section 3 of RFC 3548 [4], and that any non-US-ASCII characters MUST be transformed into US-ASCII (in accordance with standard UTF-8 transformations) prior to encoding as Base64. Refer to RFC 2617 for information regarding the syntax of the Basic Access Authorization scheme.
The Digest Access Authorization scheme is defined in RFC 2617. This scheme specifies that the authorization information shall consist of the MD5 checksum of the username, the password, a nonce value provided in the challenge, the HTTP method, and the requested URI. The profile defined herein further specifies that the the username MUST be a valid JID as described above, that the password SHOULD be empty, and that any UTF-8 characters MUST be escaped into %HEXHEX formats prior to creating the MD5 checksum. Refer to RFC 2617 for information regarding the syntax of the Digest Access Authorization scheme.
This section defines the HTTP authentication scheme. This scheme is included mainly to provide a "trap door" for web-based Jabber clients, so that they can intercept a page load, see that the "x-xmpp-auth" mechanism is offered, and pass the user's JID directly back to the server.
RFC 2616 details the general syntax for headers, and the meaning of error codes, while Section 1 of RFC 2617 details the framework of an authentication scheme; that information is not duplicated here.
The "x-xmpp-auth" scheme challenge provides the "realm" (as required by RFC 2617). The realm MUST be "xmpp" (case-sensitive).
The "x-xmpp-auth" scheme credentials MUST provide the full or bare JID of the entity that can confirm the request. The JID MUST be provided as a quoted-string.
The enhanced BNF for the "x-xmpp-auth" Access Authorization scheme is as follows:
x-xmpp-auth-challenge := "x-xmpp-auth" 1*SP "realm" "=" "xmpp">
x-xmpp-auth-credentials := "x-xmpp-auth" 1*SP "jid" "=" \
<quoted-string>
jid := XMPP address as specified in XMPP-CORE
The HTTP Server MAY offer any other valid authorization scheme, instead of or in addition to the Basic and Digest schemes mentioned above.
Once the HTTP Client has communicated the full JID or bare JID to the HTTP Server, the Jabber Server sends a confirmation request (via XMPP) to the Jabber Client. If the JID provided was a full JID, the confirmation request SHOULD be sent in an <iq/> stanza of type "get" whose 'to' attribute is set to the full JID, but MAY be sent in a <message/> stanza. If the JID provided was a bare JID, the confirmation request MUST be sent in a <message/> stanza whose 'to' attribute is set to the bare JID; this enables delivery to the "most available" resource for the user (however "most available" is determined by the Jabber Server).
Example 1. Confirmation Request Sent via IQ
<iq type='get'
from='files.shakespeare.lit'
to='juliet@capulet.com/balcony'
id='ha000'>
<confirm xmlns='http://jabber.org/protocol/http-auth'
method='GET'
url='http://files.shakespeare.lit:9345/missive.html'/>
</iq>
Example 2. Confirmation Request Sent via Message
<message type='normal'
from='files.shakespeare.lit'
to='juliet@capulet.com'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<body>
Someone (maybe you) has requested the file
http://files.shakespeare.lit:9345/missive.html.
If you wish to confirm the request, please reply
to this message by typing "OK". If not, please
reply with "No".
</body>
<confirm xmlns='http://jabber.org/protocol/http-auth'
method='GET'
url='http://files.shakespeare.lit:9345/missive.html'/>
</message>
The <confirm/> element MUST possess both a 'url' attribute and a 'method' attribute; the value of the 'url' attribute MUST be the full path of the HTTP object requested and the value of the 'method' attribute MUST be a valid HTTP method.
In addition, the <confirm/> element MAY possess an 'id' attribute; see the Implementation Notes for details.
If provided, the <thread/> element and its XML character data value MUST be mirrored in any message reply.
If the confirmation request was provided via an <iq/> stanza, the Jabber Client MUST respond to the request by sending an <iq/> stanza back to the Jabber Server. If the user wishes to confirm the request, the Jabber Client MUST reply; the <iq/> response stanza MUST be of type "result" and MAY contain the original <confirm/> child element (although this is not required):
Example 3. Jabber Client Confirms Request via IQ
<iq type='result'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'
id='ha000'/>
If the user wishes to deny the request, the Jabber Client MUST reply; the <iq/> response stanza MUST be of type "error", MAY contain the original <confirm/> child element (although this is not required), and MUST specify an error, which SHOULD be "Not Authorized":
Example 4. Jabber Client Denies Request via IQ
<iq type='error'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'
id='ha000'>
<confirm xmlns='http://jabber.org/protocol/http-auth'
method='GET'
url='http://files.shakespeare.lit:9345/missive.html'/>
<error code='401' type='auth'>
<not-authorized xmlns='urn:ietf:params:xml:xmpp-stanzas'/>
</error>
</iq>
If the confirmation request was provided via a <message/> stanza, the Jabber Client SHOULD respond to the request by sending a <message/> stanza back to the Jabber Server. If the user wishes to confirm the request, the Jabber Client MUST reply; the <message/> response stanza SHOULD be of type "normal", SHOULD mirror the <thread/> ID (if provided), and MAY contain the original <confirm/> child element (although this is not required):
Example 5. Jabber Client Confirms Request via Message
<message type='get'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<body>OK</body>
<confirm xmlns='http://jabber.org/protocol/http-auth'
method='GET'
url='http://files.shakespeare.lit:9345/missive.html'/>
</message>
If the user wishes to deny the request, the Jabber Client MUST reply; the <message/> response stanza MUST be of type "error", SHOULD mirror the <thread/> ID (if provided), MAY (but is NOT REQUIRED to) contain the original <confirm/> child element, and MUST specify an error, which SHOULD be "Not Authorized":
Example 6. Jabber Client Denies Request via Message
<message type='error'
from='juliet@capulet.com/balcony'
to='files.shakespeare.lit'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<body>No</body>
<confirm xmlns='http://jabber.org/protocol/http-auth'
method='GET'
url='http://files.shakespeare.lit:9345/missive.html'/>
<error code='401' type='auth'>
<not-authorized xmlns='urn:ietf:params:xml:xmpp-stanzas'/>
</error>
</message>
Once the Jabber Client has successfully confirmed the request, the HTTP Server allows access:
Example 7. HTTP Server Allows Access to Object
200 OK HTTP/1.1
Content-Type: text/html
Content-Length: 3032
...
If the Jabber Client denied the request, the HTTP Server MUST return a Forbidden error:
Example 8. HTTP Server Denies Access to Object
403 Forbidden HTTP/1.1
For the HEAD and OPTIONS methods, the credentials SHOULD be usable for a subsequent request from the same entity. This would allow for an entity to both determine support for this mechanism and start the authentication process.
For the POST and PUT methods (or any method containing a message body), clients MUST send all data with each request; the HTTP server is under no obligation to assume that the client will fail. This is especially true since the client can obtain credentials with a previous HEAD or OPTIONS method.
As noted above and as specified in the schema, the <confirm/> element MAY possess an 'id' attribute. If included, this attribute SHOULD be used to track requests between the HTTP client and the XMPP client; to ensure proper tracking, the ID SHOULD be generated by the HTTP client (or provided by the end user) and included as the value of the password entity within the basic or digest authentication scheme, then passed unchanged to the XMPP client as the value of the <confirm/> element's 'id' attribute.
The authentication mechanism is still vulnerable to man-in-the-middle attacks. It may be less vulnerable than HTTP "basic" or "digest" authentication, in that it utilizes an outside connection for a significant amount of the negotiation. This outside channel may be more trusted than the initial HTTP connection can be.
Additionally, this authentication scheme can be used with Secure HTTP (HTTPS) and RFC 2817 [5]. In this case, the authentication scheme is used to associate the connection to the involved JIDs, and relies on SSL/TLS to authenticate the connection.
For added security, the Jabber Server and Jabber Client may wish to communicate using end-to-end encryption. Methods for doing so are outside the scope of this proposal.
The HTTP authentication scheme "x-xmpp-auth" may be registered with the Internet Assigned Numbers Authority (IANA) [6], although this is not strictly necessary.
Upon advancement of this proposal to a status of Draft, the Jabber Registrar [7] shall add the 'http://jabber.org/protocol/http-auth' namespace to its registry of protocol namespaces.
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/http-auth'
xmlns='http://jabber.org/protocol/http-auth'
elementFormDefault='qualified'>
<xs:element name='confirm'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='id' use='optional' type='xs:string'/>
<xs:attribute name='method' use='required' type='xs:NCName'/>
<xs:attribute name='url' use='required' type='xs:anyURI'/>
</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>
1. JEP-0066: Out of Band Data <http://www.jabber.org/jeps/jep-0066.html>.
2. RFC 2616: Hypertext Transport Protocol -- HTTP/1.1 <http://www.ietf.org/rfc/rfc2616.txt>.
3. RFC 2617: HTTP Authentication: Basic and Digest Access Authentication <http://www.ietf.org/rfc/rfc2617.txt>.
4. RFC 3548: The Base16, Base32, and Base64 Data Encodings <http://www.ietf.org/rfc/rfc3548.txt>.
5. RFC 2817: Upgrading to TLS Within HTTP/1.1 <http://www.ietf.org/rfc/rfc2817.txt>.
6. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
7. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
END