Timestamps don't work when the client doesn't have a synchronized clock. It's true that a client could synchronize its clock with the network, but our implementation experience is that many clients don't for a variety of reasons. That means that age better because, you know, it works.
Adam On Mon, May 30, 2011 at 11:19 PM, Skylar Woodward <sky...@kiva.org> wrote: > I don't think you read my first message on the topic (or I wrote too much). > > Age is fragile because if the clock changes between issue_date and the time > of submission, it will fail. We know many people don't have synchronized > clocks, but using age only solves this problem if two assumptions hold true: > > 1) the client is able to guess the issue_date the server is using based on > the time the credential was issued > 2) the client system clock doesn't change between issue date and submission > time. > > Timestamp has neither of these issues because the client can always inquire > about network time and can effectively correct for inaccuracies in the device > timekeeping system. > > Regarding the first assumption, this fails when a token might be re-issued > between devices. An example is that we use MAC token for the client > credentials, which are issued when a developer registers an application. The > client has no way of determining on its own when the value was actually > issued (unless we communicate that on the developer website and force users > to embed that with client_id, which adds usability issues of users copying > and entering string date values correctly). The same is actually true for all > of our OAuth access tokens because we reissue tokens to the same client_id if > they were previously issued and are still valid. (The client would thus think > the issue_date was now() when if fact it was the time of the first issue for > client_id+scope+grantor_id). Thus, age is really just a convoluted way of > trying to communicate the device system offset: > > local_offset = current_server_time - current_device_time > age = current_device_time - (server_issue_date-local_offset) > > Since the protocol doesn't currently allow for server_issue_date to be given > with tokens, thus age currently can't have the resilience that timestamp > does. It also forces servers to issue new tokens on demand just to make the > convoluted age system work (rather than reuse existing valid tokens). Or, you > have to modify the protocol to add server_issue_date and current_server_time > into the token-issue exchange - eg, more complexity. > > Timestamp is simpler, proven, it and it has a solution for your use case of > unsyncronized clocks. > > skylar > > > On May 30, 2011, at 9:08 AM, Adam Barth wrote: > >> I can't speak for Mozilla, but I can tell you that many folks don't >> have synchronized clocks, for a wide variety of reasons. I guess I >> don't really understand why you view age as problematic. You >> reference "fragility of using time-since-credentials-issued" but you >> don't say what exactly is fragile about it. There's nothing >> particularly complex about age, especially when using the monotonic >> clock provided by all modern operating systems. >> >> Adam >> >> >> On Mon, May 30, 2011 at 12:03 AM, Skylar Woodward <sky...@kiva.org> wrote: >>> But see, now you are specializing the use of MAC token even more - now it's >>> becoming a service mainly for user-agents on home desktops? This is further >>> for the original goal of making MAC as flexible is possible. In this case >>> you should change the spec name to >>> MAC_TOKEN_FOR_BROWSER_COOKIE_REPLACEMENT_IN_AGENTS_LIKE_FIREFOX - or >>> MTBCRLF for short. >>> >>> Sarcasm aside, my point is that timestamp is just as good as your offset >>> technique and is more: reliable, straightforward, flexible. >>> >>> User agents that care about creating robust behavior for home desktops or >>> mobiles (presumably of users and OS not yet sophisticated enough to check >>> network time on their own) should be advised to do clock correction on >>> their own (by pinging a time service) and trusting the device clock alone. >>> >>> Please change the spec back to using timestamp rather than age. >>> >>> I'd also like to hear a convincing argument from the Mozilla co-authors >>> about why they think that age is more resilient than the above (I believe >>> it is not) and further more why they would find the above unattractive or >>> difficult to implement in a modern user-agent. >>> >>> Thanks, >>> skylar >>> >>> ... -.- -.-- .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. — ... -.- -.-- >>> .-.. .- .-. — .-- --- --- -.. .-- .- .-. -.. >>> skylar woodward >>> Kiva Developer Program / build.kiva.org / @buildkiva >>> >>> >>> On May 30, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: >>> >>>> Any kind of clock sync requirement for user-agents (basically, home >>>> desktops) it completely impractical. The added complexity pales in >>>> comparison to the difficulty of trying to use timestamps and any kind of >>>> clock sync. No window will be big enough as experience shows some users >>>> have closes that are off by more than an hour and a half. >>>> >>>> The issue here is who is this being optimized for. Server-to-server >>>> communication should simply use TLS for privacy and MITM protection on top >>>> of MAC instead of using nonces to prevent replay. The whole point of this >>>> kind of replay protection is when TLS is not available. >>>> >>>> I think a better approach is to simply make checking the nonce optional >>>> when TLS is used. >>>> >>>> EHL >>>> >>>>> -----Original Message----- >>>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >>>>> Of Peter Wolanin >>>>> Sent: Sunday, May 29, 2011 6:53 PM >>>>> To: Skylar Woodward >>>>> Cc: OAuth WG >>>>> Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token >>>>> >>>>> I am also concerned by the fragility of using >>>>> time-since-credentials-issued, >>>>> and also the added complexity of specifying this construction. >>>>> >>>>> I think it would be preferable to always require a timestamp as part of >>>>> the >>>>> authorization header, and maybe even include in the spec a maximum time >>>>> difference between client and server (e.g. 900 seconds) that can be >>>>> tolerated. This makes generating the nonce easier also, since the value >>>>> need >>>>> to longer be unique over all time. >>>>> >>>>> We have such rules in place for an HMAC-based authentication system we >>>>> use. Once in a while a client has a local clock so far out of sync that >>>>> there is an >>>>> issue, but it's rare. >>>>> >>>>> -Peter >>>>> >>>>> On Mon, May 23, 2011 at 9:16 PM, Skylar Woodward <sky...@kiva.org> >>>>> wrote: >>>>>> Resending to the list from my subscribed account... >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Skylar Woodward <sky...@larw.com> >>>>>>> Date: May 23, 2011 6:14:00 PM PDT >>>>>>> To: Skylar Woodward <sky...@kiva.org> >>>>>>> Cc: Eran Hammer-Lahav <e...@hueniverse.com>, OAuth WG >>>>>>> <oauth@ietf.org> >>>>>>> Subject: Re: [OAUTH-WG] issues with token age element - MAC token >>>>>>> >>>>>>> So after discussing this today and reflecting on it a bit, I would >>>>>>> suggest that >>>>> nonce simply be the "unique value" (as it is so named) without further >>>>> requirements. It might be suggested that this be composed of an >>>>> random+timestamp (not age) value, but that seems more of a MAY or >>>>> "recommended" practice. If the expectation is that very few if any >>>>> providers >>>>> would actually check the timestamp (or moreover, the nonce itself), why >>>>> add >>>>> terminology in the draft that requires it? Developers are doing extra >>>>> housekeeping (and perhaps for a perceived benefit) but with no payoff or >>>>> added security. >>>>>>> >>>>>>> I'm sending this feedback based on having implemented the v3-5 changes >>>>> last night (for both client credentials and requests w/ access tokens). >>>>> After >>>>> the changes, the nonce creation is now the most complicated part of the >>>>> normalized request string and yet these changes offer the least benefit. >>>>> What's most important is that nonces are unique on each request for an ID. >>>>>>> >>>>>>> There are issues with age as well: >>>>>>> >>>>>>> - As Bill mentioned, if the client stores the issue time based on >>>>>>> receipt, then the internal clock changes (presumably w/o knowledge of >>>>>>> the software storing the dates) then time will also fail. Assuming >>>>>>> that a user with a bad clock (of by hours or more) will never fix it >>>>>>> and actually encourages bad user behavior (don't fix your clock or >>>>>>> Twitterbot will stop working!). Though we say that timezones won't >>>>>>> bring about the situation of changed clock, I'd be to differ. Many >>>>>>> users aren't savvy enough to change time zone, but just adjust the >>>>>>> time to local time anyway. Users who are more likely to get it right >>>>>>> already have auto clock sync enabled (via web, mobile, etc.) >>>>>>> >>>>>>> - What if the token wasn't originally issued programmatically? In this >>>>>>> case, >>>>> the issue time has to be obtained from the server and stored on the client >>>>> then you have the same problem as with a timestamp - the client clock is >>>>> not >>>>> sync'd to the server clock and there is no adjustment. You want this to >>>>> apply >>>>> to uses outside of just OAuth, but now requiring the client to be able to >>>>> determine an issue time based on when it receives an HTTP request >>>>> necessarily limits the types of token flows for which this can be used. >>>>>>> >>>>>>> - It's one more detail to store. Hardly an issue for a developer, but >>>>>>> it is >>>>> inelegant. It's like having a double ID. Yet it's not an ID, it is >>>>> actually more of a >>>>> recording of "my personal clock offset value" but obfuscated several times >>>>> over (one for each token) as issue_date. >>>>>>> >>>>>>> - This implementation assumes software programs use the computer >>>>> internal clock exclusively for timestamp. A robust program that is >>>>> dependent >>>>> on accurate timestamps would ping the origin server (or similar trusted >>>>> time >>>>> authority) to ask it the current time. Then it could store a "my device >>>>> clock >>>>> offset" value for the lifetime of the program execution. All requests >>>>> needing >>>>> timestamp would be adjusted accordingly. For age, if the clock is changed >>>>> since the stored issue_date, the problem can't be corrected in this >>>>> manner. >>>>> Thus, a significant advantage for timestamp. >>>>>>> >>>>>>> All in all, this seems like a misguided but well-intentioned attempt to >>>>>>> get >>>>> around end-user issues of mis-set clocks. It feels like a hack and it >>>>> certainly >>>>> isn't a foolproof solution. The more I think about the implications of >>>>> the age >>>>> parameter, the less I like it. Timestamp has been used for many years in >>>>> the >>>>> industry and with reasonable success in relevant applications. If we >>>>> change to >>>>> a new way of trying to sync on time I think we run a greater risk of >>>>> stumbling >>>>> upon unforeseen issues, such as those outlined above. >>>>>>> >>>>>>> I recommend the requirement of an age (or timestamp for that matter) >>>>> be dropped from the nonce construction. For providers that deem it >>>>> valuable, timestamp can be an optional value (either as part of the nonce >>>>> or >>>>> the overall header, as before). >>>>>>> >>>>>>> skylar >>>>>>> >>>>>>> >>>>>>> >>>>>>> On May 23, 2011, at 2:11 AM, Skylar Woodward wrote: >>>>>>> >>>>>>>> You may have noticed, on page 8 the host is listed as "example.net" >>>>>>>> - should be example.com, I believe. (draft v5) >>>>>>>> >>>>>>>> All in all, I'm in support of the changes in v2. Certainly addresses my >>>>> hesitations from v2. >>>>>>>> >>>>>>>> skylar >>>>>>>> >>>>>>>> >>>>>>>> On May 9, 2011, at 12:36 PM, Eran Hammer-Lahav wrote: >>>>>>>> >>>>>>>>> (Please discuss this draft on the Apps-Discuss >>>>>>>>> <apps-disc...@ietf.org> mailing list) >>>>>>>>> >>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >>>>>>>>> >>>>>>>>> While this document has moved to the Apps-Discuss mailing list for the >>>>> time being, I wanted to give a quick update to those who have been >>>>> following this draft which originated on this list. >>>>>>>>> >>>>>>>>> The major changes since -02 are: >>>>>>>>> >>>>>>>>> * Removed OAuth terminology and association. The draft is now a >>>>> general purpose HTTP authentication scheme. It does include an OAuth 2.0 >>>>> binding which is described in less than a page. One suggestion would be to >>>>> move section 5.1 into the OAuth specification and drop all the OAuth 2.0 >>>>> text >>>>> from the MAC draft. >>>>>>>>> >>>>>>>>> * Added 'Set-Cookie' extension for using MAC with session cookies. >>>>>>>>> >>>>>>>>> * Removed request URI query normalization. The new draft uses the >>>>> raw request URI unchanged. >>>>>>>>> >>>>>>>>> * Replaced timestamps with credentials age to remove the need for >>>>> clock sync. >>>>>>>>> >>>>>>>>> * Added a placeholder for extension, allowing random text to be >>>>> included in the request and MAC. >>>>>>>>> >>>>>>>>> * Added issuer attribute for identifying the source of the >>>>>>>>> credentials as >>>>> an additional protection. >>>>>>>>> >>>>>>>>> Draft -04 is not compatible with previous drafts. >>>>>>>>> >>>>>>>>> EHL >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. >>>>> peter.wola...@acquia.com : 978-296-5247 >>>>> >>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"; >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
