[dix] Re: Gathering requirements for in-browser OpenID support

[Ben Laurie]

On 20/10/06, David Nicol <davidnicol at gmail.com> wrote:
> On 10/20/06, Mike Glover <mpg4 at janrain.com> wrote:
>
> > Could you explain that some more?  Specifically, how would you prevent a rogue RP from faking a redirect to the user's IdP (by proxying the request instead)?  I can't see a way that the protocol itself can guard against this.
> >
> > -mike
>
> I am sure there is a clear diagram somewhere within the POLA literature about
> how to create unproxyable capabilities, and I expect that picture describes a
> scheme where the capability is tied to the originator in such a way
> that the MITM
> would be missing something important.

You mean un-MitM-able capabilities. The holder of a capability can
always proxy it.

>
> of course, a protocol that is supposed to support users on NAT lans
> has to support
> a MITM of sorts -- the NATing router -- so there are immediately clear
> security/convenince
> tradeoffs.

? All protocols include many MitMs if you are going to call a NAT
gateway one - they're called "routers".

> Designing against theoretical MITM attacks can be impossible, since
> theoretical men
> in the middle are so capable and flexible and have unrealistic levels
> of access to
> infrastructure.

Its entirely possible. The usual weak link is users' crappy choice of passwords.

>
>
> --
> The Country Of The Blind, by H.G. Wells
> http://cronos.advenge.com/pc/Wells/p528.html
>