> -----Original Message----- > From: Skylar Woodward [mailto:[email protected]] > Sent: Tuesday, May 31, 2011 10:54 PM
> Unfortunately though, this implementation doesn't help my use cases > because such sequential requirement of a timestamp/age requires all > devices with the token to be in sync as to the value of timestamp/age. So > let's move on. This is not true. The age value has to be monotonically increasing, but not necessarily unique. Really, any counter will do. The reason why timestamp isn't any better than age or sequence is because ultimately, it is the server's memory restriction which determines the nonces storage size, not anything else (like a time limit). I am going to change the spec to define age as any 'monotonically increasing, but not necessarily unique' positive numerical value, and give timestamp and time-since-received as two examples, along with a counter. It will also specify that if the numerical value is time-based, it MUST use seconds precision. This should provide a practical solution to everyone. When the first request comes in, it goes into storage. When the second one comes, you check if its numerical part is equal or greater than the one you previously received. If the number is smaller, you should allow for some margin in case the client is using time-based value, otherwise you reject the request. Once the storage fills, you evict the nonces with the smallest numerical values as needed. The storage size should match the speed in which clients transmit requests. Unlike timestamps, the margin can be very small, like 60 seconds, because this is time-sync across *client* machines, not the client and server. It is perfectly reasonable to expect a client sharing the same MAC credentials across multiple machines to implement clock sync keeping all machines less than a minute apart. Any kind of storage-limited nonce-checking is going to fail sometimes even for valid requests because of how the numerical part is generated and how much storage the server has (across all clients). I think this is a very reasonable compromise that in practice, will produce good results with little complexity and plenty of flexibility. The alternatives presented so far (using timestamps or offering multiple options) will fail completely for the primary use cases this specification was written for. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
