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
