On May 31, 2011, at 11:41 PM, Adam Barth wrote:
> You haven't described a problem.
Maybe so, but I guess you can't see yet where this is going, or you are
ignoring it intentionally. I did preface this letter that I wanted to
understand your perspective on this two points before attempting to continue
the discussion. Let's try to move forward with your answer to the second
question.
>
> On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward <sky...@kiva.org> wrote:
>> First we should agree on a common understanding of the spec. The reason why
>> age works with unsynchronized clocks is that the client determines
>> issue_date based on the time when it receives the token over the wire. This
>> depends on the server and client both recording time this way and for the
>> transmission of the token to be be not longer than the margin of error for
>> validating age. Are we agreed on this understanding?
>
> That's not correct.
>
> The age allows the server to protect against replay attacks in bounded
> memory. With unbounded memory, the server can just remember every
> nonce it has ever seen associated with a given key and reject replays.
> With bounded memory, the server eventually needs to evict some of
> these nonces due to memory pressure. The age value lets the server
> reject the nonces with the smallest age values first. The server then
> rejects any messages with age values smaller than (or equal to) the
> largest age value it has ever evicted for the given key.
>
> Notice that neither clock synchronization nor transmission time plays
> a role in that implementation.
>
Yes, but this isn't a implementation we've yet considered and it isn't the one
suggested by the spec. The spec states:
"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."
This text is analogous to the text originally used for timestamp in which case
"old" is relative to current time. By this text, I also understand age to be
relative to the current time of the device constructing or validating the
value. If "old" means relative to previous values seen by the server then the
this text should be made more clear.
However, if this how you expect age to be used to invalidate old nonce history
then timestamp is much simpler. The client can use any value so long as it
makes sure that subsequent values come after previous values. It can keep a
counter going from 0 upwards, or it can use some upward moving counter relative
to its device (eg local clock). In fact, this is the more common definition
used by most protocols using a timestamp. It is often merely a suggestion that
current time be used for this value to avoid extra record-keeping on the part
of the client. So if this is your intent you can simplify the specification of
"age" by suggesting the client pick an arbitrary start point, but make no
mention of it needing to be within a proximity of the server's understanding of
the same start point.
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.
>> The easiest case for me to explain here is client credentials because I have
>> to assume you've built and registered a Twitter app at some point (or
>> similar OAuth 1.0a app). You registered your app on the site and were issued
>> a client_id and client_secret (called consumer_key and consumer_secret in
>> 1.0). You then embedded these values in your client (they were not issued
>> programmatically to your app). Assuming the MAC token algorithm is used then
>> for establishing client identity (originally one of the uses we, the working
>> group, hoped MAC would cover) how then will your client determine issue date?
>
> I recommend the date at which the developer obtained the credential
> from Twitter because that is the date when the credential was issued.
Okay, so this value was issued from the server to a developer account, not
directly to the client software. How do you then propose the time is
communicated to the client software program in a way where the date of issuance
is relative to the clock on that device (not to the device holding the
developer account data). For example, if the client credential was issued at
time 2120 but is then installed with a client program on a device who thinks
the current time is 630 then age is already negative (2120-630). How to
translate 2120 from the date the developer obtained the credential to the
translation of that date on a user device where the clock is significantly
behind that of the developer services server (eg, dev.twitter.com) or even that
of the local developer's box?
skylar
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
