For 1), the community needs to make a concious decision to turn our backs on a set of use cases for devices that can't take direct input. These include "smart picture frames" that come with a pre-generated request token on a piece of paper and instructions to go activate them (e.g. so you can give your parents a picture frame that shows your private picasa photos) and smart medical bracelets that connect to Google Health or similar services. This also includes things like the Roku box or other set-top boxes that don't have keyboard input. These are all real and useful cases that OAuth 1.0 supports, and I don't think we should break them capriciously. If the authorization page makes the user type in a manual token, it can provide extra warning messages like "Make sure you got this directly from the device you're authorizing", which I think is above threshold for a secure and workable model. Can others chime in who feel strongly one way or the other here?
For 2) the only way to tell 1.0 from 1.0A-with-no-callback is to use the special oob/none value. If we can't do better than this, so be it, but special values feel like a hack at best, so I'm hoping we can come up with some creative alternative that would allow the callback param to be motted entirely and still be able to tell 1.0 from 1.0a without explicit version numbers. For 3) the only requirement is for the SP to reconstruct the signature, so appending two tokens is no harder than appending an extra name/value pair when computing the signature. After the SP generates the verifier, it could store the token+verifier as the key to look up when granting an access token, and thus it wouldn't need to break them back up later. I don't feel super strongly about this, but I know for a fact it will make the libraries more complex and inconsistent if this one use case takes an extra param that none of the other (otherwise identical) invocations need... Thanks, js On Sat, May 2, 2009 at 10:32 AM, Josh Roesslein <[email protected]>wrote: > 1.) Yes this is a small window for an attacker to pull off a session > fixation, but I think it should still be closed. It just takes one > successful attack to make oauth look insecure. > It might be possible for this parameter to be optional for the SP > (banks might want to use this, but less sensitive data sites might not need > this extra security). > 2.) We can tell during the request token request if this is a 1.0 A or 1.0 > consumer. If no callback parameter is present, its 1.0. 1.0 A consumers must > still set this > parameter even if they are not setting a callback (oob, none, etc). > 3.) I don't really like this combining of the tokens. We'll have to disjoin > them on the SP to verify. I don't think it will be much of a deal changing > the signature code to make > this work. > > > On Sat, May 2, 2009 at 12:01 PM, Joseph Smarr <[email protected]> wrote: > >> Erna-just getting to a detailed review of the diff now. Generally it looks >> good but here are a couple of things I think we should change: >> >> 1) If no oauth_token is provided on the authorization URL in 6.2.1 (e.g. >> the mobile/device case where the Consumer is unable to open a web browser >> directly), then I don't think the Provider should return an oauth_verifier >> to be enterered into the Consumer. Basically I'm suggesting we stick to >> OAuth 1.0 here, and the reasons are: a) the attack we're patching is much >> harder to pull off if you have to get the victim to go to a URL and then >> manually enter a request token, and b) many devices won't provide a way to >> enter text into them, so requiring the verifier be manually entered will >> exclude those valuable use cases. >> >> 2) I agree with commenters below that providing oob for oauth_callback >> feels dirty and ideally there would be a better way to distinguish 1.0A and >> 1.0 Consumers. I really don't want to change version numbers to accomplish >> this, but maybe if we think a bit harder, we can come up with a good >> situation. For instane, if the Consumer sends oauth_callback on the >> authorization page, but not in the request token call, you know it's 1.0. I >> guess the hard part is if they don't send oauth_callback in either place, >> and you still respond with the verifier, how do you know when to expect it >> back or not. Hmm... >> >> Which brings me to the discussion we had last week (but which I believe >> has NOT made it to the list) about how Providers can support both 1.0A and >> 1.0 simultaneously for a while (which many will have to do). I would suggest >> adding this as an appendix (much as OpenID has a section on supporting both >> 1.1 and 2.0): >> >> - When granting a request token, Provider stores oauth_callback along with >> its token info (if provided). >> - On authorization page, Provider checks if they got a signed >> oauth_callback with the request token. If not, display extra warning >> messages. >> - Provider should be able to always send back an oauth_verifier, even >> though 1.0 clients will ignore it. It can store this with the request token >> info as well. >> - When exchanging for an access token, Provider looks up if it got a >> signed oauth_callback, and only then does it check for oauth_verifier and >> ensure it matches the stored version. >> >> Similarly, a consumer that wants to support 1.0A and 1.0 should be able to >> do the following: >> - always send oauth_callback both on the request token call and on the >> authorization page >> - look for oauth_verifier in the authorization response, and add it to the >> access_token call if present >> >> 3) Another suggestion we made last week was that rather than adding a >> *new* parameter to the Access Token request call (for oauth_verifier), which >> has the downside that it no longer matches the normal "oauth-signed URL >> call" signature of (token+secret+url) like request token and access token >> and protected resource access used to all share, instead you just append the >> oauth_verifier to the request token and send that up as before. This is more >> backwards-compatible in my mind and will make for a smoother transition of >> libraries and implementations. And it does not reduce the security at all. >> Anyone think this is a bad idea, and if so, why? >> >> Thanks! js >> >> >> On Thu, Apr 30, 2009 at 12:25 AM, Eran Hammer-Lahav >> <[email protected]>wrote: >> >>> >>> Please review: >>> >>> >>> http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html >>> >>> I did my best to keep the changes to a bare minimum and to avoid any >>> editorial changes to make comparison trivial: >>> >>> >>> http://code.google.com/p/oauth/source/diff?spec=svn992&old=991&r=992&format=unidiff&path=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml >>> >>> Some notes: >>> >>> 1. This is not ready for code! Please wait for a second draft before you >>> start making changes to libraries or your implementations. Given the small >>> scope of this change, I think it will be stable in the next draft. >>> >>> 2. Since this change is small, I would like to give it a short review >>> period before another draft. Please submit all your comments by May 8th. >>> >>> 3. This draft is missing a few new Security Consideration sections. It >>> will be added in the next draft but might be shared earlier on the list. >>> >>> 4. This revision does not change the value of the oauth_version parameter >>> which remains '1.0'. The reason for that is that the version has nothing to >>> do with the authorization workflow. It is specific to the signature methods >>> and parameter delivery methods. Telling the difference between the two >>> revisions is very simple: look for an oauth_callback parameter in the >>> Request Token step. >>> >>> 5. The reason why the oauth_callback parameter is now required with a >>> 'oob' value for manual entry is because the presence of the oauth_callback >>> parameter in the first step is the only indication which flow is being used. >>> Since some platforms have problem with empty parameters (they are dropped or >>> not sent on the wire), I decided to try and define a non-URL value (also >>> made the URL absolute). >>> >>> NOTE: Do no suggest ANY editorial changes that are not specific to the >>> changed sections. This is NOT an opportunity to improve the specification. >>> If you want to improve the specification in general, please provider >>> feedback to the Editor's Cut version. >>> >>> Tomorrow, I will post an updated Editor's Cut version as well as an >>> update to the IETF draft to include these changes. >>> >>> EHL >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
