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
