Subject: [http-auth] HTTP auth NG first step: determine constraints

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Dec 2010 12:23:08 -0600

We want to improve authentication for HTTP applications (both, browser-
based and non-browser-based).

One place to start would be to enumerate or choose the constraints that
apply or should apply.

Here are some example constraints.  Some subset of these might be chosen
or found to apply.  Some are exclusive of others.  Some are facetious.

a) No changes to HTTP, period.
b) No changes to how HTTP and TLS (in HTTPS) interact, period.
c) Limited changes to HTTP for communicating extended TLS state
   information to applications are allowed, but other changes to HTTP
   are not.
d) HTTP applications must provide their own session management; HTTP is
   stateless, period.
e) HTTP must provide session management, thus no longer being stateful.

The above set of example constraints we could choose from is not
complete.

Hopefully you can see how the set of applicable constraints might vary
by application (particularly along the browser/non-browser division).
And hopefully you can see how they affect possible designs.  Also, I'm
sure we'll reject some such constraints immediately, such as (e).

My idea of "GSS-REST" [0] meets constraints (a), (b), and (d), at a cost of
additional round-trips.

My idea of HTTPS using TLS/SA [1] meets (c) and (d), but not (a) and not
(b).

Other possibilities include authentication enhancements to TLS that
don't modify the TLS state machine (e.g., doesn't add round-trips) --
meets (c), (d), and maybe (b) but no (a) -- or making HTTP use
SASL/GS2 or the GSS-API directly -- meets at most (d).

Determining the constraints will delineate the solutions.  So let us
start by determining the constraints that apply and/or that we want.

My guess is that we'll end up with two solutions: one for browser-like
applications, and one for most non-browser applications.  I'd be fine
with that.

[0] Use POST/GET to implement a SASL or GSS-API authentication message
    exchange, using channel binding to TLS, using TLS server certs, and
    using secure cookies to avoid authenticating every request and to
    manage session state at the application layer.  This is specifically
    designed to be RESTful.

[1] draft-williams-tls-app-sasl-opt-04.txt.

Nico
--