Replay attacks vs man in the middle

[Brad Fitzpatrick]

Regarding nonce vs. timestamp and why it doesn't matter:

The man-in-the-middle this is preventing is an identity server in the
middle, posing as a browser to the real identity server.  When I first got
into this and went through several schemes, it quickly became apparent
that almost anything a browser could do, an identity-server-in-the-middle
could appear to do too.  The only differences were that:

 -- a real browser knew the identity server's cookies
 -- a real browser would follow redirects faithfully

Hence the TypeKey-like redirect.  If somebody can sniff your traffic and
get the DSA signature in the redirect from identity site to consumer, wow!
They know you're you!  They already knew that from sniffing the rest of
your cookies and LJ traffic.

If a pair of sites cares about that, they both use SSL.

The DSA signature with timestamp is there so consumers who DO care about
freshness can use the timestamp to make sure a signature was issued only
in the past $n minutes.  And because the signature as a whole was signed
using a random number, the entire signature itself is a nonce, so the
consumer site can prevent replay attacks by just not accepting that digest
ever again.

That said, am I still missing something?

If the problem is purely doc updates, recommend away.

- Brad


On Fri, 20 May 2005, Sam Ruby wrote:

> Disclaimer: I am not a security weanie, nor do I play one on TV.  But
> based on what I know...
>
> Replay attacks are where somebody is able to passively listen into
> network traffic, and gather some data that enables them to later send a
> message as if it were from you.
>
> Man in the middle attacks are where somebody actively is able to
> intercept and replace network traffic, with the recipient being unaware
> of the change.
>
> 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.
>
> Unfortunately, even this is not sufficient to prevent man in the middle
> attacks.  All the man in the middle needs to do is be patient - allow
> the traffic to flow normally until the one message which contains the
> full DSA signature is sent, and intercept that one.
>
> In general, the way to address man in the middle attacks involves either
> generating a hash -- or outright encoding -- over the full message.  An
> example of such an approach can be found here:
>
>    http://golem.ph.utexas.edu/~distler/blog/archives/000320.html
>
> Also note that the verify operation is something that is delayed in
> Jacques's implementation.  This can be important from two perspectives:
> eliminating delays and handling temporary network connectivity issues.
>
> Finally, let me point out that I recognize that it is quite likely that
> this project is not aiming for government auditable levels of security.
>   As such, I am not suggesting that this needs to address
> man-in-the-middle attacks.  I'd only suggest that some of the smaller
> changes above be considered, and otherwise the documentation be adjusted
> to avoid setting up false expectations.
>
> - Sam Ruby
> _______________________________________________
> yadis mailing list
> yadis at lists.danga.com
> http://lists.danga.com/mailman/listinfo/yadis
>
>