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

[Hallam-Baker, Phillip]

> > The problem I think we need to solve is the problem of how 
> a user can 
> > authenticate to any Web site using an authentication 
> technology that 
> > they select without the need for any support from the Web 
> site whatsoever.
> 
> Then you need a framework.

No, that has been done so many times, I have done it twice myself.

> Even better -- noone but your local token should need your 
> biometric information just for those purposes, so just 
> generate a large public key, select a commenter pseudonym, 
> register the key and the pseudonym together and use that key 
> to authenticate you when using that pseudonym.

At which point the 'biometric' token looks to the system just like it was
any other smartcard or OTP token and even the auth server does not need to
care.


> Yes -- make HTTP not care about the specifics.  That means 
> abstracting the process of authentication so that apps need 
> not know about mechanism details that are not relevant to them.
> 
> That's what I mean by frameworks.

I prefer the term packaging. There are plenty of abstract frameworks out
there.


> > The browser receives the 301 not-authorized response 
> together with 'fedauth'
> > as a mechanism and a challenge nonce
> > 
> > The browser retries, the request has 2 pieces of data:
> > 	B1) A globally unique identifier for the account to be 
> accessed (e.g. 
> > pbaker at verisign.com)
> > 	B2) A bag of bits to send to the relevant auth server
> 
> No, not a bag of bits to send.  A mechanism ID, a principal 
> name and a credential handle.  The mechanism might send bits 
> in the clear, it might send bits to a KDC and get a 
> cryptographic credential, it might login to your smartcard 
> and use a cert, whatever.

My point is that as far as the web site is concerned this is simply a bag of
bits. Mechanism, schmecanism. The web site should not even know the
authentication mechanism unless the authentication server wants to let it
know.

The globally unique identifier should include the information required to
locate the auth server. I.e. it should include a DNS domain name. The SRV
record can be used for mapping from the domain name to the service name (and
yes I mean SRV this time rather than NAPTR).

OK we can argue the need for some form of mechanism ID to allow the
authentication service to support different authentication protocols on
different systems.


> This is where abstractions help the most; lacking a proper 
> abstraction you refer to "[a] bag of bits to send to the 
> relevant auth server,"
> which unnecessarily constrains the solution space in ways 
> that are bad for security.

Before you get too much into teaching me abstraction please take a look at
the author list on SAML 1.0, Web Services 1.0 and HTTP Digest Auth. 

> A proper security mechanism abstraction (which the GSS-API 
> is) does not so unnecessarily constrain the solution space; 
> to the contrary, it gives mechanism designers more freedom.

The point I am making here is that to make a system work you have to make
some decisions. GSSAPI allows those decisions to be punted off into the
indefinite future which is why so little has got done.

> > There are plenty of folk who can tell you the abstract data 
> that fits 
> > into these flows. What I do not see at this point are the two 
> > ingredients required to make the system work in practice:
> > 
> > 1) A unique identifier syntax
> > 2) The binding of the bags of bits to the HTTP protocol.
> 
> Wrong abstraction!
> 
> My alternative:
> 
> 1) mechanism ID
> 2) local principal name (with generic and/or 
> mechanism-specific syntax)
> 3) target principal name (")
> 4) credential for (2) to authenticate to (3) and/or (3) to (2).

I don't really understand what you mean by the local principle name here.
The Internet is global, the local authentication problem has been solved for
over a decade.

The problem is how to deploy an internet scale authentication scheme.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5986 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-http-auth/attachments/20060307/44d15634/smime.bin