Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt

From: [email-masked]
Date: Thu, 02 Apr 2020 13:08:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF.

        Title           : Bootstrapping Remote Secure Key Infrastructures (BRSKI)
        Authors         : Max Pritikin
                          Michael C. Richardson
                          Toerless Eckert
                          Michael H. Behringer
                          Kent Watsen
	Filename        : draft-ietf-anima-bootstrapping-keyinfra-40.txt
	Pages           : 122
	Date            : 2020-04-02

Abstract:
   This document specifies automated bootstrapping of an Autonomic
   Control Plane.  To do this a Secure Key Infrastructure is
   bootstrapped.  This is done using manufacturer-installed X.509
   certificates, in combination with a manufacturer's authorizing
   service, both online and offline.  We call this process the
   Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
   Bootstrapping a new device can occur using a routable address and a
   cloud service, or using only link-local connectivity, or on limited/
   disconnected networks.  Support for deployment models with less
   stringent security requirements is included.  Bootstrapping is
   complete when the cryptographic identity of the new key
   infrastructure is successfully deployed to the device.  The
   established secure connection can be used to deploy a locally issued
   certificate to the device as well.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-40
https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-40

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-40

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Esko Dijk <[email-masked]>
Date: Fri, 3 Apr 2020 19:11:03 +0000

Thanks Michael for this update, 

The new text looks good now. I was still wondering about the pg 12 requirement in RFC 8366 ; which amounts  to:
    The [domain certificate supplied to the pledge separately by the bootstrapping protocol] MUST have [pinned-domain-cert] somewhere in its chain of certificates.

It looks like the "domain certificate" here is then not meant as (1) the EE certificate that the EST server will hand to the Pledge later on (as I thought), but rather (2) the Registrar's certificate that is supplied to the Pledge in the initial handshake.
If one interprets it like (1) then BRSKI may violate the requirement; if one interprets it to be (2) then all is fine.

A few remaining nits found during reading:

"as an trust anchor" -> as a trust anchor
"how a the MASA"
"impementations" -> implementations
"identifies a Registrar by the "pinned-domain-cert" -> missing full stop (period) at end of sentence.
"described in [I-D.ietf-anima-autonomic-control-plane]" -> missing full stop (period) at end of sentence.

Best regards
Esko

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, April 2, 2020 22:09
To: [email-masked]
Cc: [email-masked]
Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-40.txt

Abstract:

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Apr 2020 20:20:43 -0400

Esko Dijk <[email-masked]> wrote:
    > The new text looks good now. I was still wondering about the pg 12
    > requirement in RFC 8366 ; which amounts  to:

    > The [domain certificate supplied to the pledge separately by the
    > bootstrapping protocol] MUST have [pinned-domain-cert] somewhere in its
    > chain of certificates.

    > It looks like the "domain certificate" here is then not meant as (1)
    > the EE certificate that the EST server will hand to the Pledge later on
    > (as I thought), but rather (2) the Registrar's certificate that is
    > supplied to the Pledge in the initial handshake.

Can you explain "later on"  here?

The Registrar's TLS Server Certificate could be a different PKI hierarchy
than the resulting PKI.

    > If one interprets it like (1) then BRSKI may violate the requirement;
    > if one interprets it to be (2) then all is fine.

    > A few remaining nits found during reading:

Thanks. I have updated my copy of the XML, and I'll pass this on to the RFC-editor.
Nothing is going forward until the ACP LC ends and the IESG does it's reviews.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Esko Dijk <[email-masked]>
Date: Wed, 15 Apr 2020 15:57:57 +0000

>  Can you explain "later on"  here?

With 'later on' I meant the moment of the first distribution of a new domain certificate to Pledge, as part of a bootstrap process. That is, the phase immediately following the phase of sending the voucher to the Pledge - typically done using EST. 

> The Registrar's TLS Server Certificate could be a different PKI hierarchy

So the interpretation (1) above must be incorrect, as it would force EST to use the same PKI hierarchy, with the pinned domain cert always somewhere in the hierarchy of the EST-issued domain cert.

The piece of text in RFC 8366 inside the "leaf pinned-domain-cert { ... }" YANG is confusing me because most mentions of "domain certificate" in the RFC refer to the certificate that is being pinned by the voucher. (E.g. 4, 5.3, 7.3) Called the 'pinned domain certificate' or 'domain certificate' for short. 
But in this particular text "domain certificate" refers to the Registrar's certificate - and the term "this certificate" refers to the pinned domain certificate.

If a different PKI hierarchy is used by the EST server (i.e. the pinned-domain-cert will *not* be in the cert chain of the cert that the EST server issues), that seems to imply that the EST server can assign the Pledge to an arbitrary domain, even the domain of another customer. 
That seems weird, since the Registrar authenticates itself to MASA as "I'm in domain X / customer X" and then the same Registrar in its EST server role assigns the Pledge to "domain / customer Y". And the MASA doesn't know about this; it logs the Pledge to "domain X".

Esko