Problem with nonces and HTTP GET

Breno de Medeiros breno at google.com
Thu Jan 28 18:16:49 UTC 2010


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



-- 
--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