Re: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49)

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 10 February 2020 17:55 UTC

Return-Path: <mcr@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 BD94912001B for <anima@ietfa.amsl.com>; Mon, 10 Feb 2020 09:55:55 -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 dSpR-F9-1SIB for <anima@ietfa.amsl.com>; Mon, 10 Feb 2020 09:55:53 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C00C12001A for <anima@ietf.org>; Mon, 10 Feb 2020 09:55:53 -0800 (PST)
Received: from dooku.sandelman.ca (ip5f5bd76d.dynamic.kabel-deutschland.de [95.91.215.109]) by relay.sandelman.ca (Postfix) with ESMTPS id C79BC1F459 for <anima@ietf.org>; Mon, 10 Feb 2020 17:55:51 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3308A1A29B4; Mon, 10 Feb 2020 18:55:51 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org
In-reply-to: <anima-wg/constrained-voucher/issues/49@github.com>
References: <anima-wg/constrained-voucher/issues/49@github.com>
Comments: In-reply-to Esko Dijk <notifications@github.com> message dated "Mon, 10 Feb 2020 08:00:33 -0800."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Mon, 10 Feb 2020 18:55:51 +0100
Message-ID: <1272.1581357351@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/jyExRlnPKFiBEF5uZaJUhbYVgG4>
Subject: Re: [Anima] [anima-wg/constrained-voucher] Unclear how MASA obtains Domain CA cert for pinning, in case of COSE-signed Voucher Request (#49)
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: Mon, 10 Feb 2020 17:55:56 -0000

In https://github.com/anima-wg/constrained-voucher/issues/49, Esko Dijk asks:

> In BRSKI (5.5.2  MASA pinning of registrar) it is clear how the MASA can
> get the complete cert chain of the Registrar from the CMS signature
> structure. The Registrar's Domain CA cert is included in there and is used
> as the pinned domain cert in the Voucher.  However, when we now use
> COSE-signed Voucher Request by the Registrar, the Registrar's Domain CA
> cert is not included in the COSE-sign structure so the MASA cannot
> "extract" it per BRSKI 5.5.2.

> It would be good to make more explicit how the MASA should extract the
> Registrar's Domain CA cert in this case (Note: the Domain CA could be the
> Registrar itself but not necessarily.)  The obvious candidate is to get it
> from the DTLS or TLS handshake that Registrar performs with MASA. This is
> already hinted at in the text in section 6.1.3 / 6.2.3 inside the YANG
> module description "... it is wasteful ... " but that is not quite
> clear. When Registrar is using COSE signing the MASA *has* to get the
> certificate from the handshake if the MASA wants to pin the entire
> certificate in the Voucher, there seems to be no other option. Section
> 6.3.2 now mentions "out of band" distribution but that's not very clever if
> you want automated bootstrapping - it needs to go all in-protocol /
> in-band.

> It should be noted also that this modifies the BRSKI requirement section
> 5.5.2 on how the pinned Domain CA cert is obtained.

In the more constrained cases, the Registrar is identified by a Raw Public
Key. [This works in DTLS and will work in LAKE by design]
This is what should be pinned by the MASA, because that's what the pledge saw.

If you are using a certificate chain for the Registrar end point, the MASA
does not have to pin the Domain CA, it can instead pin the Registrar
certificate, since again, that's what the pledge saw (and signed).

If you want us to define a way to pin the domain CA, then I think that right
answer is to pass that entire chain along to the Pledge in the BRSKI-EST
channel in the DTLS header, and have the pledge sign that entire object.
This wouldn't be very constrained, so I am not sure why one would do this
rather than using TLS in that case.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-