[oauth] Re: Version Preference
Using the current draft, SPs now have to be able to determine/detect the spec version being used (1.0 or 1.0a). This can be achieved by either sending the oauth_callback when a request token is obtained or by using alternate endpoints as you suggested. The SP now has to essentially store the version of the auth flow used when the request token was obtained. Then in the auth and access token phases, use this stored version to determine to if the oauth_verifier is required. IF the oauth_version WAS incremented to 1.1, I wouldn't have to maintain prior knowledge of which auth flow was used. In the authorize phase, I would always return the oauth_verifier. Then when an Access Token is requested, for oauth_version 1.1, I would enforce that the oauth_verifier was required and for oauth_version 1.0, I would verify oauth_verifier if it was sent. The benefits of using the latter method (at least for me)... 1. The required changes are a lot easier to implement 2. I can easily deprecate oauth_version 1.0 when I want 3. I don't have to maintain multiple endpoints for my consumers, which is going to be confusing My main gripe about not incrementing the oauth_version, if it's not going to be incremented when we are fixing a flaw which it at the heart of OAuth, when would it ever be incremented ? And If it's not ever going to change why even have it ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Desktop Application Callback Value
On May 2, 2:19 am, Brian Eaton bea...@google.com wrote: On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote: 1. None. Applications that cannot receive callbacks (or that have static callback endpoints) should be configured as such in an out-of-band flow, along with the service provider issues the consumer key and secret. Just because the callback is preregistered doesn't mean an application won't want to update it at runtime. For example, they might want to add session state information or language preference information. We allowed for this with our implementation by returning any additional Consumer query parameters that were provided in the authorize url. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Version Preference
Not to get off topic here, but it might actually be a good idea to devalidate any access tokens when the SP changes to the new spec. The reason for this is the make sure attackers that might have used the session fixation attack prior to the fix no longer have a valid token. Sure the user will have to do a quick oauth re-authorization, but the security benefit is worth it. This is up to the SP to decide, but just a good tip. On Sat, May 2, 2009 at 1:56 AM, Luca Mearelli luca.meare...@gmail.comwrote: On Fri, May 1, 2009 at 10:15 PM, Luca Mearelli luca.meare...@gmail.com wrote: On Fri, May 1, 2009 at 10:25 AM, Blaine Cook rom...@gmail.com wrote: 1. 1.0 Rev A with no version string change (i.e., oauth_version=1.0) +1 for this Let me put a few words behind this: I see no reason for changing the value of the parameter transmitted over the wire ( oauth_version ) since changing it doesn't do any good to the task here that is fixing the spec security but instead it will rather do harm to the already deployed (and working) code. Let's not forget that the currently issued and authorized access tokens would stop to work for no reason and require reissue if that value is changed. Some of the discussion around the version are related to the possible confusion of having a different version in the spec name and in the wire parameter, to this extent any change to the name that makes it easy to communicate that we are referring to a revised protocol would be good and minimizes the possible confusion, hence the preference for calling it 1.0 Rev A. Moreover I'd see as a good thing to clarify that the role of the oauth_version parameter as NOT being the spec version but the protocol signature version (I mean the way to indicate how to build the signature base string co) Luca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Desktop Application Callback Value
Ok, thankfully it seems here we have much more consensus. I don't see anyone disagreeing that we want an 'oob' value for the callback. I would like to make the following changes to the (proposed) spec so that consumers (or service providers) aren't required to add an extra verification code entry step for desktop consumers: In 6.1.1: Change: oauth_callback: An absolute URL to which the Service Provider will redirect the User back when the Obtaining User Authorization step is completed. If the Consumer is unable to receive callbacks, the parameter value MUST be set to oob (case sensitive). To: oauth_callback: An absolute URL to which the Service Provider will redirect the User when the Obtaining User Authorization step is completed. This parameter is optional if the Consumer has provided, through alternate means, a static callback URL. If the consumer is unable to receive callbacks, the oauth_callback parameter is optional, but when present MUST be set to oob (case sensitive). and 6.2.3: Change: If no callback URL was provided (the value of the oauth_callback parameter was oob, case sensitive), ... To: If no callback URL was provided and the value of the oauth_callback parameter was oob (case sensitive), ... - end of changes Any concerns with moving forward with this wording? I believe it's important to continue supporting desktop applications that do not have support for entering verification codes, and this approach allows service providers to signal in strong terms to a user that they should only approve a request to verify a desktop application if they are actively trying to do so. b. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Desktop Application Callback Value
On Sat, May 2, 2009 at 12:17 PM, Blaine Cook rom...@gmail.com wrote: Any concerns with moving forward with this wording? I believe it's important to continue supporting desktop applications that do not have support for entering verification codes, and this approach allows service providers to signal in strong terms to a user that they should only approve a request to verify a desktop application if they are actively trying to do so. I do agree with what you propose, but I don't think the new wording vs the old is enough to keep working those desktop apps that do not have support for entering verification codes as the revised spec says: In order to ensure that the User granting access is the same User returning back to the Consumer to complete the process, the Service Provider MUST generate a verification code: a non-guessable value passed to the Consumer via the User and REQUIRED to complete the process. it seems that it doesn't allow closing the loop without the verification code being passed from consumer to service provider. (sorry if this sounds silly, I'm just trying to understand help and i don't want to start a new infinite discussion ...) Luca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: This whole version business
On 5/1/09 2:29 PM, Eran Hammer-Lahav wrote: There is a difference between what you name the specification and the string value you put on the wire. My point is that there is no reason to change what is transmitted on the wire. I also made the point that not changing the wire string but changing the document version will be more confusing. Changing both just because it helps with communication with*people* makes no sense. Protocols are for*machines* and those do not need a new version number. Considering that the changes being made to the OAuth specification MUST break backwards compatibility -- as implementations of the current unfixed specification are KNOWN to be insecure -- makes perfect _technical_ sense to rev the version number on the wire to signify this. Continuing to use the current, known insecure, specification is negligent at best and nefarious at worst. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
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 jroessl...@gmail.comwrote: 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 jsm...@gmail.com 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
[oauth] Re: POLL: Can an SP safely allow any Consumer to use the current 1.0 securely?
In practice, I imagine most SPs will do the following: roll out compatible support for 1.0 and 1.0 Rev A, and provide extra warning messages on the consent page for 1.0 consumers. To do it any other way would break all existing implementations. Then SPs will encourage their Consumers to move to 1.0 Rev A (and Consumers will be naturally inclined to do this as a way to get rid of the scary warning message). Then at some point in the future, SPs may stop supporting 1.0 entirely. Thanks, js On Sat, May 2, 2009 at 1:19 PM, Josh Roesslein jroessl...@gmail.com wrote: No, 3 legged consumers can't use the old spec safely, but 2 legged consumers are not affected so they don't need to upgrade for changes that they don't even use. This is what we mean by backward compatiblity. We still want to support 2 legged consumers who are using the same code. If we incremented the version, they would have to update the code just to change a version number for what? There is no gain in doing an increment of the wire version. On Sat, May 2, 2009 at 2:28 PM, Dossy Shiobara do...@panoptic.com wrote: On 5/2/09 2:30 PM, John Kemp wrote: But for 2009.1, I think it's right to stay with oauth_version=1.0, and move on to fix the actual security issue. Fine, it really doesn't matter what the oauth_version is, anyway. Can I see a show of hands - Can an SP safely allow any Consumer to use the current OAuth 1.0 (not referring to the revised 2009.1 draft) securely? [Yes or no?] In other words: If an SP allows an arbitrary Consumer to use the OAuth 1.0 flow as-is, then the security threat continues for that SP? If this is yes then all SP's that switch to 2009.1 _cannot_ allow the currently known insecure OAuth 1.0 flow, so backwards compatibility is a non-issue. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
1.) Well we should really not use a three legged approach for these devices. Reason: these consumers are not going to have multiple users. I suggest a two legged approach instead. 2.) I don't see it as a hack. We are telling the SP hey, we don't want to use a callback. This parameter is required, so we must still include it. 3.) The SP still needs to break them up to look up the record in the DB. We can't use the combined value as the key. If we use this combined value as the key, we can not block brute force attacks for guessing the verifier. We need to limit the number of times a request token can be swapped. If the consumer gives us a bad token+verifier, we don't have a valid key. We would have to split the token and verifier and use the token as the key. Sure we can still make this idea of token+verifier work, but it just seems like a hack to save some time. To me this seems like a hours work at most to add another parameter to the access token request. On Sat, May 2, 2009 at 3:27 PM, Joseph Smarr jsm...@gmail.com wrote: 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 jroessl...@gmail.comwrote: 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 jsm...@gmail.com 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,
