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

Justin Richer <jricher@mit.edu> Mon, 22 March 2021 17:49 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 1464B3A0EE8 for <txauth@ietfa.amsl.com>; Mon, 22 Mar 2021 10:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.405
X-Spam-Level:
X-Spam-Status: No, score=0.405 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 P9JIU7JXK7F7 for <txauth@ietfa.amsl.com>; Mon, 22 Mar 2021 10:48:57 -0700 (PDT)
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 191203A0EDB for <txauth@ietf.org>; Mon, 22 Mar 2021 10:48:56 -0700 (PDT)
Received: from [192.168.1.22] (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 12MHmnh3013707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Mar 2021 13:48:50 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <953A4B2A-6064-4E16-A6FA-B97FBE770B11@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F758942-3A18-489D-8070-0E450D7B1F13"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 22 Mar 2021 13:48:48 -0400
In-Reply-To: <CANYRo8gMQYJXcb0FU2VCVcdbBLsopZ5Wfyo3hd1Pd5tmOSs0SA@mail.gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Alan Karp <alanhkarp@gmail.com>, GNAP Mailing List <txauth@ietf.org>, Mark Miller <erights@gmail.com>
To: Adrian Gropper <agropper@healthurl.com>
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com> <20210321171800.GT79563@kduck.mit.edu> <6772CFFC-7411-4BBE-948B-8271654C0FE9@mit.edu> <CANYRo8gMQYJXcb0FU2VCVcdbBLsopZ5Wfyo3hd1Pd5tmOSs0SA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/nPBrAOPwfttpZBJGKjlNpTZ_qh4>
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: Mon, 22 Mar 2021 17:49:02 -0000

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. 


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 <mailto:jricher@mit.edu>> wrote:
> On Mar 21, 2021, at 1:18 PM, Benjamin Kaduk <kaduk@mit.edu <mailto:kaduk@mit.edu>> wrote:
> > 
> > On Sat, Mar 20, 2021 at 01:07:42AM -0400, Adrian Gropper wrote:
> >> @Alan Karp <alanhkarp@gmail.com <mailto: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 <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