RE: [security-services] Smart Browser

["Flinn, Don" <Don.Flinn@hitachisoftware.com>]

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"

winmail.dat