Replay attacks vs man in the middle

[Martin Atkins]

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've been thinking about posting something like this for a while, but 
not really being a security weenie I thought it better to wait for one 
to appear and use all the right words.

A "nonce" seems like the right approach, though I wonder at what point 
it should be generated and by whom. From Sam's reply which I'm replying 
in parallel to, it seems that the nonce would just replace the 
timestamp. However, surely the nonce needs to be something specific to 
that request which the *consumer* can validate?

I'm probably missing a step, because it normally takes me a few goes to 
figure out all of the to-ing and fro-ing with these transactions. No 
doubt I'll slap myself on the forehead as soon as someone points out 
what I've missed! :)