Re: [6tisch-security] [6lo] [Anima] Comments needed for Security Bootstrapping of IEEE 802.15.4 based Internet of Things

[peter van der Stok <[e-mail]>]

Hi Brian, Hannes,

About negotiation of bootstrapping choice:

Standardizing components for the "security bootstrapping" of low 
resource devices, gives a consortium the possibility to agree on a 
selection of building blocks
which is preloaded in the consortium stamped devices,
accompanied by parameter settings.
The parameter setting may further determine the bootstrap actions.
Prefixing parameter settings is a well-known technique. This can be done 
in the factory; Servers can also be used for that matter.

Peter

Brian E Carpenter schreef op 2015-02-21 19:53:
> Hannes,
> 
> "Bootstrapping" is a colloquialism, of course, but it conveys the idea
> of having no prior knowledge which is the main point here. Of course
> it's true (as Peter said) that different situations call for 
> differences
> in the solution. The initial target for Anima is "professionally 
> managed
> networks" and for that we tend to assume that devices are 
> pre-registered
> in some sense; that is a false assumption for homenets and (I assume) 
> IoT.
> I am pretty sure that IoT approaches will be a false assumption for
> large international carrier networks.
> 
> I know nothing about Thread, whatever and whoever it is. If they
> want to repeat the Bluetooth error of working in secret, there is
> nothing we can do about it, neither can we sit back and do nothing.
> At least draft-pritikin-anima-bootstrapping-keyinfra builds pn
> IEEE 802.1AR.
> 
> Regards
>    Brian
> 
> On 22/02/2015 00:44, Hannes Tschofenig wrote:
>> Peter, Brian,
>> 
>> I would strongly recommend not to use the term bootstrapping. 
>> Replacing
>> it with some other word that explains what you want to do.
>> 
>> After-all, we are engineers and not marketing guys. I tend to get a 
>> bit
>> nervous when I read terms like "zero-touch" and alike that create the
>> impression that there is no configuration that needs to be done by
>> anyone. Of course, that's not the case.
>> 
>> With all the security drafts in NETCONF (zerotouch) or in ANIMA I get
>> the impression that we are re-inventing the wheel not only because we
>> want to work on new stuff but largely because we actually don't
>> understand the state of the art ourselves anymore. I fear that the
>> <draft-he-iot-security-bootstrapping-00> document also falls into the
>> category of not understanding the state-of-the-art. I understand if
>> someone is not up-to-speed with the most recent efforts in Thread
>> (because they are only visible to members of that organization) but 
>> the
>> ZigBee-IP work should be known. While ZigBee-IP may be considered dead
>> by know it also appears to me that any new work in the IETF on
>> security/routing/etc. for IEEE 802.15.4 will have to compete against
>> Thread. Thread has seen a dramatic growth rate in terms of membership
>> and so I doubt that work in the same area has a lot of chances for
>> success.
>> 
>> Sorry for the rant but I believe it will help everyone to figure out
>> that most of the groups are actually developing the same solutions 
>> over
>> and over again.
>> 
>> Now to the issue of the multi-vendor equipment. Adding new solutions 
>> (as
>> it is done in ANIMA) while other groups and organizations have already
>> standardized similar technologies (using different terminology) will 
>> not
>> make the interoperability any better. I am sure you know that far too 
>> well.
>> 
>> It would be great to have a conversation (maybe at the next IETF
>> meeting) how the different environments (home environment, enterprise
>> environments/industrial environments) are different in terms of
>> provisioning credentials and configuration information to IoT devices.
>> Needless to say that there are differences and you can see them when 
>> you
>> look at how existing products work. That does, however, not 
>> necessarily
>> mean that there are no common building blocks.
>> 
>> Ciao
>> Hannes
>> 
>> On 02/21/2015 12:14 PM, peter van der Stok wrote:
>>> Hi Brian,
>>> 
>>> Just a small annotation to your default approach comment.
>>> Bootstrapping is subject to different installation procedures.
>>> A clear example is the difference between home (plug and play) and 
>>> the
>>> building control where bootstrapping is organized from a database.
>>> In the professional domain the order of things can depend on the
>>> installer. For example, some may want to bootstrap together with the
>>> setup of the network, others may want the network to be ready and 
>>> then
>>> do the security bootstrap.
>>> 
>>> Although I agree with your concern expressed as "a default procedure 
>>> to
>>> decide on the bootstrap procedure", I think there is room for 2-4
>>> different security bootstrap procedures.
>>> These procedures will be chosen as function of the application domain
>>> and application owner, installer.
>>> 
>>> Peter
>>> 
>>> 
>>> 
>>> Brian E Carpenter schreef op 2015-02-20 19:51:
>>>> Hannes,
>>>> 
>>>> I agree that we need to compare different approaches. I do have one
>>>> concern in the anima context that leads me to the conclusion that
>>>> we *must* pick a preferred solution: if we consider a collection of
>>>> multivendor equipment in factory condition that we want to bootstrap
>>>> itself into a secure network when we apply power, I don't see how
>>>> we can avoid having a single default solution. If not, we get a
>>>> rather ludicrous situation where we need a single default solution
>>>> to the problem of choosing which bootstrap solution to use.
>>>> 
>>>> Regards
>>>>    Brian
>>>> 
>>>> On 21/02/2015 01:27, Hannes Tschofenig wrote:
>>>>> Hi Danping,
>>>>> 
>>>>> I would also like to note that
>>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] is only one possible 
>>>>> way of
>>>>> distributing new keys (based on already pre-provisioned 
>>>>> certificates). I
>>>>> would like to understand how it relates to other approaches.
>>>>> Particularly if you consider an approach "heavy" it would be good 
>>>>> to
>>>>> know what your main concerns are since there is no free lunch with
>>>>> security and most of the design decisions are trade-offs.
>>>>> 
>>>>> Ciao
>>>>> Hannes
>>>>> 
>>>>> On 02/20/2015 12:59 PM, Robert Cragie wrote:
>>>>>> [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch
>>>>>> bootstrapping key infrastructure to allow joining device securely 
>>>>>> and
>>>>>> automatically bootstraps itself based on 802.1AR certificate.  It 
>>>>>> can't
>>>>>> be directly used in 802.15.4 devices due to the high security
>>>>>> complexity
>>>>>> and heavy communication overhead.": I disagree with this 
>>>>>> statement. We
>>>>>> used this approach in ZigBee IP. I agree some may think the
>>>>>> communication overhead "heavy" but that doesn't mean it can't be 
>>>>>> done.
>>>>>> The associated security complexity is also becoming less onerous 
>>>>>> as
>>>>>> crypto accelerators become built into hardware and cores.
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Anima mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> Anima mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/anima
>> 
> 
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo