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
- [OAUTH-WG] Fwd: New Version Notification for draf… Karsten Meyer zu Selhausen
- Re: [OAUTH-WG] Fwd: New Version Notification for … Vladimir Dzhuvinov
- Re: [OAUTH-WG] Fwd: New Version Notification for … Takahiko Kawasaki
- Re: [OAUTH-WG] Fwd: New Version Notification for … Vladimir Dzhuvinov
- Re: [OAUTH-WG] New Version Notification for draft… Joseph Heenan
- Re: [OAUTH-WG] New Version Notification for draft… Takahiko Kawasaki
- Re: [OAUTH-WG] New Version Notification for draft… Takahiko Kawasaki
- Re: [OAUTH-WG] Fwd: New Version Notification for … Pretty Little Wife
- Re: [OAUTH-WG] New Version Notification for draft… Vladimir Dzhuvinov
- Re: [OAUTH-WG] New Version Notification for draft… Takahiko Kawasaki
- Re: [OAUTH-WG] New Version Notification for draft… Vladimir Dzhuvinov
- Re: [OAUTH-WG] New Version Notification for draft… Daniel Fett