WebISO: the killer kerberos app?

[Russ Allbery]

Christopher Kranz <clk at princeton.edu> writes:
> Russ Allbery <rra at stanford.edu> wrote:

>> 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.

> Why not have the login server create the authenticator on behalf of the
> person sitting behind the web client?

That's exactly what we do.  The problem is that the authenticator is
portable, so in order to prevent someone from stealing it, it has to be
protected with encryption.

If we had control over the surrounding protocol and could modify the
nature of HTTP, we could use regular GSSAPI authentication, which deals
with this issue and wouldn't require the rest of the session to be
encrypted.  That's exactly the world that I want to live in long-term, but
the underlying assumption of WebAuth is that we needed to add
authentication to web sessions without requiring any software on the
client other than a standard web browser with SSL and cookie support, and
that we couldn't change anything about the HTTP protocol itself.

The authenticator that the WebKDC hands back is specific to a particular
application server, but it's not specific to a particular client.  We
could have locked it to an IP address (the whole Kerberos addressless
ticket debate), but not only is the level of security that provides
somewhat dubious, you immediately create huge problems for yourself given
NAT and similar network environments.  (Bear in mind that the WebKDC, the
application server, and the client may all disagree about the client's IP
address depending on the NAT environment the client is sitting behind.)

Does that make sense?

One other thing to keep in mind here is that you want to put the
authenticator, eventually, into a cookie.  However, one web server cannot
securely set a cookie for another web server; the best that you can do is
set a cookie for the whole domain, which is obviously problematic since
then you'd be handing the authenticator out to everyone.  So what the
WebAuth weblogin server does is create a very short-lived authenticator,
embeds it in a URL at the application server, and then sends the browser
to that URL.

The application server then receives and decodes that authenticator,
validates it, and then creates a cookie containing a more persistant
authenticator just for that service.  That cookie is, however, now that
user's identifier with respect to that service, and if someone steals that
cookie, they could masquerade as the user to that service, so the cookie
has to be protected.  Hence SSL.

The short-lived identifier times out after a minute or two, so even though
it ends up in the browser history, the security vulnerability there is
fairly low.  (It's still not ideal, and there are alternatives that are
slightly better from a security standpoint.  For example, the user could
be required to use POST to send the authenticator back to the application
server.  But embedding it in the URL has significant advantages from an
ease of use perspective, so we took that branch of the security vs. ease
of use tradeoff for this.)

> The concept I'm envisioning is split the functionality of the
> traditional Kerberos client between the web browser and the login
> server.  The web browser is the credentials cache and the login server
> contacts the KDC and does the computations required by the client.

Right, this is basically what we do.

> So the only link that need to be encrypted is the one from the web
> client to the login server.

It turns out, though, that this doesn't work because it would allow people
to steal the authenticator, particularly the persistant authenticator that
lives in the cookie.

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