Subject: [Anima] a multiplicity of pinned certificates

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Dec 2018 15:36:00 -0000

Kent Watsen <[email-masked]> wrote:
    > Separately, as long as we're raising issues with RFC 8366, I strongly
    > believe that the pinned-domain-certificate should've be a list of
    > certificates.  Or, in crypto-types [1] terms, a trust-anchor-cert-cms,
    > not a trust-anchor-cert-x509.  To enable the pinned-domain-certificate
    > for an intermediate CA to be a chain that includes the root self-signed
    > certificate, thus supporting tooling unable to validate partial-chains.

I believe that a future version could make this change relatively easily,
particularly if we do it quickly. Destinguishing between arrays of 1-element
and single-items isn't that difficult in the serializations we have.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Dec 2018 08:42:33 +1300

A small clarification below...

On 2018-11-30 16:45, Brian E Carpenter wrote:
> On 2018-11-30 15:26, Michael Richardson wrote:
>>
>> https://github.com/anima-wg/anima-bootstrap/issues/88
>>
>>> What happens if the MASA refuses to provide a voucher, or provides a wrong
>>> voucher? Can the MASA be used to restrain commerce with specific countries?
>>> Is that a feature or a bug?
>>
>> BRSKI does not eliminate other mechanisms of enrolling devices.
>> If the vendor eliminates all other ways of enrolling devices, then yes, it
>> could be used as a restraint.  But, many vendors already restrict which
>> firmware can be used in which countries, and by which customers.
>>
>> It's a feature that the MASA can be used to defer theft.
>> It's a bug that the MASA can be used to prevent resale.
>> I'd love to resolve the situation, but I don't know how.
> 
> The feature is good. The bug is a regulatory issue; IANAL
> but in any case (as with DRM) it's completely outside the IETF's
> control.
> 
> Imagine a military device in such a context. You pull the trigger
> and the gun pops up a window saying "Not authorised for use
> in Elbonia." From most viewpoints, that's a Good Thing.

To be clear, the gun won't shoot because it failed to enrol
when the Elbonian army deployed it. BRSKI happens, or doesn't
happen, at enrolment time, not later.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Dec 2018 23:53:47 -0000

Brian E Carpenter <[email-masked]> wrote:
    >> The authors seriously believe that this will result in an attempt to
    >> boil the ocean.  Yes, BRSKI is exciting for many and opens many doors,
    >> but in the context of the *ANIMA* Charter, we strongly think that this
    >> document should leave the oceans alone, and deal only with the ANIMA
    >> ACP usage.

    > Yes, violent agreement. From all the interest outside ANIMA, the basic
    > idea of BRSKI is a big hit and will be re-used in other contexts. I
    > think a strong statement about the specific scope of *this* document
    > belongs in the Abstract and Introduction, with a comment that variant
    > usages of BRSKI in other scenarios will be documented separately.

Brian, these are my proposed changes to the abstract, intro,
and adding a section on ACP Applicability.  I think that there is probably
more to say there.

This has become issue #116.

diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
index 78ce2a3..e705904 100644
--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -82,19 +82,21 @@
 
     <abstract>
       <t>
-        This document specifies automated bootstrapping of a remote secure
-        key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in
-        combination with a manufacturer's authorizing service, both online and offline.
+        This document specifies automated bootstrapping of an Autonomic
+        Control Plane.  To do this a remote secure
+        key infrastructure (BRSKI) is created using manufacturer installed
+        X.509 certificate, in combination with a manufacturer's authorizing
+        service, both online and offline. 
         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 lower security models,
         including devices with minimal identity, is described for legacy reasons
 
@@ -103,7 +105,22 @@
       <t>
         BRSKI provides a solution for secure zero-touch (automated) bootstrap of
         virgin (untouched) devices that are called pledges in this
-        document. These pledges need to discover (or be discovered by) an
+        document.
+      </t>
+      
+      <t>
+        This document primarily provides for the needs of
+        the ISP and Enterprise focused ANIMA 
+        <xref target="I-D.ietf-anima-autonomic-control-plane">Autonomic 
+        Control Plane (ACP)</xref>.  Other users of the BRSKI protocol
+        will need to provide separate applicability statements that
+        include privacy and security considerations appropriate to that
+        deployment.  Section <xref target="acpapplicability" /> explains the details
+        applicability for this the ACP usage.
+      </t>
+      
+      <t>
+        This document describes how pledges discover (or be discovered by) an
         element of the network domain to which the pledge belongs to perform
         the bootstrap.  This element (device) is called the
         registrar.  Before any other operation, pledge and registrar need to

@@ -2755,6 +2772,64 @@ Reference: [This document]
 	  </t>
 	</section>
     </section>
+    <section anchor="acpapplicability" title="Applicability to the Autonomic
+                                              Control Plane">
+      <t>
+        This document provides a solution to the requirements for secure
+        bootstrap set out in <xref target="RFC8368">Using an Autonomic Control Plane for
+        Stable Connectivity of Network Operations, Administration, and
+        Maintenance </xref>, 
+        <xref target="I-D.ietf-anima-reference-model" >A Reference Model for
+        Autonomic Networking</xref> and specifically the 
+        <xref target="I-D.ietf-anima-autonomic-control-plane">An Autonomic
+        Control Plane (ACP)</xref>, section 3.2 (Secure Bootstrap), and
+        section 6.1 (ACP Domain, Certificate and Network).
+      </t>
+      <t>
+        The protocol described in this document has appeal in a number of
+        other non-ANIMA use cases.  Such uses of the protocol will be
+        deploying into other environments with different tradeoffs of
+        privacy, security, reliability and autonomy from manufacturers.
+        As such those use cases will need to provide their own applicability
+        statements, and will need to address unique privacy and security
+        considerations for the environments in which they are used.
+      </t>
+      <t>
+        The autonomic control plane that this document provides bootstrap
+        for is typically a medium to large Internet Service Provider
+        organization, or an equivalent Enterprise that has signficant layer-3
+        router connectivity.  (A network consistenting of primarily layer-2
+        is not excluded, but the adjacencies that the ACP will create and
+        maintain will not reflect the topology until all devices participate
+        in the ACP).
+      </t>
+      <t>
+        As specified in the ANIMA charter, this work "..focuses on
+        professionally-managed networks."  Such a network has an operator
+        and can do things like like install, configure and operate the
+        Registrar function.  The operator makes purchasing decisions
+        and is aware of what manufacturers it expects to see on it's
+        network.
+      </t>
+      <t>
+        Such an operator also is capable of performing the traditional
+        (craft serial-console) based bootstrap of devices. The zero-touch
+        mechanism presented in this and the ACP document represents a
+        signficiant efficiency: in particular it reduces the need to
+        put senior experts on airplanes to configure devices in person.
+        There is a recognition as the technology evolves that not every
+        situation may work out, and occasionally a human still still have to
+        visit.
+      </t>
+      <t>
+        The BRSKI protocol is going into environments where there have
+        already been quite a number of vendor proprietary management
+        systems.  Those are not expected to go away quickly, but rather to
+        leverage the secure credentials that are provisioned by BRSKI.  The
+        connectivity requirements of said management systems are provided
+        by the ACP.
+      </t>
+    </section>
     <section anchor="privacyconsiderations" title="Privacy Considerations">
       <section title="MASA audit log">
       <t>
@@ -3292,6 +3367,7 @@ Reference: [This document]
 
       <?rfc include="reference.I-D.ietf-anima-autonomic-control-plane" ?>
       <?rfc include="reference.RFC.8366" ?>
+      <?rfc include="reference.RFC.8368" ?>
       <?rfc include="reference.I-D.ietf-anima-grasp" ?>
 
       <reference anchor="IDevID"

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 3 Dec 2018 13:06:33 +1300

> and adding a section on ACP Applicability.  I think that there is probably

Perhaps, but I think these changes clarify the scope correctly.

Thanks
     Brian

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Dec 2018 09:22:59 -0000

> Perhaps, but I think these changes clarify the scope correctly.

My sense in writing the words was that there were more words needed.
But I didn't know what else I could nail down scope-wise, so I stopped.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 3 Dec 2018 17:00:14 +0000

> and single-items isn't that difficult in the serializations we have.

By "future version", do you mean an rfc8366bis?

If open to that, I could draft an I-D...

K.