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

Daniel Fett <fett@danielfett.de> Tue, 17 November 2020 10:58 UTC

Return-Path: <fett@danielfett.de>
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 1C1F03A0FBD for <oauth@ietfa.amsl.com>; Tue, 17 Nov 2020 02:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=danielfett.de
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 AgEQ1LIsk72Z for <oauth@ietfa.amsl.com>; Tue, 17 Nov 2020 02:58:20 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3B13A0DAD for <oauth@ietf.org>; Tue, 17 Nov 2020 02:58:20 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 90AE1161CA for <oauth@ietf.org>; Tue, 17 Nov 2020 10:58:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1605610698; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=232744lVyJOIkQvPqDOLzcIpKFTScw55Sg5fJj86FkU=; b=nMgKO/MLIf6zz/euMflJ1ozIvY2TnGgqp4irTAIYCiVIuCQi04H5bFzsIFf3bCoH2UGw8C 3AVnI0XeT8GIyL5gcEiVZMcU5OPb+VulAYKUeI+EaPYyAGIBha84+rPA2/OwlqU3XYiN+A GRXzfhg4Mfxv5zoj3TwuxqnGQrwOPQw=
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> <61f07b70-f9b2-f5c3-19a2-122062ad1055@connect2id.com>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <08f76711-8fd8-da78-9ddc-ebc370bc9ef3@danielfett.de>
Date: Tue, 17 Nov 2020 11:56:07 +0100
MIME-Version: 1.0
In-Reply-To: <61f07b70-f9b2-f5c3-19a2-122062ad1055@connect2id.com>
Content-Type: multipart/alternative; boundary="------------AC2CE8544FD1CF24150EBA31"
Content-Language: en-US
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1605610698; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=232744lVyJOIkQvPqDOLzcIpKFTScw55Sg5fJj86FkU=; b=cybh2abDmXI3KJhyMHueSlZNElxyl1HbQLApsdI+SaLnUG9iP6v5kmBu9WWZdu5V0+oAtF oIOM93RMvVD3ja6zzSd123gHro1vWR22AMVL/RLxWzNeEThUvuzBqQH2AM57C6WOkeTBFu nvfe7TSocVQWhS75KV/eu0U+uNrg2Go=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1605610698; a=rsa-sha256; cv=none; b=s43hj67cZqGEmgYEXx1hbAQusCd1nq3zQwL/RJtThVZdCBewBBLIz4mtTI41ocl/weQTOp jJdIK8QdwF6dvRvvhLaQzajKmSYyk+SVf3CJ338cRiE053+deqLUuLdCj0VrZyAKcJou7t b++hEOuYRJgVOEWnd7hqezaBnrLP31c=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/e033PDFmlFN4aZkdfH8GMTiAhxs>
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 10:58:24 -0000

Thanks Vladimir and Takahiko, we incorporated your proposals into the
next version of the draft.

-Daniel

Am 17.11.20 um 08:56 schrieb Vladimir Dzhuvinov:
>
> 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
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth