[Ietf-http-auth] draft-sayre-http-hmac-digest-00

Jeffrey Altman jaltman at secure-endpoints.com
Tue Mar 7 10:04:12 PST 2006


Nicolas Williams wrote:
> On Mon, Mar 06, 2006 at 04:38:42PM -0800, Hallam-Baker, Phillip wrote:
>> When people get the politics wrong then wheels need to be reinvented.
> 
> I don't know enough about the political background of SAML to comment,
> except that from a practical standpoint if we can leverage SAML to do
> things it doesn't do today (for whatever political reasons) then it's
> worth considering.
> 
> Would you reinvent Kerberos V and PKI also?  It seems to me that there's
> plenty to complain about with respect to either of those!  :)

The direction that I want to use move towards is a world in which
authentication can migrate from one set of mechanisms to another.

PK/PKI or Password or ??? can be used to obtain a Kerberos initial
ticket granting ticket (tgt).  The tgt can be used to obtain service
tickets.  Cross realm (aka Federated) acquisition of service tickets
in foreign realms can be boot-strapped by the use of PK/PKI between
the KDCs.  Kerberos service tickets can be exchanged for X.509
certificates for performing client authentication using TLS when
appropriate.

The long term goal should be a world of universal authentication so
that users can experience the benefits of single sign-on and service
providers can gain the security of credential delegation and mutual
authentication.

SAML provides the necessary tools to describe the user via attributes
which will in turn affect what the user is allowed to do or experience.
There are well understood methods for combining SAML with existing
authentication mechanisms either by embedding or by layering.  Doing
so allows SAML to easily fit into the vision of universal authentication.

Every protocol and mechanism design has strengths and weaknesses.  The
goal should be to come up with a method to leverage the best protocol
and mechanism for the task without requiring that organizations deploy
yet another independent infrastructure.

>> I am very familiar with how SAML works. My point is that we need a mechanism
>> built into the browser/server. So pointing out other uses merely confuses. 
> 
> Into the browser/server, sure, but where in the protocol stack?  SAML
> was certainly integrated in the wrong place for my taste, but I think I
> understand (or understood) why.  Integrating at the HTTP layer seems
> much cleaner to me.  But one distasteful approach to integrating, say,
> PKI, into some application wouldn't make me want to throw PKI out with
> the bath water.

Obviously we need a solution that will work with browsers but we also
need one that works when the full set of functionality found in a
browser does not exist.  When we are using HTTP for both, certainly
we would like to have one solution that works in both spaces.  I have
no objection to layering security protocols provided that we can ensure
that there is an appropriate set of bindings such that if an
authentication is taking place within HTTP or on top of HTTP and it is
being protected by TLS (anonymous-DH or otherwise) that the
authentication is bound to the TLS client and server finished messages
on both sides of the connection.

The fact that SAML was integrated at one layer in during previous
attempts at solving a problem doesn't mean it can't also be integrated
at another layer to solve a different problem space.

Jeffrey Altman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3288 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-http-auth/attachments/20060307/f5b2e40d/smime.bin


More information about the Ietf-http-auth mailing list