WebISO: the killer kerberos app?

[Russ Allbery]

Christopher Kranz <clk at princeton.edu> writes:

> Why not just pass the TGT, the session ticket, and the authenticator as
> cookies?  Let Kerberos do the hard stuff.  Kerberos was designed to be
> able to securely authenticate someone over an insecure network. This way
> you don't have to create new types of tokens or require that the
> connection between the web client and the web application server be
> encrypted.

No, you still have to require that the connection between the web client
and the web application server be encrypted.  The thing that you're
missing is that doing regular Kerberos involves a computational step on
the client when it constructs an authenticator for the remote service.
Since you can't get that computational step into the web browser without
doing evil things that are unlikely to be portable, you have to generate
the authenticator remotely and pass it around.  This means that the
network link has to be encrypted.

This was a topic of much discussion during the WebAuth design meetings,
and we unfortunately couldn't find any way around it.

This is one reason why we didn't just use pure Kerberos -- pure Kerberos
assumes that the client will do work, rather than just being a completely
passive ticket store the way that a browser's cookie jar is.

However, if you look at the details of the WebAuth protocol, you'll see
that it's *almost* Kerberos; the cookies are basically Kerberos tickets,
just issued by the weblogin server (what we call the WebKDC) instead of a
regular Kereros KDC.  The protocol design is almost identical, just with
some minor adjustments for the nature of the web.

We thankfully had a Kerberos expert to help us with the design and to do
the initial implementation.  :)

You could potentially get even closer to Kerberos by using the pure TGTs
and the like from Kerberos rather than doing a Kerberos-like thing inside
the WebKDC, but the difficulty there is that you then irrevocably tie the
authentication system to Kerberos.  One of the goals for the WebAuth
redesign was that we be able to support other authentication mechanisms
down the road if we need to and if the world changes, so we isolated the
reliance on Kerberos to two locations (application server to WebKDC and
internal to the weblogin server).  It would be entirely feasible, and
indeed should be fairly easy, to replace Kerberos with a smartcard system,
client-side certificates, or whatever else is your authentication
mechanism du jure.

We're happy with Kerberos, so we've not done that work, but the protocol
was designed to allow for it in anticipation that other sites may wish to
use other mechanisms.

I'm hoping to eventually find the time to put more of our design decisions
and initial requirements up on the web site, but haven't had a chance yet.
We did an evaluation of the various other WebISO projects available at the
time before we started WebAuth v3 (to replace an earlier WebAuth system
that worked somewhat similarly but was far more limited that we wrote many
years ago), but none of them could meet all of our requirements (in
particular, we hope to make extensive use of proxy authentication down the
road).

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>