That approach would not work for unsolicited assertions. I suspect that some RP loadballanceing could break that as well.
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) _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
