WebISO: the killer kerberos app?

[Russ Allbery]

Wyllys Ingersoll <wyllys.ingersoll at sun.com> writes:

> Isn't this very similar to the what Passport and Project Liberty propose
> to use?  Basically, its a variation of the "secure cookie" scheme.
> Netegrity does something similar as well.

Right.

> Is there a comparison anywhere between webauthv3 and the WebISO used by
> the above mentioned projects?  I would be very interested in the
> comparison, just to know who is doing what, exactly, and what the
> benefits are for each system.

We don't have that documentation available at present.  I wish we'd
distilled our exploration into a web page at the time.  I'd like to hunt
up that documentation at some point.

I believe that the way that proxy credentials are handled is unique to
WebAuth, at least amongst the solutions that we surveyed.  I'm sure that
S/Ident support is unique to WebAuth, but that's probably not of that much
interest to people outside of Stanford (although I must say that S/Ident
really is an effective single sign-on solution if you don't have to worry
about NAT and other unusual network environments).

> One thing I dislike about webauth is that it is using raw KRB5 as
> opposed to the more portable and extensible GSSAPI interface.  Why was
> GSSAPI not chosen?

WebAuth only uses Kerberos v5 in one particular place, namely the
bootstrap for an application server.  Note that any authentication
protocol could be used here as far as the protocol is concerned; it's just
a matter of writing code to handle it.  Certainly if someone saw the need
for GSSAPI, it's easy to add that.

For our application, there didn't seem to be any point in incurring the
additional overhead (particularly in terms of network round trips) of
GSSAPI.  But it's certainly a decision that can be revisited.

> Using raw KRB5 protocol means tying one to a particular Kerberos
> implementation (MIT, Heimdal, Solaris, Microsoft).

Why do you say this?  That would indeed be an issue if true, but that
isn't our experience elsewhere.  We've not tried specifically with WebAuth
yet, however, at least so far as I know.

My impression is that Kerberos v5 is a standardized protocol and that
compatibility bugs are considered exactly that and fixed.  Am I being
naive about that?

> GSSAPI is a standard interface and is thus more portable across
> platforms and does not restrict a site to only using one Kerberos
> implementation.  It also does not restrict one to using Kerberos as the
> secure authentication protocol.

Note that neither does WebAuth, and the choice of Kerberos v5 for that
phase of the protocol does not restrict any more than the choice of GSSAPI
would.  Either way, in order to add another authentication mechanism you
have to write more code, and either way the protocol can handle the
situation once you've written more code.  So I think this is a red
herring.

> What about projects that just add support for new authentication methods
> like the "Auth Negotiate" scheme that Microsoft uses?  Work is being
> done by the Mozilla project to support Kerberos auth via GSSAPI in a
> compatible manner:  http://bugzilla.mozilla.org/show_bug.cgi?id=17578

I believe that all of us who are working on cookie-based hacks to
authenticate web access would be delighted if client-side support of
Kerberos made all of our work obsolete.  From past experience with other
protocols like e-mail, we're just not holding our breath.

Having a protocol in place is one thing.  Having a random PC be able to
authenticate to web pages without installing additional software is quite
another.

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