Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

Vladimir Dzhuvinov <vladimir@connect2id.com> Mon, 09 November 2020 13:26 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 41FC83A10CC for <oauth@ietfa.amsl.com>; Mon, 9 Nov 2020 05:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 3eueI9ZFuIwO for <oauth@ietfa.amsl.com>; Mon, 9 Nov 2020 05:26:26 -0800 (PST)
Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (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 3DD293A10C4 for <oauth@ietf.org>; Mon, 9 Nov 2020 05:26:26 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id c7BgknPF9s03rc7Bgkkly0; Mon, 09 Nov 2020 06:26:25 -0700
X-CMAE-Analysis: v=2.4 cv=BK92EHcG c=1 sm=1 tr=0 ts=5fa94381 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=is3RsFX7AAAA:8 a=ddEIn7SpAAAA:8 a=48vgC7mUAAAA:8 a=__SxRlIrAAAA:8 a=A1X0JdhQAAAA:8 a=9YbGl7VAAAAA:8 a=4ezpLM88s8vack6FeQoA:9 a=9TZmf1GdRN-sQNED:21 a=OkXOjrVIByJe2-6Z:21 a=QEXdDO2ut3YA:10 a=LBoxaBkYVh4A:10 a=idCLnkAckNQA:10 a=13CRv-QaNUMA:10 a=pGLkceISAAAA:8 a=94LdQcbE46jLBJERA_0A:9 a=AvLyLvJS67_e691E:21 a=-CVsevPRWKxegHmW:21 a=-bhPNmUlWenlCia9:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=CvJ-9y_HEmGQg9NJmnFv:22 a=0LcYgHMQs7_kImmFrmno:22 a=w1C3t2QeGrPiZgrLijVG:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=Df3jFdWbhGDLdZNm0fyq:22 a=AcK2Xwxry4XOpw9gWFIK:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <160430230298.9780.18195581822860811409@ietfa.amsl.com> <fc75c5d7-49b2-7760-c98a-8dd6ca3d09eb@hackmanit.de> <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com> <CAHdPCmNMTse_VJ4moYpeS+CCxrEDZTMcRL-dbNWUU_wPmMcZyw@mail.gmail.com> <ddae11a3-fbeb-ac48-0e7c-ad22056aab34@connect2id.com> <69B0850B-D863-4792-905E-54EE20823323@authlete.com> <CAHdPCmOOeRuvgJe6SPvC9bPZmZ+0hdgJbfs3tRsqY5cRvhRhKw@mail.gmail.com> <CAHdPCmMHh=fC+T+frKNDowPW4+U3hrCsgNhkH4NENyy1_hJ_Fw@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <7ddcaef6-0b92-8cd4-e408-32de4a7f4f75@connect2id.com>
Date: Mon, 9 Nov 2020 15:26:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAHdPCmMHh=fC+T+frKNDowPW4+U3hrCsgNhkH4NENyy1_hJ_Fw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000706080109010803080109"
X-CMAE-Envelope: MS4xfFqp3mEhz5HoM4L9tulA9IfqRwOqJFxsQRxsE6UrZven9SuQ+lAa/agbeozhsbfYKZB7ZX585IFFsEOaqBdpNXW1Q+cnbGo8GqpHWpg2BM7z7p6WYbCx 7Y6unQhZfO9Knl09s5N05akepBCv/VNuW/KObK4RVh/XPp+g5eQvkdWdki7Jf5lxd9MZvGUHUcxVow==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/3AAcxw5JhfhD8OMJxzHc6-SIVmo>
Subject: Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
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: Mon, 09 Nov 2020 13:26:29 -0000

Re Case 1: When JARM is used:

A colleague pointed me to the following statement in the JARMs spec, so
I'd suggest to say the "iss" MUST NOT be included when JARM is used:

https://openid.net//specs/openid-financial-api-jarm.html#jwt-based-response-mode

> All response parameters defined for a given response type are conveyed
> in a JWT

Now, there isn't a proper normative keyword in this JARM spec sentence,
so I guess some may interpret this as a strong check for no other query
params, while others may not. Hence the MUST NOT to prevent potential
unintended errors.

What are your thoughts on this?

Vladimir

On 06/11/2020 23:34, Takahiko Kawasaki wrote:
> I implemented the draft quickly and found no big hurdle for
> authorization server implementations. The current snapshot of my
> implementation does not add the `iss` parameter when JARM is used.
> However, for interoperability, I feel that the spec should describe
> expected behaviors when a JWT is included in an authorization
> response. The following is an implementer's comment for some cases.
>
> Case 1: When JARM is used
>
> An `iss` claim is included in the response JWT as one of top-level
> entries together with response parameters. It is not so unnatural to
> regard the `iss` claim as a response parameter. Conclusion would be
> "When JARM is used, the `iss` parameter is not necessary."
>
> Case 2: When an ID token is issued
>
> It is unnatural to regard the `iss` claim in an ID token as a response
> parameter. However, because FAPI Part 2 has already been using an ID
> token as detached signature for integrity protection, it would be
> difficult to find a convincing reason to prohibit using the `iss`
> claim in an ID token as a countermeasure to mix-up attacks. Conclusion
> would be "When an ID token is issued, the `iss` parameter is not
> necessary."
>
> Case 3: When an unencrypted JWT access token is issued
>
> It is technically possible to use the `iss` claim in an unencrypted
> JWT access token as the `iss` parameter. However, requiring the client
> to check the `iss` claim means "The access token is no longer opaque
> to the client." Conclusion would be "Even when an access token is
> issued and its format is JWT, the `iss` parameter is necessary."
>
> BTW, I found that a certain system raises an error when an unknown
> response parameter (that is, the `iss` parameter) is included in error
> authorization responses. To ask the administrator of the system to
> regard the `iss` parameter as a known one, at least the spec draft
> needs to be adopted by the community as a working draft. I hope that
> "call for adoption" for the draft will be conducted soon.
>
> Best Regards,
> Taka
>
> On Wed, Nov 4, 2020 at 4:46 AM Takahiko Kawasaki <taka@authlete.com
> <mailto:taka@authlete.com>> wrote:
>
>     It sounds that the Security Considerations section or somewhere
>     appropriate should have a paragraph like below.
>
>     When an authorization response includes a JWT whose `iss` claim
>     represents the issuer identifier of the authorization server, the
>     `iss` claim can be used as a substitute for the `iss` parameter.
>     Therefore, such authorization response does not have to have the
>     `iss` parameter outside the JWT separately. Examples of such JWTs
>     include the value of the `id_token` parameter in OIDC and the
>     value of `response` parameter in JARM.
>
>     Taka
>
>     On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan <joseph@authlete.com
>     <mailto:joseph@authlete.com>> wrote:
>
>         I agree, it is in redundant in the JARM case.
>
>         I find the text
>         in https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-security-considerations
>         (the 4th paragraph where JARM & JWTs) are mentioned a bit
>         confusing - I think it would be good to say something along
>         the lines of:
>
>         Although integrity protection is not necessary to prevent
>         mixup, any authorization response method that includes a JWT
>         with an ‘iss' (for example, JARM or OIDC hybrid flow) will
>         prevent the attack (assuming the client is validating the iss).
>
>
>         I’m not entirely sure I understand what "MUST NOT allow
>         multiple authorization servers to return the same issuer
>         identifier during registration” means as I don’t think
>         https://tools.ietf.org/html/rfc7591 returns the issuer?
>
>         It might be clearer to say something like “When
>         https://tools.ietf.org/html/rfc8414 is used the client MUST
>         implement the validation described in
>         https://tools.ietf.org/html/rfc8414#section-3.3. When
>         authorization server details can be manually configured in the
>         client, the client must verify that all issuer values are
>         unique.” (Or at least something along those lines, I’m sure my
>         wording can be improved. But if the client is correctly
>         implementing rfc8414 or OIDC discovery [and does not have any
>         manually configured authorization servers] then there’s no
>         requirement for any further checks that the issuer is unique.)
>
>         Joseph
>
>
>>         On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov
>>         <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> wrote:
>>
>>         This can potentially occur. If JARM is used "iss" becomes
>>         redundant. To me JARM is an "enhanced" iss.
>>
>>         If both are included a sensible client should make sure the
>>         iss and the JARM iss match.
>>
>>         My suggestion is to not require iss when a JARM is present,
>>         but in case both do occur to have the client check both.
>>
>>         Vladimir
>>
>>         On 02/11/2020 22:34, Takahiko Kawasaki wrote:
>>>         Hi Karsten,
>>>
>>>         The specification mentions JARM. Does this specification
>>>         require the iss response parameter even when JARM is used?
>>>         That is, should an authorization response look like below?
>>>
>>>         HTTP/1.1 302 Found
>>>         Location:
>>>         https://client.example.com/cb?response={JWT}&iss={ISSUER}
>>>         <https://client.example.com/cb?response=%7BJWT%7D&iss=%7BISSUER%7D>
>>>
>>>         Or, can the iss response parameter be omitted when JARM is used?
>>>
>>>         A small feedback for the 3rd paragraph in Section 4:
>>>         s/identifes/identifies/
>>>
>>>         Best Regards,
>>>         Taka
>>>          
>>>
>>>         On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov
>>>         <vladimir@connect2id.com <mailto:vladimir@connect2id.com>>
>>>         wrote:
>>>
>>>             Thanks Karsten, looks good to me now, no further comments.
>>>
>>>             Vladimir
>>>
>>>             On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote:
>>>>
>>>>             Hi all,
>>>>
>>>>             Daniel and I published a new version of the "iss"
>>>>             response parameter draft to address the feedback from
>>>>             the WG.
>>>>
>>>>             Changes in -01:
>>>>
>>>>               * Incorporated first WG feedback
>>>>               * Clarifications for use with OIDC
>>>>               * Added note that clients supporting just one AS are
>>>>                 not vulnerable
>>>>               * Renamed metadata parameter
>>>>               * Various editorial changes
>>>>
>>>>
>>>>             We would like to ask you for further feedback and
>>>>             comments on the new draft version.
>>>>
>>>>             Best regards,
>>>>             Karsten
>>>>
>>>>             -------- Forwarded Message --------
>>>>             Subject: 	New Version Notification for
>>>>             draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>             Date: 	Sun, 01 Nov 2020 23:31:42 -0800
>>>>             From: 	internet-drafts@ietf.org
>>>>             <mailto:internet-drafts@ietf.org>
>>>>             To: 	Karsten Meyer zu Selhausen
>>>>             <karsten.meyerzuselhausen@hackmanit.de>
>>>>             <mailto:karsten.meyerzuselhausen@hackmanit.de>, Karsten
>>>>             zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>
>>>>             <mailto:karsten.meyerzuselhausen@hackmanit.de>, Daniel
>>>>             Fett <mail@danielfett.de> <mailto:mail@danielfett.de>
>>>>
>>>>
>>>>
>>>>
>>>>             A new version of I-D,
>>>>             draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>             has been successfully submitted by Karsten Meyer zu
>>>>             Selhausen and posted to the
>>>>             IETF repository.
>>>>
>>>>             Name: draft-meyerzuselhausen-oauth-iss-auth-resp
>>>>             Revision: 01
>>>>             Title: OAuth 2.0 Authorization Server Issuer Identifier
>>>>             in Authorization Response
>>>>             Document date: 2020-11-01
>>>>             Group: Individual Submission
>>>>             Pages: 10
>>>>             URL:
>>>>             https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
>>>>             Status:
>>>>             https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/
>>>>             Html:
>>>>             https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html
>>>>             Htmlized:
>>>>             https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01
>>>>             Diff:
>>>>             https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01
>>>>
>>>>             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
>>>>             flow. If
>>>>             implemented correctly, the "iss" parameter serves as an
>>>>             effective
>>>>             countermeasure to "mix-up attacks".
>>>>
>>>>
>>>>
>>>>             Please note that it may take a couple of minutes from
>>>>             the time of submission
>>>>             until the htmlized version and diff are available at
>>>>             tools.ietf.org <http://tools.ietf.org/>.
>>>>
>>>>             The IETF Secretariat
>>>>
>>>>
>>>>             -- 
>>>>             Karsten Meyer zu Selhausen
>>>>             IT Security Consultant
>>>>             Phone:	+49 (0)234 / 54456499
>>>>             Web:	https://hackmanit.de <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 <mailto:OAuth@ietf.org>
>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>             _______________________________________________
>>>             OAuth mailing list
>>>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/oauth
>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov