Detecting the Man in the Middle
Nathan D. Bowen
nbowen+yadis at andtonic.com
Thu Jun 23 22:47:13 PDT 2005
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
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
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
Such a detection would provide proof that any identities verified
against that association were invalid.
More information about the yadis