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

[Hannes Tschofenig <[e-mail]>]

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


 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
>