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

[Sheng Jiang <[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?

Indeed, the scope is an important question. For me, the answer rely on solution rather than autonomic concept. Every network, no matter what kind of network it is, has the requirements to be autonomic, or more and more autonomic. However, giving the differences of these networks, we may not be able to find a generic solution that suits all. It is time for us to start discuss the potential solution and their suitable scenarios. After then, we may know whether we can unify into the same autonomic network or we have to settle on more than one autonomic network architecture.

Regards,

Sheng

>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