Re: [GNAP] Will GNAP support Zero Trust Architecture?

Fabien Imbault <fabien.imbault@gmail.com> Wed, 24 March 2021 16:36 UTC

Return-Path: <fabien.imbault@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 CAAB63A3060 for <txauth@ietfa.amsl.com>; Wed, 24 Mar 2021 09:36:52 -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 Opj-FcFxxxbN for <txauth@ietfa.amsl.com>; Wed, 24 Mar 2021 09:36:48 -0700 (PDT)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 D4A073A305F for <txauth@ietf.org>; Wed, 24 Mar 2021 09:36:47 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id k8so22156282iop.12 for <txauth@ietf.org>; Wed, 24 Mar 2021 09:36:47 -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=6QFG6OnjlGFY2PbA8td9cPxk5YxhUxKLIvbTGztFK2k=; b=BQ+5HUX355M/vdXbiwYBM4N0imsKirmYcAzAEGOGfFgcmDK1jpQrXV1o1ebHNtvkOO o5e/mLl2uFx1GHITpGltjgo76l8yPZygCSj92oMEVE2SMLTaiEjVFQ4a7LIy/AH4XT0o o8dgZsMZTc0Z+zaQDCrYR2KdunoVif9jZVOmDkpC1LxxoNbgOSkeZ77MMzmJbVpIc3Oa ZRh8tm845b/8FetBgls/pVsVMt4WP+kT7P575o50qoWjKLQpDQAUWMA6rMldb0OtLhEc hG4SyVP56MbMp3QDSFwvwUTXQ0YI8kesJuNMEZyx4WbGLiJ+5BHSiVDaniHPS6St/Q5U obnw==
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=6QFG6OnjlGFY2PbA8td9cPxk5YxhUxKLIvbTGztFK2k=; b=jI8pqX35PLjIn7OWT+LY47gRvoxKoSdN55duM6HZfhVFtLv2reAzY1kpM5pDecLWYO M4iGnrGM4gT4aZmPVRDPF/Vtck5pr7FjxE/UxQ38jfaPzOfdJArwBXLolkq/GKDHPZR3 FA7zWn8JbjL+/Cq117M8DsfL1pw4Fn7mnLna73ITV9+CnsTl7G7ERB9//Q3JDf/QV++s RTZN1ufg+Zv1KsICIcd9kyQaHS9/k4R5xpoB9UDYng+Og/RS09dYcUziEuWnycAQ8p3+ Dl+jhPLH8MM7NyOQhKE9JOmgh/p9UlMUDSANGSPecrNoTgMc7WgwTjEgCGeBytnNjpOK 3EgA==
X-Gm-Message-State: AOAM533zbx9OwTfGwJTfCDoWoi2LflhCiNdeSYUkGBI58T6BUu6fJQF4 FPXffmaVZNBaEl5zsEyb3YX+443KMOt1Sa5lZkQ=
X-Google-Smtp-Source: ABdhPJzcIVfj1+2qZ7Pr/AP52KW+zl1wQg7BekebehyB/cTzeq8FY3Jekd+tP1k3nPnhKPjrjttky9Y1YwG4WcjXay4=
X-Received: by 2002:a05:6602:228f:: with SMTP id d15mr2963603iod.141.1616603806221; Wed, 24 Mar 2021 09:36:46 -0700 (PDT)
MIME-Version: 1.0
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <CANYRo8gMQYJXcb0FU2VCVcdbBLsopZ5Wfyo3hd1Pd5tmOSs0SA@mail.gmail.com> <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu> <CANYRo8iPeeM3rLP9BYid2B71NzU7fR6J9Ra4=PSODTFE7i75Zg@mail.gmail.com> <CEECEE23-24D0-4C0C-B39E-9FDFF9E1E13D@mit.edu> <CANpA1Z2S8Y3+U+jOa-ZbTzsZ9hkybCnGfzx0kP8VF=Z=Se4uew@mail.gmail.com> <CAM8feuTaYEZY8BNtp5j8dAxZjBLnM-0CZQUO9UgGAAx=-qQyJA@mail.gmail.com> <CANpA1Z2Zt0ksRZqu7f6kGc5CXvWjRvuBMyDn4-EeiVE7Ndj3yw@mail.gmail.com>
In-Reply-To: <CANpA1Z2Zt0ksRZqu7f6kGc5CXvWjRvuBMyDn4-EeiVE7Ndj3yw@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Wed, 24 Mar 2021 17:36:34 +0100
Message-ID: <CAM8feuRk6bB6ry1dy9W-9OKSgckYqicVtQ7jsrxseA2iJQdPKQ@mail.gmail.com>
To: Alan Karp <alanhkarp@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Adrian Gropper <agropper@healthurl.com>, Benjamin Kaduk <kaduk@mit.edu>, Mark Miller <erights@gmail.com>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009cc85705be4ae7aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/puYiWprGozLSbkiGiYts8vkipmY>
Subject: Re: [GNAP] Will GNAP support Zero Trust Architecture?
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: Wed, 24 Mar 2021 16:36:53 -0000

Hi Alan and Adrian,

I've created issue AS-RO policy delegation (
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/223) to capture
your input.
A first question that arises: can we give a definition to AS-RO?

Thanks
Fabien

On Tue, Mar 23, 2021 at 4:15 PM Alan Karp <alanhkarp@gmail.com> wrote:

> Fabien Imbault <fabien.imbault@gmail.com> wrote:
>
>> Hi Alan,
>>
>> Yes, but in that flow, the token relationship between AS-RS and AS-RO is
>> only secure if the tokens issued by AS-RS are cryptographically attenuable
>> in the first place.
>>
>
> Attenuated delegation is a requirement, but that doesn't have to be done
> cryptographically.  Token exchange works just fine.  SPKI and zcap-ld are
> examples of the crypto approach, and we used token exchange in the system
> for HP.
>
> --------------
> Alan Karp
>
>
> On Tue, Mar 23, 2021 at 4:12 AM Fabien Imbault <fabien.imbault@gmail.com>
> wrote:
>
>> Hi Alan,
>>
>> Yes, but in that flow, the token relationship between AS-RS and AS-RO is
>> only secure if the tokens issued by AS-RS are cryptographically attenuable
>> in the first place.
>>
>> Fabien
>>
>> On Mon, Mar 22, 2021 at 9:26 PM Alan Karp <alanhkarp@gmail.com> wrote:
>>
>>> Justin Richer <jricher@mit.edu> wrote:
>>>
>>>>
>>>> But with all that in mind, I think the key here is going to be looking
>>>> at what the inputs to the AS are, and how those can be defined in an
>>>> interoperable way for AS’s that can accept them. I think there’s a lot of
>>>> room for innovation and flexibility here that doesn’t break the trust model
>>>> or core use cases. If I have an AS-RS set that won’t accept my favorite
>>>> flavor of policy engine inputs, then I can decide not to use that one. But
>>>> this is a very different question than saying the RS itself needs to accept
>>>> my own AS — and we can’t keep conflating these two models.
>>>>
>>>> I agree.  The point of having an AS-RO is to allow RO to specify a
>>> policy for which of RO's access tokens should be delegated under what
>>> conditions.  AS-RS should not need to understand those policies.  The flow
>>> would be
>>>
>>>    - RO contacts AS-RS and gets one or more access tokens.
>>>    - RO delegates one or more of those tokens, potentially sub-scoped,
>>>    to AS-RO.
>>>    - A different user contacts AS-RO to get a potentially sub-scoped
>>>    access token from AS-RO.
>>>    - That user presents the access token delegated by AS-RO when
>>>    invoking the resource.
>>>
>>> AS-RS only needs to verify that the delegation chain is legitimate,
>>> e.g., no increase in scope, and that it grants permission for the request
>>> being made.  AS-RS does not need to understand the policy behind granting
>>> the delegation by AS-RO.
>>>
>>> --------------
>>> Alan Karp
>>>
>>>
>>> On Mon, Mar 22, 2021 at 11:40 AM Justin Richer <jricher@mit.edu> wrote:
>>>
>>>> Adrian,
>>>>
>>>> I think this shows the problem with the terminology as it’s been
>>>> applied in this conversation, which I’ve tried to shine light on before.
>>>> What you and others are calling the “RS” is really the “AS and RS working
>>>> together” — everything to the right of the line. When Denis had brought up
>>>> “eliminating the AS” in another thread, what he’d really done is labeled
>>>> everything to the right of the line as the “RS”. Of course, the irony here
>>>> is that everything to the right of the line used all be called the “AS” or
>>>> simply “server” in the OAuth 1 days. As you say below, I don’t want the
>>>> client to have visibility on what happens on that side.
>>>>
>>>> Note well: The Google+ logo labeled “IdP” in the diagram is not the AS,
>>>> as far as GNAP is concerned. It does not issue an access token that the RS
>>>> will accept. The elements to the left of the line could be a lot of things,
>>>> but they are NOT the AS — by definition. The client lives over on the left,
>>>> but so do any external inputs to the AS. These could be policy inputs on
>>>> behalf of the RO, they could be presentation artifacts, they could be
>>>> federated logins, they could be the output of policy decisions. How the AS
>>>> comes to trust those things is up to the AS’s implementation. It’s
>>>> something we can talk about, but ultimately GNAP won’t be in any position
>>>> to dictate because in practice some AS’s are simply going to internalize
>>>> all policies and we will never successfully force those open.
>>>>
>>>> But with all that in mind, I think the key here is going to be looking
>>>> at what the inputs to the AS are, and how those can be defined in an
>>>> interoperable way for AS’s that can accept them. I think there’s a lot of
>>>> room for innovation and flexibility here that doesn’t break the trust model
>>>> or core use cases. If I have an AS-RS set that won’t accept my favorite
>>>> flavor of policy engine inputs, then I can decide not to use that one. But
>>>> this is a very different question than saying the RS itself needs to accept
>>>> my own AS — and we can’t keep conflating these two models.
>>>>
>>>> So to me, GNAP can support a Zero Trust Architecture by LEVERAGING the
>>>> AS, not by subsuming or eliminating it. It is in fact the AS, not the
>>>> client and not the RS, that will request and consume the results of a
>>>> privacy-preserving zero-trust policy query thing. Anything that happens
>>>> downstream from that is of little concern to the zero-trust components
>>>> because, as you point out, it’s on the “other side” of the line.
>>>>
>>>> I think we got this basic component model pretty right in OAuth: the AS
>>>> and RS and client working together. Where OAuth misses the mark is the
>>>> assumption that the user has to log in to the AS through a webpage and
>>>> interact directly, thereby proving they’re the RO. It’s this latter space
>>>> where I think we can both push innovation and also address the important
>>>> and compelling use cases like the ones you’re bringing.
>>>>
>>>>  — Justin
>>>>
>>>> On Mar 22, 2021, at 2:14 PM, Adrian Gropper <agropper@healthurl.com>
>>>> wrote:
>>>>
>>>> I'm sorry, Justin. As a Resource Owner, I look at the RS trust boundary
>>>> (the dotted line in the diagram) as being the RS. I don't expect any
>>>> visibility into what's going on on the right.
>>>>
>>>> My problem with the framing you propose is that requests are going to
>>>> the RS (or the AS-RS) and I don't want to share my policies with the AS-RS.
>>>> I want to keep the RS and AS-RS as ignorant as possible.
>>>>
>>>> Adrian
>>>>
>>>> On Mon, Mar 22, 2021 at 1:48 PM Justin Richer <jricher@mit.edu> wrote:
>>>>
>>>>> Adrian,
>>>>>
>>>>> What you’re discussing below, in terms of logging in to a site, is not
>>>>> approaching the RS. You are in fact approaching the client, and identifying
>>>>> both the AS and RS to the client. The client is a client *of your
>>>>> identity* in this model, and the RS is part of the identity provider.
>>>>> It’s really important that we don’t conflate the RS and client in this way
>>>>> as it leads to a lot of confusion downstream and a lot of broken trust
>>>>> boundaries.
>>>>>
>>>>> With that model in mind, approaching the “RS" and providing it your
>>>>> identity is really just a case of the “federated login to AS” pattern that
>>>>> we discussed on the WG call. The user here approaches an RS, which has its
>>>>> own AS. To share things from this RS, the RO has to authenticate to the
>>>>> RS’s AS. This particular AS allows the RO to do so using an external
>>>>> identity — in which case, the AS is now a “client” of a separate,
>>>>> disconnected (but layered) delegation. The ultimate client that eventually
>>>>> calls the RS down the way may or may not know about these layers.
>>>>>
>>>>> <PastedGraphic-1.png>
>>>>> This same AS, which is closely tied to the RS and trusted by the RS,
>>>>> might also take in FIDO credentials, or DIDs, or any number of other proof
>>>>> mechanisms. The output of this is an access token the RS trusts, but the
>>>>> input is up to the AS. The RS is not what you’re logging in to.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> On Mar 22, 2021, at 1:28 PM, Adrian Gropper <agropper@healthurl.com>
>>>>> wrote:
>>>>>
>>>>> I too am in favor of avoiding consolidation and correlation. Right
>>>>> now, when I approach a service provider (RS) for the first time, I'm
>>>>> offered the opportunity to identify my persona as: email, sign-in with
>>>>> Google, Facebook, or Apple. I know there are people who try to create
>>>>> one-off email addresses but that is mostly a waste of time.
>>>>>
>>>>> So, along come FIDO2 and DID wallets to the rescue. Now, in theory, I
>>>>> have a way to start out my RS relationship pseudonymously.
>>>>>
>>>>> When I want my resource to be discovered or shared I will post that RS
>>>>> URL including my pseudonym. If I then want to introduce a mediator in front
>>>>> of my AS or messaging service endpoint, I have that option. If I want to
>>>>> keep requests away from the mediator, I would publish an encryption key
>>>>> along with my pseudonym.
>>>>>
>>>>> - Adrian
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 22, 2021 at 9:55 AM Justin Richer <jricher@mit.edu> wrote:
>>>>>
>>>>>> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>>>>>> >
>>>>>> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
>>>>>> >> @Alan Karp <alanhkarp@gmail.com> shared a talk about the
>>>>>> Principle Of Least
>>>>>> >> Authority (POLA) in a recent comment
>>>>>> >>
>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-803099693
>>>>>> >> I recommend it.
>>>>>> >>
>>>>>> >> We might expect a protocol with authorization in the title to use
>>>>>> authority
>>>>>> >> as a core principle. I advocate for a GNAP design that maximizes
>>>>>> the power
>>>>>> >> of the RO, to be seen as a human rights issue when the RO is a
>>>>>> human. This
>>>>>> >> causes me to ask how to combine better security with better human
>>>>>> rights in
>>>>>> >> GNAP.
>>>>>> >>
>>>>>> >> Who should have the least authority in the GNAP design?
>>>>>> >>
>>>>>> >> The AS derives authority as a delegate of the RO. If we ask the RO
>>>>>> to
>>>>>> >> partition limited authority across dozens of different ASs by
>>>>>> domain and
>>>>>> >> function, then we are not using technology to empower the
>>>>>> individual.
>>>>>> >> Probably the opposite, as we introduce consent fatigue and burden
>>>>>> normal
>>>>>> >> people to partition their lives into non-overlapping domains.
>>>>>> >>
>>>>>> >> My experience says we should aim for one AS per persona because
>>>>>> that maps
>>>>>> >> into the way we manage our public and private identities. POLA
>>>>>> would then
>>>>>> >> teach care in keeping ASs and RSs related to work / public
>>>>>> separate from
>>>>>> >> ASs and RSs related to private life so that a policy vulnerability
>>>>>> in our
>>>>>> >> delegation to an AS would have the least likelihood of harm.
>>>>>> >
>>>>>> > Thinking about how least authority/least privilege would apply to
>>>>>> GNAP
>>>>>> > seems like a useful exercise.  I do want to point out some potential
>>>>>> > pitfalls with one-AS-per-persona that we can also be aware of.  If
>>>>>> > one-AS-per-persona becomes one-persona-per-AS as well, then the AS's
>>>>>> > identity in effect also serves as a persona identity and there are
>>>>>> privacy
>>>>>> > considerations to that.  If, on the other hand, the
>>>>>> > multiple-personas-per-AS (presumably corresponding to multiple
>>>>>> humans)
>>>>>> > route is taken, we should consider whether that would lead to
>>>>>> various
>>>>>> > (e.g., market) forces driving consolidation to just a handful of
>>>>>> > super-popular AS services.  That topic is a current matter of
>>>>>> concern to
>>>>>> > some IETF participants.
>>>>>> >
>>>>>>
>>>>>> Hi Ben, big +1 to this. This is something that we discussed ages ago
>>>>>> in the UMA working group, and it’s one of the biggest problems with the
>>>>>> personal AS (and personal data store) model. This kind of thing makes
>>>>>> RS-first trust models really difficult in practice.
>>>>>>
>>>>>> As a strawman, let’s say that I’ve got software that wants to access
>>>>>> my medical information. It calls an RS and requests access, but it hasn’t
>>>>>> been granted anything yet. Now I as the RO have set up the RS so that it
>>>>>> talks to my personal AS, that only I use. In addition to the RS having to
>>>>>> be able to figure out which medical records are being requested from the
>>>>>> context of the unauthenticated request (which means it needs identifiers in
>>>>>> the URL or something similar for the RS to be able to tell, assuming that
>>>>>> it protects data for more than one person). So this client software doesn’t
>>>>>> know who I am and doesn’t know my medical record information, makes a
>>>>>> completely unauthorized request to the RS, and the RS says “Go to Justin’s
>>>>>> personal AS to get a token”. The client can now make a direct correlation
>>>>>> between the data that’s being protected at the RS and the person running
>>>>>> the AS that protects it. Importantly, this client makes this call with no
>>>>>> prior relationship to the RS and no really auditable way to track it down
>>>>>> after the fact. This is a design feature in the good case, and terrifying
>>>>>> in the bad case.
>>>>>>
>>>>>> If the RS instead says “welcome to Medicine Doctor RS, please talk to
>>>>>> the Medicine Doctor AS to get access”, we haven’t exposed anything at all.
>>>>>> And from the perspective of both the patient and the RS, this is more
>>>>>> privacy-preserving, and it’s really the least surprising option. Once the
>>>>>> client gets to the AS, it can start a negotiation of figuring out who the
>>>>>> RO is for the information being accessed.
>>>>>>
>>>>>> On top of this, the usability expectations of people managing their
>>>>>> own AS, or set of AS’s for multiple personas to keep things separate, is a
>>>>>> huge burden. Even in the tech community, I know people who can’t reliably
>>>>>> manage more than one email address for different purposes. I wouldn’t
>>>>>> expect my partner to do that — they have trouble enough balancing all the
>>>>>> logins and sessions required for different kids remote schooling, I
>>>>>> couldn’t imagine them having to understand all the requirements for
>>>>>> managing multiple authorization servers and associated policies. I also
>>>>>> don’t expect any person to “manage keys” — I’ve been on the internet for
>>>>>> decades and I can barely keep tabs on my GPG keys, and only use them when I
>>>>>> am forced to. This is exactly the kind of “market pressure” that I think
>>>>>> Ben mentions above, people will just want to outsource that to someone
>>>>>> else, and the reality will be a few popular providers.
>>>>>>
>>>>>> In which case, we could end up doing a ton of work to allow an RS
>>>>>> choice only to end up with a world where the RS ends up making a limited
>>>>>> choice anyway. We see how that plays out with OpenID Connect — RP’s could
>>>>>> allow arbitrary IdPs but they choose Google because it works and that’s
>>>>>> where the users are. (And that’s not to say anything of the proprietary
>>>>>> OIDC-like protocols, but that’s another discussion).
>>>>>>
>>>>>> For further reading on these topics, I recommend both “Why Johnny
>>>>>> Can’t Encrypt” and “Why CSCW Systems Fail”.
>>>>>>
>>>>>> So what does this have to do with GNAP? I think we can be clear-eyed
>>>>>> on what kinds of expectations we have for the participants. If we expect
>>>>>> users (RO’s) to have to set up the AS-RS relationship, or expect them to
>>>>>> carry their AS, or manage their personal keys — I think we’ve lost the
>>>>>> battle for relevance.
>>>>>>
>>>>>>  — Justin
>>>>>
>>>>>
>>>>>
>>>> --
>>> TXAuth mailing list
>>> TXAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>