Re: [GNAP] Consensus Call on Continuation Request

Dick Hardt <dick.hardt@gmail.com> Fri, 11 December 2020 17:54 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 EB4303A0E26 for <txauth@ietfa.amsl.com>; Fri, 11 Dec 2020 09:54:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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
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 0q2OrTZlqPDU for <txauth@ietfa.amsl.com>; Fri, 11 Dec 2020 09:54:40 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 6123F3A0E1D for <txauth@ietf.org>; Fri, 11 Dec 2020 09:54:35 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id a1so11894628ljq.3 for <txauth@ietf.org>; Fri, 11 Dec 2020 09:54:35 -0800 (PST)
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=/WEpSudFWZlXxymVGHtmUYd0vns2ig3+QQuVJ3cjbzY=; b=Lnxz8vqFAuuDdQrCuWqeU4pAKtUa3u1WHkUxFYufrd6T1cLwp5N1rga/KCCf5SZWfq UqwjzwvAfGiPK9u1Roni9P1XCYTAEwXB/6QW3NKLRUZ2l0BfKpjYSsIHIpKy44XaM8V3 DdlKdkEsE5f2meiGNOe4OCrinYmG8URquckfkhKR7n/1VUeq420kWLeSPU9XBkGvqgmO YnlBoZvfIbDv8sKrHw1Tsddwsc+Hd77dAUjrh3ksAfWhbOaFfGSXa2J53kLphuyaUGkV rmC+OFxwGEy4uMr2RTohlWpfmKKc26NH67ezI9QcA+Ug2Yox8MKI4iMjI4vnAjYIEMMa xORA==
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=/WEpSudFWZlXxymVGHtmUYd0vns2ig3+QQuVJ3cjbzY=; b=nJD+7Zj48nkh0ViPofml3HrFbBiZFzaH1C5vRI67iJ+6CZVRMGd+ML1Kf147Y70KnP INlbmZWGYvRsm2ikVFktsmeSAXz4UMG1Eo+mM9G2XevMHS7MXDu0kRMEXW4dnkCPXYkY +IgyKElb5P10I04RBn84ncInOZKYvmZcqGgeYpZky42noKTfm5J1VytHlCS8tcx6EqcL K/3hU+AxlRHnX2QDhvnDD2puwltPS2jHfOJNOpFEs7pCTOJyvaiQD001FC72BrSlb0NY KADrlEzmetnFXrnaI4+aCH81/0P5ZK442TDwOfEL81mZT2gjkzE1bp0R0S6Qsag8DaqP KB8A==
X-Gm-Message-State: AOAM530COfUWjdjTTf0hpVzqwhEQp/SZGD1ri0rNZx6W/XNvnpFQDp5i S9ChyQNqy7KmMhx7Tm9HngMe7ES3tdhN8jOuNaQ=
X-Google-Smtp-Source: ABdhPJz4IcFCEBSb/q6KWPO8MIN8O56bQtGJdMRDVRcBO9rdHTo0cDrbPcW7z6jegj8ckd4O4FktqNY6hybSy+FxqZc=
X-Received: by 2002:a2e:9654:: with SMTP id z20mr5338050ljh.335.1607709273042; Fri, 11 Dec 2020 09:54:33 -0800 (PST)
MIME-Version: 1.0
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> <ACC9EAE9-9601-4164-8A57-C5C2DB770671@mit.edu>
In-Reply-To: <ACC9EAE9-9601-4164-8A57-C5C2DB770671@mit.edu>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Fri, 11 Dec 2020 09:53:56 -0800
Message-ID: <CAD9ie-u3t=SGQJGZxMbwcw9W2dM9aK=9kXrSa7i9S3a1Dd+M8A@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, Warren Parad <wparad@rhosys.ch>, txauth gnap <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001f33fc05b633fc35"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/KhcDLjYzLZRwuospjTWjfWOdrAw>
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:54:50 -0000

Justin / Fabien: are your responses as editors, or as individuals? Are you
gathering consensus, or arguing your views?

Fabien: I don't think you understand how cookies work -- they are not set
by the client.

I agree with the consistency and clarity goals for client developers --
this proposal violates both.

How the client makes the initial request is different from the continue
calls. To be consistent, the client would authenticate the same way on all
calls.

In contrast to calls to the AS, the RS is not handing back an
"access_token" to use on subsequent calls.

A key-bound access token is an important option when calling an RS -- but
bearer tokens have proven to be adequate for many APIs -- so many clients
will likely not have to use key-bound access tokens when calling an RS.

Not all clients are needed to access an RS -- the client may only be
acquiring claims.

While a token-based protocol is interesting -- it is not a common pattern
-- and a token-based protocol is not the same as one using an access token
-- and it is not a common pattern that I have seen -- for the small number
of AS that want to be completely distributed and stateless -- they can put
it in the URL -- or a new standard mechanism for a token-based protocol can
be developed -- or they could use cookies just as web browsers do for
maintaining state.

I have zero requirement to encapsulate the grant request in a token --
having a URI uniquely identify the request works fine, just as it does with
many, many other deployed APIs -- requiring an AS to create a token it does
not need so that it conforms with the protocol adds complexity with zero
benefit.

ᐧ

On Fri, Dec 11, 2020 at 9:07 AM Justin Richer <jricher@mit.edu> wrote:

> 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> 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> wrote:
>>
>>> -1 per all the reasons I laid out in
>>> https://mailarchive.ietf.org/arch/msg/txauth/hBMexdKrh7RuR--Dq6UEVJN8hkY/
>>> ᐧ
>>>
>>> On Thu, Dec 10, 2020 at 7:52 AM Justin Richer <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
>>>>
>>>> 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
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>> --
>>> TXAuth mailing list
>>> TXAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>> --
>> TXAuth mailing list
>> TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>
>
>