[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
- [Anima] Benjamin Kaduk's Yes on draft-ietf-anima-… Benjamin Kaduk via Datatracker
- Re: [Anima] Benjamin Kaduk's Yes on draft-ietf-an… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Yes on draft-ietf-an… Benjamin Kaduk
- [Anima] issues with using public/WebPKI anchors f… Michael Richardson