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

Nat Sakimura sakimura at gmail.com
Mon Nov 2 09:54:12 UTC 2015


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
>>
>>
>>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
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/20151102/87862a93/attachment.html>


More information about the Openid-specs-ab mailing list