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

From: "Hedanping (Ana)" <[email-masked]>
Date: Mon, 2 Feb 2015 08:13:19 +0000

Hi Michael,
Thank you for the interest and the questions are illuminating. Please see my reply inline.

	> I have added a number of CCs, I think that this fits into ANIMA best.
	> 

	> Hedanping (Ana) <[email-masked]> wrote:
	>     > A new draft is submitted, it's about the security bootstrapping
	>     > architecture and methods for IoT networks that implement IETF
	> protocols
	>     > (e.g. 6LoWPAN, 6lo, RPL, AODV, DSR) over IEEE 802.15.4.
	>     > Two types of bootstrapping methods are developed: network level
	>     > bootstrapping and joining device level bootstrapping
	> 
	>     > The link is:
	>     > http://tools.ietf.org/html/draft-he-iot-security-bootstrapping-00
	> 
	> I read the document with great interest.
	> I found that you explained the incremental boot-strapping process quite well,
	> and nobody has clearly articulated the process yet.  People have just assumed
	> that everyone knows this process, but really it needs to get written down, so I
	> thank you for doing that.

Thank you for the praise. As it is the initial version, more discussions and comments are needed to make it better.

	> 
	> Given that:
	> 
	>    Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard
	>    security bootstrapping protocol should be light-weight with low
	>    complexity.  The protocol must allow for commissioning of devices
	> 
	> I was surprised that the draft then suggested EAP with PANA as a transport:
	> 
	>    If EAP is used, PANA can be used to relay the authentication message
	>    from configured FFDs to 6LBR.  If the validation is successful, the
	>    IP address and network key are generated and delivered to the FFD.
	> 
	> But, EAP-TLS with PANA is exactly what the Zigbee IP specification has specified.
	> Do you envision any changes from that specification?

Zigbee IP specification was developed to enable IP address for Zigbee application, thus the protocol stack are built on IETF's standards, including EAP-TLS. 
As discussed in many working groups, TLS might result in a significant amount of retransmissions due to unreliable communication capability of the network and device, thus energy will be consumed fast.
I think EAP over DTLS /profiled DTLS could be a good option.

	> A minority of people had prefered this mechanism for 6tisch-security, but
	> none stepped forward to write up that mechanism.   Perhaps this draft could
	> fulfill that need?

Yes, we should describe more clearly on this mechanism, and maybe this draft is a right place. It would be great if folks in the mailing list make comments and contribution on this technical point. 

	> You write that the IP address would be generated; usually that occurs via
	> distribution of PIOs via ND (router-adveristments) or RPL.  Were you going to
	> suggest something else here?

According to my knowledge, IP address can be generated once a device is authenticated to network access, afterwards, other further protocols can use IP to communicate. 
Besides, PANA needs IP as well. The incremental bootstrapping takes advantage of such IP address generation mechanism, so that PANA can be run without any problem.

	> From the ANIMA and 6tisch-security point of view, my view is that this is all
	> about the choice of certificates for the TLS setup.  Do you have any view on
	> how that might work?

For unconstrained environment, I agree with you. But when it comes to constrained device and constrained network communication, TLS might not be a good choice as mentioned before. Certificate is not a good choice either due to the high cost. 
I would like to say: it is about the choice of credential type for secure channel setup. The good candidates of credential types are Raw public key, Physical Unclonable Function (PUF).

	> 
	> The 6tisch-security bootstrap process aims to create a
	> YANG/CBOR-over-CoAP-over-DTLS session between a Join Coordinator and the
	> Joining Node: over that management link, security (and timeslot scheduling)
	> would be provisioned.

CoAP-DTLS coincides with my idea.
Yang sounds like at a higher level, but I think EAP is actually the mechanism running behind ^_^

Regards,
Ana

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Feb 2015 13:58:27 +0200

Hedanping (Ana) writes:
> 	>    Because IEEE 802.15.4 maximum payload size is 128 Bytes,
> 	>    a standard security bootstrapping protocol should be
> 	>    light-weight with low complexity. The protocol must allow
> 	>    for commissioning of devices I was surprised that the
> 	>    draft then suggested EAP with PANA as a transport: If EAP
> 	>    is used, PANA can be used to relay the authentication
> 	>    message from configured FFDs to 6LBR. If the validation
> 	>    is successful, the IP address and network key are
> 	>    generated and delivered to the FFD. But, EAP-TLS with
> 	>    PANA is exactly what the Zigbee IP specification has
> 	>    specified. Do you envision any changes from that
> 	>    specification?
> 
> Zigbee IP specification was developed to enable IP address for
> Zigbee application, thus the protocol stack are built on IETF's
> standards, including EAP-TLS.  
> As discussed in many working groups, TLS might result in a
> significant amount of retransmissions due to unreliable
> communication capability of the network and device, thus energy will
> be consumed fast. 

There is work going on in the IEEE 802.15.9 task group which specifies
the key management for 802.15.4, or more specifically it will specify
a way to transport existing key management protocols over the
802.15.4 frames. This would allow running for example IKEv2 + EAP over
the 802.15.4 and generate keys for 802.15.4 security and then protect
all messages between the two nodes.

In normal case this would be run even before the IEEE 802.15.4
assocation is done, i.e. immediately after the beacon before doing the
association, and would allow protecting the association process too.

For this uses the IKEv2 + EAP would be most likely quite good, i.e.
the IKEv2 frames would be exchange between the peer joining the
network and its next hop router, and inside those IKEv2 frames there
would be EAP messages, which are then relayed to the AAA server (trust
center TC in draft-he-iot-security-bootstrapping-00) for actual
authentication.

The 802.15.9 is now in letter ballot phase in IEEE, meaning we should
be finished quite soon. One issue there is that, during the 802.15.9
work we noticed some issues with 802.15.4 base specifciation which
have been worked on in the 802.15.4 maintenance revision process, and
we need to wait for it to finish before 802.15.9 can finish...

Most likely both of those will finish before the end of year.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 6 Feb 2015 12:18:36 +0200

Behcet Sarikaya writes:
> Did you consider 802.1X which does similar things?

Yes, but 802.1X is not enough on its own. It only provides
authentication, not key management. We currently have two 802.1X
versions, i.e. 802.1X/MKA and 802.1X/KEY, but there is going to be
some rewriting happening on those sections. In addition to those we
have IKEv2, HIP, PANA and Dragonfly.
-- 
[email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 5 Feb 2015 14:29:02 -0600

Hi Tero,

> Most likely both of those will finish before the end of year.

Good to know.

Regards,

Behcet
> --
> [email-masked]
>
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Robert Cragie <[email-masked]>
Date: Fri, 20 Feb 2015 11:59:23 +0000

Hi Danping,

I have some general comments on the draft and some additional comments 
inline, bracketed by <RCC></RCC>

General comments:

I think the general model is good but could be simplified to two cases:

1) Where the authenticator is in direct communication
2) Where the authenticator is not in direct communication (relay case)

My reasoning is because:

a) There isn't much distinction between RFD and FFD from an 
authentication perspective
b) There isn't much distinction between joining an existing network and 
initial joining

If you think there are distinctions, then they need clarifying.

Other points:

  * "Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard
    security bootstrapping protocol should be light-weight with low
    complexity.": I think it would be better to say "should ideally be
    light-weight with low complexity". There may be requirements where
    high security strength is required and therefore this will
    necessarily involve more communication overhead and processing.
  * I think the hierarchical joining description is generally useful.
  * It is conceivable for an RFD to communicate directly with a 6LBR so
    I don't think that should be excluded from Figure 1
  * "[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.
  * The document mentions a couple of protocols (EAP and PANA) but
    doesn't go into enough detail on how those are deployed. Also, there
    are other choices. The document could give generic names to the
    particular communications and then add a section to give examples.

Robert

> Thank you for the praise. As it is the initial version, more discussions and comments are needed to make it better.
<RCC>I agree that it has not generally been articulated well. To some 
extent, it is because up to now, there has been no "the one way to do 
it". Therefore, something ZigBee IP is a profile which defines one 
particular way of doing it. There are other ways as well, of course. I 
guess the question is whether it can be generalised sufficiently to be 
generally applicable and whether that is in fact worth doing</RCC>
> 	> I was surprised that the draft then suggested EAP with PANA as a transport:
<RCC>I realise that PANA/EAP/EAP-TLS gets roundly criticised for being 
"heavyweight". Indeed, there are overheads in the use of these three 
very well-established protocols which could be removed in certain cases. 
However, this would result in the development of new protocols. Having 
done a lot of work in looking at DTLS options, I can confidently say 
that the difference at the end of the day is quite small</RCC>
> I think EAP over DTLS /profiled DTLS could be a good option.
<RCC>EAP-TLS only uses TLS handshakes carried as EAP payloads, therefore 
has little to do with TLS as it is normally used, i.e. over TCP. If you 
then start to look at the difference between EAP-TLS (over UDP) and DTLS 
handshakes over UDP, there is actually not much difference. In some 
areas, EAP is actually preferable (fragmentation and header overhead)</RCC>
> Yes, we should describe more clearly on this mechanism, and maybe this draft is a right place. It would be great if folks in the mailing list make comments and contribution on this technical point.
<RCC>I am happy to write up that mechanism</RCC>
> Besides, PANA needs IP as well. The incremental bootstrapping takes advantage of such IP address generation mechanism, so that PANA can be run without any problem.
<RCC>ZigBee IP solved this problem by using SLAAC IPv6 addresses based 
on the EUI-64. These can be used in PANA straight away without the need 
for any other configuration</RCC>
> I would like to say: it is about the choice of credential type for secure channel setup. The good candidates of credential types are Raw public key, Physical Unclonable Function (PUF).
<RCC>There certainly are overheads in certificates but in the 802.1AR 
scenario (draft-pritikin-anima-bootstrapping-keyinfra-01) it has clear 
value.</RCC>
> Yang sounds like at a higher level, but I think EAP is actually the mechanism running behind ^_^
<RCC>Again, in this document, it might be better to abstract this 
session and describe what it is used for</RCC>
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Feb 2015 13:27:50 +0100

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Feb 2015 07:51:54 +1300

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Feb 2015 14:51:30 -0600

Hi Robert,

 Thank you for your comments.

On Fri, Feb 20, 2015 at 5:59 AM, Robert Cragie
<[email-masked]> wrote:
> a) There isn't much distinction between RFD and FFD from an authentication
> perspective
> "Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard
> light-weight with low complexity". There may be requirements where high
> security strength is required and therefore this will necessarily involve
> more communication overhead and processing.
> I think the hierarchical joining description is generally useful.
> It is conceivable for an RFD to communicate directly with a 6LBR so I don't
> think that should be excluded from Figure 1

> "[I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch
> 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.

So there is already ZigBee IP's EAP-TLS approach.
Then, why do you think a new approach is needed?

> 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.
> The document mentions a couple of protocols (EAP and PANA) but doesn't go
> into enough detail on how those are deployed. Also, there are other choices.
> The document could give generic names to the particular communications and
> then add a section to give examples.
>

Thanks for the pointers.

We are currently working on an analysis draft to see if there is
interest in new work in this area.
I think that any solution work should follow on the results of such a
discussion.

What do you think?

Regards,

Behcet
> extent, it is because up to now, there has been no "the one way to do it".
> Therefore, something ZigBee IP is a profile which defines one particular way
> of doing it. There are other ways as well, of course. I guess the question
> is whether it can be generalised sufficiently to be generally applicable and
> whether that is in fact worth doing</RCC>
>
> >
> > Given that:
> >
> "heavyweight". Indeed, there are overheads in the use of these three very
> well-established protocols which could be removed in certain cases. However,
> this would result in the development of new protocols. Having done a lot of
> work in looking at DTLS options, I can confidently say that the difference
> at the end of the day is quite small</RCC>
>
> >
> Zigbee IP specification was developed to enable IP address for Zigbee
> application, thus the protocol stack are built on IETF's standards,
> including EAP-TLS.
> As discussed in many working groups, TLS might result in a significant
> amount of retransmissions due to unreliable communication capability of the
> network and device, thus energy will be consumed fast.
> <RCC>EAP-TLS only uses TLS handshakes carried as EAP payloads, therefore has
> little to do with TLS as it is normally used, i.e. over TCP. If you then
> start to look at the difference between EAP-TLS (over UDP) and DTLS
> handshakes over UDP, there is actually not much difference. In some areas,
> EAP is actually preferable (fragmentation and header overhead)</RCC>
>
> Yes, we should describe more clearly on this mechanism, and maybe this draft
> is a right place. It would be great if folks in the mailing list make
> comments and contribution on this technical point.
>
> According to my knowledge, IP address can be generated once a device is
> authenticated to network access, afterwards, other further protocols can use
> IP to communicate.
> Besides, PANA needs IP as well. The incremental bootstrapping takes
> advantage of such IP address generation mechanism, so that PANA can be run
> without any problem.
>
> <RCC>ZigBee IP solved this problem by using SLAAC IPv6 addresses based on
> the EUI-64. These can be used in PANA straight away without the need for any
> other configuration</RCC>
>
>
>
> For unconstrained environment, I agree with you. But when it comes to
> constrained device and constrained network communication, TLS might not be a
> good choice as mentioned before. Certificate is not a good choice either due
> to the high cost.
> I would like to say: it is about the choice of credential type for secure
> channel setup. The good candidates of credential types are Raw public key,
> Physical Unclonable Function (PUF).
>
> <RCC>Again, in this document, it might be better to abstract this session
> and describe what it is used for</RCC>
>
>
> Regards,
> Ana
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Feb 2015 07:53:54 +1300

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Feb 2015 11:17:05 +1300

By the way, even if it's ludicrous...

> to the problem of choosing which bootstrap solution to use.

This could be done with GDNP. Notionally, it would look like this

Discover("Enrollment Method"="Any")
 followed by
Response("Enrollment Method"="Thread", Locator=<some IP address>)
 or
Response("Enrollment Method"="RFCxxxx", Locator=<some IP address>)

or whatever.

I would consider this unfortunate because it immediately raises
interoperability issues. But it could be done, if the world ends
up with competing solutions.

     Brian

---

From: peter van der Stok <[email-masked]>
Date: Sat, 21 Feb 2015 12:14:56 +0100

Hi Brian,

Peter

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 21 Feb 2015 12:44:26 +0100

Peter, Brian,

Ciao
Hannes

---

From: peter van der Stok <[email-masked]>
Date: Mon, 23 Feb 2015 09:21:45 +0100

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Feb 2015 07:52:50 +1300

On 23/02/2015 21:21, peter van der Stok wrote:
> Standardizing components for the "security bootstrapping" of low resource devices, gives a consortium the possibility to agree
> on a selection of building blocks

And that is a problem. I mean the word "consortium" is a problem; it
amounts to a cartel and excludes non-consortium members from the market.
That is not what we want in the Internet. We may have to deal with it as
part of reality, but we have to focus on open standards that everybody
can implement. Whether the open standard is based on draft-pritikin or
something else is a separate question, of course.

In the last few days I've had to deal with two vendor-specific wireless
enrollment issues (garage door openers and remote weather sensors) and
I don't think that is a direction we should encourage.

> Prefixing parameter settings is a well-known technique. 

And it's exactly what we want to avoid in autonomic networks.

   Brian

> This can be done in the factory; Servers can also be used for that matter.
> 
> Peter
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 23 Feb 2015 14:59:03 -0600

Hi Hannes,

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

> category of not understanding the state-of-the-art.

Don't worry about it.

> I understand if
> by know

You mean

 by  now?

> it also appears to me that any new work in the IETF on

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

> that most of the groups are actually developing the same solutions over

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

> mean that there are no common building blocks.

Good point.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 24 Feb 2015 01:32:13 +0000

I also have been thinking that there can be only one default for a given
piece of vendor equipment.  Though it is conceivable that a vendor may
offer different SKUs to set which default is used.

That said, it seems that the "default mechanism" can actually be a suite
of mechanisms.  I postulate that there can be a safe ordering of
bootstrapping mechanisms, so long as a denial-of-service on an earlier
mechanism doesn't lead to a weaker mechanism.  To this I add that physical
presence (e.g., USB flash drive) is more secure than networking, and that
local networking (link-local) is more secure than WAN networking.  The
question is if using a more secure mechanism actually makes a difference.
For instance, one might think that information loaded from a USB flash
drive could forego needing to be signed, but why do this if the risk it
introduces is non-zero and the signing operation is low-burden?

Thanks,
Kent

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Feb 2015 17:02:44 +0100

Hi Brian,

On 02/21/2015 07:53 PM, Brian E Carpenter wrote:
> 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
> 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
> 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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Feb 2015 13:40:20 +1300

Hi Kent,

> offer different SKUs to set which default is used.

I fear that we may have to assume the worst (i.e. there is no universal
solution that all vendors will support).

> mechanism doesn't lead to a weaker mechanism.  

Sigh: you are probably right. This sounds like a major topic in itself,
so Anima will have to be flexible.

> To this I add that physical
> presence (e.g., USB flash drive) is more secure than networking,

Well in theory yes, but don't forget the Stuxnet propagation mechanism.

> and that
> local networking (link-local) is more secure than WAN networking. 

I would extend link-local to domain-local (for a professionally managed
network), but otherwise I agree.

> The

Makes sense in a large network where USB drives found in the parking lot
might be considered a risk.

    Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Feb 2015 15:25:37 -0600

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Feb 2015 13:52:01 +1300

On 26/02/2015 10:25, Behcet Sarikaya wrote:

...
>> http://threadgroup.org/Portals/0/documents/events/ThreadIntro.pdf

Thanks for that. It seems to have all the downsides of secretive ad hoc
membership-based consortia, except for the upside of a RAND-RF IPR
policy.

> Enterprise or industrial environments seem to be excluded.

So far. The boundary between this and larger building services
networks is pretty fuzzy, isn't it?

In any case, should we (the WGs on copy, and perhaps some others)
be asking the IAB to arrange a meaningful liaison with Thread?

Back at Hannes: is there a spec for their approach to security
enrollment?

   Brian

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Thu, 26 Feb 2015 08:22:33 +0000

Hi Hannes, Behcet and all,

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

[A]
It is a good idea, a conversation is definitely needed. I think it would be great if an analysis draft is prepared, and we can discuss more efficiently in Dallas. 
According to our discussion, the document will include survey of the state-of-the-art works by IETF, Thread, ZigBee, IEEE, etc., and it will also analyze the impacts of different categories of environment.
I am willing to prepare the draft, are you interested in adding your words in it?
[/A]

Cheers,
Ana

> 
> > 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
> >
> >> A clear example is the difference between home (plug and play) and
> >> the building control where bootstrapping is organized from a database.
> >> 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
> >>> concern in the anima context that leads me to the conclusion that we
> >>> *must* pick a preferred solution: if we consider a collection of
> >>> 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
> >>>
> >>>> [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
> >>>>
> >>>>> mean it can't be done.
> >>>>> The associated security complexity is also becoming less onerous
> >>>>> as crypto accelerators become built into hardware and cores.
> >>>>
> >>>>
> >>>>

---

From: Paul Duffy <[email-masked]>
Date: Thu, 26 Feb 2015 12:47:19 -0500

> To be honest, I am a bit doubtful about the value of the IEEE 802.1AR

"Cisco Connected Grid Security for Field Area Network"

http://www.cisco.com/web/strategy/docs/energy/C11-696279-00_cgs_fan_white_paper.pdf

Page 3

Cheers

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 26 Feb 2015 23:41:31 +0100

I'm definitely interested in having that discussion in Dallas.
Thomas

On Thu, Feb 26, 2015 at 6:47 PM, Paul Duffy <[email-masked]> wrote:

> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 25 Feb 2015 17:44:47 -0800

> On Feb 25, 2015, at 4:52 PM 2/25/15, Brian E Carpenter <[email-masked]> wrote:
> 

What would we want to get from a liaison arrangement with Thread?

We had a liaison with ZigBee Alliance but let it lapse as ZA appears to have finished its work on Z-IP.

We might also consider a liaison arrangement with Wi-SUN Alliance because of the Wi-SUN FAN spec.

As I seem to sit at an intersection of WG chairs and IAB, I can bring up the issue if we think there is reason to move forward.

- Ralph

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Feb 2015 16:12:44 +1300

Hi Ralph,
> What would we want to get from a liaison arrangement with Thread?

I think the main thing is to have a chance to review their specs before
finalization. They seem to touch numerous IETF WGs directly or
indirectly (at least homenet, anima, 6lo, 6tisch and probably
6man indirectly). Both sides have everything to gain by detecting
misfits and overlaps ASAP.

    Brian

---

From: peter van der Stok <[email-masked]>
Date: Thu, 26 Feb 2015 10:25:01 +0100

Hi Ana,

I would certainly be interested to contribute,

Peter

Hedanping (Ana) schreef op 2015-02-26 09:22:
>> solutions
> It is a good idea, a conversation is definitely needed. I think it
> would be great if an analysis draft is prepared, and we can discuss
> more efficiently in Dallas.
> According to our discussion, the document will include survey of the
> state-of-the-art works by IETF, Thread, ZigBee, IEEE, etc., and it
> will also analyze the impacts of different categories of environment.