Re: [http-auth] [saag] re-call for IETF http-auth BoF

[Nico Williams <[e-mail]>]

On Mon, Jun 6, 2011 at 5:11 PM, Tim <[e-mail]> wrote:
> Agreed.  One of the problems is that there are so many proposals.  I
> can't keep up with them all.  I live and breathe web security, but I
> don't have time to read up on all of the new stuff until a customer
> actually implements something and I'm asked to test it.
>
> For the average developer, figuring out which to use is just as
> difficult, if not more difficult.

We have fundamentally the following choices:

 - new TLS auth methods (but... how to upgrade existing TLS firmware, ...?)
 - new HTTP auth methods (but... how to upgrade the many HTTP stacks?)

 - new HTTP redirect-based authentication methods (with all the
problems those entail)

 - new auth methods based on TLS user (and server?) certs, such as
downloading keys and certs via SACRED, getting short-lived certs from
onine CAs (to which one authenticates via, say, a password-based
method), or via registration of random self-signed certs (where one
uses a password-based method, say, to authenticate in the cert
registration protocol)

 - application-layer auth methods

 - ?? (out-of-band authentication?)

My proposal is to do authentication at the application layer.  In most
other Internet protocols that's _exactly_ what we do: authentication
at the application layer.  What we can't do is transport protection at
the application layer (for practical reasons as well as because of
existing investments in TLS concentrators, etcetera) -- so enter
channel binding (see RFCs 5056 and 5929).

> In my experience, new technologies are most commonly adopted because
> they fill a need and they have a low implementation cost, not because
> they are the best all-around solution.  Understanding how a technology
> works is part of the implementation cost.  If you put out the most
> secure, most feature rich, and most efficient protocol possible, it
> probably won't be adopted if it isn't super easy to understand,
> implement, etc.

I believe application-layer authentication can fulfill this because no
changes are required to the existing TLS and HTTP stacks.

> For a guy like me, who spends most of his time in the trenches, it
> seems like the best approach is to have a firm idea of where you want
> to go with your framework, but release it in small digestable pieces.
> For instance, authentication protocols that can be used in very
> specific scenarios (e.g. one that replaces basic/digest auth, another
> that improves on client certificates, etc).

What if the authentication mechanisms exist, but you're only just
awaiting for a way to use them in this one class of applications?

>> How would you protect against phishing attacks via a new
>> authentication system?  I'm serious.  I believe it's possible to
>> improve the situation significantly that way, and I have my reasons,
>> but I want to hear yours.
>
> Well, we've discussed this in the past, and agreed essentially that:
>
> 0. We must assume that users will fail to validate the trust of the
>   domain they are visiting (definition of typical phishing attack)

Yes!

This means that whatever authentication method you use to authenticate
the user MUST also authenticate the server.  And, because we'll have
TLS around forever, we must have channel binding of authentication to
the TLS channel.

> 1. Authentication must be conducted outside of the web page, since
>   that will be attacker-controlled.  Proposals have been to include
>   it in the browser "chrome", but OS-level authentication could work
>   as well.  It is essential that whatever is selected as a GUI widget
>   must not be easily spoofable through fancy web features.

Yes!

See Sam Hartman's presentation from the W3C workshop two weeks ago.

> 2. In the case of password authentication, the server must prove it
>   knows the password as well.  This is what HTTP Mutual can
>   accomplish, though other protocols can accomplish it as well (TLS
>   SRP?)

Yes!  This is really just a restatement of the mutual authentication
requirement that you implied above.

> Note that this doesn't eliminate all phishing attack vectors.  An
> attacker could still phish someone by convincing them to hand out their
> personal information outside of an authenticated session.

Phishing attacks depend on the fact that humans are susceptible to
cons.  We can't prevent people for falling to cons.  HOWEVER, we may
be able to make some (not all) classes of phishing and MITM attacks
much harder, or impossible -- I believe that we can.

> Is there something I'm missing?

Channel binding :)

Nico
--