WebISO: the killer kerberos app?

Christopher Kranz clk at princeton.edu
Fri Mar 5 19:13:36 EST 2004


Russ Allbery <rra at stanford.edu> wrote in message news:<87znav6r15.fsf at windlord.stanford.edu>...
> 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.

Why not have the login server create the authenticator on behalf of
the person sitting behind the web client?   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.  So the only link that
need to be encrypted is the one from the web client to the login
server.  Which it had to be in any case since the password would have
to be communicated via this channel as well.


More information about the Kerberos mailing list