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

On Tue, Dec 21, 2010 at 7:03 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> 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 username@example.com, 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!).
>

No, there is no reliance on DNSSEC here, ideally the relationship is
authenticated end-to-end using an EV cert.

DNSSEC would be acceptable however.



> 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.
> >
> >
>

Again, no.

The assumption is that you will choose an authentication provider that may
or may not be your current email provider. It is assumed that there will be
certain email forwarding taking place - at the account holder's discretion.

But if you use lame.com as your email you would end up going somewhere else
for your authentication if they won't support it.




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.
>

Raw public keys work less well than people think here.

A public key identifies a device, never a person. To make a binding to a
person you need infrastructure like I am describing here.

We are in the UK for Xmas, between the four of us we brought ten computers
(three laptops, on kindle, on iPad, two nintendo DS and three iPhones). Only
some of those devices are single user and four of the devices are shared by
all four of us.

So I would very much like to pair a federated authentication scheme for
people with a device level public key. I would also like to employ strong
two factor schemes that can be tied to device level keying. But client certs
alone do not serve this need.

-- 
Website: http://hallambaker.com/