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

2020-10-26 Thread Aaron Parecki 
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


On Mon, Oct 26, 2020 at 7:33 AM Karsten Meyer zu Selhausen <
karsten.meyerzuselhau...@hackmanit.de> wrote:

> 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
> 
> ).
> 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
>
> ___
> 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] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

2020-10-26 Thread Brian Campbell 
 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 <
karsten.meyerzuselhau...@hackmanit.de> wrote:

> 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
> 
> ).
> 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
>
> ___
> 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] New draft: Mix-up prevention - adding "iss" parameter to the authorization response

2020-10-26 Thread Vladimir Dzhuvinov 
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:
>
> 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
> ).
> 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
>



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