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

Roman Danyliw <rdd@cert.org> Mon, 06 July 2020 14:35 UTC

Return-Path: <rdd@cert.org>
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 E56463A157E for <txauth@ietfa.amsl.com>; Mon, 6 Jul 2020 07:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_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 (1024-bit key) header.d=cert.org
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 IZDQbzTta_qP for <txauth@ietfa.amsl.com>; Mon, 6 Jul 2020 07:35:52 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538D13A1574 for <txauth@ietf.org>; Mon, 6 Jul 2020 07:35:51 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066EZlLB018448; Mon, 6 Jul 2020 10:35:47 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 066EZlLB018448
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1594046147; bh=LPUrTs/A04q1JW5T8HQ7r+wS8+sNzM/rpE0UxypK5V4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=opJ1UbRsGo4ezlY+O48JFKeNloqY2cDrH1gFOWNfdnTnXqbLzucA6t8oWufHykBJf BHPyKzVLFwTf66fr/HpdorN0dVcxXj9HY/rIdbcRjAMnEnIggtQA7bU7wYb1uzoTP1 lJuiKFbYkcLupeo0z3wYhVP20j6hcEsVmwTvD/KY=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066EZkj5009602; Mon, 6 Jul 2020 10:35:46 -0400
Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 6 Jul 2020 10:35:46 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 6 Jul 2020 10:35:46 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 6 Jul 2020 10:35:46 -0400
From: Roman Danyliw <rdd@cert.org>
To: Dick Hardt <dick.hardt@gmail.com>, Denis <denis.ietf@free.fr>
CC: Nat Sakimura <sakimura@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>
Thread-Topic: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
Thread-Index: AQHWS9RNiDy30JPhzE2lVpUcI/9MaqjrXPEAgAAQEoCABAYNgIAFbXIAgAEAHICAARM1gIADnf7w
Date: Mon, 06 Jul 2020 14:35:45 +0000
Message-ID: <731a364a19a74e1d982d59d9c441dc0a@cert.org>
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>
In-Reply-To: <CAD9ie-tbuykhJAMFao+4wJU51GgCKPXCPZB-P+q+doMBFezarg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.182]
Content-Type: multipart/alternative; boundary="_000_731a364a19a74e1d982d59d9c441dc0acertorg_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/BFLe5KeBN4rgDTD8mFvCsxj_DaE>
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 14:35:56 -0000

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> On Behalf Of Dick Hardt
Sent: Friday, July 3, 2020 9:41 PM
To: Denis <denis.ietf@free.fr>
Cc: Nat Sakimura <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<mailto: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<mailto: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<mailto: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