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

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 17 November 2020 07:56 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 C84923A11BD for <oauth@ietfa.amsl.com>; Mon, 16 Nov 2020 23:56:10 -0800 (PST)
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_MSPIKE_H4=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 IA_G_SwNbh-u for <oauth@ietfa.amsl.com>; Mon, 16 Nov 2020 23:56:07 -0800 (PST)
Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (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 A50B23A11AC for <oauth@ietf.org>; Mon, 16 Nov 2020 23:56:07 -0800 (PST)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id evqPkjvaxle7revqQk7AmA; Tue, 17 Nov 2020 00:56:07 -0700
X-CMAE-Analysis: v=2.4 cv=f6KNuM+M c=1 sm=1 tr=0 ts=5fb38217 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=__SxRlIrAAAA:8 a=is3RsFX7AAAA:8 a=ddEIn7SpAAAA:8 a=A1X0JdhQAAAA:8 a=9YbGl7VAAAAA:8 a=AGt6jbFzJ15_AqTjfE4A:9 a=ZzQglzhH7yfu32qe:21 a=58bV5VuECqQEJRzP:21 a=QEXdDO2ut3YA:10 a=idCLnkAckNQA:10 a=LBoxaBkYVh4A:10 a=13CRv-QaNUMA:10 a=pGLkceISAAAA:8 a=aZL1-Zqr0g_DdfdxC8cA:9 a=VqviYuB2Ter2sWrc:21 a=r7aulU3LGZCx6iQa:21 a=YxgiVD8eB8PxfBR3:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=CvJ-9y_HEmGQg9NJmnFv:22 a=0LcYgHMQs7_kImmFrmno: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> <7ddcaef6-0b92-8cd4-e408-32de4a7f4f75@connect2id.com> <CAHdPCmPtMSChOxi8m=tS3Ot102VpN6R5hMRU0W9aw=W6i4Xj6g@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: <61f07b70-f9b2-f5c3-19a2-122062ad1055@connect2id.com>
Date: Tue, 17 Nov 2020 09:56:05 +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: <CAHdPCmPtMSChOxi8m=tS3Ot102VpN6R5hMRU0W9aw=W6i4Xj6g@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040302080401090304080507"
X-CMAE-Envelope: MS4xfNgUZHx5sJSB5JaBiaLflEFFk2FSU/3TbP8t0liEwDJpER+YzuP2WfkaHeW9dwcG5IhRebfO4zEjyGmH6XwGWSCTi7SYVeAIdRIKXA9wAcp8waaG1BAJ ExD1XScpt9X2v2ZFLO+IRkuhvT1pJo1evPTm7fy75RciIs2XiW9DxhvncgRNQR3JrwLXLTwUmXqIBA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/VBOriL-QKsvsvDZSKtWG3CWJZ8o>
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: Tue, 17 Nov 2020 07:56:11 -0000

Noting two unrelated comments that came up:

 1. The iss value in the example doesn't appear to be URL encoded:

    https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html#name-example-authorization-respo


 2. There was the question from a developer whether error responses
    should also have the iss. I suggest the spec to be more explicit
    that iss is added to both success and error responses, and even
    include a second example, with an error response.

Vladimir

On 10/11/2020 22:25, Takahiko Kawasaki wrote:
> Hi Vladimir,
>
> Good point. Considering the similarity to JAR (JWT Secured
> Authorization Response), if we apply the same logic, our discussion
> will eventually reach "response parameters outside the response JWT
> are almost meaningless in the context of JARM". For interoperability
> and simplicity, it may be good to say "MUST NOT" as you suggested.
>
> Taka
>
> On Mon, Nov 9, 2020 at 10:26 PM Vladimir Dzhuvinov
> <vladimir@connect2id.com <mailto:vladimir@connect2id.com>> wrote:
>
>     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 <mailto:OAuth@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>     -- 
>     Vladimir Dzhuvinov
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>     https://www.ietf.org/mailman/listinfo/oauth
>