Bob
Thanks for your usual illuminating response. Also thanks for the
reference. It has been updated to -
http://www.brown.edu/Facilities/CIS/ATGTest/Infrastructure/Web_Access_Co
ntrol/GoalsOptions-ver2.html#anchorklp2 dated Oct. 1997.
You are correct in that my goal was to have more options for HTTP
authentication and my specific proposal was to use Kerberos. The bottom
line as I interpret your mail is that trying to insert a Kerberos
protocol into SAML would be a.) quite difficult and b.) not something
that we should attempt (it's still in the realm of a research project).
That was my concern when I proposed the approach. So I would say that,
at least for v 1 of SAML, it be dropped.
The browser protocols that we have are the "one-time" artifact and
possibly Shibboleth. I don't believe that a thorough cryptanalysis has
been performed on the "one-time" artifact and thus I don't feel
comfortable with proposing it as a security profile for SAML. I think
that Shibboleth is an excellent approach but it doesn't seem to cover
the general browser case that SAML is trying to address, i.e. its scope
is narrower than SAML's in some respects. An alternate approach would
be for us to declare the complete browser profile to be "out of scope"
for version 1, given that we are trying for a December completion date.
Don
-----Original Message-----
From: RL 'Bob' Morgan
Sent: Fri 10/19/2001 3:32 PM
To: Flinn, Don
Cc: Oasis Sstc (E-mail)
Subject: Re: [security-services] Smart Browser
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_Co
ntrol/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"
