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