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

Joseph Heenan <joseph@authlete.com> Tue, 03 November 2020 13:46 UTC

Return-Path: <joseph@authlete.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 6FA013A0AA1 for <oauth@ietfa.amsl.com>; Tue, 3 Nov 2020 05:46:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=authlete-com.20150623.gappssmtp.com
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 mVXcrHCgSBKl for <oauth@ietfa.amsl.com>; Tue, 3 Nov 2020 05:46:46 -0800 (PST)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8E53A0A9C for <oauth@ietf.org>; Tue, 3 Nov 2020 05:46:45 -0800 (PST)
Received: by mail-wm1-x32b.google.com with SMTP id v5so12807577wmh.1 for <oauth@ietf.org>; Tue, 03 Nov 2020 05:46:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=hw16jBlCJ0UxSZgjIGj8UWyAOBQ0qOC4UdLDxd6JDZ8=; b=kc2ggRb7LzkDtLahSnIWOksLgFSFBILounhh5PJgUHJ/1lonru9RLqLSSfsZKW+h2Q O0ABLyDwFUoqtJaCQFTOG0qF5tdKUNvl0KNFHmxe3DEftrrue0o1L+R6f8Ec7pmD4+QZ mY3BBGxudkeIz4raH5oSNk4HlhO8rOtOJEjc1/Q/LTmGp7TASEUQCSUMNg4s/z5EBGtI 292xBPypMKnGU8FJJvgvSi+JMhZsvBVenZ6SpC/hK2nfAe+hzPZTFfQPsiEZr3Zpoh1G jmKgxBGFzZeYN3qXelm41UKG5+5T+8zLIBpOrMZs9TYufVoQxmPh7IAIRG/ltWMIavPp FRkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=hw16jBlCJ0UxSZgjIGj8UWyAOBQ0qOC4UdLDxd6JDZ8=; b=KCh4eIjOtnKqp2sFUse0MVA+5bWTyKa0/CW+F8ICN7IvVeMvXI1PwzRdgFfqtUe7II FcpAhv8T+RWtXpNoVeYLBKlHrP8/wFcz+xylRKpqK8BDW7IeIzwihVrTRrF4gXJpMYYg bhC8zjyBU+XXAM349VVddCKSyBaZM8DannZJm4IrX8TPo1Au06yF1JpyB9ZraXKQlDLA lGriEroJMObAS8jEQ+idmIadW1c4pU1oD4AB9XvHVoCLSbChEXmCTWCPK/boj0lbmC9q Jsoc4sieJQpn9vCBMc7Ps+hlWqWA1yXRMkRJwHDFI+VAdensyqo1YPdfUGfzunXyAUPz xl4A==
X-Gm-Message-State: AOAM530kOl0LIxxJOdV0k4Z8GCWgPE3TsnItBZ7uHyxB+fk2T5zoQd8j VQRjTkLpBEtxzLBOiGopMtjq5bx1GI0QloeQ
X-Google-Smtp-Source: ABdhPJzG404lWqjDybrj6g7eJdUS1d5s7RogXgg0XhHD86gqZByrfbcgo8OGn3QWX35LjouEU6AgFw==
X-Received: by 2002:a1c:f214:: with SMTP id s20mr3667437wmc.71.1604411203769; Tue, 03 Nov 2020 05:46:43 -0800 (PST)
Received: from dhcp121.sh2.org.uk (home.heenan.me.uk. [212.159.108.133]) by smtp.gmail.com with ESMTPSA id v6sm2945271wmj.6.2020.11.03.05.46.42 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Nov 2020 05:46:42 -0800 (PST)
From: Joseph Heenan <joseph@authlete.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C632B5E8-753D-4798-9732-2B00F319404E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 3 Nov 2020 13:46:41 +0000
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>
To: oauth <oauth@ietf.org>
In-Reply-To: <ddae11a3-fbeb-ac48-0e7c-ad22056aab34@connect2id.com>
Message-Id: <69B0850B-D863-4792-905E-54EE20823323@authlete.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2cbeQM4E5wqBKTN2nQ4Vc79M4L4>
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, 03 Nov 2020 13:46:48 -0000

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> 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={JWT}&iss={ISSUER}>
>> 
>> 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 <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/ <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 <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 <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 <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 <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 <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>
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth