Subject: Re: [OAUTH-WG] Doc Shepherd Review - OAuth 2.0 Authorization Server Issuer Identification

From: Karsten Meyer zu Selhausen <[email-masked]>
Date: Thu, 7 Oct 2021 07:21:43 +0200

Hi Rifaat,

apologies for the delay.

We published a new draft addressing your comments.

We changed Section 2.4, paragraph 3 to:

> If clients interact with both authorization servers supporting this
>     specification and authorization servers not supporting this
>     specification, clients MUST store the information which authorization
>     server supports the iss parameter.  Clients*MUST*  reject authorization
>     responses without the iss parameter from authorization servers which
>     do support the parameter according to the client's configuration.
>     *Clients SHOULD discard authorization responses with the iss parameter 
> from authorization servers which do not indicate their support for the 
> parameter. However, there might be legitimate authorization servers 
> that provide the iss parameter without indicating their support in 
> their metadata. The decision of whether to accept such responses is 
> individual for every scenario and it is not in the scope of this 
> specification.*

Let us know if there is anything else we should work on.

Best regards,
Karsten

On 26.09.2021 00:04, Rifaat Shekh-Yusef wrote:
> Karsten, Daniel,
>
> Can you please address my comments in a new version of the draft to 
> allow me to progress it?
>
> Regards,
>  Rifaat
>
>
> On Mon, Sep 6, 2021 at 6:50 AM Karsten Meyer zu Selhausen 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Rifaat,
>
>     thank you for the shepherd's review.
>
>     Those are valid comments. We will have a second look on this
>     paragraph.
>
>     Best regards,
>     Karsten
>
>     On 04.09.2021 16:20, Rifaat Shekh-Yusef wrote:
>>     Hi Karsten, Daniel,
>>
>>     As the document shepherd, I have reviewed the document and I have
>>     the following comments on draft-ietf-oauth-iss-auth-resp-01 version:
>>
>>
>>     Section 2.4, paragraph 3, first sentence:
>>
>>     "If clients interact with both authorization servers supporting this
>>        specification and authorization servers not supporting this
>>        specification, clients SHOULD store the information which
>>        authorization server supports the "iss" parameter."
>>
>>     Why is this a SHOULD?
>>
>>
>>     "Clients MUST
>>        reject authorization responses without the "iss" parameter from
>>        authorization servers which do support the parameter according
>>     to the
>>        client's configuration."
>>
>>     What should the client do when it receives a response with "iss"
>>     parameter
>>     from an authorization server that did not indicate its support
>>     for this parameter?
>>
>>
>>     Section 7
>>
>>     RFC6479 should be replaced with *RFC6749*
>>
>>
>>     Regards,
>>       Rifaat
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/oauth  <https://www.ietf.org/mailman/listinfo/oauth>
>
>     -- 
>     Karsten Meyer zu Selhausen
>     Senior IT Security Consultant
>     Phone:	+49 (0)234 / 54456499
>     Web:	https://hackmanit.de  <https://hackmanit.de>  | IT Security Consulting, Penetration Testing, Security Training
>
>     Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? Find out more on our blog:
>     https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks  <https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks>
>
>     Hackmanit GmbH
>     Universitätsstraße 60 (Exzenterhaus)
>     44789 Bochum
>
>     Registergericht: Amtsgericht Bochum, HRB 14896
>     Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
>
-- 
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training

Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? Find out more on our blog:
https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 7 Oct 2021 08:23:50 -0400

Thanks Karsten!

On Thu, Oct 7, 2021 at 1:21 AM Karsten Meyer zu Selhausen <
[email-masked]> wrote:

>    server supports the iss parameter.  Clients *MUST* reject authorization
>    from authorization servers which do not indicate their support for
>    the parameter.  However, there might be legitimate authorization
>    servers that provide the iss parameter without indicating their
>    support in their metadata.  The decision of whether to accept such
>    responses is individual for every scenario and it is not in the scope
>    of this specification.*
>
>
> Can you please address my comments in a new version of the draft to allow
> me to progress it?
>
> Regards,
>  Rifaat
>
>
> On Mon, Sep 6, 2021 at 6:50 AM Karsten Meyer zu Selhausen <
> [email-masked]> wrote:
>
>> Hi Rifaat,
>>
>> Those are valid comments. We will have a second look on this paragraph.
>>
>> Best regards,
>> Karsten
>> As the document shepherd, I have reviewed the document and I have the
>> following comments on draft-ietf-oauth-iss-auth-resp-01 version:
>>
>>
>>    authorization servers which do support the parameter according to the
>>    client's configuration."
>>
>> What should the client do when it receives a response with "iss" parameter
>> from an authorization server that did not indicate its support for this
>> parameter?
>>
>>
>> Section 7
>>
>> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>>
>> --
>> Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? Find out more on our blog:https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>>
>> Hackmanit GmbH
> Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? Find out more on our blog:https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
>
> Hackmanit GmbH