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

Roman Danyliw <rdd@cert.org> Tue, 07 July 2020 03:08 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 414563A09A4; Mon, 6 Jul 2020 20:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, T_FILL_THIS_FORM_SHORT=0.01, 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 zHpKZJh97K8j; Mon, 6 Jul 2020 20:08:39 -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 0266E3A09A3; Mon, 6 Jul 2020 20:08:38 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06738ZoK004184; Mon, 6 Jul 2020 23:08:35 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 06738ZoK004184
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1594091315; bh=bu9Bbai87uhpKaMXXHNtmylPHuI+qcO/Wmzioofog7I=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=B2UCdpVeWpIchd6ulz00JOhJWThd5RDfjqn3BKCACgXi0/PWakvC1yqAledohcez4 8pKflGHFJC0rdi0J77wCxIsfpzg44EB5EUWcLNTB9maZn9WOpD0frxkdMZ/br/+iig JTzgPWKsBf4TYkfznXBGiwtnByUrg9TgA/pCN6TA=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06738Yv9045183; Mon, 6 Jul 2020 23:08:34 -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 23:08:34 -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 23:08:33 -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 23:08:33 -0400
From: Roman Danyliw <rdd@cert.org>
To: Denis <denis.ietf@free.fr>, "iesg@ietf.org" <iesg@ietf.org>
CC: "txauth@ietf.org" <txauth@ietf.org>
Thread-Topic: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
Thread-Index: AQHWS9RNiDy30JPhzE2lVpUcI/9Maqj69j8AgABtYMA=
Date: Tue, 07 Jul 2020 03:08:32 +0000
Message-ID: <3424311c60f541b197cfda6e9f3b494e@cert.org>
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr>
In-Reply-To: <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr>
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_3424311c60f541b197cfda6e9f3b494ecertorg_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/n_y4xZ3BtYu7xocgdhA-VQ119B0>
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: Tue, 07 Jul 2020 03:08:42 -0000

Hi Denis!

Thanks for the feedback and for repeating your review on the revised text.  More inline …

From: iesg <iesg-bounces@ietf.org> On Behalf Of Denis
Sent: Monday, July 6, 2020 10:55 AM
To: iesg@ietf.org
Cc: txauth@ietf.org
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

Since it is today the last day to send back comments, you will find hereafter my comments on the last charter version-05.
charter-ietf-gnap-00-05

This group is chartered to develop a fine-grained delegation protocol for authorization, API access, user identifiers, and identity assertions.



[Denis] Fine.



The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request.



[Denis] This sentence is too vague because "as part of its request" is not explicit enough. If it means  "as part as an access token request"

this should be explicitly said. If, it is not the case, then it should be clearly explained. The AS should know as little as possible (including nothing)

about what the client is doing.



[Roman] The “request” here is the “access token request”.  That can be made clearer.



This protocol will allow an authorizing party to delegate access to client software through an authorization server.



[Denis] The word "privacy" is still missing in the charter. "Delegating access to client software through an authorization server"

is negating the fact that the user's privacy will ever be considered. IMHO, I believe that a RS may delegate some operation to another RS,

but I don't believe that an AS should be concerned by any form of delegation, otherwise it would have the ability to act as "Big Brother".

OAuth has not been constructed taking into consideration the user's privacy. The major difference with it should be that GNAP has been

constructed along "privacy by design" principles.



[Roman]  I don’t exactly follow how considerations for privacy are being negated.  Above and beyond use-case specific considerations that would be defined later, RFC6973 is the IETF consensus design guidance that will guide the privacy threats and mitigations of the work.  What design guidance would you recommend that the WG should consider that aren’t captured in RFC6973?



It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations

scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove

unnecessary dependence on a browser or user-agent for coordinating interactions.



[Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. "non-expanded" use cases) should be supported

differently from OAuth 2.0 and OpenID Connect, in particular to support the user's privacy.



[Roman] I’d want to hear others on this rescoping.  Building upon the use cases of OAuth 2.0 and OpenID Connect has been core, consensus-validated tenant for some time now.



The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the channels used

by the protocol participants to communicate from the delegation channel, which happens directly between the client and the authorization server (in contrast

with OAuth 2.0, which is initiated by the client redirecting the user’s browser).



[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs.

The term "delegation channel" is being used but it is left undefined. It is not understandable.



[Roman] This sentence was just added into -05 address Security AD feedback.  In this case, it was made to distinguish between in-band signaling and the new purpose-to-be-built channel.



The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process.

The client and Authorization Server (AS) will use these interaction mechanisms to involve the user, as necessary, to make authorization decisions.



[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs. The AS should know as little as possible (including nothing)

about what the client is doing.



[Roman] Understood – as I understand it, you have concern with the scope of the AS behavior.  I’d be interesting in hearing additional support for this rescoping.



This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types

of clients and interaction channels.



[Denis] This is not understandable to me. Is such a sentence really needed in a charter ?



[Roman] Can someone on the TxAuth mailing list remind us on why this sentence is here?  With a fresh read, I also can’t remember why we need it.



The group will define interoperability for this protocol between different parties, including

-          client and authorization server;

-          client and resource server; and

     -      authorization server and resource server.



[Denis] In order to support the user's privacy, there should be no interaction at all between an authorization server and a resource server

at the time of a client request.



The group will seek to minimize assumptions about the form of client applications, allowing for:

-          Fine-grained specification of access

-          Approval of AS attestation to identifiers and other identity claims

-          Approval of access to multiple resources and APIs in a single interaction

-          Multiple access tokens in a single request and response

-          AS-directed dispatch of access tokens to the appropriate RS

[Denis] As-directed dispatch does not allow to support the user's privacy. However, RS-directed dispatch allows to support the user's privacy.

It should be explicitly mentioned.

[Roman] As above (per the AS vs. RS behavior)

-          Separation between the party authorizing access and the party operating the client requesting access



[Denis] It is questionable whether such a separation would be really beneficial. In doubt, this item should be removed.

[Roman] Could you say more on why this flexibility wouldn’t be worth it?

The group will define extension points for this protocol to allow for flexibility in areas including:



Cryptographic agility for keys, message signatures, and proof of possession

-          User interaction mechanisms including web and non-web methods

-          Mechanisms for conveying user, software, organization, and other information used in authorization decisions

-          Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys

Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process



Additionally, the group will provide mechanisms for management of the protocol lifecycle including:

-          Discovery of the authorization server

-          Revocation of active tokens

Data model for granted access and mechanisms for the AS and RS to communicate the granted access model



[Denis] While it is the duty for the RS to communicate the granted access model to the client at the appropriate instant of time,

the AS should be kept fully ignorant of it.



Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect,

the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.



This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily

compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed to the OAuth Working Group, including

functionality back-ported from the protocol developed here to OAuth 2.0.



The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process.

This group is not chartered to develop new cryptographic methods.



The group is chartered to develop mechanisms for conveying identity information within the protocol including existing identifiers

(such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens,

SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group

chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available.



The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage

of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as COAP

when doing so does not conflict with the primary focus.



Milestones to include:

-          Core delegation protocol

[Denis] Before defining a "Core delegation protocol", a simple client server-protocol involving the presentation of several access tokens to one RS should be defined.

Privacy principles should be applied when defining the protocol. Then after, a delegation mechanism allowing one RS to forward an operation to another RS should be defined.

-          Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures

[Denis] Bindings to TLS are now deprecated, why should they be maintained ?

Signatures may be needed but they do not necessarily need to be "detached HTTP signature, and embedded HTTP signatures".

This item should be either removed or reworded.

[Roman] Noted.  I’d want to hear others on this rescoping.



-          Conveyance mechanisms for identifiers and assertions

-          Guidelines for use of protocol extension points (if needed)
     -    Guidelines on migration paths, implementation, and operations
[Denis] The above three lines are rather mysterious.
[Roman] The guidelines on migration paths came from the initial IESG review in order to have a named activity to action the design goal of “… the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible” a bit earlier in the text.
Where possible, the group will seek to make use of tools to guide and inform the standardization process including formal analysis,
architecture documents, and use case documents. These artifacts will not be considered as working group milestones or deliverables.
The working group will cooperate and coordinate with other IETF WGs such as OAUTH, and work with external organizations,
such as the OpenID Foundation, as appropriate.
[Denis] The charter should be shorter.

[Roman] Definitely.  Nevertheless, we have the current text through rough consensus process achieved from two BoFs and multiple mailing list consensus calls.

Regards,
Roman

/Denis


A new IETF WG has been proposed in the Security Area. The IESG has not made

any determination yet. The following draft charter was submitted, and is

provided for informational purposes only. Please send your comments to the

IESG mailing list (iesg@ietf.org<mailto:iesg@ietf.org>) by 2020-07-06.



Grant Negotiation and Authorization Protocol (gnap)

-----------------------------------------------------------------------

Current status: Proposed WG



Chairs:

  Yaron Sheffer <yaronf.ietf@gmail.com><mailto:yaronf.ietf@gmail.com>

  Leif Johansson <leifj@sunet.se><mailto:leifj@sunet.se>



Assigned Area Director:

  Roman Danyliw <rdd@cert.org><mailto:rdd@cert.org>



Security Area Directors:

  Benjamin Kaduk <kaduk@mit.edu><mailto:kaduk@mit.edu>

  Roman Danyliw <rdd@cert.org><mailto:rdd@cert.org>



Mailing list:

  Address: txauth@ietf.org<mailto:txauth@ietf.org>

  To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth

  Archive: https://mailarchive.ietf.org/arch/browse/txauth/



Group page: https://datatracker.ietf.org/group/gnap/



Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/



This group is chartered to develop a fine-grained delegation protocol for

authorization and API access, as well as requesting and providing user

identifiers and claims. This protocol will allow an authorizing party to

delegate access to client software through an authorization server. It will

expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect

(itself an extension of OAuth 2.0) to support authorizations scoped as

narrowly as a single transaction, provide a clear framework for interaction

among all parties involved in the protocol flow, and remove unnecessary

dependence on a browser or user-agent for coordinating interactions.



The delegation process will be acted upon by multiple parties in the protocol,

each performing a specific role. The protocol will decouple the interaction

channels, such as the end user’s browser, from the delegation channel, which

happens directly between the client and the authorization server (in contrast

with OAuth 2.0, which is initiated by the client redirecting the user’s

browser). The protocol will include a means of specifying how the user can

potentially be involved in an interactive fashion during the delegation

process. The client and Authorization Server (AS) will use these interaction

mechanisms to involve the user, as necessary, to make authorization decisions.

This decoupling avoids many of the security concerns and technical challenges

of OAuth 2.0 and provides a non-invasive path for supporting future types of

clients and interaction channels.



The group will define interoperability for this protocol between different

parties, including

 - client and authorization server;

 - client and resource server; and

 - authorization server and resource server.



The group will seek to minimize assumptions about the form of client

applications, allowing for:

- Fine-grained specification of access

- Approval of AS attestation to identifiers and other identity claims

- Approval of access to multiple resources and APIs in a single interaction

- Support for multiple access tokens in a single request and response

- Support for directed, audience-restricted access tokens

- Separation between the party authorizing access and the party operating the

client requesting access



The group will define extension points for this protocol to allow for

flexibility in areas including:



- Cryptographic agility for keys, message signatures, and proof of possession

- User interaction mechanisms including web and non-web methods

- Mechanisms for conveying user, software, organization, and other

information used in authorization decisions

- Mechanisms for presenting tokens to resource servers and binding resource

requests to tokens and associated cryptographic keys

- Optimized inclusion of additional information (including identifiers and

identity assertions) through the delegation process



Additionally, the group will provide mechanisms for management of the protocol

lifecycle including:



- Discovery of the authorization server

- Revocation of active tokens

- Mechanisms for the AS and RS to communicate the access granted by an access

token



Although the artifacts for this work are not intended or expected to be

backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt

to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol

where possible.



This group is not chartered to develop extensions to OAuth 2.0, and as such

will focus on new technological solutions not necessarily compatible with

OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed

to the OAuth Working Group, including functionality back-ported from the

protocol developed here to OAuth 2.0.



The group is chartered to develop mechanisms for applying cryptographic

methods, such as JOSE and COSE, to the delegation process. This group is not

chartered to develop new cryptographic methods.



The group is chartered to develop mechanisms for conveying identity

information within the protocol including existing identifiers (such as email

addresses, phone numbers, usernames, and subject identifiers) and assertions

(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable

Credentials). The group is not chartered to develop new formats for

identifiers or assertions, nor is the group chartered to develop schemas for

user information, profiles, or other identity attributes, unless a viable

existing format is not available.



The initial work will focus on using HTTPS for communication between the

client and the authorization server, taking advantage of optimization

features of HTTP/2 and HTTP/3 where possible, and will strive to enable

simple mapping to other protocols such as COAP when doing so does not

conflict with the primary focus.



Milestones to include:

- Core delegation protocol

- Key presentation mechanism bindings to the core protocol including TLS,

detached HTTP signature, and embedded HTTP signatures

- Conveyance mechanisms for identifiers and assertions

- Guidelines for use of protocol extension points

- (if needed) Guidelines on migration paths, implementation, and operations



Where possible, the group will seek to make use of tools to guide and inform

the standardization process including formal analysis, architecture documents,

and use case documents. These artifacts will not be considered as working

group milestones or deliverables.



The working group will cooperate and coordinate with other IETF WGs such as

OAUTH, and work with external organizations, such as the OpenID Foundation,

as appropriate.



Milestones:



  Jul 2021 - Core delegation protocol in WGLC



  Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to

  WGLC



  Oct 2021 - Key presentation mechanism binding to the core protocol,

  detached HTTP signatures, to WGLC



  Oct 2021 - Key presentation mechanism binding to the core protocol,

  embedded HTTP signature, to WGLC



  Dec 2021 - Guidelines for use of protocol extension points to WGLC



  Feb 2022 - Guidelines on migration paths, implementation, and operations to

   WGLC