Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00

Vladimir Dzhuvinov <vladimir@connect2id.com> Fri, 21 May 2021 08:04 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE8F3A1E96 for <oauth@ietfa.amsl.com>; Fri, 21 May 2021 01:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyml7xmWd7o5 for <oauth@ietfa.amsl.com>; Fri, 21 May 2021 01:04:45 -0700 (PDT)
Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94DE23A1E95 for <oauth@ietf.org>; Fri, 21 May 2021 01:04:45 -0700 (PDT)
Received: from [192.168.1.54] ([95.252.42.22]) by :SMTPAUTH: with ESMTPSA id k09BloN5BLUlzk09Dl7ckY; Fri, 21 May 2021 01:04:44 -0700
X-CMAE-Analysis: v=2.4 cv=Bewdbph2 c=1 sm=1 tr=0 ts=60a7699c a=w78HfMY2VEfYiftKuTMIiA==:117 a=w78HfMY2VEfYiftKuTMIiA==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=9YbGl7VAAAAA:8 a=jR2JG8yXz23Gw5estEYA:9 a=8EGsiurGPPrZ2qEk:21 a=_jqJP7BRyuMle0gI:21 a=QEXdDO2ut3YA:10 a=lI5-fTjbmPQmOHT2o2MA:9 a=4AbbWULRkcvWiS6t:21 a=sAhFzbQ7b-1CU4af:21 a=nNy5eYtFMGG-LDRN:21 a=_W_S_7VecoQA:10 a=q4BqFUJ_zBrgMs8ZHv4A:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=AcK2Xwxry4XOpw9gWFIK:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <634f7b10-bb26-e05c-7d79-566c893c32b6@hackmanit.de> <CADNypP_P=bdtSHmX0aM4eK4yw+8n9HYnnS6ERVdOC_x7U3spZw@mail.gmail.com> <CA+k3eCQboyohxe=u8wxtA9RyVhy=E4sMDkdsn76x3Xk19asVMA@mail.gmail.com> <b70f1d84-f395-9272-754d-61becb8e9aec@hackmanit.de> <CA+k3eCSAxMwdFNUtZazo_TPa1Mc624n4AJdqcT7sEh3JxUaeEA@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <774cacbb-a4d5-ebb8-4b53-6ad26b5bfbd7@connect2id.com>
Date: Fri, 21 May 2021 11:04:40 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CA+k3eCSAxMwdFNUtZazo_TPa1Mc624n4AJdqcT7sEh3JxUaeEA@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010203020306050308050504"
X-CMAE-Envelope: MS4xfG+0zLgOvL/ZYT7CoC4K2cwwDV0arK3QDZ+kqjYRYquM90T+6gaBs0iAxxCjupE3ma1jQzMKnLQymsV9bIk+ZsGxuVvdSkwACnKH+wmg0cDKrmINruDQ dVr8x9angevGA6wTqKDA2xxeH7nIoRgsn5/J2upfPs1icD3edjgN5RRe0ldKsQeAIG55sw1eHhQpQw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/mEu3bxIWEVE16S57LjtunaHHoMI>
Subject: Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2021 08:04:50 -0000

The spec is fine, we've had it implemented for some time now and support 
its publication.

+1 to Brian's comment. I suppose it suffices to say the iss parameter is 
redundant when JARM is used as JARM provides the same countermeasure. I 
found the normative text about what JARM allows or disallows (or have 
text that reads like normative) problematic, the JARM spec should remain 
the place for this.

Thanks for this work Karsten. Also my thanks to Daniel.

Vladimir

On 21/05/2021 00:00, Brian Campbell wrote:
> Thanks Karsten,
>
> That's moving in the right direction. But I think the last sentence is 
> still too strong and maybe prone to misunderstanding given it's not 
> 100% obvious in the JARM case what exactly constitutes an 
> authorization response parameter.
>
> I'd say the last sentence could just be dropped altogether. Or maybe 
> changed to something like this, "Therefore, an additional iss 
> parameter outside the JWT is unneeded when JARM is used."
>
>
> On Wed, May 19, 2021 at 12:45 AM Karsten Meyer zu Selhausen 
> <karsten.meyerzuselhausen@hackmanit.de 
> <mailto:karsten.meyerzuselhausen@hackmanit.de>> wrote:
>
>     Hi Brian,
>
>     thank you for your feedback.
>
>     I agree that the language is too strong here. What do you think
>     about this new note?
>
>>     Note: The "JWT Secured Authorization Response Mode for OAuth 2.0
>>     (JARM)" [JARM] defines a mechanism that conveys all authorization
>>     response parameters in a JWT. This JWT contains an iss claim that
>>     provides the same protection if it is validated as described in
>>     Section 2.4. Therefore, an additional iss authorization response
>>     parameter as defined by this document MUST NOT be used when JARM
>>     is used.
>
>     Best regards,
>     Karsten
>
>     On 15.05.2021 00:35, Brian Campbell wrote:
>>     Overall it looks pretty good to me.
>>     One little nit is that I don't love this text from the end of sec
>>     2.4 that talks about JARM:
>>
>>     'Note: The "JWT Secured Authorization Response Mode for OAuth 2.0
>>     (JARM)" [JARM] forbids the use of additional parameters in the
>>     authorization response. Therefore, the iss parameter MUST NOT be
>>     used when JARM is used. However, JARM responses contain an iss
>>     claim that provides the same protection if it is validated as
>>     described in Section 2.4.'
>>
>>     JARM doesn't exactly forbid additional parameters but rather just
>>     wraps up all the authorization response parameters as claims in a
>>     JWT which is itself sent as a single form/query/fragment
>>     parameter. So really the iss authorization response parameter of
>>     this draft is still sent as a claim of the JARM JWT. It just
>>     happens to be the same as the iss claim value that JARM is
>>     already including.
>>
>>     On Sat, May 1, 2021 at 2:47 PM Rifaat Shekh-Yusef
>>     <rifaat.s.ietf@gmail.com <mailto:rifaat.s.ietf@gmail.com>> wrote:
>>
>>         All,
>>
>>         We have not seen any comments on this document.
>>         Can you please review the document and provide feedback, or
>>         indicate that you have reviewed the document and have no
>>         concerns.
>>
>>         Regards,
>>          Rifaat & Hannes
>>
>>
>>         On Thu, Apr 15, 2021 at 3:04 AM Karsten Meyer zu Selhausen
>>         <karsten.meyerzuselhausen@hackmanit.de
>>         <mailto:karsten.meyerzuselhausen@hackmanit.de>> wrote:
>>
>>             Hi all,
>>
>>             the latest version of the security BCP references
>>             draft-ietf-oauth-iss-auth-resp-00 as a countermeasures to
>>             mix-up attacks.
>>
>>             There have not been any concerns with the first WG draft
>>             version so far:
>>             https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
>>             <https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/>
>>
>>             I would like to ask the WG if there are any comments on
>>             or concerns with the current draft version.
>>
>>             Otherwise I hope we can move forward with the next steps
>>             and hopefully finish the draft before/with the security BCP.
>>
>>             Best regards,
>>             Karsten
>>
>>             -- 
>>             Karsten Meyer zu Selhausen
>>             Senior IT Security Consultant
>>             Phone:	+49 (0)234 / 54456499
>>             Web:	https://hackmanit.de  <https://hackmanit.de>  | IT Security Consulting, Penetration Testing, Security Training
>>
>>             Is your OAuth or OpenID Connect client vulnerable to the severe impacts of mix-up attacks? Learn how to protect your client in our latest blog post on single sign-on:
>>             https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks  <https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks>
>>
>>             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 <mailto:OAuth@ietf.org>
>>             https://www.ietf.org/mailman/listinfo/oauth
>>             <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>         <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./ 
>
>     -- 
>     Karsten Meyer zu Selhausen
>     Senior IT Security Consultant
>     Phone:	+49 (0)234 / 54456499
>     Web:	https://hackmanit.de  <https://hackmanit.de>  | IT Security Consulting, Penetration Testing, Security Training
>
>     Möchten Sie sich für ein Projekt mit dem Thema Single Sign-On oder den Standards OAuth und OpenID Connect vertraut machen?
>     Dann melden Sie sich jetzt an für Ihre Einführung in Single Sign-On, OAuth und OpenID Connect am Mittwoch, 09.06.2021, von 10:00 - 14:30 Uhr!
>     https://www.hackmanit.de/de/schulungen/uebersicht/139-einfuehrung-in-single-sign-on-oauth-und-openid-connect  <https://www.hackmanit.de/de/schulungen/uebersicht/139-einfuehrung-in-single-sign-on-oauth-und-openid-connect>
>
>     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
>
>
> /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