Detecting the Man in the Middle

[Nathan D. Bowen]

Nathan D. Bowen wrote:

> a new thread to invite comment.

I've got some comments of my own, but I didn't want to pollute the 
proposal itself.

1) I am not a cryptographer, so hopefully Paul can provide guidance if 
any of my assumptions about security are incorrect.

2) My experience has only been with one specific implementation, so 
hopefully other developers can point out any hurdles they anticipate in 
their implementations.

3) Brad just announced that some code will be rolling out soon, but I 
don't know whether that means it's too late to consider this sort of 
thing for now.

> 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.

It's not inconceivable that an attacker could compromised the entire 
server site. I'd think of that attacker as more than a man in the 
*middle*. I assume that complete compromise of the server is as far out 
of OpenID's scope as is the physical security of the server's hardware 
(for example).

> 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. 

Just adding the association's dh_consumer_public as a new field to the 
identity response would suffice. Other options would include adding an 
SHA1 hash of the value instead, or adding one of those values to the 
signature input instead of adding it as a new response field.

I expect this to be the sticky point for implementors, because it places 
a new burden on the server, who now must remember the DH public value of 
its consumers.

Perhaps the server could store the value only long enough to send it 
with the first identity request for which it is relevant -- giving the 
consumer a chance to detect an attack -- and then scrap it and free up 
the memory.

Of course, the consumer couldn't scrap the stored value after the first 
UA it encounters, because that UA could be the man-in-the-middle -- but 
the server is the party that might be saving memory by calculating 
secrets instead of storing them. The consumer is already required to 
store information about each association it makes.

As a side note, since any technique for detecting a man in the middle of 
OpenID relies on subsequent requests from legitimate UAs, extremely 
*short* expirations on associations might be as suspicious as extremely 
long expirations.