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

[Behcet Sarikaya <[e-mail]>]

Hi Hannes,

On Sat, Feb 21, 2015 at 5:44 AM, Hannes Tschofenig
<[e-mail]> 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.

Sorry but, Hannes, you have been saying these things for some time but
I have not heard your proposal yet. What should we call it if not
bootstrapping?

>
> 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.

Don't worry about it.


> 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

You mean

 by  now?

> 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.
>

Yes but what is Thread's solution on this? Is this different than what
we have in IETF?



> 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.

Agreed, so it should be based on IETF work?
>
> 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.


Exactly. Maybe this is what Peter is pointing at when he says several
solutions can be developed, different for each environment.


> 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.

Good point.

>
> 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
>