Problem with nonces and HTTP GET

John Bradley john.bradley at wingaa.com
Thu Jan 28 18:22:58 UTC 2010


Sorry I am slow.  I missed adding a nonce to the return_to.

John B.
On 2010-01-28, at 3:16 PM, Breno de Medeiros wrote:

> 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