Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

Dick Hardt <dick.hardt@gmail.com> Mon, 06 July 2020 16:26 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC06C3A16AE; Mon, 6 Jul 2020 09:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 L8_U5I_dy98j; Mon, 6 Jul 2020 09:26:07 -0700 (PDT)
Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 A0D833A1618; Mon, 6 Jul 2020 09:26:06 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id 9so46097620ljv.5; Mon, 06 Jul 2020 09:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jdr5J2q07kzZduUMegqQJpQhhcgTc4QqiLYY4pK2q5k=; b=AGtLiSGdokRcnImM2wB0Qu1CH67ObavSa3OLhxDWZ+9yPShp0e/s3sir5xb13TAIBL fQY2d7gwyfYG+Wwq6nCrwaTtafCkI8gkbRg8rzgzxS/iU0Io/9r+YEi/dwz97EoElr1A J1hr1+EStYiVYpOEVxf2sGo8M5DIdsoQv8LOZ+VMg8BXNAxn016xInyC4Yxrx+cDEeC6 Ogy3oTjAbgwfh/bLNcPG3shvHsDgyvwuPl0LguTLdfbW1/LAvGJlF70DBtPoapNGPBvu Vs1e37Xeg8G+UzMwWUXebDIA1xwmHYNEeBQh5xeNQI+RADimG5fIbHr2jGQpDBfV6/ig 6hDw==
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:cc; bh=jdr5J2q07kzZduUMegqQJpQhhcgTc4QqiLYY4pK2q5k=; b=LkozWS2PjD2yKxesbBB7zSNNXpfIK499bGkjpL3sepNZQoiEx5wDp+3IScG90YrYtv n8T02UGeUoqKfbDJNrQ53/UxhyDbc4LakttV98LeMmDUMIYYTfsns7FIXTn69+VfcFxj aKjmQTaU+4kqe8SUvc+ZgthYMI9JrPDhgBc1pmih3rpF1ARjuHKajbs8Loau8haTdDFy ly3tzp2ffy0kbVwEe1IXcFhb1iuVPJS0jm99DGdU+mW0jOzj2RkRvv0iEuAmiQ52Jy1J J3TUJpIiFd3iYI44JUDQ8Wa5cs2jZUWLYmFEL02jg49d7LQFUUiH8yPZ76Q6e3dro5Lp f/Jg==
X-Gm-Message-State: AOAM532ILc95C/y4WaQWyvRx4u83xfh92WAUEa3dRszHEPssHC4ct9+N Y+oOWWTj20klXeFYyLd790bVBoMwYm7JUUtcH10=
X-Google-Smtp-Source: ABdhPJy1h7ikCfRbncuqhvB4L4qY2MqCy7puKcVcBpbncUSSqAfCxwVPKkJnDDG3oVZQ8oBtDSbgN4lmJjtj2S1oQH8=
X-Received: by 2002:a05:651c:547:: with SMTP id q7mr26177291ljp.437.1594052764659; Mon, 06 Jul 2020 09:26:04 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <cdbb228a-1412-e2e2-fe15-852fdd4649ac@free.fr> <CAD9ie-vrMk_D8WSz7h5aAw_FmnBJDkRJyWQeXTTsAP3ofH0iNg@mail.gmail.com> <a21d84cc-02d2-8140-bb4c-e4d6a05d737f@free.fr> <CAD9ie-tswzXQPgn13SMdQYQFfSxiuVu1hCuwsuUT5XbzbhmsKw@mail.gmail.com> <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr> <CAD9ie-tbuykhJAMFao+4wJU51GgCKPXCPZB-P+q+doMBFezarg@mail.gmail.com> <731a364a19a74e1d982d59d9c441dc0a@cert.org> <ef68863a-d97f-7632-7902-cc31136759eb@free.fr>
In-Reply-To: <ef68863a-d97f-7632-7902-cc31136759eb@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 6 Jul 2020 09:25:28 -0700
Message-ID: <CAD9ie-saCvan0UPDOy=ccy11F7sQcmXOQjzBvDR=FUJrH1g9ow@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Roman Danyliw <rdd@cert.org>, Nat Sakimura <sakimura@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ca71c105a9c854ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/GmT7fuilOSAAAsvanwwuSr5Lh4A>
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jul 2020 16:26:10 -0000

Hi Denis

Just like "privacy", "security" is not called out as a goal. (it is
mentioned as an issue with OAuth 2.0).



On Mon, Jul 6, 2020 at 8:49 AM Denis <denis.ietf@free.fr> wrote:

> One single comment.
>
> Dick wrote on the last line:
>
> I think pretty much everyone is onboard supporting privacy, but not all
> use cases have the same privacy considerations.
>
> I hope that this is true, but in such a case I can't understand why the
> word "*privacy*" is missing in the charter.
>
> Denis
>
> Note: IESG added
>
> Hello!
>
>
>
> I’m top-posting here because there is no easy way for me to cleaning
> insert my process comment.  I think we are having a necessary conversation
> below and in no way should it stop because of this note.
>
>
>
> As a process check, this thread started with a request for community
> review on the charter text [1].  Among other things, this charter review is
> trying to ensure the problem is clear, defines the bounds of the desired
> solutions and identifies critical objections from the consensus-derived
> text.  The text is not intended to define detailed
> requirements/architecture, resolve tradeoffs, or to specify a solution,
> unless they are critical to bounding the solution.  These details should be
> left to future discussions of a chartered WG (not that they can’t start now
> in parallel).  Additionally, as a reminder, while there are multiple
> individual drafts with proposed solutions in the datatracker, the design
> decisions they make are not part of the charter and their adoption is not
> assumed by the charter.  If there are key design elements in those or any
> other documents that is felt to be crucial to scoping the WG,  we need to
> capture the thinking, generalize it (as appropriate), and add it to the
> charter text explicitly or by reference.
>
>
>
> Let’s continue to talk about the technical details of the use cases,
> design properties, constraints and candidate solutions.  Additionally,
> given the -05 charter text and milestones [2], it would be helpful to
> understand what outstanding concerns remain with the charter text in
> preparation for the Thursday, July 9th telechat where the IESG will use
> community feedback to help decide the way ahead for this proposed WG.
>
>
>
> Roman
>
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/
>
> [2] https://datatracker.ietf.org/doc/charter-ietf-gnap/
>
>
>
>
>
>
>
> *From:* Txauth <txauth-bounces@ietf.org> <txauth-bounces@ietf.org> *On
> Behalf Of *Dick Hardt
> *Sent:* Friday, July 3, 2020 9:41 PM
> *To:* Denis <denis.ietf@free.fr> <denis.ietf@free.fr>
> *Cc:* Nat Sakimura <sakimura@gmail.com> <sakimura@gmail.com>om>;
> txauth@ietf.org
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization
> Protocol (gnap)
>
>
>
> + Nat as he is mentioned
>
> - IESG
>
>
>
> On Fri, Jul 3, 2020 at 2:16 AM Denis <denis.ietf@free.fr> wrote:
>
> Hello Dick,
>
>
>
> Catching up on this email ... comments inserted ...
>
>
>
> On Mon, Jun 29, 2020 at 12:06 AM Denis <denis.ietf@free.fr> wrote:
>
> Hello Dick,
>
>
>
> Denis, thanks for sharing your thoughts, some clarifications on your
> statements inserted:
>
>
>
> On Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr> wrote:
>
> <snip>
>
> *New proposed charter*
>
> <snip>
>
>
> Resource servers inform their clients about which access token formats are
> acceptable and depending upon the king of operation
> that is requested, which kind of attributes are needed and from which ASs
> that my be obtained.
>
> While at times this may be appropriate, at other times disclosing the
> attributes the RS requires is not needed by the client.
> For example, an enterprise client accessing a resource does not need to
> know which groups a user belongs to,
> but the RS may require that to determine if the user running the client
> has access.
>
> As soon as there is a desire to implement privacy by default, the client
> should not provide more attributes than strictly necessary.
> Even after three readings of your example, I failed to understand it.
>
>
> A major difference with OAuth 2.0 is that there is no bilateral trust
> relationship between an authorization server and a resource server:
> for a given category of attributes, a resource server may trust one or
> more authorization servers. Another major difference with OAuth 2.0.
> is that the content of an attributes token is meant to be accessible to
> the client.
>
> This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF
> presentation on what became OAuth 2.0
>
>
>
> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>
> I looked at the two slides.
>
> Unfortunately slide 7 has just one arrow with the word "trust". This is
> insufficient to understand what is meant unless being present
> at the presentation. Does it mean that the PR (RS) trusts one AS or that
> it may trust multiple ASs ?
>
> Unfortunately slide 8 has just one arrow between the PR and the AS which
> is red-crossed but no text at all. This is insufficient to understand
> what is meant unless being present at the presentation. Does it mean that
> the PR and the AS never communicate directly ?
> Does it mean that they have no relationships at all, besides the one way
> trust relationship mentioned in slide 7 ?
>
> So it hard to say whether these two slides are indeed meaning that there
> is no bilateral relationship between an authorization server and a resource
> server.
>
> Apologies for not providing an explanation on the slides.
>
>
>
> Slide 7 shows that trust between the AS and PR (now RS) was
> unidirectional, from the RS to the AS.
>
> Slide 8 indicates that trust is not bidirectional.
>
> [Denis]  ... which means that slide 8 contradicts slide 7.  :-)
>
>
>
> Slide 8 says it does not go both ways. Slide 7 says it goes one way. I
> don't see the contradiction.
>
> I would have preferred that you meant: the RS and the AS never communicate
> directly, which is indeed a nice property to follow
> to ensure the user's privacy.
>
> That is one model. Other models are appropriate in other circumstances..
>
>
>
>
>
> There is no limit on how many ASs an RS may trust.
>
> [Denis] This is fine.
>
>  On June 12, Nat Sakimura recently answered to an email with the
> following topic:
>
> Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
> Authorization Framework: JWT Secured Authorization Request))
>
> My arguments were:
>
>      The original model for OAuth was making the assumption that the AS
> and the RS had a strong bilateral relationship.
>
>       *A key question is whether such strong relationship will be
> maintained for ever *or
>      whether it will be allowed to perform some evolutions of this
> relationship.
>
>      In order to respect the privacy of the users, there is the need to
> encompass other scenarios. One of these scenarios is that the AS and the RS
>      do not need any longer to have such a strong relationship. In terms
> of trust relationships, a RS simply needs to trust the access tokens issued
> by an AS.
>      The AS does have any more a "need to know" of all the RSs that are
> accepting its access tokens. This would be a major simplification of the
> current global architecture.
>
> Nat's position was:
>
> "My take is that the basic assumption of OAuth 2.0 Framework is that there
> is a strong relationship between AS and RS.
> I feel that it is quite unrealistic that an RS would trust the access
> token issued by an AS that it has no strong relationship with".
>
> There are indeed different positions on this topic.
>
>
>
> I don't think Nat and I have different opinions, but I will let Nat
> clarify.
>
> Just because there is a strong relationship between the AS and RS, does
> not mean it is bidirectional. I would understand
>
>
>
> "I feel that it is quite unrealistic that an RS would trust the access
> token issued by an AS that it has no strong relationship with"
>
>
>
> to indicate Nat is expecting the trust to be from the RS to the AS.
>
> [Denis]  Speaking of a "strong relationship" is ambiguous. The key point
> being whether the relationship is unilateral or bilateral.
> There is no need to use the wording "strong relationship" when the
> relationship is only unilateral: a RS simply trusts an AS for the access
> tokens it issues.
> In such a case, this does not mean that an AS is knowing all the RSs that
> are trusting it.
>
> On the contrary, a strong (bi-)relationship is when a RS and an AS both
> agree between them about the meaning of scope parameters.
> This is a typical case for OAuth 2.0.
>
> You can ask Nat what he meant by "strong relationship"
>
>
>
> The AS is stating what a scope means to it and the user.. The RS can do
> whatever it wants. I don't see that as requiring a bidirectional
> relationship.
>
>
>
>
>
>
>
>
>
>
>
> The AS may not even know who the RS (or PR in the slides) is.
>
>
>
> <snip>
>
>
> I got rid of the word "delegation": the client does not delegate anything
> to an authorization server. If it would, this would mean that the
> authorization server
> would be able to act as the client and could know everything that the
> client will do, which comes into contradiction with the user's privacy.
>
>
>
> The above is not true.
>
>
>
> The Resource Owner is delegating access control to the AS in authorization
> use cases.
>
> The OAuth 2.0 model does not mandate any more the presence of a Resource
> Owner.
>
>
>
> Why do you say that? The RO is who owns the RS. Your statement does not
> make sense.
>
> [Denis]  I mean that there is not necessarily a protocol defined so that
> the RO can interact with the requests from the clients.
>
> Is the RO the User? In consumer use cases it usually is, and the RO is
> using the client. I'm not sure what you scenario you are describing
>
>
>
>
>
>
>
>
>
> The client is may be delegating user authentication to the AS in identity
> claim use cases.
>
> Delegating user authentication to the AS is different from delegating
> access control to the AS.
>
>
>
> Agreed. Your statement was there was no delegation. I'm explaining there
> are potentially two delegations.
>
>
>
> The AS can act as the client in many OAuth deployments, as the access
> token is a bearer token.
>
> A bearer token is rather insecure.
>
> Cookies are also bearer tokens. But we use them all the time in web apps
> for storing session state and prior authentication! :)
>
>
>
>
>
> That does not mean the AS knows what the client is doing.
>
> There are currently two attempts in the OAuth WG to let know to the AS
> what the client is doing:
>
>    - draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization Framework:
>    JWT Secured Authorization Request)
>    - draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization
>    Requests)
>
> Those are optional, and in some situations are a desired property.
>
> [Denis]  However, in these two drafts, the privacy considerations sections
> are silent on this point.
>
> There are lots of missing details in both drafts! Security considerations,
> error messages etc.
>
>
>
> I think pretty much everyone is onboard supporting privacy, but not all
> use cases have the same privacy considerations.
>
>
>
> /Dick
>
>
>