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

[Kevin Gaynor <[e-mail]>]

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

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: OAuth <[e-mail]> on behalf of Warren Parad <[e-mail]>
Sent: Wednesday, December 9, 2020 8:34:53 AM
To: Karsten Meyer zu Selhausen <[e-mail]>
Cc: oauth <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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:

*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.


[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 <[e-mail]<mailto:[e-mail]>> 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]

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.
     *   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:
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?

[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 <[e-mail]<mailto:[e-mail]>> wrote:
+1
[X]ᐧ

On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>> 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/

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

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

--
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

--
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