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

["Michael Behringer (mbehring)" <[e-mail]>]

> -----Original Message-----
> From: Anima [mailto:[e-mail]] On Behalf Of Brian E
> Carpenter
> Sent: 17 June 2014 01:01
> To: [e-mail]
> Cc: 6tisch-security
> Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis]
> 
> 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?

Brian, we have always positioned AN also in the IoT context, and I agree with Sheng, AN can be used everywhere. Especially when it comes to devices that will be deployed and managed in the thousands or even millions, autonomic concepts are a requirement, not a nice to have. 

We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a high-level solution in 6tisch. It explains how you CAN bootstrap a network, zero-touch AND secure, and fits perfectly to the 6tisch requirements. The corresponding use case is described in draft-behringer-autonomic-bootstrap. 

To me, the bootstrap problem is one of the real solid examples of autonomic behaviour, because to bootstrap a device into a network I MUST have some functionality on the devices, ie, distribution is absolutely mandatory here. 

So this is one of the criteria for the use cases: Is distribution a requirement? Because if it is, then this points very clearly to an autonomic solution. 

Michael

 
> 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 =-
> >
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima