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

[Rifaat Shekh-Yusef]

All,

Based on the feedback during the last interim meeting and on this list
below, the WG has decided to adopt this draft as a WG document.


Authors,

When you have a chance, feel free to submit a new WG document.

Regards,
 Rifaat & Hannes


On Mon, Dec 14, 2020 at 5:02 AM Dominick Baier 
wrote:

> +1
>
> ———
> Dominick Baier
>
> On 8. December 2020 at 13:51:04, Rifaat Shekh-Yusef (
> rifaat.s.i...@gmail.com) 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dominick Baier]

+1

———
Dominick Baier

On 8. December 2020 at 13:51:04, Rifaat Shekh-Yusef (rifaat.s.i...@gmail.com)
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Kevin Gaynor]

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

Get Outlook for iOS

From: OAuth  on behalf of Warren Parad 

Sent: Wednesday, December 9, 2020 8:34:53 AM
To: Karsten Meyer zu Selhausen 
Cc: oauth 
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 
mailto:karsten.meyerzuselhau...@hackmanit.de>>
 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 of 
the security BCP.

There are other mix-up variants which work without this precondition. One 
variant is described in the security 
BCP,
 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.


On Wed, Dec 9, 2020 at 8:55 AM Karsten Meyer zu Selhausen 
mailto:karsten.meyerzuselhau...@hackmanit.de>>
 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
 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 

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

[Daniel Fett]

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




>   
>
> Warren Parad
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture.
> Implement Authress .
>
>
> On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt  > wrote:
>
> +1
> ᐧ
>
> On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef
> mailto:rifaat.s.i...@gmail.com>> 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
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> 

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

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

   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 .


On Tue, Dec 8, 2020 at 8:01 PM Dick Hardt  wrote:

> +1
> ᐧ
>
> On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef 
> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dick Hardt]

+1
ᐧ

On Tue, Dec 8, 2020 at 4:51 AM Rifaat Shekh-Yusef 
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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vladimir Dzhuvinov]

Support with both hands!

Vladimir

On 08/12/2020 14:50, Rifaat Shekh-Yusef 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




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Dave Tonge]

I support adoption

On Tue, 8 Dec 2020 at 13:51, Rifaat Shekh-Yusef 
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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
Dave Tonge
CTO
[image: Moneyhub Enterprise]

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/ 
. 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.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Brian Campbell]

support adoption

On Tue, Dec 8, 2020 at 5:51 AM Rifaat Shekh-Yusef 
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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Karsten Meyer zu Selhausen]

+1

On 08.12.2020 13:50, Rifaat Shekh-Yusef 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
OAuth@ietf.org
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



OpenPGP_signature
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Takahiko Kawasaki]

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

Taka

On Tue, Dec 8, 2020 at 9:50 PM Rifaat Shekh-Yusef 
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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Daniel Fett]

Obviously, +1.

Am 08.12.20 um 13:50 schrieb Rifaat Shekh-Yusef:
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
https://danielfett.de

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

I support the WG adoption of this draft. 

> Am 08.12.2020 um 13:50 schrieb Rifaat Shekh-Yusef :
> 
> 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
> OAuth@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth=gmail-imap=160803665600=AOvVaw3LQv8gGHF-mvbizMYxf_54

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Neil Madden]

I support adoption of this draft.

> On 8 Dec 2020, at 12:50, Rifaat Shekh-Yusef  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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


-- 
ForgeRock values your Privacy 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Rifaat Shekh-Yusef]

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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth