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

Takahiko Kawasaki <taka@authlete.com> Tue, 03 November 2020 19:46 UTC

Return-Path: <taka@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 D1A1D3A10FE for <oauth@ietfa.amsl.com>; Tue, 3 Nov 2020 11:46:17 -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 J_JunxZ6hnT4 for <oauth@ietfa.amsl.com>; Tue, 3 Nov 2020 11:46:13 -0800 (PST)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 6CEB73A10FD for <oauth@ietf.org>; Tue, 3 Nov 2020 11:46:13 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id h62so416803wme.3 for <oauth@ietf.org>; Tue, 03 Nov 2020 11:46:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4DSDgf2O6JgaVUtQwHQFNtS3GwdVNqac6Ig6SAMd/a8=; b=xyRCxec3cHemLLqXvJH1+6+rUdp2PTG6yDf3yXcrOtyyo7L31QEYKp+MuWIYJrOUeV ahp7f1P0bLJv38Qf2/houh/uFOCCL5VjTpIVwL1Q4q8IUC73ZnS0aau/8DqK1djmnrNA SrSahgs2j/lcW4loSfZ2htvyTIDok4MLYNI6YhGVcjK6+iSXOv3+MZn5JdvLlwDqZHS5 MvD/urZG5yuThmxcJEltu75u7PPHBjf9zapAaSVEINGVlQeRS/J9tEdgkuRN+erzWMdo dAilXJzSSxGMzX0Bm7oW8grrCLTbNBIe4kSdEyf2vDga/z1fPpVdTfbeZMDGFAFnbTOR LBww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4DSDgf2O6JgaVUtQwHQFNtS3GwdVNqac6Ig6SAMd/a8=; b=DS8AV6Y/n6JXQ9w2lPjB2yIOhredLXeitMsaFpjsyfv0wGJGuSkQhjziXS2n9J1Klj Korn6M2LZxy+0z948XuyhXLKfWxXo6uBeCH9ZL1fYi5RW53bE4QIqkizB9oH+K3nuRvV /Mf5vidtW/kTMGTNjdEqN84U4JuSnePCUXmybVrvtQ9PQl1pxNUQ0oJ0FVshhOyWynQ/ UCUEu3jsUMd01P87X8ezH0Yu8YbFMaTIuhhGRMLzA/FVPNZKARz2yu5HpxzfZr1aqfB6 ft/Vn+PybOBbEzVeafgj36hst+odsDcY4S86eCikFhjxTjsgRC4ZIEN6VygI+8z8/znP g2iA==
X-Gm-Message-State: AOAM531Aa3vWmbPaVYkmpPVOh7eQlwpH8zxdOaK5FNBmdzmobzdhpS6Y tQuJRScMsCSREbw25dQ9FdNSnHTyATIfDZgIjX4GWOAWIHGDzA==
X-Google-Smtp-Source: ABdhPJwOUNEKLRP41S5rxZvgqNbJ0NE9gVjCqU8N+5rdTpS1H9gnjTBsHXS/Wbjts/7S/m21ZqhkHbTNl4V9DdbMeLE=
X-Received: by 2002:a1c:2b05:: with SMTP id r5mr741968wmr.179.1604432771226; Tue, 03 Nov 2020 11:46:11 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <69B0850B-D863-4792-905E-54EE20823323@authlete.com>
From: Takahiko Kawasaki <taka@authlete.com>
Date: Wed, 4 Nov 2020 04:46:12 +0900
Message-ID: <CAHdPCmOOeRuvgJe6SPvC9bPZmZ+0hdgJbfs3tRsqY5cRvhRhKw@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000065390d05b3391d96"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/8lvK5oGhq7ay5VcXE0VtD7pmJHM>
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 19:46:18 -0000

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> 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>
> 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}
>
> 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>
> 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
>> To: Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>
>> <karsten.meyerzuselhausen@hackmanit.de>de>, Karsten zu Selhausen
>> <karsten.meyerzuselhausen@hackmanit.de>
>> <karsten.meyerzuselhausen@hackmanit.de>de>, Daniel Fett <mail@danielfett.de>
>> <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.
>>
>> The IETF Secretariat
>>
>>
>> --
>> Karsten Meyer zu Selhausen
>> IT Security Consultant
>> Phone:	+49 (0)234 / 54456499
>> Web:	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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>