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

[Tero Kivinen <[e-mail]>]

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. 
> I think EAP over DTLS /profiled DTLS could be a good option.

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