[Openid-specs-ab] Securing token requests when discovery service is used

Nat Sakimura sakimura at gmail.com
Thu Nov 5 05:42:28 UTC 2015


We will get back to you.

2015-11-05 1:45 GMT+09:00 Preibisch, Sascha H <Sascha.Preibisch at ca.com>:

> I guess the meeting already happened, correct?
>
> Unfortunately I cannot/ couldn't join but as others I am certainly
> interested in the outcome.
>
> Sascha
>
> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on
> behalf of John Bradley <ve7jtb at ve7jtb.com>
> Date: Monday, November 2, 2015 at 4:04 AM
> To: Nat Sakimura <sakimura at gmail.com>
> Cc: "openid-specs-ab at lists.openid.net Ab" <
> openid-specs-ab at lists.openid.net>
> Subject: Re: [Openid-specs-ab] Securing token requests when discovery
> service is used
>
> 5 is OK with me.  We should be able to use 313 again.
>
>
> On Nov 2, 2015, at 8:42 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>
> Any prospect of a meeting room?
> We'll probably need a white board.
> Unfortunately, it is a public holiday so I cannot offer NRI's meeting
> rooms in Yokohama...
>
> =nat via iPhone
>
> 2015/11/02 20:07、nov matake <nov at matake.jp> のメッセージ:
>
> It works for me too.
>
> On Nov 2, 2015, at 19:43, Justin Richer <jricher at mit.edu> wrote:
>
> That works for me, too (it’s just after the COSE meeting).
>
>  — Justin
>
> On Nov 2, 2015, at 7:25 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
> 5pm tomorrow works for me. Meet at the IETF registration desk?
> ------------------------------
> From: Nat Sakimura <sakimura at gmail.com>
> Sent: 11/2/2015 6:54 PM
>
> To: nov matake <nov at matake.jp>
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Securing token requests when discovery
> service is used
>
> What about 5pm and before the social?
>
> 2015-11-02 18:40 GMT+09:00 nov matake <nov at matake.jp>:
>
>> Does the f2f happen tomorrow in Yokohama?
>> Then I can join :)
>>
>> nov
>>
>> On Nov 2, 2015, at 11:29, Nat Sakimura <sakimura at gmail.com> wrote:
>>
>> perhaps do a f2f adhoc this week?
>>
>>
>>
>> 2015年11月2日月曜日、John Bradley<ve7jtb at ve7jtb.com>さんは書きました:
>>
>>> The attack is not on the authentication, it is on intercepting the code
>>> and being able to replay it.
>>>
>>> Using a key the client is given from  registration to authenticate the
>>> request to the token endpoint won’t help because that can just be man in
>>> the middled by the attacker as well.
>>>
>>> This is also not specific to dynamic client registration.  It just makes
>>> it easier.  I could make the client come to a site to register and give it
>>> bad endpoints as well.
>>>
>>> In Connect if you do a id_token code flow the issuer in the returned
>>> token would be wrong for the request so that should actually stop the
>>> attack on a client that is validating id_token correctly in that flow.
>>>  (allowing late binding per one proposal will make this vulnerable as well
>>> I think.
>>>
>>> In the code only flow it is much harder to stop because the attacker can
>>> register itself and then replay any keys it gets from the real AS.
>>> If the client provides a public key in registration that would help if
>>> we used signed requests.
>>>
>>> To stop the attack you really need to send the token endpoint URI in the
>>> request to the Authorization server, or use a asymmetric pkce challenge
>>> verifier.
>>>
>>> I haven’t had a chance to organize the options yet.
>>>
>>> John B.
>>>
>>>
>>>
>>> On Oct 31, 2015, at 5:14 AM, Mike Jones <Michael.Jones at microsoft.com>
>>> wrote:
>>>
>>> The other thing that can't be faked by an attacker is the OP's keys. If
>>> the ID token isn't signed by the right keys, then the RP knows that there's
>>> a problem.  This points to a possible solution involving authenticating the
>>> jwks_uri value.
>>>
>>> Remember also that the Implicit flows don't use a token endpoint. So
>>> solutions that involve authenticating the token endpoint won't work for
>>> deployments using only Implicit flows.
>>>
>>> John, Justin, and Nov, when you send in your IIW session notes, can you
>>> also please send them here?
>>>
>>> Thanks,
>>> -- Mike
>>> ------------------------------
>>> From: Preibisch, Sascha H
>>> Sent: 10/30/2015 1:00 PM
>>>
>>> To: openid-specs-ab at lists.openid.net
>>> Subject: [Openid-specs-ab] Securing token requests when discovery
>>> service is used
>>>
>>> Hi!
>>>
>>> Now that IIW is over I would like to bring up my thoughts regarding the
>>> session we had with John regarding the discovery service issue.
>>>
>>> If I am the 'bad' discovery service provider I can fake all values within
>>> the discovery response. Except for the /token endpoint. That has to point
>>> to my system in order for me to receive the authorization_code and client
>>> credentials.
>>>
>>> Therefore I believe there are two solutions:
>>>
>>> * the discovery response to the client has to include a secret which has
>>> to be included
>>> in the initial /authorize request. The authorization server validates the
>>> value and fails the request if it is invalid. This of course has the
>>> drawback that the authorization server has to keep state. As a server guy
>>> I would not like to support this flow
>>>
>>> * The better solution I see, and as I mentioned during the discussion, is
>>> that the client should include the target /token endpoint as an
>>> additional
>>> request parameter for the initial /authorize request. The authorization
>>> server does a simple string comparison and fails if the /token endpoint
>>> is
>>> not the one as expected
>>>
>>> Regards,
>>> Sascha
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=CwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=bOTOfTxEmIQTjiRHPC3i3r2EPT_oWedSENfSi8VwmdA&s=FlU_e-9cDXuiuApS7juSCLK3lqIvLbj6DBFlO82ztOM&e=>
>>>
>>>
>>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=CwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=bOTOfTxEmIQTjiRHPC3i3r2EPT_oWedSENfSi8VwmdA&s=uP8Ls0zwqc3Uw2TCt6NaOUDvc-9c9pM6ZHSzD4O8N-o&e=>
>> @_nat_en
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=CwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=bOTOfTxEmIQTjiRHPC3i3r2EPT_oWedSENfSi8VwmdA&s=FlU_e-9cDXuiuApS7juSCLK3lqIvLbj6DBFlO82ztOM&e=>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nat.sakimura.org_&d=CwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=bOTOfTxEmIQTjiRHPC3i3r2EPT_oWedSENfSi8VwmdA&s=uP8Ls0zwqc3Uw2TCt6NaOUDvc-9c9pM6ZHSzD4O8N-o&e=>
> @_nat_en
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=CwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=bOTOfTxEmIQTjiRHPC3i3r2EPT_oWedSENfSi8VwmdA&s=FlU_e-9cDXuiuApS7juSCLK3lqIvLbj6DBFlO82ztOM&e=>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=CwQFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=bOTOfTxEmIQTjiRHPC3i3r2EPT_oWedSENfSi8VwmdA&s=FlU_e-9cDXuiuApS7juSCLK3lqIvLbj6DBFlO82ztOM&e=>
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20151105/fa008772/attachment.html>


More information about the Openid-specs-ab mailing list