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

Alan Karp <alanhkarp@gmail.com> Sat, 20 March 2021 17:58 UTC

Return-Path: <alanhkarp@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 2F4283A2753 for <txauth@ietfa.amsl.com>; Sat, 20 Mar 2021 10:58:07 -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 9sD5M8_SBgv2 for <txauth@ietfa.amsl.com>; Sat, 20 Mar 2021 10:58:04 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 556D23A2752 for <txauth@ietf.org>; Sat, 20 Mar 2021 10:58:04 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id 7so6395475qka.7 for <txauth@ietf.org>; Sat, 20 Mar 2021 10:58:04 -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=nTTpfGwLlcW5SbV0jOcm2o7hN/wQbJ4C3+0IyH3sRyM=; b=OJBos3430kiGU4EdK9ieHucfO77DoRZwTYzvHEVKHzbDSM6d2NFgAErw5fjgLlLRTt Wh/uWrjoJt0cxiTGUOyOoMhP0mdzHNkp7IH9zlnUWhVFzxOTtgRD4v1MlEeFo6mcgocJ PoDYQvsouS0U3PyYDpmityA0HCPQu+62H+eIBFvncv/iAOEk3AwAlJyNPox80HF/TfCs RY7AkZx/K4PrQnczYWY3lRE2NDMtmoENg6+A0yBRM2ir9LKoRGZtjGVue1fF6IX3Mqus +n47skwfBnT76Mo2D0lWMx4oymiav0OtKkE5K+aYsklexdm9d9S+iKsfrvVyK4PGnWcr djPQ==
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=nTTpfGwLlcW5SbV0jOcm2o7hN/wQbJ4C3+0IyH3sRyM=; b=uFA30Ay3ByHzoaByKQ+q9IvP/IZO3LUjbUtuQ/FHCra1kTOzoGm/ViVAFO2vhZzD7Q jgYvzRU3Vll3quJvKPy+GBK/a6vADtrk5KCl+5/FJEFOWU+hw7l2DszAEvvLnG5nHSqp 5poPldZF5yINCchllu1AobZtBqOI+ZEBIkaZ873ZCaHXgaMqGFGjoiQzmwc7dJkWgHt0 7+jvzBODg7qNH5fT1s71MCL93JlZglfXnVdEH3l3BeD+1oVxdMheDe9EFZaSkeRxpCxT oUYEU5Mtwhz/FFaBp78rg0sBeTxFVimKsMvHFZuI4uQigfkSZAeAjcXhzWttQdFOcUOQ bDMQ==
X-Gm-Message-State: AOAM530P+YwNwAbc7ftBZ39PKtkzdEu8KV74o4f3apjfvlBuNiEOfILP CF6G3zG5khl2LpgB6UoYHvy5ENWIhWVf4U7fHXg=
X-Google-Smtp-Source: ABdhPJyUSkLBLgHo9xKsePQzv9HcGFBMPXXVdf4UijlE0pCqV68F+Z37wZ7Qxd5rnM7T0mB/xTiEH6F+DgpUl7dBCH4=
X-Received: by 2002:a37:2785:: with SMTP id n127mr3998799qkn.320.1616263082815; Sat, 20 Mar 2021 10:58:02 -0700 (PDT)
MIME-Version: 1.0
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <CAM8feuSUmfL8thipf=hV-QHtkuy-Zh5txbAspvO9vxm6P3MgZg@mail.gmail.com> <CANYRo8gPcPqjmonr_bJOgF_bS5E-o-o2ZVN3WfQCwbnwv0jPQw@mail.gmail.com> <CAM8feuTS5SCLVdO0ZZ-RJOWV08=gEeAvC8hrdUD0c9L8AHjYtQ@mail.gmail.com>
In-Reply-To: <CAM8feuTS5SCLVdO0ZZ-RJOWV08=gEeAvC8hrdUD0c9L8AHjYtQ@mail.gmail.com>
From: Alan Karp <alanhkarp@gmail.com>
Date: Sat, 20 Mar 2021 10:57:51 -0700
Message-ID: <CANpA1Z1-9yCPMaY53LQYT9jEsGif-kdZ6RtCxL+z2K8sUpKQHQ@mail.gmail.com>
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: Adrian Gropper <agropper@healthurl.com>, GNAP Mailing List <txauth@ietf.org>, Mark Miller <erights@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ea32a005bdfb9289"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/BLCKzYUMdBhmnWblk7FNdR80sRE>
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: Sat, 20 Mar 2021 17:58:07 -0000

You are close on the flow.  The only change is that the RO does not need to
inform the RS that the RO is using an AS.

The flow is described in our Zebra Copy tech report,
https://www.hpl.hp.com/techreports/2007/HPL-2007-105.pdf, which, by the
way, uses non-opaque tokens.  (Don't worry about the length.  The last 60
pages are a walkthrough of the reference implementation.)  I believe that
example is closer to the GNAP use cases than the one in the talk Adrian
mentioned.  Also, I hope the different terminology isn't too confusing.

   1. The owner of RS delegates a set of rights to the administrator of the
   service, AS-RS.
   2. RO contacts AS-RS and gets back a capability authorizing a specific
   set of methods at RS.
   3. RO can use that capability to invoke RS with any of the authorized
   permissions.
   4. RO can delegate a subset of those rights to a client, who can then
   invoke the RS with any of the authorized permissions.
   5. RO can delegate a subset of those rights to an AS-RO.
   6. AS-RO can delegate a subset of those rights to a client based on a
   policy specified by RO.
   7. That client can invoke RO with any of the authorized permissions.

Note that AS-RS doesn't need to know anything about the various
delegatees.  It just needs to verify that the delegations are valid.

Responsibility tracking follows those steps.  AS-RS will hold RO
responsible for all uses of any token delegated from the one AS-RS gave
RO.  Each delegator is responsible for knowing who to hold responsible for
each of its delegations.  Say there's a $100 penalty for misuse, and the
client in step 6 does something bad.  AS-RS will collect $100 from RO.
It's up to RO to collect $100 from AS-RO and up to AS-RO to collect from
the client.

This approach is the only thing that makes sense.  What would RS or AS-RS
do with the information that RO delegated to AS-RO?  AS-RS has no way of
collecting from AS-RO; only RO does.

--------------
Alan Karp


On Sat, Mar 20, 2021 at 3:52 AM Fabien Imbault <fabien.imbault@gmail.com>
wrote:

> Thanks for the description.
>
> Trying to summarize what a capability  flow would look like following
> those ideas:
>
> 1) RS issues a capability for the RO. For instance "view and download
> photo".
>
> 2) RO can delegate that capability (or an attenuated version) to the AS.
> Say "view photo", possibly with some ambient conditions.
> If the RO further wants to choose between a list of possible ASs, the RO
> would have to signal its choice to the RS, which would then have to signal
> it to the client (what we had called RS preflight in some discussions). So
> the AS-RS relationship would be mediated via the RO (or more precisely its
> agent).
>
> 3) a core GNAP negociation takes place with the AS (traditional photo
> example).
>
> Is that correct? Do not hesitate to correct me if I didn't accurately
> capture what you said.
> (I volontarily put DID aside for now)
>
> Steps occurring before 3 are optional (for reasons discussed before and
> also because we can't assume all RSs would be able to support that).
>
> Fabien
>
> Le sam. 20 mars 2021 à 10:49, Adrian Gropper <agropper@healthurl.com> a
> écrit :
>
>> Hi Fabien,
>>
>> Yes, it’s optional and adding meaningful options is one way to consider
>> the ethical imperative http://www.cybsoc.org/heinz.htm
>>
>> If I understand Alan’s teachings, the RS has the option to either issue
>> one or more capabilities to the RO or to store some identity-related
>> information about the RO such as the DID of the RO and, by reference, the
>> AS service endpoint controlled by that DID.
>>
>> Given some capabilities, the RO can either deal with them manually or
>> hand them to an AS. Either way, the RS has no idea of the RO’s choice until
>> it receives a token from some end user. This seems to be what the Letters
>> of Transit in Casablanca were all about.
>>
>> If, on the other hand, the RO chooses to give 5e RS a DID, a
>> self-sovereign identifier, instead of taking some capabilities, then the RS
>> has the expectation  to trust tokens signed by that DID.
>>
>> It’s my hope that GNAP can allow an ethical RS to offer both choices to
>> the RO.
>>
>> Adrian
>>
>>
>> On Sat, Mar 20, 2021 at 4:23 AM Fabien Imbault <fabien.imbault@gmail.com>
>> wrote:
>>
>>> Hi Adrian,
>>>
>>> Calling to one AS per persona can only be optional, as we have no way,
>>> and no wish, of knowing all the identities used by the RO.
>>>
>>> I think this relates to the idea of the RO having its own distinct
>>> agent, but I still don't understand how that would work (even re-reading
>>> the thread in issue 145). Could you elaborate?
>>>
>>> Thxs
>>> Fabien
>>>
>>>
>>> Le sam. 20 mars 2021 à 06:08, Adrian Gropper <agropper@healthurl.com> a
>>> écrit :
>>>
>>>> @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.
>>>>
>>>> Beyond that fairly obvious principle, we could spread our interactions
>>>> among as many services as possible. We already do this when we spread
>>>> assets across multiple banks, internet services across redundant platforms,
>>>> or we use LinkedIn, Twitter, and Facebook with limited overlap in social
>>>> graphs.
>>>>
>>>> At the next level down, we want to manage resources at each RS using
>>>> least authority in order to make AS policy vulnerabilities easier to spot
>>>> and debug. My AS might get multiple capabilities or access to scopes from
>>>> an RS, each one carefully labeled with its intended uses so that the policy
>>>> engine of my AS could be structured to consider requests relative to only
>>>> one capability or scope family at a time. For example, in issuing health
>>>> record authorizations, I might separate the behavioral health capabilities
>>>> from capabilities to access the physical parts of my record at a given
>>>> hospital's GNAP RS API.
>>>>
>>>> Lastly, at the level of attenuation, I would choose a relationship with
>>>> RSs that issue to me capabilities that can be attenuated not only by my AS
>>>> but also by the requesting parties that receive them as part of an access
>>>> token.
>>>>
>>>> Adrian
>>>>
>>>>
>>>> --
>>>> TXAuth mailing list
>>>> TXAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>