Problem with nonces and HTTP GET

Breno de Medeiros breno at google.com
Thu Jan 28 17:41:44 UTC 2010


On Thu, Jan 28, 2010 at 09:38, John Bradley <john.bradley at wingaa.com> 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 <john.bradley at wingaa.com> 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 <john.bradley at wingaa.com> 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 <john.bradley at wingaa.com>
>>>>> 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
>>>>> specs at lists.openid.net
>>>>> 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)


More information about the specs mailing list