I'm not sure we need a Skype call. Can you explain the trouble caused by age clearly? I didn't understand your previous explanation. The more concrete you can be, the better.
Thanks, Adam On Tue, May 31, 2011 at 1:04 AM, Skylar Woodward <sky...@kiva.org> wrote: > 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 <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
