xeps/xep-0101.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>HTTP Authentication using Jabber Tickets</title>
  <abstract>This document defines a protocol for authenticating HTTP requests using Jabber Tickets.</abstract>
  &LEGALNOTICE;
  <number>0101</number>
  <status>Deferred</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>RFC 2616</spec>
    <spec>RFC 2617</spec>
    <spec>XEP-0030</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>Not yet assigned</shortname>
  <author>
    <firstname>Richard</firstname>
    <surname>Dobson</surname>
    <email>richard@dobson-i.net</email>
    <jid>richard@dobson-i.net</jid>
  </author>
  <revision>
    <version>0.2</version>
    <date>2004-01-18</date>
    <initials>red</initials>
    <remark>Expanded introduction, requirements, implementation notes, security concerns, and added server response use case.</remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2003-06-25</date>
    <initials>red</initials>
    <remark>Initial version.</remark>
  </revision>
</header>
<section1 topic='Introduction'>
  <p>Jabber Ticket Authentication is a method of authenticating with HTTP servers using your jabber identification.</p>
  <p>This allows you to login to websites using your jabber address in a single sign-on fashion similar to .NET Passport, but unlike .NET Passport is not locked into a single authentication provider.</p>
  <p>Tickets also mean the jabber ticket provider and the web server do not need to be tightly integrated for authentication to work, also because its not tightly integrated it means webmasters do not need to setup their own jabber server to provide tickets, they can use a third party provider even a central "tickets.jabber.org". Also because tickets are not tightly integrated it makes it far easier for webmasters to integrate with Jabber, it also makes web farms far more scalable and reliable.</p>
</section1>
<section1 topic='Requirements'>
  <p>The motivations for this document are:</p>
  <ul>
    <li>To provide a method of using a jabber connections authenticated stream to provide a method of authenticating with an HTTP server.</li>
    <li>To provide this authentication without needing the jabber ticket component and the webserver to be tightly coupled, this is essential in a web farm environment for scalability.</li>
    <li>To make the communication between the jabber client and the server(s) as simple as possible.</li>
  </ul>
</section1>
<section1 topic='Use Cases'>
  <section2 topic='Client web browser window requests a Jabber Ticket Authentication protected web page'>
    <example caption='Request for page'><![CDATA[
GET http://www.webserver.com/webpage.html HTTP/1.1]]></example>
    <example caption='The server responds with a 401 and WWW-Authenticate header'><![CDATA[
401 Unauthorised HTTP/1.1
WWW-Authenticate: JabberTicket realm="ticket.server.com"]]></example>
<p>The realm is the JID you need to request your JabberTicket from.</p>
  </section2>
  <section2 topic='Client requests JabberTicket'>
    <example caption='Request for ticket'><![CDATA[
<iq
    to='ticket.server.com'
    type='get'
    id='ticket1'>
  <query xmlns="http://jabber.org/protocol/ticket"/>
</iq>]]></example>
    <example caption='Server responds with jabber ticket'><![CDATA[
<iq
    to='user@domain.com/resource'
    from='ticket.server.com'
    type='result'
    id='ticket1'>
  <query xmlns="http://jabber.org/protocol/ticket">
    54yudvjhssa76dta6sgdst78r4sadsfjdhs...
  </query>
</iq>]]></example>
<p>The ticket is encrypted data represented as a string, the client does not need to decode it since it is passed to the webserver unaltered.</p>
  </section2>
  <section2 topic='Client replies to 401 HTTP error'>
    <example caption='Client HTTP request'><![CDATA[
GET http://www.webserver.com/webpage.html HTTP/1.1
Authorization: JabberTicket 54yudvjhssa76dta6sgdst78r4sadsfjdhs...]]></example>
  </section2>
  <section2 topic='Server responds and allows or denies access to the file'>
    <example caption='Server allows access'><![CDATA[
200 OK HTTP/1.1
Content-Type: text/html]]></example>
    <example caption='Server denies access'><![CDATA[
403 Forbidden HTTP/1.1]]></example>
  </section2>
</section1>
<section1 topic='Implementation Notes'>
  <p>The following guidelines may assist developers.</p>
  <ul>
    <li>The ticket can be encrypted however the provider likes since only they will need to understand it.</li>
    <li>The ticket must somewhere contain in it the JID of the end user (or some method of knowing who the user is), so that the webserver knows who it is.</li>
    <li>It is recommended that your tickets also use an extra level of authentication such as ensuring the User-Agent is the same across requests, that the ip address is the same across requests.</li>
  </ul>
</section1>
<section1 topic='Security Considerations'>
  <section2 topic='Man in the middle'>
    <p>This form of HTTP authentication is susceptable to man in the middle attack where the ticket could be captured and retransmitted by someone else, but this can be solved by using an encrypted jabber connection (e.g. HTTPS) and an HTTPS connection to the webserver.</p>
  </section2>
  <section2 topic='Key length'>
    <p>It is recommended the encryption key length for the ticket be long enough to make it hard to crack the ticket.</p>
  </section2>
  <section2 topic='Ticket expiration'>
    <p>It is recommended the ticket has an expiration and that it be between a few minutes and a few hours, e.g. 60 minutes.</p>
  </section2>
</section1>
<section1 topic='IANA Considerations'>
  <p>The HTTP authentication scheme "JabberTicket" may need to be registered with IANA.</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
  <p>The &REGISTRAR; will need to register the new namespace of "http://jabber.org/protocol/ticket".</p>
</section1>
</xep>