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

[Behcet Sarikaya <[e-mail]>]

 Hi Robert,

 Thank you for your comments.


On Fri, Feb 20, 2015 at 5:59 AM, Robert Cragie
<[e-mail]> wrote:
> 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.


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
> 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) <[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.
>
> <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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>
>
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>