Subject: [OAUTH-WG] Timestamp and sync

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 23:52:36 -0700

I am going to base the new HMAC method closely after the current HMAC-SHA1 method (SHA1 will be negotiable and might be replaced as the base protocol to something more current, but this is off topic). This means we will need to deal with timestamps to prevent replay attacks.

Tim Polk made a comment today on the 1.0 RFC draft that the server should be able to simply tell the client to use a trusted time service for clock synchronization. Since timestamp management has been a problematic issue for many, I feel we need to address it in the new spec to ensure it will not cause interop issues.

The two main options are:

1. Create a new simple mechanism for clock sync (via error message or API call).
2. Have the server point the client to a trusted time service (which the server can run if desired), using a protocol we pick such as NTP (RFC 1305).

Comments?

EHL

---

From: George Fletcher <[email-masked]>
Date: Thu, 03 Dec 2009 09:23:40 -0500

+1 to option #1

Given that some OAuth clients will be desktop apps (and not web 
servers), I think it's very scary to change the time on a person's 
machine who may have specifically changed it (for some reason).  As for 
real-world implementations, this is what we use with our proprietary 
protocol today. The server returns it's time value and then the client 
can calculate the skew and process accordingly.

Thanks,
George

Eran Hammer-Lahav wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 07:36:57 -0700

<hat type='individual'/>

On 12/3/09 7:23 AM, George Fletcher wrote:
> 
> Eran Hammer-Lahav wrote:
>> I am going to base the new HMAC method closely after the current
>> HMAC-SHA1 method (SHA1 will be negotiable and might be replaced as the
>> base protocol to something more current, but this is off topic). This
>> means we will need to deal with timestamps to prevent replay attacks.
>>
>> Tim Polk made a comment today on the 1.0 RFC draft that the server
>> should be able to simply tell the client to use a trusted time service
>> for clock synchronization. Since timestamp management has been a
>> problematic issue for many, I feel we need to address it in the new
>> spec to ensure it will not cause interop issues.
>>
>> 2. Have the server point the client to a trusted time service (which
>> the server can run if desired), using a protocol we pick such as NTP
>> (RFC 1305).
>
> +1 to option #1
> 

I don't see a good reason to design around operating systems that can't
be bothered to synchronize to recognized time servers via NTP. And I
think it's extremely unlikely that a person will specifically change
their machine's time to be, say, 10 minutes ahead of canonical time. By
all means provide a way for the server to tell the client what its time
is when returning an error related to expired tokens and the like, but
don't let's reinvent NTP while we're at it. :)

Peter

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 03 Dec 2009 09:43:24 -0500

I am actually +1 on both options (assuming that using GPS for time 
synchronizaion is implicitly included). While I agree with George that 
the client's clock may not be manipulated externally, I did not think 
that option #2 implied that.

Igor

George Fletcher wrote:
> machine who may have specifically changed it (for some reason).  As 
> for real-world implementations, this is what we use with our 
> proprietary protocol today. The server returns it's time value and 
> then the client can calculate the skew and process accordingly.
>
> Thanks,
> George
>
> Eran Hammer-Lahav wrote:
>> HMAC-SHA1 method (SHA1 will be negotiable and might be replaced as 
>> the base protocol to something more current, but this is off topic). 
>> This means we will need to deal with timestamps to prevent replay 
>> attacks.
>>
>> should be able to simply tell the client to use a trusted time 
>> service for clock synchronization. Since timestamp management has 
>> been a problematic issue for many, I feel we need to address it in 
>> the new spec to ensure it will not cause interop issues.
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 08:29:50 -0700

<hat type='individual'/>

> that option #2 implied that.

What confuses me about option #2 is this: why is it the OAuth server's
responsibility to tell the OAuth client about a trusted NTP server? IMHO
the device on which the OAuth client is running can already discover NTP
servers on its own, and nothing the OAuth server tells the OAuth client
will have an special influence here.

/psa

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 03 Dec 2009 10:34:26 -0500

Ah, now I see the point.  I agree.

Igor

---

From: Paul Madsen <[email-masked]>
Date: Thu, 03 Dec 2009 10:43:40 -0500

Isn the point of #2 to allow the server to indicate to the client 'Hey 
use NTP - perhaps this server' when it is clear that the client wasnt 
already doing so?

Peter Saint-Andre wrote:
> ------------------------------------------------------------------------
>

---

From: George Fletcher <[email-masked]>
Date: Thu, 03 Dec 2009 10:49:19 -0500

I agree that OAuth shouldn't try and solve the clock-sync problem at the 
device level. Rather provide a way to work with whatever skew the device 
the OAuth client is running on has. Of course, if we can get the device 
to sync it's clock that's better but it shouldn't be an OAuth protocol 
requirement.

Data point: Given our history with deploying multiple desktop clients, 
we have lots of real-world data that says consumers have out-of-sync clocks.

Thanks,
George

---

From: George Fletcher <[email-masked]>
Date: Thu, 03 Dec 2009 10:50:21 -0500

But what can the client do with that message? Should the client modify 
the OS settings of the device to start syncing the clock?

Thanks,
George

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 09:55:45 -0700

Just use the NTP data to calculate the skew. No need to change the OS  
level clock. That was not implied in my list.

EHL

On Dec 3, 2009, at 7:50, "George Fletcher" <[email-masked]> wrote:

>>> --- 
>>> --- 
>>> ------------------------------------------------------------------
>>>
>> --- 
>> ---------------------------------------------------------------------
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 10:19:19 -0700

Giving some other entity control over the server's time is a security risk. It is obvious why the server may want to sync with a specific time server which it trusts cannot be manipulated. The client will then need to sync with a server that uses the same time source. I agree that if servers implement a reasonable window this will not be an issue, regardless of which time server is being used, but it can, and the server might have a strong opinion about which time servers it wants to use.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peter Saint-Andre
> Sent: Thursday, December 03, 2009 7:30 AM
> To: [email-masked]
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Timestamp and sync
> 
> <hat type='individual'/>
> 
> responsibility to tell the OAuth client about a trusted NTP server? IMHO the
> device on which the OAuth client is running can already discover NTP servers
> on its own, and nothing the OAuth server tells the OAuth client will have an
> special influence here.
> 
> /psa

---

From: Paul Lindner <[email-masked]>
Date: Thu, 3 Dec 2009 09:23:00 -0800

How does this relate to the OAuth Problem Reporting extension?

*timestamp_refused *
the oauth_timestamp value is unacceptable to the Service Provider. In this
case, the response SHOULD also contain an oauth_acceptable_timestamps
parameter (described below).

The parameter named *oauth_acceptable_timestamps* consists of two numbers in
decimal notation, separated by '-' (hyphen). It's the range of timestamps
acceptable to the sender. That is, it means the sender will currently accept
an oauth_timestamp that's not less than the first number and not greater
than the second number.

If the client sees this error it can adjust the skew based on the server's
clock, not some arbitrary NTP server...

---

From: Ben Laurie <[email-masked]>
Date: Thu, 3 Dec 2009 09:28:51 -0800

> level clock. That was not implied in my list.

If the server is the one that is not synced, then pointing the client
at an NTP server gets you nowhere. Seems far more sensible to just
have the server tell the client what time it thinks it is.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 3 Dec 2009 09:36:49 -0800

> have the server tell the client what time it thinks it is.

Agreed, let's just have the server tell the client the timestamp it
wants to use.  That's what people are doing in the wild already.

(And +1 to George's comment about this being a real problem, we've seen it too.)

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 10:39:53 -0700

It relates indirectly. The problem reporting extension provides one way to implement #1. However, since we are proposing a new auth scheme, we are going to revisit error codes anyway.

EHL

From: Paul Lindner [mailto:[email-masked]]
Sent: Thursday, December 03, 2009 9:23 AM
To: Eran Hammer-Lahav
Cc: George Fletcher; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Timestamp and sync

timestamp_refused
the oauth_timestamp value is unacceptable to the Service Provider. In this case, the response SHOULD also contain an oauth_acceptable_timestamps parameter (described below).

The parameter named oauth_acceptable_timestamps consists of two numbers in decimal notation, separated by '-' (hyphen). It's the range of timestamps acceptable to the sender. That is, it means the sender will currently accept an oauth_timestamp that's not less than the first number and not greater than the second number.
If the client sees this error it can adjust the skew based on the server's clock, not some arbitrary NTP server...

On Thu, Dec 3, 2009 at 8:55 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Just use the NTP data to calculate the skew. No need to change the OS
level clock. That was not implied in my list.

EHL

On Dec 3, 2009, at 7:50, "George Fletcher" <[email-masked]<mailto:[email-masked]>> wrote:

>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Sam Quigley <[email-masked]>
Date: Thu, 3 Dec 2009 13:21:56 -0800

> 2. Have the server point the client to a trusted time service (which the server can run if desired), using a protocol we pick such as NTP (RFC 1305).

Isn't there a third option, actually?  Namely: drop the requirement for timestamps altogether.

As long as the requirement for nonces remains, the protocol will maintain its protection against replay attacks.  Is there anything else that timestamps are necessary for?

-sq

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Thu, 3 Dec 2009 16:26:32 -0500

Don't you need a timestamp with a nonce to bound how long you have to
remember a used nonce on the server side? i.e. if I have a policy that I
only accept requests whose timestamp is less than 5 minutes old, then I
never have to remember any particular nonce for longer than 5 minutes.
This lets me bound the server resources that are necessary for
"remembering" all the nonces, from a capacity planning point of view.

Jon
........
Jon Moore
Comcast Interactive Media

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sam Quigley
Sent: Thursday, December 03, 2009 4:22 PM
To: Eran Hammer-Lahav
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Timestamp and sync

Isn't there a third option, actually?  Namely: drop the requirement for
timestamps altogether.

As long as the requirement for nonces remains, the protocol will
maintain its protection against replay attacks.  Is there anything else
that timestamps are necessary for?

-sq

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 14:27:15 -0700

Technically no, but without a timestamp component, the server will have to save every nonce ever used to prevent replay. Making nonce structure consistent (by specifying a timestamp component) helps interoperability by removing the need for servers to make up their own nonce structure.

EHL

> From: Sam Quigley [mailto:[email-masked]]
> Sent: Thursday, December 03, 2009 1:22 PM
> To: Eran Hammer-Lahav
> > 2. Have the server point the client to a trusted time service (which the
> server can run if desired), using a protocol we pick such as NTP (RFC 1305).
> 
> As long as the requirement for nonces remains, the protocol will maintain its
> protection against replay attacks.  Is there anything else that timestamps are
> necessary for?
> 
> -sq

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 03 Dec 2009 13:32:25 -0800

> 1. Create a new simple mechanism for clock sync (via error message or

+1. At least the client can compare what the server has to what it has
to determine the issue, and could even potentially skew its time
reporting to the server based on the calculated difference.

> the server can run if desired), using a protocol we pick such as NTP

-1. If we presume the world runs on UTC, then isn't what NTP server to
use irrelevant? It's hard to fathom an OAuth server saying to a client,
"hey, use this non-UTC time source!" I think the protocol still needs to
cope with some drift in timestamps/nonces, so I don't even think which
stratum server to use would even be pertinent.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 03 Dec 2009 13:35:13 -0800

> for timestamps altogether.

I don't think this is a good option, as given the assumptions that
timestamps are monotonically increasing, you only have to retain a
limited set of nonces. If you drop timestamp, then you'd conceivably
have to retain all nonces used for the lifetime of the key/token.

> maintain its protection against replay attacks.  Is there anything
> else that timestamps are necessary for?
> 
> -sq

---

From: Sam Quigley <[email-masked]>
Date: Thu, 3 Dec 2009 14:06:09 -0800

Fair enough; I'd forgotten about the nonce-scoping trick.  What about going the other way, and dropping nonces entirely — and replacing the timestamp with a monotonically-increasing counter.  (Which, in most cases, could just be the client's timestamp.)

The monotonicity would guarantee replay protection, and servers would only need to track a few bytes per consumer…

In case it's not obvious, what I'm worried about is that OAuth 1.0 went too far down a slippery slope: we required nonces to prevent replay attacks; then we added timestamps to scope nonces; now we're considering reimplementing NTP to sync timestamps, and so on.  It doesn't seem like defeating replays ought to be such a hard problem, and I'm grasping for alternatives…

-sq

---

From: Jonathan Sergent <[email-masked]>
Date: Thu, 3 Dec 2009 14:08:04 -0800

Monotonically increasing counter is unnecessarily hard to do in a
distributed consumer.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 03 Dec 2009 14:21:21 -0800

On Thu, 2009-12-03 at 14:06 -0800, Sam Quigley wrote:
> Fair enough; I'd forgotten about the nonce-scoping trick.  What about
> going the other way, and dropping nonces entirely — and replacing the
> timestamp with a monotonically-increasing counter.  (Which, in most
> cases, could just be the client's timestamp.)

I've encountered cases where there may be multiple client instances
(sharing the same consumer key)—multiple servers in a cluster for
instance—and in fact needed to relax the monotonically increasing
timestamp (allow for an acceptable amount of skew to accommodate
multiple instances).

There's also the issue of request order when near-concurrent requests
are transmitted from the consumer. The Interweb allows flexible routing
of requests, and one request sent just before another from the consumer
could reach the server after the second.

Another issue will be timestamp granularity—if the value must increase
for each request, then you limit the frequency of requests to the
granularity of your timestamp.

Timestamp+nonce provides ways to handle these types of issues. One
without the other makes these problems more difficult to handle.

> The monotonicity would guarantee replay protection, and servers would
> only need to track a few bytes per consumer…
> 
> In case it's not obvious, what I'm worried about is that OAuth 1.0
> went too far down a slippery slope: we required nonces to prevent
> replay attacks; then we added timestamps to scope nonces; now we're
> considering reimplementing NTP to sync timestamps, and so on.  It
> doesn't seem like defeating replays ought to be such a hard problem,
> and I'm grasping for alternatives…
> 
> -sq
> 
> 
> >> 1. Create a new simple mechanism for clock sync (via error message
> or
> > API call).

---

From: Sam Quigley <[email-masked]>
Date: Thu, 3 Dec 2009 16:24:43 -0800

> without the other makes these problems more difficult to handle.

All good points.  

There might, though, still be room to relax the timestamp requirement, and make it merely a monotonically increasing counter…  Given a request, the server would check first that the counter is greater than or equal to all other counters received from this consumer; and, second, the server would check that the nonce is unique among requests issued with the same counter value.  Unless there's still something I'm missing, this would:

* protect against replays 
* no require clock sync
* not require infinite nonce storage on the server
* scale up for massively distributed consumers (which could just use their current timestamp)
* scale down for embedded and other "dumb" devices which don't necessarily have well-synchronized clocks

There would still be the problem of packet reordering, though — I expect that this would have to be solved, as you suggest, by allowing a bit of skew in the counter.  And servers would have to be prepared to handle degenerate consumers which never increment their timestamps — though it seems reasonable to simply reject requests in this case.

Even if all that does work, though, I wonder if it might not be better to simply make protection from replay attacks out-of-scope for OAuth.  From various conversations, it sounds like most (all?) major OAuth installations don't actually check nonces anyway, as the server-side synchronization requirements are too onerous.  If an application *does* require protection against replays, it's generally pretty easy to add something at the application layer that would solve the problem… and whatever we can do to simplify the spec will certainly be appreciated.

-sq

---

From: Brian Eaton <[email-masked]>
Date: Thu, 3 Dec 2009 17:07:47 -0800

On Thu, Dec 3, 2009 at 4:24 PM, Sam Quigley <[email-masked]> wrote:
> There might, though, still be room to relax the timestamp requirement, and make it merely a monotonically increasing counter…

Monotonically increasing counters in distributed systems are a classic
hard problem in computer science.  Let's not write a spec that
requires them, please.  (Even if you allow for skew in the counter,
you end up needing to do frequent writes to a central server that
maintains the counters.  The performance sucks, and the central server
turns into a reliability problem.)

I can see a few ways forward here.

1) Challenge-response
    This requires an extra round trip to establish the base line challenge.

2) Synchronized clocks
    This skips a round trip, but is known to fail in some corner cases.

3) Don't do replay protection.
    This is reasonable only if something like the scalable OAuth
extension (or WRAP) is used to periodically refresh credentials.
Otherwise you end up sending credentials that never expire at all,
with associated security risks.

The nice thing about the proposed scheme of synchronized clocks + an
error response when they are not synchronized is that it is fast in
the average case, and degenerates to challenge-response in the worst
case.  This solution has been proven to work already for OAuth 1.0.

Cheers,
Brian

---

From: Sam Quigley <[email-masked]>
Date: Thu, 3 Dec 2009 17:21:51 -0800

> turns into a reliability problem.)

Maybe I'm misunderstanding you — but timestamps *are* monotonically increasing counters, and the spec already requires those.  "Monotonically increasing" isn't the same as "strictly increasing"…

-sq

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 18:25:41 -0700

> Of Brian Eaton
> Sent: Thursday, December 03, 2009 5:08 PM
> To: Sam Quigley
> > There might, though, still be room to relax the timestamp requirement,
> > and make it merely a monotonically increasing counter...
> 
> Monotonically increasing counters in distributed systems are a classic hard
> problem in computer science.  Let's not write a spec that requires them,
> please.  (Even if you allow for skew in the counter, you end up needing to do
> frequent writes to a central server that maintains the counters.  The
> performance sucks, and the central server turns into a reliability problem.)
> 

Do that, and you might as well let the server issue the nonce, and end up with Digest.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Thu, 3 Dec 2009 17:28:32 -0800

On Thu, Dec 3, 2009 at 5:21 PM, Sam Quigley <[email-masked]> wrote:
> Maybe I'm misunderstanding you — but timestamps *are* monotonically increasing counters, and the spec already requires those.

Timestamps are not monotonically increasing counters.

For example: http://www.ece.udel.edu/~mills/leap.html

But aside from backwards leap seconds, which are rare, you need to
consider the case of multiple computers sending requests at once.
Their clocks are not perfectly synchronized, and it is highly likely
that one computer will send a timestamp that is less than the
timestamp sent from another computer.

Cheers,
Brian

---

From: Richard Barnes <[email-masked]>
Date: Tue, 8 Dec 2009 18:47:00 -0500

I actually like this approach: If the server rejects the request  
because the timestamp is stale, then it includes a timestamp in its  
response, corresponding to the current time by its clock.  The client  
can then remember the offset for this server to maintain sync for  
future requests.  Distributed clients can pass this state to their  
peers as they get it.  When this is being used in the delegation  
workflow, the client and server can sync up as part of the delegation,  
when they're both establishing state already.  This works pretty well  
as long as the clocks don't skew much against each other.

Note that there is a potential security vulnerability here, however:  
An attacker could exploit this mechanism to get the client to generate  
signatures with timestamps in the future (as seen by the server), for  
the attacker to use when the time comes.  The simplest mitigation to  
this seems to be to have the server authenticate the returned  
timestamp, e.g., by constructing a signature that covers the client's  
nonce and timestamp as well as the server's timestamp.  This is  
another reason to allow OAuth signatures on responses, as I think was  
suggested earlier.  Trying to sync via the problem reporting extension  
(as Paul suggests), would still leave this vulnerability.

--Richard

On Dec 3, 2009, at 12:39 PM, Eran Hammer-Lahav wrote:

> It relates indirectly. The problem reporting extension provides one  
> way to implement #1. However, since we are proposing a new auth  
> scheme, we are going to revisit error codes anyway.
>
> EHL
>
> the oauth_timestamp value is unacceptable to the Service Provider.  
> In this case, the response SHOULD also contain an  
> oauth_acceptable_timestamps parameter (described below).
>
> The parameter named oauth_acceptable_timestamps consists of two  
> numbers in decimal notation, separated by '-' (hyphen). It's the  
> range of timestamps acceptable to the sender. That is, it means the  
> sender will currently accept an oauth_timestamp that's not less than  
> the first number and not greater than the second number.
> If the client sees this error it can adjust the skew based on the  
> server's clock, not some arbitrary NTP server...
>
>