Adam and I have discussed a proposal which should address everyone's use cases. I will post shortly. Just FYI so people don't invest too much time in this thread...
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Phil Hunt > Sent: Tuesday, May 31, 2011 3:35 PM > To: Adam Barth > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > 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 > [email protected] > > > > > > 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 <[email protected]> > 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 <[email protected]> > 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 > <[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:oauth- > [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 > >>>>>>>>>> random+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- > toke > >>>>>>>>>>>>>> n > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 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 > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
