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. If the RP has a loadballancer they would have to synchronies the cookie value across all of the RP servers. 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) _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
