Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    > Overall:

    > a) Requirements about EST:

    > - The introduction says: "Integration with a complete EST enrollment is
    > optional but trivial"
    > - 5.8.3 says "The Pledge MUST request a new client certificate".
    > - 1.4 says "bootstrapped devices have a common trust anchor and a certificate
    > has optionally been issued from a local PKI

    > a) The text needs to be made consistent across all places where requirements
    > are defined. I have in general no strong opinion how "optional" the text should
    > say EST operations are, BUT consider he following points:

    > b) We need a complete list of BRSKI requirements for ANI devices, where EST
    > operation requirements are made stronger. I suggest a separate subsection at an
    > appropriate place so that "ANI requirements" shows up in the table of contents:

    > Section X.Y.Z Requirements for ANI devices:

    > For BRSKI on ANI Devices (ANI = BRSKI + ACP), EST operations is mandator.
    > The ANI pledge MUST perform
    > - "CA Certificates Request",
    > - "CSR Attributes"
    > - "Client Certificate Request"
    > - "Enrollment status Telemetry"
    > The ANI registrar MUST support BRSKI and these EST operations.
    > All ANI devices SHOULD support the BRSKI proxy function.

I've done the following:

+     1.5.  Requirements for Autonomic Network Infrastructure (ANI)
+           devices . . . . . . . . . . . . . . . . . . . . . . . . .  10

-   BRSKI is agile enough to support bootstrapping alternative key
-   infrastructures, such as a symmetric key solutions, but no such
-   system is described in this document.


+   BRSKI is agile enough to support bootstrapping alternative key
+   infrastructures, such as a symmetric key solutions, but no such
+   system is described in this document.
+
 1.1.  Other Bootstrapping Approaches

    To literally "pull yourself up by the bootstraps" is an impossible
@@ -233,9 +237,10 @@ Internet-Draft                    BRSKI                    February 2018
    without external help is also an impossibility.  Today it is commonly
    accepted that the initial connections between nodes are insecure,
    until key distribution is complete, or that domain-specific keying
-   material is pre-provisioned on each new device in a costly and non-
-   scalable manner.  Existing mechanisms are known as non-secured 'Trust
-   on First Use' (TOFU) [RFC7435], 'resurrecting duckling'
+   material (often pre-shared keys, including mechanisms like SIM cards)
+   is pre-provisioned on each new device in a costly and non-scalable
+   manner.  Existing mechanisms are known as non-secured 'Trust on First
+   Use' (TOFU) [RFC7435], 'resurrecting duckling'
    [Stajano99theresurrecting] or 'pre-staging'.

    Another approach is to try and minimize user actions during

@@ -358,6 +364,13 @@ Internet-Draft                    BRSKI                    February 2018
       "Registrar".  The term JRC is used in common with other bootstrap
       mechanisms.

+   (Public) Key Infrastructure:  The collection of systems and processes
+      that sustain the activities of a public key system.  In an ANIMA
+      Autonomic system, this includes a Domain Certification Authority
+      (CA), (Join) Registrar which acts as an [RFC5280] Registrar, as
+      well as appropriate certificate revocation list (CRL) distribution
+      points and/or OCSP ([RFC6960]) servers.
+
    Join Proxy:  A domain entity that helps the Pledge join the domain.
       A Proxy facilitates communication for devices that find themselves
       in an environment where they are not provided connectivity until

+1.5.  Requirements for Autonomic Network Infrastructure (ANI) devices

+   The BRSKI protocol can be used in a number of environments.  Some of
+   the flexibility in this document is the result of users out of the
+   ANI scope.  This section defines the base requirements for ANI
+   devices.

+   For devices that intend to become part of an Autonomic Network
+   Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes
+   an Autonomic Control Plane
+   ([I-D.ietf-anima-autonomic-control-plane]), the following actions are
+   required and MUST be performed by the Pledge:

+   o  BRSKI: Request Voucher

+   o  EST: CA Certificates Request

+   o  EST: CSR Attributes

+   o  EST: Client Certificate Request

+   o  BRSKI: Enrollment status Telemetry

+   The ANI Registrar (JRC) MUST support all the BRSKI and above listed
+   EST operations.

+   All ANI devices SHOULD support the BRSKI proxy function, using
+   circuit proxies.  Other proxy methods are optional, and may be
+   enabled only if the JRC indicates support for them in it's
+   announcement.  (See Section 4.4)

    > II) This leaves the option that EST to install trust anchor is mandatory, but
    > enrolment with a certificate is optional (except for ANI case).

    > Aka: would be good to write a sentence/paragraph exactly outlining what is
    > permitted to happen after a voucher and if any, what parts of EST are deemed to
    > be necessary by BRSKI (outside of ANI devices. the requirements for ANI devices
    > are listed above).

I think that this should be left to other users.

I am going to push the -11 with these changes, and the ones from last week.
I acknowledge that I still have a bunch of edits from the rest of your message.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-