I think the use case document should focus on v2, not on MAC. At some point, it becomes impractical to keep every use case discussed on this list recorded.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Igor Faynberg > Sent: Tuesday, May 31, 2011 3:50 PM > To: Phil Hunt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > ...Sorry to turn the question around so as to underline my pet peeve: > Have we *documented* all cases? (This is what the Use Cases document is > supposed to be all about.) > > Just to clarify: I am not arguing with Phil's point now. I just stress that > as of > this moment we don't have anything to check against. > > Igor > > Phil Hunt 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_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: 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 > >>>>>>>>>>> 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 > >>>>>>>>>>>>>>> <apps-disc...@ietf.org> mailing list) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac- > tok > >>>>>>>>>>>>>>> en > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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 > > > _______________________________________________ > 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
