Subject: [Anima] draft-pritikin-anima-bootstrapping-keyinfra-00

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Nov 2014 08:22:55 +1300

Hi,

I have a few comments on this draft after a fairly quick reading.

Firstly a general point. I suggest deleting every occurrence of the
word "cloud" in the document. I couldn't find any place where it
actually means anything.

>    MASA Cloud Service:  A Manufacturer Authorized Signing Authority
>       (MASA) cloud service on the global Internet.  At a minimum the
>       MASA provides a trusted repository for audit information
>       concerning privacy protected bootstrapping events.  As a service
>       offering the MASA can encorporate many of the bootstrapping
>       elements (such as the Registrar and the Domain CA) into the cloud
>       service.

1) The MASA abbreviation is used several times before it's defined.

2) How can a given vendor's MASA service incorporate the Registrar
and Domain CA functions  for a multi-vendor customer? We are not here
to make customer capture easier for vendors.

3) Having those functions *outside* the target domain seems like a
serious security exposure in itself. I think we should strongly recommend
that the Registrar and Domain CA are physically within the target
domain (for the "professionally managed" networks in anima scope).

> 3.3.  Accepting New Entities
> 
>    For each New Entity the Registrar is informed a priori the unique
>    identifier (e.g. serial number).

That should probably be (e.g. manufacturer's OUI + serial number).

>                                     This can be supplied automatically
>    from the Orchestrator [[EDNOTE: TBD]] or inputed manually by the
>    administrator.

I think there's a third option: acquired automatically when the
new entity is first connected inside the target domain's physically
secure area (e.g. its central warehouse), before shipping to its
final destination (e.g. a remote PoP).

...
>     ...(Registrars
>    can be shipped with the keyIdentifier of a significant number of
>    third-party manufacturers).

That seems dangerous, in the same way that shipping browser code
with built-in CA certificates is an attack vector. I can see why
you might have to do this for consumer networks, but it doesn't
seem advisable for carriers or large enterprises.

> 4.1.  Behavior of a new entity
> 
>    A New Entity that has not yet been bootstrapped attempts to find a
>    local domain and join it.  A number of methods are attempted for
>    establishing communications with the domain in a specified order.
> 
>    Client behavior is as follows:
> 
>    1.  Discover a communication channel to the "closest" Registrar by
>        trying the following steps in this order:
> 
>        A.  Search for a Proxy on the local link using Neighbor
>            Discovery.  If multiple local proxies are discovered attempt
>            communications with each before widening the search to other
>            options.  If this fails:
> 
>        B.  Obtain an IP address using DHCP, and search for a local
>            registrar using DNS service discovery.  If this fails:
> 
>        C.  Obtain an IP address using DHCP, and search for a pre-defined
>            Factory provided global registrar using DNS.

I believe that the discovery and search would be appropriately done
using whatever anima adopts for generic autonomic discovery (running
temporarily without full security, for obvious reasons, but we have
that issue in any case during bootstrapping).

> 4.5.1.  Network boundaries

This is an important topic but I'm not sure it belongs in the
present draft. It may need a new draft that we haven't yet planned.

    Brian

-- 
Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182