Subject: [OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

From: Karsten Meyer zu Selhausen <[email-masked]>
Date: Mon, 26 Oct 2020 15:33:33 +0100

Hello WG,

adding the issuer identifier to the authorization response as a
countermeasure to mix-up attacks is well-known on this list and already
part of the security BCP (see 4.4.2
<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.4.2>).
However, the "iss" parameter is currently not properly specified. Daniel
and I wrote an ID to solve this issue.

We would like to ask the working group to give us feedback on our first
draft version:
https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-00

Abstract

   This document specifies a new parameter "iss" that is used to
   explicitly include the issuer identifier of the authorization server
   in the authorization response of an OAuth authorization grant.  If
   implemented correctly, the "iss" parameter serves as an effective
   countermeasure to "mix-up" attacks.

The need for a proper specification of the "iss" parameter was discussed
in this thread:
https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/

Best regards,
Karsten

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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen the security? Learn more about the procetion PKCE provides and its limitations in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client

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: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 26 Oct 2020 17:06:49 +0200

Hi Karsten,

Thanks for the write up. I would like to suggest the name
authorization_response_iss_parameter_supported, instead of
iss_parameter_supported. To make it explicit and unambiguous that it's
about the authZ response.

Vladimir

On 26/10/2020 16:33, Karsten Meyer zu Selhausen wrote:
> countermeasure to mix-up attacks is well-known on this list and
> already part of the security BCP (see 4.4.2
> However, the "iss" parameter is currently not properly specified.
> Daniel and I wrote an ID to solve this issue.
>
> We would like to ask the working group to give us feedback on our
> first draft version:
> The need for a proper specification of the "iss" parameter was
> discussed in this thread:

---

From: Brian Campbell <[email-masked]>
Date: Mon, 26 Oct 2020 10:40:41 -0600

I'd suggest removing the "of an OAuth authorization grant" bit from the
abstract. The term 'authorization grant' has meaning from
https://tools.ietf.org/html/rfc6749?#section-1.3 that doesn't really work
there in the abstract.

On Mon, Oct 26, 2020 at 8:33 AM Karsten Meyer zu Selhausen <
[email-masked]> wrote:

> Does your OAuth or OpenID Connect implementation use PKCE to strengthen the security? Learn more about the procetion PKCE provides and its limitations in our new blog post:https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client
>
> Hackmanit GmbH
> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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._

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 26 Oct 2020 10:03:08 -0700

To capture my comment from the interim meeting call, I would like to see
some explicit text in this draft (as well as the Security BCP section that
will reference this draft) that clarifies this parameter is not needed and
this attack is not relevant if a client only interacts with one
authorization server.

More broadly, I would like to make sure the scope of the attacks that this
prevents is clarified so that people may better understand when they do not
need to worry about this and don't need to use this new parameter.

---
Aaron Parecki
https://aaronparecki.com