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

["Hedanping (Ana)" <[e-mail]>]

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) <[e-mail]> 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