The client should calculate the time of issue based on when it gets the credentials. Network delays should be accounted for by the server when allowing shifts in the nonce itself.
EHL > -----Original Message----- > From: Skylar Woodward [mailto:[email protected]] > Sent: Tuesday, May 31, 2011 1:04 AM > To: Adam Barth > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > 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_FI > REFOX - 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
