Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt

[Nicolas Williams <[e-mail]>]

On Wed, Dec 05, 2007 at 04:07:33PM -0800, Roy T. Fielding wrote:
> It would be a lot more useful to have a paper or small set
> of references that explains why all these assertions are
> believed to be true.  If you have such a thing, please post it.

Let me give some context that might help:

 - First, my presentation was very strongly influenced by
   draft-hartman-webauth-phishing-06.txt.


 - Second, my primary message to the Liberty folks was this: SAML,
   CardSpace, OpenID, etcetera, all such web authentication frameworks
   will fail to prevent phishing if the don't ensure that the server
   that the browser is connected to is not an MITM, because if phishers
   cannot steal authentication credentials but can still get in the
   middle, then they can still steal from users (e.g., by
   surreptitiously making bank transfers).  Phishers will mount MITM
   attacks if that's all they can do.


 - Third, my secondary message, was about UIs and federations.

   This I did not deliver quite so succinctly, but that's fine given that
   the target audience focus on the protocol aspects of web
   authentication.  I also had very limited time to present.

   This secondary message is based on an insight I got from Sam: that in
   the face of confusables and so on, the only thing that untrained
   users can rely on is their expectations of what they should find at
   some website.

   E.g., at your bank's site you expect a login page, and once logged in
   you expect to see specific account balances.

   Now, such expectations alone cannot defeat phishers who are mounting
   an MITM attack, and anyways, once the user gives their credentials to
   the phisher the game is lost anyways.  The next step is to reinforce
   the process by adding authentication and MITM detection to try to
   address that problem, but we still need to provide something that can
   meet expectations and in a way that the phisher gets nothing useful.

   The next insight is that if we have lots of smallish federations
   around, then the thing that the user can expect at any one site, such
   as their bank, is that the browser will have authenticated them as a
   specific identity.

   Users already expect to see the authenticated name of the server in
   their browser status bar + lock icon, but this alone is not enough as
   there may be confusables and CAs/registrars cannot help as much as
   we'd like.

   But small federations, by virtue of being small, can much more easily
   prevent sites with confusable names from participating than
   CAs/registrars can.

   The UI element I have in mind is a status-bar-like element that shows
   the federation used to do authentication (and possibly also the
   user's identity in that federation).


 - To summarize: federation + a UI element showing the user's identity
   as authenticated to the server + mutual user<->server authentication
   + MITM prevention/detection = a decent solution to phishing.

   The (federation + UI element showing... + mutual auth) part deals
   with non-MITM phishers.  The MITM prevention/detection part rounds
   out the picture.


 - There are several ways to detect/prevent MITMs in these apps (which,
   today, pretty much all use TLS).

   Three of these are:

    - push authentication down into TLS
    - get rid of TLS and push cryptographic session protection up to the
      application layer
    - use channel binding of authentication at the application layer to
      the TLS channels making up the session

   Of these I believe the channel binding solution is the best.  But
   given the efforts to add GSS-API support to TLS I think we cannot
   discount the first item either.  Finally, in the OASIS WSS TC / SOAP
   world I wouldn't discount the push-session-crypto-up approach.


 - Note that the federation enrolment case can still be susceptible to
   phishing.  I.e., this scheme, if it works, pushes the opportunity for
   phishing to an area that's much less frequent that normal user web
   browsing activity.


Nico
--