Replay attacks vs man in the middle

[Sam Ruby]

Imran Ghory wrote:
> On 5/20/05, Sam Ruby <rubys at intertwingly.net> wrote:
> 
>>Having a server issue a something unique to include in the data to be
>>signed addresses replay attacks.  As long as it is extremely unlikely
>>that the server will issue the same data again, the knowledge that the
>>listener gains is effectively useless.  This design could be improved by
>>having the server issue the openid.timestamp, and verify that the
>>timestamp returned was the one that the server initially provided.
> 
> I was about to post a message saying essentially the same thing,
> however using the timestamp id is a bad idea as an attacker could just
> launch a simultaneous attack and succeed. It is convention in
> cryptographic protocols to use a nonce in such situation, essentially
> a random number which is uninfluencable by external factors. That way
> you reduce the chance of attack significantly more.
> 
> Also I believe the reason for including timestamp is to ensure
> freshness but there doesn't seem to be anything in the protocol which
> actually verified the date/time is recent ?

I agree, nonces are better.  In fact, I would have suggested it, but I 
wanted to "ease into" this group as I am not sure yet what level of 
changes people are willing to consider.

More thoughts on nonces:

   http://www.intertwingly.net/blog/2003/09/04/Nonce

Summary: from the client's perspective, it is just a server provided 
string.  Some servers could even simply provide the timestamp as a 
nonce.  Over time, other servers -- or even the same servers -- could 
upgrade to a less predictable scheme, all without impacting the client 
in any way.

- Sam Ruby