[OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11

[Hallam-Baker, Phillip]

> From: Ben Laurie [mailto:benl at google.com] 

> > The only way that I can see that you are going to 
> circumvent an attempt using existing browser capabilities is 
> to introduce a malicious login page is through use of some 
> form of shared secret such as a picture of a cuddly animal 
> chosen by the user or Secure Letterhead.
> 
> How is this kind of shared secret a defence against a MitM?

Good question to address to those vendors selling such schemes.

There are controls that can be put in place to control attempts to capture the shared secret but these rely on a lot of active defense infrastructure that it is dangerous to assume could be deployed by low end IdPs. The bigger problem is getting users to insist on the display of their secret before entering their details. Witness the recent rash of phishing attacks against these schemes.


> > Letterhead requires a browser upgrade so it breaks the 
> 'existing capabilities' constraint.
> >
> > If you change the browser you might as well really change 
> the browser 
> > and use a strong authentication mechanism based on PKI
> 
> I'm sure you meant to say "based on asymmetric cryptography".

No, any time you have a trusted key you have an infrastructure.

Some infrastructures have much higher costs than others. Support for offline verification as the Kohnfelder architecture attempts is very expensive. Key centric architectures are much lighter weight. 

The reason I state PKI is not to say 'it must be X.509', its because PKIX got the way it did largely because people underspecified and underarchitected in the beginning and then a bunch of folk resisted necessary features rather than working out early on how to accommodate them. The result being a series of extensions on extensions and no overall coherence.