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: Wed, 25 Feb 2015 14:48:56 +0000

Hi Robert,
Thank you very much for the comments, please see my reply inline.

  > -----Original Message-----
  > From: Robert Cragie [mailto:[email-masked]]
  > Sent: Friday, February 20, 2015 7:59 PM
  > To: Hedanping (Ana); Michael Richardson
  > Cc: [email-masked]; [email-masked]; [email-masked]
  > Subject: Re: [6lo] Comments needed for Security Bootstrapping of IEEE
  > 802.15.4 based Internet of Things
  > 
  > 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.
  > 

<A>
IMHO, there are distinctions between the network level bootstrapping and joining device level bootstrapping. Network level bootstrapping includes at least two cases: network start-up case and re-commissioning case. The bootstrapping network level bootstrapping request should be different from that of joining device level request in order to converge efficiently. I agree that they need to be clarified.

>From authentication messaging point of view, there is no much distinction between RFD and FFD. This feature allows scalability and we don't need to reinvent the wheel and develop different authentication message for different types of devices.
</A>

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

<A>
 ' can't be directly used' means that fragmentation is needed and certificate management is needed once 802.1AR is applied.
Thank you for providing this application information, the expression will be modified in the next version.
</A>

  > * The document mentions a couple of protocols (EAP and PANA) but doesn't
  > go into enough detail on how those are deployed. 

<A>This is the initial version, we expect to reach consensus on the mechanism and architecture at first.</A>

  >Also, there are other
  > choices. The document could give generic names to the particular
  > communications and then add a section to give examples.

<A>Good point. We are preparing to do so. The certificate approach you implemented is useful, are you willing to contribute to the new section?</A>

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

<A>This draft targets at 802.15.4 networks, and one standard approach is possible. It is worth of generalizing an automatic mechanism for bootstrapping IoT network. As the size of the network can be large, network start-up or re-commission will be the burden of the network administrator.</A>
  
  > 	>
  > 	>    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>I agree that the handshake process is similar, however DTLS and UDP is supported by CoAP and match the feature of constrained device. Reusing the protocols can reduce the HW and SW cost. Besides, EAP-TLS only supports certificate as authentication material, while allowing other materials would be desired for IoT network.</A>

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

<A>That's great, we'll discuss more and move this work forward.</A>

  > 
  > 	> 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>
  > 
  > 
<A>Agree</A>
  > 
  > 	>
  > 	> 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>
  > 
  
<A>I am not sure whether I understand the meaning of 'session'.</A>

  > 
  > 
  > Regards,
  > Ana
  > 
  > _______________________________________________
  > 6lo mailing list
  > [email-masked]
  > https://www.ietf.org/mailman/listinfo/6lo
  >

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Feb 2015 08:06:22 +1300

Hi,

On 26/02/2015 03:48, Hedanping (Ana) wrote:
...
> IMHO, there are distinctions between the network level bootstrapping
> and joining device level bootstrapping. Network level bootstrapping 
> includes at least two cases: network start-up case and re-commissioning
> case. The bootstrapping network level bootstrapping request should be
> different from that of joining device level request in order to converge
> efficiently. I agree that they need to be clarified.

How does a device that has just been switched on know whether it
is joining an existing network or is simply one of many devices that
are attempting to form a new network?

How does a set of devices that are attempting to form a new network
know that they are re-commissioning a previously existing network?

The only safe assumption seem to be that devices cannot know
these things. Autonomic devices have no state at power-on.

   Brian

---

From: "Hedanping (Ana)" <[email-masked]>
Date: Thu, 26 Feb 2015 06:18:07 +0000

Hi Brian,
Please see my reply inline.

 > From: 6lo [mailto:[email-masked]] On Behalf Of Brian E Carpenter
 > Sent: Thursday, February 26, 2015 3:06 AM
 > To: Hedanping (Ana); [email-masked]; Michael Richardson;
 > Behcet Sarikaya
 > Subject: [6lo] Device vs network bootstrapping [Comments needed for Security
 > Bootstrapping of IEEE 802.15.4 based Internet of Things]
 > 
 > Hi,
 > 
 > > includes at least two cases: network start-up case and
 > > re-commissioning case. The bootstrapping network level bootstrapping
 > > request should be different from that of joining device level request
 > > in order to converge efficiently. I agree that they need to be clarified.
 > 
 > How does a device that has just been switched on know whether it is joining
 > an existing network or is simply one of many devices that are attempting to
 > form a new network?
 > 
The device can learn from its neighbors about the network state. For instance, from the bits indicating network ID and device type in hello/beaconing message, the device knows whether a neighbor belongs to an existing network or it is a 'new' device as well, and whether the neighbor has ability to forward/verify authentication message.

 > How does a set of devices that are attempting to form a new network know
 > that they are re-commissioning a previously existing network?
 > 
Again, the state can be learnt by exchanging the network ID that devices belonged to

 > The only safe assumption seem to be that devices cannot know these things.
 > Autonomic devices have no state at power-on.
 > 
The devices cannot know these things by themselves, but through collaboration it is possible. From this aspect, I do not object that autonomic devices have no state at power-on.

Regards,
Ana

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Feb 2015 08:23:43 +1300

Below...

> The devices cannot know these things by themselves, but through collaboration it is possible. From this aspect, I do not object that autonomic devices have no state at power-on.

OK. With my Anima hat on, I see a strong need for a solution that does
not have any specific L2 technology dependence. What you describe here
works for a specific technology with specific bits set in L2 packets.
What we need is a generic solution that doesn't care about which L2
technology is involved, because we are trying to establish trust at
a level above L3 routing.

    Brian

---

From: Kent Watsen <[email-masked]>
Date: Thu, 26 Feb 2015 21:53:16 +0000

>a level above L3 routing.

Agreed.  This is why the netconf-zerotouch drafts have emphasized devices
downloading signed documents, so that it does not matter how the documents
are obtained (usb flash drive vs network, ip vs. optical, v4 vs v6, etc.).

That said, the big difference I see in the homenet/anima vs Enterprise/SP
scenarios is a notion of the device having an "owner".  The NETCONF
ZeroTouch solution keys off tying a serial-number to an "owner" that has
staged some config for the device to find, whereas homenet/anima are more
about having someone in the local environment (e.g, the home) do something
to associate trust between the instance and network.

I believe that these are irreconcilable differences that will drive the
solutions to difference ends.

Kent

---

From: Kris Pister <[email-masked]>
Date: Thu, 26 Feb 2015 14:31:59 -0800

Brian -

 > a level above L3 routing.

This is a fine goal, and it may be exactly what 6lo or some other
group should be working on, but I think that it is out of scope for 6tisch.
What we need to do is figure out who to trust to configure a very specific
L2, with very specific constraints.  If we can leverage other more general
work that's great, but the constraints of 4e/TSCH are likely to push
6top-configuration trust in a different direction.

ksjp

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Feb 2015 12:02:56 +1300

> 6top-configuration trust in a different direction.

That sounds absolutely reasonable, as long as the various WGs involved
are aware of their own scope and the potential for overlaps. I think
Anima has to ride over these various solutions (and be versatile, since in
some scenarios we can expect pre-registration and in others we can't,
to answer Kent's point).

    Brian

>>> The device can learn from its neighbors about the network state. For instance, from the bits indicating network ID and device
>>> type in hello/beaconing message, the device knows whether a neighbor belongs to an existing network or it is a 'new' device
>>> as well, and whether the neighbor has ability to forward/verify authentication message.
>>>
>>> The devices cannot know these things by themselves, but through collaboration it is possible. From this aspect, I do not
>>> object that autonomic devices have no state at power-on.