By unique, does that mean statistically unique or verifiably unique? That is,
do I need store the nonce or can I just gin up a bunch of entropy of suitable
collision resistance? The latter is generally preferable.

Mike

Blaine Cook wrote:
+1. This is good.

On 19 November 2011 16:41, Eran Hammer-Lahav <[email protected]> wrote:
We had a long discussion about what to use for the numerical component of
the nonce string. I would like to suggest we use:



   nonce

         REQUIRED.  A unique string generated by the client to allow the

         server to verify that a request has never been made before and

         helps prevent replay attacks when requests are made over an

         insecure channel.  The nonce value MUST be unique across all

         requests with the same MAC key identifier.



         The nonce value MUST consist of an age, a colon character

         (%x25), and a unique string (typically random).  The age

         portion MUST be a monotonically increasing, but not necessarily

         unique, positive integer value.  The change in the age value

         between requests MUST reflect the number of seconds elapsed.

         For example, the age can be a client timestamp expressed as

         seconds since 01-01-1970 or since the credentials were issued

         to the client.  The value MUST NOT include leading zeros (e.g.

         "000273156").  For example: "273156:di3hvdf8"



         To avoid the need to retain an infinite number of nonce values

         for future checks, the server MAY choose to restrict the time

         period after which a request with an old age is rejected.  If

         such a restriction is enforced, the server SHOULD allow for a

         sufficiently large window to accommodate network delays.  The

         server SHOULD use the first age value received from the client

         to establish a method for comparing the server time with that

         of the client.  In addition, the server SHOULD accommodate small

         negative changes in age values caused by differences between

         the multiple clocks of a distributed client configuration

         utilizing more than one device.



This text keeps the age as a seconds count but uses the first request to
establish a clock sync on the server side instead of mandating one way to
calculate it.



Feedback?



EHL





_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to