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) _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
