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
-~----------~----~----~----~------~----~------~--~---
