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

[Tim <[e-mail]>]

I don't necessarily disagree with many of the things you mentioend
(that i've cut).

> Passwords do have the benefit that they work everywhere.  Smartcards
> requre that they be carried around.

This is the point I was trying to get at.  Until the typical user has
a brain implant to handle digital signatures, there will be a place
for methods of authentication that don't require hardware. (And even then...)



> Fortunately users now have powerful computers with them at all times
> (i.e., mobile phones).  Unfortunately these are powerful computers,
> with all attendant local security problems.  (Also, not everyone
> carries their phones with them at all times.  My daughter certainly
> doesn't, for example.  So we need to be careful here.)

Yes, I think the case for SYH is becoming more and more strong with
the way portable devices are going, but there's just so much legacy...

> I proposed an authentication framework (based on existing ones) two
> weeks ago.  It turns out that even when there's no fundamental
> objections to a proposal (or even any objections at all), the fact is
> that it's hard to get momentum going for any real solutions if those
> would require either significant investment or just significant
> re-thinking, or any sort of leap-of-faith.  (For example, in my
> proposal there's a leap-of-faith that not only will mutual
> authentication help, but that it's feasible to have such a thing on an
> Internet scale.  I don't have proof either way -- it's just a
> conjecture, though many of us believe that it is correct, but that may
> not be enough.  For another example, I believe my proposal is
> relatively simple to implement, but I've to convince others of this,
> and that, for the moment, seems difficult.  This is not a complaint --
> it is an illustration of the difficulty in achieving change here.
> Lots of smart people have been working on these problems for many
> years, and yet we're still more or less stuck with mid-90s technology
> -- it's not for want of effort or good ideas, but that momentum is
> difficult to change.)

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.  

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. 

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


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

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.

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?) 


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.  

Is there something I'm missing?

tim