Detecting the Man in the Middle

[Nathan D. Bowen]

This proposal was sort of buried as a tangent to another thread, but I'm 
convinced that it presents a viable improvement to the protocol. I'm 
repeating it as a new thread to invite comment.

Since OpenID is intended for use between consumers and servers who have 
no prior knowledge of each other, the DH exchanges in OpenID are 
unauthenticated (there's nothing to authenticate when your caller is 
anonymous).

Unauthenticated DH is susceptible to a man-in-the-middle attack.

A man-in-the-middle attack against unauthenticated DH is impossible to 
prevent, but the risk of an attack can be mitigated through detection.

For OpenID's purposes, authentication doesn't mean that a consumer needs 
to know *who* the server is.

What an OpenID consumer needs to know is that a signature arriving from 
a UA was generated by the server with which it associated.

A man-in-the-middle who impersonates the server from the standpoint of 
the consumer is probably not empowered to impersonate the server from 
the standpoint of all of the UAs who use that server.

Therefore, although the man-in-the-middle can obtain the MAC secret and 
use it undetected in his own UA, he cannot interfere with what the 
server will send to the consumer by way of legitimate UAs.

The server knows the DH public value of the party with whom it 
associated. If it associated with a malicious imposter, it would have 
the DH public value of the imposter -- not the DH public value of the 
consumer.

So if the server somehow includes that DH public value in a response (or 
responses) that are sent through a non-compromised UA, the consumer can 
detect whether or not a man-in-the-middle was present during the initial 
DH association.

Such a detection would provide proof that any identities verified 
against that association were invalid.