Re: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation

[Jeffrey Hutzelman <[e-mail]>]

On Sat, 2010-12-18 at 16:48 +0000, Phillip Hallam-Baker wrote:

> 
> As Web sites discover that their account holders cannot remember their
> username, most have adopted email addresses as account identifiers.
> That is what we should use as the basis for federated web
> authentication. 
> 
> 
> 
> 
> So if the user account identifier looks like [e-mail], how
> does an entity verify that a purported user has a valid claim to that
> account?
> 
> 
> The obvious mechanism in my view is to use DNS based discovery of an
> authentication service. For example, we might use the ESRV scheme I
> have been working on:
> 
> 
> _auth._ws.example.com  ESRV 0 prot "_saml._ws"
> _auth._ws.example.com  ESRV 0 prot "_xcat._ws"
> 
> 
> Which declares that the SAML and 'XCAT' (presumably kitten in XML)
> protocols may be used to resolve authentication requests.
> 


I see two fundamental technical problems with this approach:

1) It relies on unsecured DNS to be secure.  Particularly, you suggest
that, in order to discover a means to securely authenticate users
associated with some entity with which I have no prior relationship, I
should look up information about that entity in the DNS.  But DNSSEC is
not widely-deployed enough (yet) for that to be realistic.  Further, I'm
generally opposed to schemes that rely on the integrity of the DNS to
secure applications, because, at the enterprise level and below, the
operators of the DNS are frequently not entrusted with the security of
applications.  I mistrust any system which insists on forcing that to
change, while providing no recourse to those for whom such a policy is
unacceptable (and no, "advertise in the DNS whether to use the DNS" is
not such a recourse!).

2) It makes the assumption that my email service provider is interested
in providing authentication services to me, and that I'm interested in
giving them the ability to impersonate me to my bank.
> 
> 

I'd be much happier to see a model wherein, at registration time, I tell
a service my public key, and then it uses public-key cryptography to
authenticate me in the future.  Unfortunately, there are a number of
practical problems there, such as dealing with multiple clients per
user, kiosks, reinstalling machines, stolen credentials, etc., and it's
really preferable to avoid having every service provider deal with those
issues, rather than a much smaller number of authentication providers.