Sorry I am slow. I missed adding a nonce to the return_to. John B. On 2010-01-28, at 3:16 PM, Breno de Medeiros wrote:
> On Thu, Jan 28, 2010 at 10:09, John Bradley <[email protected]> wrote: >> The problem is tying the cookie to the request. Unless you include a nonce >> in the request. >> >> Andrew's lib is doing that for openID 1.1. >> >> You could generate a RP nonce and store that encrypted in the cookie. >> That is closer to holder of key. The IdP winds up signing the RP generated >> nonce as part of the return to. > > That's exactly what I said by adding a crypto function of the cookie > to the return_to URL a couple of emails earlier in this thread. > >> >> Otherwise I could get a cookie and replay someone else's positive response. >> >> John B. >> On 2010-01-28, at 2:41 PM, Breno de Medeiros wrote: >> >>> On Thu, Jan 28, 2010 at 09:38, John Bradley <[email protected]> wrote: >>>> Yes if you immediately followed a positive assertion with a checkID >>>> immediate. >>>> >>>> On the other hand if you are going to do that you could always reject the >>>> duplicate token and follow up with a checkid immediate using the claimed >>>> ID in the rejected assertion. That would work, requires no spec change >>>> and gets rid of the back button problem. >>> >>> Yes, that's something RPs should be doing also. >>> >>>> >>>> If the RP has a loadballancer they would have to synchronies the cookie >>>> value across all of the RP servers. >>> >>> No, the cookie is stored on client only (the expiration time could be >>> enforced via the authenticated encryption in the callback URL or by >>> using a signed cookie) >>> >>>> That is I think the largest issue with the cookie. >>>> >>>> John B. >>>> On 2010-01-28, at 2:26 PM, Breno de Medeiros wrote: >>>> >>>>> On Thu, Jan 28, 2010 at 09:24, John Bradley <[email protected]> >>>>> wrote: >>>>>> That approach would not work for unsolicited assertions. >>>>>> I suspect that some RP loadballanceing could break that as well. >>>>> >>>>> Well, it would if you followed up with a checkid_immediate. I have no >>>>> idea why it'd break load-balancing either: The cookie is a random >>>>> value. >>>>> >>>>>> >>>>>> Something like accept the token only once if r is not present, but >>>>>> accept it multiple times if the correct cookie is there. >>>>>> >>>>>> It is not quite holder of key but perhaps a reasonable compromise >>>>>> without changing the protocol. >>>>>> >>>>>> John b. >>>>>> On 2010-01-28, at 1:27 PM, Breno de Medeiros wrote: >>>>>> >>>>>>> Replay protection can be provided by the RP without OP intervention. >>>>>>> E.g., RP sets a cookie with value = r, where r is a random number. RP >>>>>>> encrypts r into c and attaches &nonce=c to the callback URL. The >>>>>>> cookie could have a suitably short expiration date, say 15 minutes. >>>>>>> >>>>>>> If a replay is performed after 15 minutes, the cookie doesn't match. >>>>>>> >>>>>>> If someone is able to recover the callback URL somehow, it can't >>>>>>> reproduce the cookie, so no good. >>>>>>> >>>>>>> Of course, if the user hits the browser back button, and re-submits >>>>>>> the value repeatedly, the replay 'attack' succeeds, but that is a >>>>>>> desirable behavior. >>>>>>> >>>>>>> If I were implementing an RP with an SSL endpoint, that's how I would >>>>>>> implement protection against replay attacks. Not only it's much >>>>>>> simpler to do (no need to synchronize state) it's actually much more >>>>>>> robust and provides a better user experience without introducing >>>>>>> vulnerabilities (if someone can steal the user's secure cookies in >>>>>>> near-real time then they will be able to steal the user's browser >>>>>>> session anyways). >>>>>>> >>>>>>> On Thu, Jan 28, 2010 at 06:56, John Bradley <[email protected]> >>>>>>> wrote: >>>>>>>> The same response multiple times from the browser without the RP being >>>>>>>> able >>>>>>>> to set a cookie? >>>>>>>> Is that really that common a issue? >>>>>>>> One way that could possibly work is if there is an existing session >>>>>>>> cookie >>>>>>>> that the RP associates with the response and tracks on the RP end. >>>>>>>> This >>>>>>>> has clustering synchronization issues though. >>>>>>>> Artifact resolution won't help for that. >>>>>>>> At the moment several large RP's are only using the timestamp in the >>>>>>>> nonce >>>>>>>> to protect against replay, due to clustering issues. >>>>>>>> Only checking the timestamp while better than nothing would not be >>>>>>>> considered LoA 1 for a RP. >>>>>>>> SP-800-63 is looking for checking a nonce to protect against replay >>>>>>>> and also >>>>>>>> would like timestamp checking (not on or after) on bearer tokens., to >>>>>>>> mitigate against interception at LoA 1. >>>>>>>> The GSA LoA 1 profile required RP to check the nonce for replay and >>>>>>>> recommends placing a maximum time on the validity of an assertion >>>>>>>> based on >>>>>>>> the timestamp in the nonce. >>>>>>>> At LoA 2 timestamp checking would be required. >>>>>>>> I think finding a way for RP to detect and deal with the issue is the >>>>>>>> way to >>>>>>>> go rather than changing the protocol. >>>>>>>> John B. >>>>>>>> On 2010-01-28, at 11:11 AM, Andrew Arnott wrote: >>>>>>>> >>>>>>>> On Thu, Jan 28, 2010 at 3:16 AM, John Bradley <[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> The problem is that RP are not tying the received assertion to the >>>>>>>>> browser >>>>>>>>> session the first time they receive the token. >>>>>>>>> If you get the same token from the same browser session multiple times >>>>>>>>> that should not be a problem. >>>>>>>>> If you get the token from a different browser session that is a >>>>>>>>> problem >>>>>>>>> and it should be rejected. >>>>>>>>> I don't think nonce processing in the spec is broken. Perhaps RP >>>>>>>>> implementations need to improve there handling of authentication >>>>>>>>> tokens. >>>>>>>>> eg set a cookie with the nonce from the last authentication so that >>>>>>>>> if the >>>>>>>>> user hits the back button and resubmits you can detect it. >>>>>>>> >>>>>>>> The broken scenario I started this thread with is about the RP >>>>>>>> receiving the >>>>>>>> assertion multiple times from the browser, but in such a way that the >>>>>>>> initial HTTP responses were discarded. So the RP setting a cookie in >>>>>>>> the >>>>>>>> HTTP response wouldn't help the scenario. >>>>>>>> But I think what you're suggesting would definitely help some of the >>>>>>>> problems around this. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> specs mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> --Breno >>>>>>> >>>>>>> +1 (650) 214-1007 desk >>>>>>> +1 (408) 212-0135 (Grand Central) >>>>>>> MTV-41-3 : 383-A >>>>>>> PST (GMT-8) / PDT(GMT-7) >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --Breno >>>>> >>>>> +1 (650) 214-1007 desk >>>>> +1 (408) 212-0135 (Grand Central) >>>>> MTV-41-3 : 383-A >>>>> PST (GMT-8) / PDT(GMT-7) >>>> >>>> >>> >>> >>> >>> -- >>> --Breno >>> >>> +1 (650) 214-1007 desk >>> +1 (408) 212-0135 (Grand Central) >>> MTV-41-3 : 383-A >>> PST (GMT-8) / PDT(GMT-7) >> >> > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
