[Anima] issues with using public/WebPKI anchors for ACP

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 01 November 2020 20:53 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294AD3A0100 for <anima@ietfa.amsl.com>; Sun, 1 Nov 2020 12:53:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 vUt4-izTVRHq for <anima@ietfa.amsl.com>; Sun, 1 Nov 2020 12:53:57 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51EF3A00E5 for <anima@ietf.org>; Sun, 1 Nov 2020 12:53:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CA19F389A0 for <anima@ietf.org>; Sun, 1 Nov 2020 16:00:53 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JUtsPdlpWYfZ for <anima@ietf.org>; Sun, 1 Nov 2020 16:00:53 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 30EFE3899F for <anima@ietf.org>; Sun, 1 Nov 2020 16:00:53 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D40441D5 for <anima@ietf.org>; Sun, 1 Nov 2020 15:53:54 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org
In-Reply-To: <20201028174825.GZ48111@faui48f.informatik.uni-erlangen.de>
References: <160159178470.16845.16995175102690434365@ietfa.amsl.com> <21081E12-D74B-4BF1-830F-180098F984A9@cisco.com> <12822.1602181920@localhost> <20201027151445.GM48111@faui48f.informatik.uni-erlangen.de> <11303.1603828122@localhost> <7D699D2F-FBF2-4111-B8AF-4EEC0CBC53DE@cisco.com> <2915.1603906633@localhost> <20201028174825.GZ48111@faui48f.informatik.uni-erlangen.de>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sun, 01 Nov 2020 15:53:54 -0500
Message-ID: <15627.1604264034@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/QXoXxXuoDNFPdE2P_nAfBv_SFGw>
Subject: [Anima] issues with using public/WebPKI anchors for ACP
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Nov 2020 20:53:59 -0000

A concern came up in a private thread about whether or not a Registrar could
use WebPKI [that is, a public anchor] via ACME (or other interface), within an *ACP* context.

For instance, there are efforts to use ACME with BRSKI:
   draft-ietf-acme-integrations   --- approaching WGLC
   draft-friel-acme-subdomains    -- yet to be adopted, simplifies integrations

These efforts are not aimed at enabling an ACP, but rather just onboarding of
devices.  Avoiding the need for a PKI in a SOHO is a rather useful thing.

The ACP can use a suborbinate-CA or a private-CA equally well.
The distinction between them is whether another level of CA has signed the
anchor certificate, or whether it's self-signed.  As long as *that* level
is what is returned by the EST /cacerts return, then the ACP works just fine.

The ACP fundamentally uses "if X signed Y, then Y is my friend" logic.
Some might say that it is not the best form of authorization for the overlay,
but it is simple, and there aren't a lot of other decentralized authorization
systems which are implemented already into IPsec management systems.

The problem with the above policy is that it fails if the anchor point
is a public trust anchor.  In that case, any entity that can get a
certificate signed by the same trust anchor can probably join the ACP overlay.

We could have made the ACP trust mechanism slightly more sophisticated; we
have the ACP domain in the otherName.  But, we have no way to know what
checks a public anchor will make when its sets the otherName.
At this point, most public anchors will not put anything they can not verify
in the otherName, so it will in fact just fail.

Some Enterprises have subordinate-CAs (aka "Enterprise CA") which chain up to
a public trust root.  The trend (which may be universal at this point due to
CABForum policy), is for those subordinate CAs to be operated by the parent
CA in an outsourced fashion.  Those CAs may be sign anything the Enterprise
says, but only what the Enterprise says.  They aren't public CAs.

My understanding is that they still may not sign iPAdress SANs for reserved
networks, or dNSName for internal names.  The servers and names involved
do not have be visible from the Internet.  So one can have:
   my.private.server.example.com IN A 10.1.1.3

with a dNSName of "my.private.server.example.com", so long as "example.com" is a public (unique) name.
If you have
   my.private.server.example.com IN AAAA 2001:db8::1234

and you want an iPAddress of 2001:db8::1234, you can have that too, since
that's not a reserved IP address, even if 2001:db8::1234 is never visible on
the Internet.

One of the reasons I wrote draft-richardson-anima-registrar-considerations
was so to capture some of my thinking about how different networks can/should
operate their BRSKI Registrar.

If the WG wants to discuss different ways of operating/building a registrar,
perhaps the WG would like to take another look at the above document.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide