Re: [GNAP] Consensus Call on Continuation Request

Justin Richer <jricher@mit.edu> Fri, 11 December 2020 17:08 UTC

Return-Path: <jricher@mit.edu>
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 1A02F3A0CFE for <txauth@ietfa.amsl.com>; Fri, 11 Dec 2020 09:08:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 MpNgnSMFqK_7 for <txauth@ietfa.amsl.com>; Fri, 11 Dec 2020 09:08:00 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 547F83A0D2C for <txauth@ietf.org>; Fri, 11 Dec 2020 09:07:59 -0800 (PST)
Received: from [192.168.1.19] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BBH7u3b028178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Dec 2020 12:07:57 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <ACC9EAE9-9601-4164-8A57-C5C2DB770671@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DB2305AE-13B9-49AE-832B-2BB6F6894596"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 11 Dec 2020 12:07:56 -0500
In-Reply-To: <CAM8feuQMK5tZQmUDBYtOBAm0PrSiRzFPz=8=kqZPwDzM-MGfLw@mail.gmail.com>
Cc: Warren Parad <wparad@rhosys.ch>, Dick Hardt <dick.hardt@gmail.com>, txauth gnap <txauth@ietf.org>
To: Fabien Imbault <fabien.imbault@gmail.com>
References: <94973397-0354-4B02-9EC8-EF972A7F1867@mit.edu> <CAD9ie-v-j=PBGjLmiWT+z1Whimfmqo=+Pqw1DVFmXZO-bm7=4w@mail.gmail.com> <CAJot-L1XuL0csXJi2MX81Ado_BmQdys1CQDFZ1rRp7LfEsmeZg@mail.gmail.com> <CAM8feuQMK5tZQmUDBYtOBAm0PrSiRzFPz=8=kqZPwDzM-MGfLw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/4e9H4qHA9drTv4fhH4YdUjK7GmI>
Subject: Re: [GNAP] Consensus Call on Continuation Request
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <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: Fri, 11 Dec 2020 17:08:03 -0000

Consistency and clarity for client developers is the goal with the proposed PR. Since the “continue” set of functions was refactored to be an API, the thought was to treat this API exactly like we’d treat an external API hosted at an RS. This pattern would allow the AS to reap the benefits of a token-based protocol (distributed deployments, better security, and so on) as well as making the client developer’s life easier by not making them do something special just to talk to the AS.

As Fabien points out, the “access_token” field is exactly the same field as what comes back in a response for a separate API. The semantics of everything in that field are exactly the same in both places, including the “key” field. The only difference, right now, is that the “key” field is only allowed to have one value, to indicate it’s bound to the requesting client’s instance key that was used in the initial request. There’s been some confusion on that, and so it’s something we might want to change — but that’s a separate issue, and if we use access tokens for continuation then we can solve that problem in a consistent way.

When the client is continuing, you can think of the key presentation as it “authenticating”, but I’d argue that you don’t need to “authenticate” the client at this stage: you just need the context of the ongoing request, and you need to make sure that the caller of that request is the right caller. That is, they can present the right set of security material. A key-bound access token is the perfect map to this function, and it’s something we already want as a core artifact. It also has the benefit of allowing different parts of the AS to communicate via the access token itself without things getting leaked in the URL. Could we put all that state in the URL itself? Sure, but then we need to include discussion about how to protect all of that. Instead, we have an opportunity to avoid problems that we already know exist, instead of repeating them and requiring fixes out of the gate. GNAP is our opportunity to do things better than before.

It’s been argued that a client that isn’t dealing with access tokens at all would need to know something “new” to deal with this continuation API. While technically true, the difference between signing a request that includes an access token and signing a request that doesn’t include an access token is minimal. Further, I personally think that the use case for clients who aren’t going to have any access tokens is going to be exceedingly small, and so optimizing the protocol for that use case is a big lose for the wider community.

 — Justin

> On Dec 11, 2020, at 9:17 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
> 
> Hi, 
> 
> I commented previously on Dick's input (in short, I disagree - at least with the cookie comparison).
> 
> I'm not sure I follow your point here. "access_token" already has its field, the proposal is just reusing it throughout the protocol (see for instance section 3.2.1) as a fairly consistent api. The only difference is the meaning of the "key" boolean parameter (which I would be in favor of renaming to clarify).
> 
> The proposed alternative comes with issues with seem very hard to get around, at least in a systematic way. Like potential logs of capability URLs that include the token, which opens the doors to vulnerable implementations. 
> 
> Fabien
> 
> On Fri, Dec 11, 2020 at 11:24 AM Warren Parad <wparad@rhosys.ch <mailto:wparad@rhosys.ch>> wrote:
> For the part I agree with Dick, but I also dislike the separation of the "access token" into its own field. If I understand continue correctly, the access_token would only ever be used with the continue uri, in which case, having the token in the url is much better than having a separate parameter which has to be merged with the continue request to auth it. In my opinion there is no reason to break HATEOAS here, this is one of the few places where the capability URL makes sense, and given its limited use and accessibility the concerns are alleviated. Additionally moving the token back into the uri, avoids the whole problem of naming and how to treat this token.
> 
> 
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>.
> 
> 
> On Thu, Dec 10, 2020 at 9:06 PM Dick Hardt <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>> wrote:
> -1 per all the reasons I laid out in https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/ <https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/>
> ᐧ
> 
> On Thu, Dec 10, 2020 at 7:52 AM Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
> The editors and chairs would like to confirm consensus on a current pull request:
> 
> https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129 <https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/129>
> 
> This pull request simplifies the continuation response and request by making the access token mandatory, and it clarifies the responsibilities of the AS in enforcing the security of the continuation request. Several WG members expressed specific support for keeping the access token to enable specific use cases, and there was general support for simplifying the process from what it currently is in the draft. The editors believe the pull request represents a solution that meets these goals.
> 
> This call is open until Monday December 14. At that point, the PR will be merged unless the chairs determine there is not rough consensus for its inclusion.
> 
> Thank you,
> 
>  - Justin, Aaron, and Fabien
> -- 
> TXAuth mailing list
> TXAuth@ietf.org <mailto:TXAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> TXAuth@ietf.org <mailto:TXAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> TXAuth@ietf.org <mailto:TXAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>