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

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

On 02/02/2015 08:13, Hedanping (Ana) wrote:
> 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.
<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>
>
> 	>
> 	> 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:
<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>
> 	>
> 	>    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.
<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>
>
> 	> 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.
<RCC>I am happy to write up that mechanism</RCC>
>
> 	> 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.
<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>
>    
>
> 	> 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).
<RCC>There certainly are overheads in certificates but in the 802.1AR 
scenario (draft-pritikin-anima-bootstrapping-keyinfra-01) it has clear 
value.</RCC>
>
> 	>
> 	> 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 ^_^
<RCC>Again, in this document, it might be better to abstract this 
session and describe what it is used for</RCC>
>
>
> Regards,
> Ana
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

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

On 2/23/2015 11:02 AM, Hannes Tschofenig wrote:
>> 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.
>
>

"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: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Mar 2015 17:36:15 +0100

At the moment the specifications are only available to Thread members
since the specification is still work in progress.

I don't know when it will be finalized and released to the wider public.

Regarding the liaison I do not have an opinion about the value of it.

Ciao
Hannes

On 02/26/2015 01:52 AM, Brian E Carpenter wrote:
> On 26/02/2015 10:25, Behcet Sarikaya wrote:
> 
> ...
>>>> I know nothing about Thread, whatever and whoever it is.
>>>
>>> Here is an intro document:
>>> 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.
> 
>> 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.
> 
> 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
> 
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Ralph Droms <[email-masked]>
Date: Tue, 3 Mar 2015 12:22:25 -0500

Brian, Hannes ...

> On Mar 3, 2015, at 11:36 AM 3/3/15, Hannes Tschofenig <[email-masked]> wrote:
> 

I've opened a discussion within the IAB Liaison Oversight program regarding establishment of a liaison relationship with Thread.

- Ralph

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Mar 2015 08:34:42 +1300

> Regarding the liaison I do not have an opinion about the value of it.

It is precisely to get access before the work is finalised, so that it
can be reviewed by all the right people. We know that closed standards
development produces bad standards.

    Brian

---

From: Rene Struik <[email-masked]>
Date: Tue, 03 Mar 2015 16:29:54 -0500

Dear colleagues:

I don't understand all the excitement here: everyone is free to draw up 
architectural blueprints and complete designs to their liking. This can 
be done in the attic, as company-internal project, with an industry 
consortium, or with SDOs, such as IETF. There is  no way of knowing what 
people dream up in their attic or in a "secret" project X type of 
effort. Or, is the fear that IETF will loose its lustre?

Competition (without bullying) is good and is an enticement to consider 
solid designs and thinking outside of the 
"we-did-this-20-years-ago-like-this-and-therefore-have-to-stick-to-this" 
box (the flaky ones will end up with marketing and PR departments of 
competing efforts to poke fun at).

Best regards, Rene

On 3/3/2015 2:34 PM, Brian E Carpenter wrote:
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Mar 2015 11:06:22 +1300

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

> effort. Or, is the fear that IETF will loose its lustre?

No. The fear (and it has been realised many times in the past) is
that a closed consortium will agree on and start shipping a solution
which does not mesh well with the rest of the Internet. A liaison
arrangement can help to avoid that.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 4 Mar 2015 01:22:15 +0000

>arrangement can help to avoid that.

The IETF is mainly a standardization organization. Most of efforts in IETF is for interoperation. IETF produces a bunch of open standards, no secret at all. Then every company can implementation the interface following these standards. Of course, there are many internal implementation, which does not need interoperation with other devices, and they can be closed or secret. Devices can then interoperate with each other as long as the all following the same standards.

Consequently, the main efforts of standardization actually compromise rather than competition. It is all participators to work together towards a consensus, which most of people could live with (in which maybe everybody have something unsatisfied.) So, people are encouraged to discuss, coordinate, merge and make compromises. Working along and producing several competition solutions would NOT be good in any standardization organizations.

---

From: Rene Struik <[email-masked]>
Date: Tue, 03 Mar 2015 22:38:42 -0500

Hi Sheng:

I think you quite misinterpreted my email: I was just commenting on 
guessing games re what industry consortia or others may have up their 
sleeves (not easy to control or influence). From the numerous emails, I 
got the impression that "Thread" was actually spelled as "Threat". This 
email exchange would never have happened if it would have been another 
"Attic project X".

Of course, all goodies re striving for convergence and for consensus 
apply (where discussion re relative technical merit could be viewed as 
competition of ideas [and what IETF often does quite liberally]).

Rene

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 4 Mar 2015 05:45:12 +0000

>email exchange would never have happened if it would have been another

Sorry for my misinterpret. I missed all the Thread discussion due to my Chinese New Year holidays. I was still catching up. My apologize.

Fortunately, I did not say something wrong. What I said regarding to IETF standardization, interoperation, coordinate, and compromise is generally right and can be applied.

Best regards,

Sheng

>> The IETF is mainly a standardization organization. Most of efforts in IETF is
>for interoperation. IETF produces a bunch of open standards, no secret at all.
>Then every company can implementation the interface following these
>standards. Of course, there are many internal implementation, which does
>not need interoperation with other devices, and they can be closed or secret.
>Devices can then interoperate with each other as long as the all following the
>same standards.
>>
>> Consequently, the main efforts of standardization actually compromise
>rather than competition. It is all participators to work together towards a
>consensus, which most of people could live with (in which maybe everybody
>have something unsatisfied.) So, people are encouraged to discuss,
>coordinate, merge and make compromises. Working along and producing
>several competition solutions would NOT be good in any standardization
>organizations.
>>
>>>     Brian
>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Mar 2015 09:03:23 +0100

I was corrected after I sent the mail below to the list and learned
something new (after consulting with my co-worker Robert).

The specifications are not yet available to all members but only to a
core group of member companies. They will be made available to the them
probably in June.

If the specs become available publically I will post a link to the list.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Mar 2015 09:28:16 +0100

While I agree with you, Rene, I still think it is useful to look at
other work that is being done (particularly if they appear relevant to
this group).

With regards to the security aspects, I believe at least the following
efforts appear relevant:

 * TR69
 * OMA LWM2M
 * Netconf Zerotouch
 * Certificate management protocols like EST, CMP, etc.
 * IEEE 802.1AR

(Maybe there are others.)

Looking at those examples provides ideas about what worked well and what
didn't.

Ciao
Hannes

On 03/04/2015 04:38 AM, Rene Struik wrote:
>> The IETF is mainly a standardization organization. Most of efforts in
>> IETF is for interoperation. IETF produces a bunch of open standards,
>> no secret at all. Then every company can implementation the interface
>> following these standards. Of course, there are many internal
>> implementation, which does not need interoperation with other devices,
>> and they can be closed or secret. Devices can then interoperate with
>> each other as long as the all following the same standards.
>>
>> rather than competition. It is all participators to work together
>> towards a consensus, which most of people could live with (in which
>> maybe everybody have something unsatisfied.) So, people are encouraged
>> to discuss, coordinate, merge and make compromises. Working along and
>> producing several competition solutions would NOT be good in any
>> standardization organizations.
>>
>>>     Brian
>>>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 05 Mar 2015 12:16:14 +0000

The primary reason for Thread being done in a closed way is to focus on 
the specification and implementation thereof in a tight and controlled 
manner. ZigBee IP, which we did in conjunction with the IETF, resulted 
in continually shifting sands as the specifications kept changing. This 
meant it took a long time, with implementers continually having to 
change code, retest etc. This resulted in a lengthy and drawn out 
development which frankly we can't afford to do in Thread. Sure, there 
are risks with this approach but the aim is to contribute back on the 
"rough consensus and running code" basis. This is not a criticism of the 
IETF at all; it is simply an approach to manage the unpredictability 
which will naturally occur in an open development process. A liaison 
agreement will certainly help and rest assured there are some veterans 
involved in the Thread development who will make sure it is not too weird.

It's no secret that Thread is already based on a number of accepted 
Internet standards (http://threadgroup.org/Downloads.aspx). We have 
already successfully demonstrated Thread running in conjunction with 
another 6LoWPAN implementation, using border routers to connect to a 
server, with end-to-end CoAP transactions taking place. "6LoWPAN" per se 
never has been, nor ever will be an interoperable standard, hence the 
need for activities like Thread and ZigBee IP to ensure that product 
certified as such can be interoperable.

Robert