Re: [Anima] [6tisch-security] Scope question [was: autonomic bootstrap: gap analysis]

["Pascal Thubert (pthubert)" <[e-mail]>]

I agree with Michael,

As IT and more specifically IEEE/IETF technology is getting pervasive, we need to simplify commissioning and deployment in a fundamental manner.

There are no CCIEs in an oil field or a deep mine in Alaska and still growing amounts of IP and Ethernet devices get deployed in all sorts of places, homes, curbs, factory floors, you name it, with a renewed interest in wireless monitoring.

6TiSCH targets at some of those environments and it clearly requires AN for use cases with huge scalability or ease-of-deployment constraints.

And certainly, the lack of CCIEs is more pervasive than just the WSN/6TiSCH...

Pascal

Le 17 juin 2014 à 08:59, "Michael Behringer (mbehring)" <[e-mail]> a écrit :

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