On Sun, Apr 26, 2009 at 12:48 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > Let's see if we can take a quick break from the discussion and get a sense of > where we are. Please answer the questions to follow. > > --- > > We have identified 2 solutions listed here: > > https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory > > > * Signed Approval URLs > > This proposal breaks the protocol into two separate flows, one for Consumers > capable of launching a browser and accepting callbacks, and another for those > who can't. It requires a significant rewrite of the specification because of > the way the flow and signature are mixed together in the current Core 1.0 > specification. > > > * Signed Callback URLs > > This proposal makes the callback URL part of the signed request for Request > Token (which does not allow an attacker to manipulate it), and adds some > unpredictable value to the callback redirection that is needed to get an > Access Token. > > The spec changes include (see quick reference at the bottom): > > - Move the oauth_callback parameter from 6.2.1 to 6.1.1 > - Add a new parameter to 6.2.3 which is needed to make 6.3.1 > > --- > > Open questions: > > 1. Am I missing a completely different alternative? If yes, please create a > new wiki page and point to it (if you don't have access ask or email it to > someone who does). > > 2. Given the simplicity of the Signed Callback URLs *specification change*, I > would like to instead of asking people which solution they prefer, to ask > people if they have a strong objection to using the Signed Callback URLs > solution, and if so, to explain why? >
I believe this proposal requires one more piece to verify the user authenticating on SP is the user at the consumer. I would propose: 1. upon completion of 6.2.2, the SP displays a "valet key" to the user: an easy-to-remember string that the user will be required to enter on the consumer side to complete the handshake. 2. This "valet key" is a secret and should NOT be shared before transaction is completed. (the SP encrypts this valet key into the callback_verifier so it will be able to check it before issuing access token at 6.3.2) 3. Before 6.3.1, while on the consumer site, the user is required to enter their "valet key," which is then sent as a parameter along with 6.3.1. 4. SP checks to make sure that the callback_verifier is authentic (and matches the valet key) and if so, issues the access token. (This valet key is impossible for the attacker to convince the victim to enter, since it does not exist before AuthN at SP.) I would note that this proposal *could* be made an extension to OAuth (offering a higher level of security) if there is a general feeling that it is overkill for standard OAuth. Does this hold up? Seem like a reasonable plan? --peter > 3. For the Signed Callback URLs solution, what to call the new parameter > returned in 6.2.3? Suggestions so far included: > > - pin > - verifier > - chaperon > - callback token > - callback secret > > 4. And, should the new parameter be added to 6.3.1 (oauth_token + > oauth_something) or replace the value of the oauth_token parameter? > > The second option basically returns an authorized token which is used with > the existing secret from 6.1.2. The benefit of a new parameter is it is > easier to follow the protocol. The benefit of reusing oauth_token to make > 6.3.1 is that is keeps the signed request consistent with all other signed > requests (no new parameters). > > EHL > > --- > > Quick Reference > > 6.1.1. Consumer Obtains a Request Token > 6.1.2. Service Provider Issues an Unauthorized Request Token > 6.2.1. Consumer Directs the User to the Service Provider > 6.2.2. Service Provider Authenticates the User and Obtains Consent > 6.2.3. Service Provider Directs the User Back to the Consumer > 6.3.1. Consumer Requests an Access Token > 6.3.2. Service Provider Grants an Access Token > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
