> -----Original Message----- >> From: Skylar Woodward [mailto:[email protected]] >> 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...
No, I had two use cases to discuss. One of access tokens being re-issued and the other of client credentials. Token re-issue seemed easier to explain because it is the more common case of device conflict. The issues with client credentials are minimized with the algorithm for nonce expiration that Adam suggested (sequential) which was not clear as a suggestion by the spec. I could outline a problem with age for client credentials which use the "flagged as old" algorithm, but this seems less important now if we assume "sequential with a window of tolerance" as the algorithm for invalidation. However, there are possible cases where two software instances use the same client credential (and where it's still possible to secure the secret). Most of those cases are ones where the software distribution is protected inside a controlled network. A few examples (not common across OAuth, though some of these will be popular for providers like Kiva where its customers deploy proprietary software inside controlled intranets where secrets can be protected from the public even in "native" apps): - Great State University makes an app for managing student grading. This app is distributed to all faculty iPhones using the Apple Enterprise Deployment system. GSU expects faculty not to share the installed software with non-faculty or to use jail-broken phones -- doing so is a violation of school code of ethics. GSU makes the case that the client credentials in the grading app are securable with reasonable deployment and legal protections in place. All installs of the app onto faculty iPhones use the same client credential. They use the client credential as an additional hurdle to protect against forged clients trying to authorize. - Green Microlender makes an app for submitting loan data to Kiva that also interfaces with their local MIS system. This is a Visual Basic program installed on Windows PCs throughout field offices in southern Uganda which each on the organization's protected VLAN (or multiple protected LANs). This program is deployed by IT staff only onto these devices. They choose to use client credentials in this program as they feel comfortable in asserting that the client secrets are protected adequately by Green Microlender. - MegaWorld Tracker deploys websites in France and the US. They set up different instances of their website program in servers in France and the US. Each deployment is configured with the same MegaWorld OAuth client ID since it is the same program, but different locale settings to make the software render text in French or English, respectively. Since MegaWorld Tracker isn't a huge corp, they've haven't put in place measures to sync user's access tokens between the French servers and the US servers. This means a user that hits both the FR server and the US server will have to authenticate twice to megaworld.com (and thus access tokens issued to each server install). Since they also didn't bother to register two client IDs (mw_tracker instead of mw_tracker_us and mw_tracker_fr) they essentially have two installs using the same client credentials. It's a reasonable gray area. I do admit these won't be en masse in the grand collective of all deployed OAuth v2 apps, but they are reasonable use cases, and for some organizations, very important use cases. >> - 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? these are access tokens > > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
