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

[Balazs Lengyel <[e-mail]>]

When speaking about bootstraping, does this have much in common with the
http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01
draft?
regards balazs

On 2014-06-17 08:59, Michael Behringer (mbehring) wrote:
>> -----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
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: [phone]
Mobile: [phone]              email: [e-mail]