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

Benjamin Kaduk <kaduk@mit.edu> Sun, 21 March 2021 17:18 UTC

Return-Path: <kaduk@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 587943A1157 for <txauth@ietfa.amsl.com>; Sun, 21 Mar 2021 10:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.403
X-Spam-Level:
X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[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] 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 Qbb-j6kNmTmt for <txauth@ietfa.amsl.com>; Sun, 21 Mar 2021 10:18:14 -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 E285B3A1154 for <txauth@ietf.org>; Sun, 21 Mar 2021 10:18:13 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12LHI0Xe029890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Mar 2021 13:18:06 -0400
Date: Sun, 21 Mar 2021 10:18:00 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Adrian Gropper <agropper@healthurl.com>
Cc: GNAP Mailing List <txauth@ietf.org>, Alan Karp <alanhkarp@gmail.com>, Mark Miller <erights@gmail.com>
Message-ID: <20210321171800.GT79563@kduck.mit.edu>
References: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANYRo8jBZFVWyvAgVSWSmnuC+i1NaEkJEGWextzGB0xNFnD9fA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/1udILtVaA-GMasIzkoBJDs7dQaA>
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: Sun, 21 Mar 2021 17:18:15 -0000

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.

Thanks,

Ben