Adding SASL to HTTP/1.1

1. Adding SASL to HTTP/1.1 draft-nystrom-http-sasl-07.txt Magnus Nyström, RSA Security (Magnus@rsasecurity.com) Alexey Melnikov, Isode Limited (alexey.melnikov@isode.com)

2. Benefits of using SASL in HTTP • Adds a security framework to HTTP/1.1 with programmatic possibilities and “pluggable” security • Not necessarily public key-based security like TLS • Client always authenticates, mutual authentication is possible depending on chosen SASL mechanism • SASL allows for stronger authentication mechanisms than Basic and Digest • Adds a possibility to establish a secure “End-to-End” channel between a HTTP client and server (not involving any TLS client or server)

3. Benefits of a SASL security layer • The benefit of a SASL mechanism providing a security layer is that entire HTTP messages will be protected when transmitted rather than just the HTTP body. As with TLS, once the authentication exchange has completed, the HTTP protocol exchanges continue unaware that they are being protected • Requires the use of CONNECT to avoid confusing proxies… • Avoids potential MITM attacks which may exist with tunneled authentication (see e.g. http://eprint.iacr.org/2002/163.pdf)

4. Technical details • The document describes a “full” SASL profile, including: • Both client and server can request a security handshake • Support of SASL security layers (for persistent connections) • Client can query the server for the list of available SASL mechanisms • Possibility to optimize the SASL handshake • when it is known that there is only a single applicable SASL mechanism • when the SASL mechanism requires client to send data first (“initial response” message type) • Can be used to authenticate to both the end-server and a proxy and vice versa.

5. C: GET http://classified.example.com/classified.html HTTP/1.1 Host: classified.example.com S: HTTP/1.1 401 Unauthorized Cache-Control: no-store WWW-Authenticate: SASL mechanisms="GSSAPI,KERBEROS_V4,DIGEST-MD5", realm="testrealm@example.com", id="0001" C: CONNECT classified.example.com:80 HTTP/1.1 Host: classified.example.com S: HTTP/1.1 200 OK C: GET http://classified.example.com/classified.html HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL mechanism="KERBEROS_V4", id="0001" S: HTTP/1.1 401 Unauthorized Cache-Control: no-store WWW-Authenticate: SASL id="0001", challenge=AmFYig== C: GET http://classified.example.com/classified.html HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="0001", credentials=Bac...OKi1Qh S: HTTP/1.1 401 Unauthorized Cache-Control: no-store WWW-Authenticate: SASL id="0001", challenge=or//EoAADZI= C: GET http://classified.example.com/classified.html HTTP/1.1 Cache-Control: no-store Pragma: no-cache Host: classified.example.com Authorization: SASL id="0001", credentials=DiAF5A4gA+oOIALuBkAAmw== S: HTTP/1.1 235 OK Cache-Control: no-store WWW-Authenticate: SASL id="0001" CP: GET http://classified.example.com/classified.html HTTP/1.1 Host: classified.example.com SP: HTTP/1.1 200 OK ...Requested Document follows... CP: ...Any subsequent request for a data on the same server, unless the server requests reauthentication... Example

6. Some design decisions • Use 401 as return code during SASL handshake • Allow interleaving of authentication exchanges • Avoiding sending request body with every authentication step for POST/PUT methods • Currently suggest to use POST requests with no body • Use of persistent connections • required if negotiating a security layer • not required if only doing authentication, but recommended • New 2XX status codes to specify that "authentication is complete, please resubmit the original request” • Though adds additional round-trip • Use of OPTIONS method for requesting the list of supported mechanisms

7. Persistent connection • Use of persistent connection was a subject of many debates. • HTTP experts insist that authentication should work even in absence of persistent connection • Proposed method now supports this, but: • Any server implementing SASL in HTTP in absence of a persistent connection has to deal with the following difficulties: • session caching (need to keep a cache of SASL sessions) • session expiration (can’t free SASL session on disconnect anymore) • dealing with duplicated authentication requests (client retries or attacks can make life more difficult) • keeping track of authenticated clients using some state management technique

8. Some open issues • Not dealing with how a SASL server shall track the client after authentication (in the absence of persistent connection) • Usage of the SASL "realm" parameter is underspecified

9. Prior Art • RFC 2617: "HTTP Authentication: Basic and Digest Access Authentication" defines BASIC authentication (cleartext) and DIGEST (vulnerable to man-in-the-middle attacks, no security layer) • draft-brezak-spnego-http-XX.txt by John Brezak • Works only with SPNEGO GSSAPI authentication mechanisms • Doesn’t support channel protection (authentication only). • Needs special indication from proxies that they don’t share authentication state ("Proxy-support: Session-Based-Authentication”) • draft-burdis-http-sasl-XX by Keith Burdis (expired) used HTTP Upgrade. • CONNECT is required to establish the end-to-end tunnel, as the Upgrade header is hop-by-hop. • Comments and suggestions from Keith have been incorporated into our memo (and this presentation)

10. Next step • Cleanup remaining minor outstanding issues • Comments and feedback solicited, send to authors or http-sasl@isode.com (subscribe using http-sasl-request@isode.com) • Last Call the document in July/August • Need implementations! • IESG to resist publishing documents based on HTTP Basic/Digest (e.g. Basic and Digest for SIP)?