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

[Behcet Sarikaya <[e-mail]>]

On Mon, Feb 23, 2015 at 10:02 AM, Hannes Tschofenig
<[e-mail]> wrote:
> Hi Brian,
>
> On 02/21/2015 07:53 PM, Brian E Carpenter wrote:
>> Hannes,
>>
>> "Bootstrapping" is a colloquialism, of course, but it conveys the idea
>> of having no prior knowledge which is the main point here.
>
> The problem with the term is that it is ill-defined.
>
> In many of the cases it actually does not mean that there is no prior
> knowledge. For the specifications we are talking about here we are
> assuming various information pre-configured, such as certificates, trust
> anchors, and other configuration parameters. That's not exactly my
> understanding of "no prior knowledge".
>
>  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.
>
> Here is an intro document:
> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf
>


I think we need to clarify here that Thread Group is formed to deal
with home environments.

Enterprise or industrial environments seem to be excluded.

Regards,

Behcet
>
>  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.
>
> The IEEE, the Bluetooth SIG, and Thread have (as organizations) many
> things in common. Only member companies can influence the specification
> content but, unlike the IEEE, Thread is a fairly new organization and
> hence their specifications have not yet been released since they are
> still work in progress. Both IEEE and Bluetooth SIG release their
> specifications to the general public when they are finalized.
>
> I am not sure I agree that the Bluetooth SIG made huge mistakes since
> otherwise the technology wouldn't be so successful.
>
>> At least draft-pritikin-anima-bootstrapping-keyinfra builds pn
>> IEEE 802.1AR.
>
> To be honest, I am a bit doubtful about the value of the IEEE 802.1AR
> specification.
>
> The specification basically says to use certificates and the PKI (using
> RSA / ECC-based keys) for authenticating devices and defines a MIB for
> configuring various aspects of that infrastructure (using SNMP).
>
> It also lists the fields of a certificate and defines the "device
> identity" in Section 7.2.8 as "This may include the unique device serial
> number assigned by the manufacturer or any other suitable unique DN
> value that the issuer prefers."
>
> I am sure there are some (not described) good reasons why the
> specification exists but it is not as earth-shaking as you might think.
> Particularly, if you plan to use it in ANIMA you might ask yourself how
> many management interfaces you actually need to provision and configure
> credentials on devices. (This actually leads us back to my original mail.)
>
> I have to think about the use of these specifications for Internet of
> Things scenarios I am a bit hesitant to immediately get excited. I
> already have other protocols that provide this functionality and much
> more functionality (such as a software update mechanism) without the use
> of a network management protocol. In general, the specification offers
> too many options.
>
> How does all of this relate to the work you are doing in the ANIMA
> working group? I do not necessarily have any objections against a new
> attempt to solve problems that have already been solved before. There
> may be short-comings with the existing solutions. Of course, that
> assumes that one has ideas about what should be improved about the
> existing solutions.
>
> Ciao
> Hannes
>
>>
>> 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
>>>
>>
>> _______________________________________________
>> Anima mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima
>>
>
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>