On Fri, May 20, 2011 at 4:18 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: >> Additional comments: >> >> - Using nonces for replay protection is heavy-duty. It is difficult to >> implement a reliable, secure, high-performance replay cache. (It is easy to >> implement just a high-performance replay cache: use >> memcache.) >> >> I recommend an option to use sequence numbers at the server's choice, >> understanding, of course, that requests will not be received in sequence. >> The use of a sliding sequence number window makes it possible to do at >> least as well as when using nonce, and probably faster while still being >> secure. > > We switched to use time since credentials were issued. This should be pretty > easy to implement if you really need reply protection by using a small window > (clock sync is no longer a problem, just the delay in getting the credentials > to the client, which should be a small window).
Kerberos has had an option to use time or sequence numbers for a long time. We've learned a few things from this experience. For a memcache-type implementation, timestamps are probably best because maintaining a sequence number window in memcache, synchronized, would be a pain, if not impossible. Other replay cache implementations would likely do better using sequence numbers, especially when they have a small sequence number window per-session. And, of course, memcache isn't going to be durable (but probably it will be good enough in many cases). If you set a skew window to be tight on the future side, then you can compensate for this if you can detect loss of replay data (hmmm, not likely with memcache, eh?). One big gotcha to be aware of: - Some clocks have lousy resolution, leading to easily repeated values in high-rate environments. One fix is to add resolution on the wire and use random numbers for the unused precision bits. Another solution is to not use time. My advice is that you allow the server to select which of timestamps or sequence numbers to use. Also, I strongly recommend that you specify replay cache semantics in some detail. Think of the Kerberos V5 replay cache semantics. >> - In an open wifi environment active attacks may not be very difficult, thus >> an option to secure more than just a handful of bits from the request, would >> be nice (all of the request and all of the response, say). The hard part is >> how >> to decide when to use one or the other. Ideally browsers can request more >> protection when the network is reconfigured such that there's one or more >> clear wifi interfaces. > > There is just no easy way to do that. If you need more, use TLS. But even then you need to know when to use TLS. TLS doesn't solve the problem when you're trying to solve problems without introducing TLS in the first place. This is a serious problem. You think you're fixing one problem (cookie theft by passive attackers on open networks) and you're very likely only making things somewhat harder for the attacker -- we need to be very careful that the attacker can't just automate active attacks and still win. Nico -- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
