What use case isn't addressed by age? No one has actually articulated it. Adam
On Tue, May 31, 2011 at 3:35 PM, Phil Hunt <phil.h...@oracle.com> wrote: > There seems to be a demonstrated need for both age and timestamp tokens. > > The list has 2 separate cases with 2 separate proposals that do not solve all > cases. > > Can we at least agree that neither proposal works in all cases? > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2011-05-31, at 2:41 PM, Adam Barth wrote: > >> You haven't described a problem. >> >> 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. >> >>> 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. >> >>> After we can establish where you're at on the two above points I'll >>> continue with the explanation. But as a preview, the next points would be: >>> >>> - If issue_date comes form the server, how is it translated to the client? >> >> The issue_date does not come from the server. >> >>> - If you use a server provided issue_date, how do you then translate that a >>> value relative to the local unsyncronized clock? >> >> The server does not provide the issue_date. >> >>> - If your answer to that is to also provide the current server time to the >>> client so the offset on the server provided issue_date can be calculated >>> what is the difference between all of these values and just using timestamp? >> >> My answer is not to provide the current server time to the client. >> >> Kind regards, >> Adam >> >> >>> So don't get wrapped up in those 3 questions until we establish your >>> contextual understanding of the first two paragraphs. Feel free to also >>> respond to me off the list so we don't trouble everyone else with us >>> getting on the same page (the reason, I thought, why a Skype call would be >>> more efficient and painless). I do think my explanations all have been very >>> clear thus far. There must be a contextual confusion that is keeping us >>> from a common understanding of the terminology or the use cases. >>> >>> skylar >>> >>> >>> On May 31, 2011, at 10:30 AM, Adam Barth wrote: >>> >>>> 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
