Subject: [OAUTH-WG] nonce and timestamp

From: Brian Eaton <[email-masked]>
Date: Mon, 6 Jul 2009 13:03:57 -0700

Can we rewrite the nonce and timestamp section of
http://www.ietf.org/internet-drafts/draft-ietf-oauth-authentication-00.txt?

Some specific gripes:

"The timestamp value MUST be a positive integer and MUST be equal or
greater than the timestamp used in previous requests with the same
client credentials and token credentials combination."

Monotonically increasing clocks are not practical if you are sending
requests in parallel.

"Server applying such restriction SHOULD provide a way for the client
to sync its clock with the server's clock."

This is important for desktop clients.  We should define a method, in
the protocol, for a client to synchronize with the server's clock.  I
like the method defined in the OAuth problem reporting extension
(server returns a special error code along with a range of acceptable
timestamps.)

"To avoid the need to retain an infinite number of nonce values for
future checks, servers MAY choose to restrict the time period after
which a request with an old timestamp is rejected."

Is there any other reasonable way to implement the protocol?  AFAICT,
a server that does not implement time stamp checks is broken.

Cheers,
Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 06 Jul 2009 14:47:39 -0600

<hat type="individual"/>

> Monotonically increasing clocks are not practical if you are sending

A more general point: monotonically increasing clocks are not practical.
For example, an NTP update might result in a clock change backwards.

> (server returns a special error code along with a range of acceptable

How does the client know when it needs to synchronize with the server?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 06 Jul 2009 16:14:44 -0600

<hat type="individual"/>

On 7/6/09 3:52 PM, Brian Eaton wrote:
> On Mon, Jul 6, 2009 at 1:47 PM, Peter Saint-Andre<[email-masked]> wrote:
> The server tells it so.  The OAuth problem reporting extension defined
> a way to do this that is a tad verbose, but it gets the job done.
> 
> (See http://wiki.oauth.net/ProblemReporting "timestamp_refused").

Aha, I was looking in draft-ietf-oauth-authentication. It strikes me as
somewhat sub-optimal to define the error reporting codes related to
authentication in a document other than the core specification, but I'll
give it more in-depth thought sometime soon...

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Brian Eaton <[email-masked]>
Date: Mon, 6 Jul 2009 14:52:11 -0700

Cheers,
Brian

---

From: George Fletcher <[email-masked]>
Date: Tue, 07 Jul 2009 12:54:45 -0400

+1 to pulling the error-reporting extension into the core spec

Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> <hat type="individual"/>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpSd1QACgkQNL8k5A2w/vw+jACgpN+nMglxv2/NlP7qOOHfR8Ud
> rHQAnRXZNGRglpycONkLFfcj5kjJO6Ln
> =1a7H
> -----END PGP SIGNATURE-----
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>