Re: [security-services] Smart Browser

[RL 'Bob' Morgan <rlmorgan@washington.edu>]

Don et al:

> I would like to get a reading from the group on the Smart Browser
> Profile concept that I put on the mailing list a couple of weeks ago.
> There has been no discussion on this.  I would like to know whether
> this means that there is no interest and the idea should be dropped or
> whether people thought it worthwhile, in which case I would do
> additional work on it, or hated the idea.

It's necessary with this kind of thing to be clear about goals.  I think
you are interested in having more options for HTTP authentication, and in
particular having an option that "works like" Kerberos, perhaps taking
advantage of real existing Kerberos infrastructure (deployed KDCs in
particular).  Assuming I'm correct about this, there are a lot of people
interested in this kind of thing, I think, and a lot of possibilities, but
as usual with the web, a great weight of world-wide deployment issues.
Let me offer what I know, and my opinions on this.

There is a long history of trying to make Kerberos work for HTTP
authentication (and data-stream protection too), dating back to at least
1993.  My colleague Steven Carmody at Brown University wrote up a survey
of many of these several years ago:

http://www.brown.edu/Facilities/CIS/ATGTest/Infrastructure/Web_Access_Control/GoalsOptions.html

Many approaches are in production use at particular sites but nothing is
common.  Of course the limiting factor is lack of support in standard
browsers and webservers, about which much could be said, but you'll have
to catch me at the bar some time.  Here's a list of approaches that seem
at least vaguely viable to me at this point.

RFC 2712 specifies "Kerberos Cipher Suites" for TLS (aka SSL).  This
reuses the TLS messages to exchange Kerberos objects instead of X.509
objects, replacing the application-server message exchanges from RFC 1510.
This seems to me to be clean, and potentitally to fit in well with TLS/SSL
support that's already in browsers and servers.  It provides both mutual
authentication and datastream protection.  Some implementations have been
done, but none are mainstream.

Microsoft implements a GSSAPI-based method in later versions of IE and
IIS.  This can work with Kerberos and NTLM (at least), as well as
negotiating among mechanisms via SPNEGO (RFC 2478).  They recently started
documented this in draft-brezak-spnego-http-00.txt; it's being discussed
in the IETF Kerberos WG.  This puts the security material into HTTP
headers.  It provides mutual (?)  authentication but not datastream
protection (which presumably in practice would be done by TLS/SSL).  I
have heard knowledgeable Microsoft folks say that this has enough problems
that their approach to this will likely change (perhaps to RFC 2712).
I've heard about folks implementing the approach defined in this draft on
other platforms, eg Apache/Mozilla, so as to work with IE/IIS deployed
base.

The most widely designed-in authentication framework for Internet-style
protocols is SASL (RFC 2222); protocols using it include LDAP, IMAP, POP,
SMTP, ACAP, CAP, and BEEP.  Obviously HTTP is not among these.  There have
been some early proposals on making HTTP work with SASL
(draft-burdis-http-sasl-00.txt, draft-nystrom-http-sasl-00.txt).  These
are fascinating and I'd love to see this succeed, but it doesn't seem very
likely to me.  But if you want a drop-in framework that can work with
multiple already-defined security mechanisms (including SRP, though the
SASL/SRP spec isn't a standard yet), that's your baby.

None of the above has anything to do with SAML.  One could imagine a role
for SAML assertions, say as an alternative to X.509 certs in TLS, or being
part of a newly-defined SASL mechanism.  This would seem to me to be
making SAML (authn) assertions replace X.509 certs directly in some
existing protocols; I believe there is consensus that we should avoid
this.

So I think there is interesting work to be done on this topic, and venues
to do it, but that this committee is not one of them.

 - RL "Bob"