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

[Phillip Hallam-Baker <[e-mail]>]

[We seem to have dropped off the mailing lists, Jeffrey suggested I post
this which shows where we ended up.]

On Wed, Dec 22, 2010 at 3:02 AM, Jeffrey Hutzelman <[e-mail]>wrote:

> On Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote:
>
> > 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.
> >
>
> I don't follow.  Your example shows an advertisement to service
> providers that users from example.com can be authenticated to the SP by
> using one of two authentication services.
>

Yes, it is assumed that there is some means of authenticating this binding,
I did not specify what.



>  Unless I'm misunderstanding
> you, this is about how the SP knows who to trust, and _not_ about how
> the user's software talks to the user's identity provider.  Thus EV is
> really mostly irrelevant, since EV is about being able to make claims
> that are really only meaningful when the relying party is controlled by
> a human (the green bar is pretty, but I've yet to see an email server
> that evaluates users' credentials on the basis of what color location
> bar it sees).
>

You do not understand the purpose of EV then.

EV is about accountability. The green bar is displayed because the issuer
applied validation practices that ensure a measure of accountability.



> So, to accept a user's credentials, the SP needs to know two things:
> 1) Is the assertion of user identity authentic?
> 2) Does the assertion of user identity come from an authorized entity?
>
> The answer to (1) is provided by the authentication protocol in use,
> which may well be public-key based.  But that's not the part I'm worried
> about.
>
> I am worried about (2).  You show an example of one way to answer part
> or all of (2).  But you don't show how that answer is itself
> authenticated.  DNSSEC is certainly an acceptable answer to that, modulo
> a whole bunch of conditions and issues that I'm willing to handwave
> away, for now.  But I don't think it can be the _only_ answer, for
> reasons I've already raised.  So, what's the other answer?
>

If there is a federated mechanism, there is going to have to be some
registry of federation points available somewhere. We could use
fred#facebook, jim#google and so on. But if there are friendly user
identifiers and multiple auth providers there are going to be multiple
repositories to disambiguate.

So there is going to be some PKI involved however you do it.


My preference is to use DNS for the signaling layer and DNSSEC to
authenticate the in-zone data. How you authenticate the server when you
arrive at it is another matter entirely.

My view is that authentication providers should be considered to require
substantial levels of infrastructure and planning. I totally reject the view
floated in OpenID that it should be a design requirement that some fred in a
shed can whack an authentication provider together from some Perl scripts
without even bothering to upgrade to a recent version of perl.



> >         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.
> >
> Raw public keys, usually wrapped in the completely unnecessary trappings
> of a self-signed certificate, work surprisingly well in a wide variety
> of circumstances.  But they basically require first-order one-to-one
> relationships between every client and every service provider, with all
> the trappings required to deal with loss or compromise of the key, and
> that simply doesn't scale to the Internet.


CardSpace works perfectly well as a method of authenticating the client to
the authentication service. Less well as a means of federated
authentication.

Various people have proposed 'CardSpace' in the cloud. Which sounds really
convincing until you realize that they have not thought the problem through
at all.



> > To make a binding to a person you need infrastructure like I am
> > describing here.
> >
> Not necessarily.  I could imagine an infrastructure in which a user
> authenticates to some key-management service, which then hands the user
> his private key (the key belongs to the user, not the key-management
> service, so revealing it to the user is OK).  The user then uses that
> key for authentication with whatever other services he wants.  In fact,
> to services other than the key-management service, this is
> indistinguishable from the user having had the key all along.  Of
> course, it does involve the user handing his private key to some other
> service, which has its own problems.
>

I don't like that approach because in my view a private key is something
that should only ever exist in one place where it is created and later
destroyed.

I prefer an approach where the client-authentication provider authentication
uses whatever tool is best and then the authentication provider supplies
some form of token that can be used for authentication to at least one third
party.

That token could use public key, but symmetric is sufficient and more
efficient.

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