It seems we're failing to communicate. Or you're not understanding my use cases. Age doesn't "just" work. It only works for a limited number of uses cases that must include all of yours - and it is brittle at that. It doesn't work for any of our uses cases (where the client can't know issue_date w/o the server telling it - in which case we have the equivalent problem as timestamp).
If you'd like to talk this out over Skype I'm happy to do that, so I can help you understand why age doesn't work. On May 31, 2011, at 9:47 AM, Adam Barth wrote: > 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 <[email protected]> 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 <[email protected]> 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: [email protected] [mailto:[email protected]] 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 <[email protected]> >>>>>> wrote: >>>>>>> Resending to the list from my subscribed account... >>>>>>> >>>>>>> Begin forwarded message: >>>>>>> >>>>>>>> From: Skylar Woodward <[email protected]> >>>>>>>> Date: May 23, 2011 6:14:00 PM PDT >>>>>>>> To: Skylar Woodward <[email protected]> >>>>>>>> Cc: Eran Hammer-Lahav <[email protected]>, OAuth WG >>>>>>>> <[email protected]> >>>>>>>> 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 >>>>>>>>>> <[email protected]> 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 >>>>>>>>>> [email protected] >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. >>>>>> [email protected] : 978-296-5247 >>>>>> >>>>>> "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"; >>>>>> _______________________________________________ >>>>>> 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
