[Anima] Scope question [was: autonomic bootstrap: gap analysis]

[Brian E Carpenter <[e-mail]>]

Michael's message is very interesting. For present purposes,
i.e. getting ready for the UCAN BOF, do we need to add some
points to the relevant use case draft
(http://tools.ietf.org/html/draft-behringer-autonomic-bootstrap)?

More generally - I think the AN protagonists have been thinking
of the scope of AN being carrier, enterprise, and home networks.
Should we add IoT to the scope? I think it's an important
question, because it would put new meanings on "simple" and
"available resources". It seems obvious that IoT networks need
to be completely autonomic, but is it the *same* autonomic?

Regards
   Brian

On 17/06/2014 08:13, Michael Richardson wrote:
> I recognize that bootstrap is only one of the autonomic mechanisms that
> are relevant to this group.  I have much reading on the other aspects
> which I hope to get done.
> 
> The 6tisch security design team has been working on a "zero-touch" mechanism
> that would permit constrained devices to join a Lowpower/Loss Network (LLN)
> in a secure way.   We have considered adapting EAP-TLS (as ZigbeeIP has
> done), or turning the WirelessHART (IEC62591) packet flow into something more
> IPv6-like.  While there are significant bits of design space to explore
> while trying to optimize packet count, size and total energy risk of the
> join protocol;  the idea that there should be a set of authorization tokens
> From the device vendor which would permit the network and new nodes to
> recognize each other has been central to all discussions.
> 
> while draft-pritikin-bootstrapping-keyinfrastructures and
>       draft-behringer-autonomic-bootstrap-00
> 
> have proposed valid high level concepts, I believe that specification of the
> authz token is critical for the IoT space.  A great concern that is that the
> LLNs created remain operational for decades at a time, and that the
> components can individually and also in aggregate be both (re-)sold,
> and/or the service provider operating the network be replaced.
> 
> (There are real life examples where a part of a 100 square mile refinery
> is actually sold to a competitor; obviously it doesn't get moved.  On the
> other side, one has the very real risk that you bought your sensor network
> From a "Nortel")
> 
> I was pointed at 802.1AR's device ID mechanism.  Really, 802.1AR is about an
> API between a (constrained) device and it's cryptographic hardware
> module/TPM.   It profiles a number of IETF PKIX specifications in a useful
> way, but there is little there in terms of actual protocol.  When it comes to
> what does an *DevID look like, in it's section 7.2.8, saying that the DN
> should contain a "serialNumber" attribute:
> 
>    The formatting of this field shall contain a unique X.500
>    Distinguished Name (DN). This may include the unique device serial number assigned by the manufacturer
>    or any other suitable unique DN value that the issuer prefers.
> 
> What I have observed is that there needs to be a way to clearly delegate from
> Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to
> SERVICE-PROVIDER.    It would significantly reduce the number of certificates
> in (non-constrained device) databases for some levels of this hierarchy if
> the IDevID were aggregateable in some fashion.  RFC3779 came to mind, which
> deals with delegation of Autonomous Systems Numbers (ASN) and IP address
> ranges from RIRs to LIRs to ISPs and Enterprises.
>           RFC3779: X.509 Extensions for IP Addresses and AS Identifiers
> 
> I created:
>     X509.v3 certificate extension for authorization of device ownership
>                  draft-richardson-6tisch-idevid-cert-00
> 
> which cribbed together via nroff2xml and a search and replace.
> 
> The Pritikin and Behringer documents seem to assume that the ultimate goal of
> the trusted enrollment process is to create a path in which "EST"= Enrollment
> over Secure Transport could operate that would permit a new locally
> significant certificate to be loaded into the new device.
> I agree with that goal.
> 
> There is the question of how that trust circuit is created, and in discussion
> it seemed that it involve some kind of leap-of-faith TLS setup which would be
> authenticated by the "authz" tokens later on.  I disagree; I think that with
> appropriate evaluation of path constraints that the authentication can occur
> within the TLS protocol. (Even easier if done in IKEv2)
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>