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
