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

Dick Hardt <dick.hardt@gmail.com> Mon, 06 July 2020 16:59 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 1DA993A17E8; Mon, 6 Jul 2020 09:59:03 -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 oFfsc17XxSA2; Mon, 6 Jul 2020 09:58:59 -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 CAFDE3A1809; Mon, 6 Jul 2020 09:58:58 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id q4so10548872lji.2; Mon, 06 Jul 2020 09:58:58 -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=OeyxxEsbbBTtRX7fNeYuixV4JY4+4XZLSMvVf9QGyNU=; b=WFSp9/y6PZuLsIVj3BhitEK6AvUo3GpDDivSpqgZkj9LKk+uNpLYL2k1JitV75p5tR uAwB/uD6nfIFYY7FQWXTTURveE6AaBcJ5Ji18n6GKIEAWL5caw1Vam1aGuA7BumrQZWW 3RHgb1ZOLK7JnBSOEAXkr13Otz4V0ak+25YFS3kig3I3ZrQNuClSgC1+RH4Xxz83xNsj 2Uhu2YdJmbXLHfpyb1db/N4PnNVmd/9VVMk/p4zFliWNPU+dx4sDI070N2aGDEGsOSXV s15vWYrnJ1ZCmgz4mLYax6AX5N7hN1AGx5q70EMOhq3EcVGAEA69lsuo1Qbq5vvKmdHV UktA==
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=OeyxxEsbbBTtRX7fNeYuixV4JY4+4XZLSMvVf9QGyNU=; b=Uj2bjHQnZNRJOhidOSGIYm+bfo9G5y/hQUO5xsdbW75hOrpremUfimUgIuEqb1jJCl w1TTTDTmwxwDpHs/Wpcl/5J0LtuNbpqLAdL7NNiRcJhgczcUXmQaXYQ/pLx/iXBpfKS0 +hqESsmdIz8a49kxWRrNPu3TOwPKRaQeqzh2aI9+/SfQ9GeCou6NBPVyx2cH9GiTaFgw HazIrA16IcTt6voqqo1USWXBeNDIGqelcIGvXkGLJBAPCxoEReDiLh1v01WSEgScIWxv Rl31XZKghGh/tOQ5QoEB57D+v2wi2X/TgSk7YpI682+PpQczx1wFEOMMFkYmznYFAaI3 502Q==
X-Gm-Message-State: AOAM5324VsxFKcpFQ9tW2NMtQeBJggWhHDp8ablfeiQXag5yl0qE8NLu Gj/0mUQayAXiZOgcTlHnpm5FbA2LDAxPmhE/k1co8Pqf
X-Google-Smtp-Source: ABdhPJyPJSV3fRLVk4XDsSZxFBRmExHyyM0V4r0S/s2kL4nTGgJvu1dofMwQhAoBAZs9r4iyVeMtAegc4GF2QN6yxDw=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr29375886ljg.242.1594054736725; Mon, 06 Jul 2020 09:58:56 -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> <CAD9ie-saCvan0UPDOy=ccy11F7sQcmXOQjzBvDR=FUJrH1g9ow@mail.gmail.com> <354edabf-d9d5-1318-403f-866043e8d0a6@free.fr>
In-Reply-To: <354edabf-d9d5-1318-403f-866043e8d0a6@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 06 Jul 2020 09:58:20 -0700
Message-ID: <CAD9ie-uc+4k1wJpt=wBKn8yRDha_0W00WqW+t57fEVqq9xrirQ@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="00000000000055cc4205a9c8cabc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/nByUfQpU-HG9OG7-zRzmtpM9Ocs>
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:59:10 -0000

Security is not called out as a goal, but is a goal for ALL
implementations/deployments.

While privacy will be a goal for some implementations/deployments, it will
NOT be a goal for all. I think your suggested additions will constrain the
work.


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

> Hi Dick,
>
> Hi Denis
>
> Just like "privacy", "security" is not called out as a goal. (it is
> mentioned as an issue with OAuth 2.0).
>
> The word "security" appears once in the charter, but the word "privacy"
> does not appear.
>
> What goes well without saying, goes even better when you say it.
>
> Many features announced in the charter *prevent *to apply privacy
> principles.
> So it is easy to get the impression that the charter is considering that
> privacy is a non-goal.
>
> "Privacy by design" should be mentioned as well as "privacy by default".
> These two magic sentences are of utmost importance.
>
> Denis
>
>
> 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>;
>> 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
>>
>>
>>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>