Subject: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 8 Dec 2020 07:50:33 -0500

All,

This is a call for adoption for the following AS Issuer Identifier in
Authorization Response as a WG document:
https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/

Please, provide your feedback on the mailing list by Dec 22nd.

Regards,
 Rifaat & Hannes

---

From: Neil Madden <[email-masked]>
Date: Tue, 8 Dec 2020 13:05:01 +0000

I support adoption of this draft.

> On 8 Dec 2020, at 12:50, Rifaat Shekh-Yusef <[email-masked]> wrote:
> 
> All,
> 
> This is a call for adoption for the following AS Issuer Identifier in Authorization Response as a WG document:
> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ <https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/>
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 8 Dec 2020 14:05:58 +0100

I support the WG adoption of this draft. 

> Am 08.12.2020 um 13:50 schrieb Rifaat Shekh-Yusef <[email-masked]>:
> 
> All,
> 
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1608036656000000&usg=AOvVaw3LQv8gGHF-mvbizMYxf_54

---

From: Daniel Fett <[email-masked]>
Date: Tue, 8 Dec 2020 14:40:16 +0100

Obviously, +1.

-- 
https://danielfett.de

---

From: Takahiko Kawasaki <[email-masked]>
Date: Tue, 8 Dec 2020 23:33:11 +0900

+1. I've implemented the specification. I think that the current draft is
already good enough for implementers. Thank you, authors.

Taka

---

From: Karsten Meyer zu Selhausen <[email-masked]>
Date: Tue, 8 Dec 2020 15:50:53 +0100

+1

On 08.12.2020 13:50, Rifaat Shekh-Yusef wrote:
> <https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/>
>

-- 
Karsten Meyer zu Selhausen
IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training

Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:
https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021

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, Dr. Marcus Niemietz

---

From: Brian Campbell <[email-masked]>
Date: Tue, 8 Dec 2020 08:12:36 -0700

support adoption

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Dave Tonge <[email-masked]>
Date: Tue, 8 Dec 2020 16:14:21 +0100

I support adoption

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 8 Dec 2020 19:40:27 +0200

Support with both hands!

Vladimir

---

From: Dick Hardt <[email-masked]>
Date: Tue, 8 Dec 2020 11:00:43 -0800

+1
ᐧ

---

From: Warren Parad <[email-masked]>
Date: Tue, 8 Dec 2020 20:15:37 +0100

As an implementer on both sides of the issue I'm struggling to understand
how this problem would occur. I'm finding issues with the proposed problems:

   1. Honest AS is compromised, assuming this does happen details on why
   adding iss to the AS response would prevent attacks is necessary for me. In
   other words, how would an AS be compromised in a way that would be
   identifiable through the issuer value? (my ignorant assumption is that a
   compromised AS is compromised enough that an attacker would be able to send
   the correct ISS)
   2. Attacker AS is registered. I fully support the idea that this can and
   will happen, however from attempting to test-implement this proposal, I
   can't see how the authorization would be sent to the wrong token endpoint.
   Since there is no information in the AS auth code response, the client must
   already have the knowledge of where they are going to send the token, no
   mix-up can be executed. I would argue, if anything, adding the ISS
   parameter would open a new attack surface by providing clients an
   opportunity to blatantly trust the ISS parameter as the honest AS and thus
   actually sending the code there instead of sending it to one specified in
   the metadata document.

My confusion is the following:

   - Are multi AS services utilizing authorization codes in a way where
   there could be a mix up attack for #2.
   - Is there a #3 that I'm missing which even in light of #1 & #2 I
   brought up that would still make this change valuable?

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.

---

From: Daniel Fett <[email-masked]>
Date: Wed, 9 Dec 2020 08:43:43 +0100

Hi Warren,

Am 08.12.20 um 20:15 schrieb Warren Parad:
> As an implementer on both sides of the issue I'm struggling to
> understand how this problem would occur. I'm finding issues with the
> proposed problems:
>
>     adding iss to the AS response would prevent attacks is necessary
>     for me. In other words, how would an AS be compromised in a way
>     that would be identifiable through the issuer value? (my ignorant
>     assumption is that a compromised AS is compromised enough that an
>     attacker would be able to send the correct ISS)
>
If an AS is compromised, we can't do much for it anyway. We must assume
that all credentials from this AS can be stolen or forged and that
resource servers relying on this AS have a big problem, too. The Mix-Up
Attack is about attacking *other* (uncompromised) AS using the client's
trust in the compromised AS.

For clarification, in our slides we refer to

- an uncompromised AS as H-AS (honest AS) - this is the AS which issues
the credentials the attacker wants to read, and
- a compromised AS as A-AS - this may have been uncompromised previously
or may have been introduced into the ecosystem for the sole purpose of
running the mix-up attack.

In the mix-up attack, the client assumes that it is talking to A-AS but
actually received the authorization response from H-AS. This is why the
iss parameter helps: It always comes from H-AS (together with the
authorization code) and therefore cannot be modified by the attacker.
(If the attacker would be able to intercept/tamper with this
communiction, there would be no need to run a mix-up attack in the first
place.)

>  1. Attacker AS is registered. I fully support the idea that this can
>     and will happen, however from attempting to test-implement this
>     proposal, I can't see how the authorization would be sent to the
>     wrong token endpoint. Since there is no information in the AS auth
>     code response, the client must already have the knowledge of where
>     they are going to send the token, no mix-up can be executed.
>
The assumption in the mix-up attack is that the client stores where to
send the authorization code, for example in a session bound to the
resource owner's browser. This would always be the token endpoint of the
attacker (A-AS) in the mix-up attack, either because the user selected
A-AS as the AS or because the attacker had an opportunity to modify the
user's choice.
>
>  1. I would argue, if anything, adding the ISS parameter would open a
>     new attack surface by providing clients an opportunity to
>     blatantly trust the ISS parameter as the honest AS and thus
>     actually sending the code there instead of sending it to one
>     specified in the metadata document.
>
As far as I can see, the potential attacks from such a bug on the
client's side would not be worse than mix-up, at least. It would
undermine session integrity probably, in that an attacker-AS would be
able to steer the client to send the code to H-AS. I'll take a closer
look at this.
>   * Are multi AS services utilizing authorization codes in a way where
>   * Is there a #3 that I'm missing which even in light of #1 & #2 I
I'm not sure if I could help to clear up the confusion a bit. I'd
recommend that you take a look at Section 3.3.2. of this document [1]
which provides a more detailed description of the mix-up attack and why
the defense mechanism works.

-Daniel

[1]
https://elib.uni-stuttgart.de/bitstream/11682/10214/1/%27An%20Expressive%20Formal%20Model%20of%20the%20Web%20Infrastructure.pdf

> On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     +1
>     ᐧ
>
>     On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         All,
>
>         This is a call for adoption for the following AS Issuer
>         Identifier in Authorization Response as a WG document:
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
https://danielfett.de

---

From: Karsten Meyer zu Selhausen <[email-masked]>
Date: Wed, 9 Dec 2020 08:55:20 +0100

Hi Warren,

I think there is some misunderstanding on how mix-up attacks work. I 
will try to clear things up.

Have a look at the following mix-up attack example (slide 4 
<https://datatracker.ietf.org/meeting/interim-2020-oauth-17/materials/slides-interim-2020-oauth-17-sessa-as-issuer-identifier-in-authorization-response-00#page=4> 
from the interim meeting):

I marked the important parts:

  * In step 1 the client stores the attacker's AS (A-AS) as the selected
    AS.
  * Step 5: The authorization response is issued by the honest *(= not
    compromised)* AS, not by the attacker's AS. The H-AS will use its
    own correct issuer identifier as the value for the AS parameter.
      o In a mix-up attack the attacker cannot directly influence the
        value of the iss parameter in the authorization response as it
        is issued by the H-AS.
  * Step 6: The client sends the token request to the token endpoint of
    the A-AS, because it stored the A-AS as the selected AS in step 1.
    This leaks the authorization code to the attacker who can use it in
    a code injection attack, for example.

With an iss parameter present in step 5 the client would be able to 
recognize that the code was issued by the H-AS, not by the A-AS. The 
client would be able to abort the authorization grant instead of leaking 
the code to the A-AS.

I hope this addresses your concerns.

Best regards,
Karsten

On 08.12.2020 20:15, Warren Parad wrote:
>  2. Attacker AS is registered. I fully support the idea that this can
>     they are going to send the token, no mix-up can be executed. I
>     would argue, if anything, adding the ISS parameter would open a
>         <https://www.ietf.org/mailman/listinfo/oauth>
>
>     <https://www.ietf.org/mailman/listinfo/oauth>
>

Hackmanit GmbH

---

From: Warren Parad <[email-masked]>
Date: Wed, 9 Dec 2020 10:47:35 +0100

Okay, it wasn't clear that the user agent was required to be compromised
for this to be a problem. Here's where it breaks down for me, if the
attacker can manipulate the first request, why would they not be able to
manipulate the AS where the Auth Response code is sent?  Unless we can
guarantee there is an attack surface that would only affect the
authorization request AS selection and not the auth response, the solution
the draft lacks purpose for me.

Warren Parad

Founder, CTO

On Wed, Dec 9, 2020 at 8:55 AM Karsten Meyer zu Selhausen <
[email-masked]> wrote:

> Hi Warren,
>
> I think there is some misunderstanding on how mix-up attacks work. I will
> try to clear things up.
>
>    - In step 1 the client stores the attacker's AS (A-AS) as the selected
>    AS.
>    - Step 5: The authorization response is issued by the honest *(= not
>    compromised)* AS, not by the attacker's AS. The H-AS will use its own
>    correct issuer identifier as the value for the AS parameter.
>       - In a mix-up attack the attacker cannot directly influence the
>       value of the iss parameter in the authorization response as it is issued by
>       the H-AS.
>    - Step 6: The client sends the token request to the token endpoint of
>    the A-AS, because it stored the A-AS as the selected AS in step 1. This
>    leaks the authorization code to the attacker who can use it in a code
>    injection attack, for example.
>
> recognize that the code was issued by the H-AS, not by the A-AS. The client
> would be able to abort the authorization grant instead of leaking the code
> to the A-AS.
>
>    and will happen, however from attempting to test-implement this proposal, I
>> On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef <
>> [email-masked]> wrote:
>>
>>> All,
>>>
> Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil:https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021
>
> Hackmanit GmbH

---

From: Jim Willeke <[email-masked]>
Date: Wed, 9 Dec 2020 04:54:13 -0500

I support the adoption of AS Issuer Identifier in Authorization Response.
--
-jim
Jim Willeke

On Wed, Dec 9, 2020 at 4:48 AM Warren Parad <[email-masked]> wrote:

>>    - In step 1 the client stores the attacker's AS (A-AS) as the
>>    selected AS.

---

From: Karsten Meyer zu Selhausen <[email-masked]>
Date: Wed, 9 Dec 2020 11:40:13 +0100

The attacker being able to manipulate the first request is an additional 
precondition for the mix-up attack variant we used as an example. The 
precondition is based on the attacker A2 defined in section 3 
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-3> 
of the security BCP.

There are other mix-up variants which work without this precondition. 
One variant is described in the security BCP 
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.4.1>, 
for example:

> *Mix-Up Without Interception*: A variant of the above attack works
>        even if the first request/response pair cannot be intercepted, for
>        example, because TLS is used to protect these messages: Here, it
>        is assumed that the user wants to start the grant using A-AS (and
>        not H-AS, see Attacker A1).  After the client redirected the user
>        to the authorization endpoint at A-AS, the attacker immediately
>        redirects the user to H-AS (changing the client ID to "7ZGZldHQ").
>        Note that a vigilant user might at this point detect that she
>        intended to use A-AS instead of H-AS.

On 09.12.2020 10:47, Warren Parad wrote:
> Okay, it wasn't clear that the user agent was required to be 
> compromised for this to be a problem. Here's where it breaks down for 
> me, if the attacker can manipulate the first request, why would they 
> not be able to manipulate the AS where the Auth Response code is 
> sent?  Unless we can guarantee there is an attack surface that would 
> only affect the authorization request AS selection and not the auth 
> response, the solution the draft lacks purpose for me.
>
> 	
>
> Warren Parad
>
> Founder, CTO
>
> On Wed, Dec 9, 2020 at 8:55 AM Karsten Meyer zu Selhausen 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Warren,
>
>     I think there is some misunderstanding on how mix-up attacks work.
>     I will try to clear things up.
>
>       * In step 1 the client stores the attacker's AS (A-AS) as the
>         selected AS.
>       * Step 5: The authorization response is issued by the honest *(=
>         not compromised)* AS, not by the attacker's AS. The H-AS will
>         use its own correct issuer identifier as the value for the AS
>         parameter.
>           o In a mix-up attack the attacker cannot directly influence
>             the value of the iss parameter in the authorization
>             response as it is issued by the H-AS.
>       * Step 6: The client sends the token request to the token
>         endpoint of the A-AS, because it stored the A-AS as the
>         selected AS in step 1. This leaks the authorization code to
>         the attacker who can use it in a code injection attack, for
>         example.
>
>     With an iss parameter present in step 5 the client would be able
>     to recognize that the code was issued by the H-AS, not by the
>     A-AS. The client would be able to abort the authorization grant
>     instead of leaking the code to the A-AS.
>
>>     understand how this problem would occur. I'm finding issues with
>>     the proposed problems:
>>
>>      1. Honest AS is compromised, assuming this does happen details
>>         on why adding iss to the AS response would prevent attacks is
>>         necessary for me. In other words, how would an AS be
>>         compromised in a way that would be identifiable through the
>>         issuer value? (my ignorant assumption is that a compromised
>>         AS is compromised enough that an attacker would be able to
>>         send the correct ISS)
>>      2. Attacker AS is registered. I fully support the idea that this
>>         can and will happen, however from attempting to
>>         test-implement this proposal, I can't see how the
>>         authorization would be sent to the wrong token endpoint.
>>         Since there is no information in the AS auth code response,
>>         the client must already have the knowledge of where they are
>>         going to send the token, no mix-up can be executed. I would
>>         argue, if anything, adding the ISS parameter would open a new
>>         attack surface by providing clients an opportunity to
>>       * Are multi AS services utilizing authorization codes in a way
>>         where there could be a mix up attack for #2.
>>       * Is there a #3 that I'm missing which even in light of #1 & #2
>>         I brought up that would still make this change valuable?
>>
>>     	
>>
>>     Warren Parad
>>
>>     Founder, CTO
>>
>>     Secure your user data and complete your authorization
>>     architecture. Implement Authress <https://bit.ly/37SSO1p>.
>>
>>
>     Web:	https://hackmanit.de  <https://hackmanit.de>  | IT Security Consulting, Penetration Testing, Security Training
>
>     https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021  <https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021>
>
>     Hackmanit GmbH

Hackmanit GmbH

---

From: Warren Parad <[email-masked]>
Date: Wed, 9 Dec 2020 14:34:53 +0100

Since there is a potentially valid TLS case, let's shelve the non-TLS case
without the precondition. I agree a MITM attack on the authorization code
is a legitimate case which would be mitigated by resolving the ISS
parameter to determine the valid token endpoint. I would suggest to improve
the language in the *Introduction* to specifically indicate this as a
solution to the authorization code interception. (It wasn't clear to me
before this conversation that it helped solved that problem)

So +1

On Wed, Dec 9, 2020, 11:40 Karsten Meyer zu Selhausen <
[email-masked]> wrote:

> There are other mix-up variants which work without this precondition. One
> variant is described in the security BCP

---

From: Kevin Gaynor <[email-masked]>
Date: Wed, 9 Dec 2020 13:36:58 +0000

Whaybdo I keep getting these messages and how did you hack my email

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: OAuth <[email-masked]> on behalf of Warren Parad <[email-masked]>
Sent: Wednesday, December 9, 2020 8:34:53 AM
To: Karsten Meyer zu Selhausen <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

Since there is a potentially valid TLS case, let's shelve the non-TLS case without the precondition. I agree a MITM attack on the authorization code is a legitimate case which would be mitigated by resolving the ISS parameter to determine the valid token endpoint. I would suggest to improve the language in the Introduction to specifically indicate this as a solution to the authorization code interception. (It wasn't clear to me before this conversation that it helped solved that problem)

So +1

On Wed, Dec 9, 2020, 11:40 Karsten Meyer zu Selhausen <[email-masked]<mailto:[email-masked]>> wrote:

The attacker being able to manipulate the first request is an additional precondition for the mix-up attack variant we used as an example. The precondition is based on the attacker A2 defined in section 3<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-3> of the security BCP.

There are other mix-up variants which work without this precondition. One variant is described in the security BCP<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.4.1>, for example:

On 09.12.2020 10:47, Warren Parad wrote:
Okay, it wasn't clear that the user agent was required to be compromised for this to be a problem. Here's where it breaks down for me, if the attacker can manipulate the first request, why would they not be able to manipulate the AS where the Auth Response code is sent?  Unless we can guarantee there is an attack surface that would only affect the authorization request AS selection and not the auth response, the solution the draft lacks purpose for me.

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit.ly/37SSO1p>.

On Wed, Dec 9, 2020 at 8:55 AM Karsten Meyer zu Selhausen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Warren,

I think there is some misunderstanding on how mix-up attacks work. I will try to clear things up.

Have a look at the following mix-up attack example (slide 4<https://datatracker.ietf.org/meeting/interim-2020-oauth-17/materials/slides-interim-2020-oauth-17-sessa-as-issuer-identifier-in-authorization-response-00#page=4> from the interim meeting):

[X]

  *   In step 1 the client stores the attacker's AS (A-AS) as the selected AS.
  *   Step 5: The authorization response is issued by the honest (= not compromised) AS, not by the attacker's AS. The H-AS will use its own correct issuer identifier as the value for the AS parameter.
     *   In a mix-up attack the attacker cannot directly influence the value of the iss parameter in the authorization response as it is issued by the H-AS.
  *   Step 6: The client sends the token request to the token endpoint of the A-AS, because it stored the A-AS as the selected AS in step 1. This leaks the authorization code to the attacker who can use it in a code injection attack, for example.

With an iss parameter present in step 5 the client would be able to recognize that the code was issued by the H-AS, not by the A-AS. The client would be able to abort the authorization grant instead of leaking the code to the A-AS.

Best regards,
Karsten

On 08.12.2020 20:15, Warren Parad wrote:
As an implementer on both sides of the issue I'm struggling to understand how this problem would occur. I'm finding issues with the proposed problems:

  1.  Honest AS is compromised, assuming this does happen details on why adding iss to the AS response would prevent attacks is necessary for me. In other words, how would an AS be compromised in a way that would be identifiable through the issuer value? (my ignorant assumption is that a compromised AS is compromised enough that an attacker would be able to send the correct ISS)
  2.  Attacker AS is registered. I fully support the idea that this can and will happen, however from attempting to test-implement this proposal, I can't see how the authorization would be sent to the wrong token endpoint. Since there is no information in the AS auth code response, the client must already have the knowledge of where they are going to send the token, no mix-up can be executed. I would argue, if anything, adding the ISS parameter would open a new attack surface by providing clients an opportunity to blatantly trust the ISS parameter as the honest AS and thus actually sending the code there instead of sending it to one specified in the metadata document.

  *   Are multi AS services utilizing authorization codes in a way where there could be a mix up attack for #2.
  *   Is there a #3 that I'm missing which even in light of #1 & #2 I brought up that would still make this change valuable?

[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO

Secure your user data and complete your authorization architecture. Implement Authress<https://bit.ly/37SSO1p>.

On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
+1
[X]ᐧ

On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:
All,

Regards,
 Rifaat & Hannes
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

Hackmanit GmbH

Hackmanit GmbH

---

From: Dominick Baier <[email-masked]>
Date: Mon, 14 Dec 2020 02:02:35 -0800

+1

———
Dominick Baier

On 8. December 2020 at 13:51:04, Rifaat Shekh-Yusef ([email-masked])
wrote:

All,

Regards,
 Rifaat & Hannes