> -----Original Message----- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Wednesday, June 01, 2011 12:16 AM > To: Eran Hammer-Lahav > Cc: Adam Barth; OAuth WG > Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token > > Provider: api.megaworld.com > > Software Program: A universal binary iOS app called MegaWorld for iOS Client > ID: mega_app > > User: Frankie in London > Username: frankie_uk > > Device A: Frankie's iPhone > Device B: Frankie's iPad > > Now imagine MegaWorld for iOS installed on device A & B. Client ID is the > same across the two devices.
This is broken. You are using MAC for client authentication, but your client is a native application which should not have a secret... > - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to > access his account (frankie_uk) > - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time > on device A is 1306911444. > - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS to > access his account (frankie_uk) > - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time > on device B is 1275375611. When you say issued, you mean MAC credentials (access token) or client credentials? EHL > The provider, mega_app, does not issue multiple tokens for the same grant > request (scope, client_id). This simplifies provider implementation but also > helps enforce the correct user UI with respect to credential control at > http://megaworld.com/my/apps - that is, the provider can't accurately know > if frankie_uk has authorized one software instance twice on the same > device, or multiple software instances once each (across multiple devices). > Thus, the my/apps UI shows one authorization for "Megaworld for iOS" and > thus one option to de-authorize this client_id (and thus all installed > instances > of the single software program with ID mega_app). > > Regardless if age or timestamp is used, if the implementation for validating > the time value is sequential (perhaps with some window of error) then one > device will have all its OAuth requests rejected as soon as the other presents > a request. If timestamps are used the one with the older clock (device B) is > rejected. If age is used, the one with the highest value of time (in this > case, > the more correct client) will be rejected as age will be calculated to be > smaller > than device B with an incorrect clock. > > If you also consider the case where device A and B have the same value for > current time (UTC time, let's say) then age fails for device B after device A > submits a request since device B thinks the credential is younger than device > A. Timestamp does not fail in this case (because clocks are already sync'd). > > Only when the timestamp is a unified standard like UTC can both device A > and B both use token 89ARC. If client B has it's request rejected it can > quickly > check UTC from any reasonable source (including api.megaworld.com) to > correct its clock. Even better, it can politely check the correct system time > on > a regular basis and cache the offset between UTC and device time. Though > experience may show that many software developers don't currently do this > clock correction, it is trivial to adopt as a best practice. (Many software > developer also don't routinely review their software for security or stability > vulnerabilities of any sort.) Certainly is nothing for the small percentage of > well-written high-value clients such as Firefox, TweetDeck or any serious > effort with even moderate distribution or engineering resources. > > skylar > > > On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: > > > This is not true. > > > > The age value has to be monotonically increasing, but not necessarily > unique. Really, any counter will do. The reason why timestamp isn't any > better than age or sequence is because ultimately, it is the server's memory > restriction which determines the nonces storage size, not anything else (like > a time limit). _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
