Subject: [Dtls-iot] Comments on draft-keoh-dice-multicast-security-01

From: Michael StJohns <[email-masked]>
Date: Mon, 18 Nov 2013 19:35:09 -0500

This is mostly a recap of comments I made at the mike in the DICE 
meeting at the last IETF.

There's always some confusion about what exactly is meant by multicast 
and whether it's necessary for any given application.
  For the purposes of this document, I'm assuming multicast is a L3 
store and forward of IPv6 packets from neighbor to neighbor and that 
there is no required dependence on L2 broadcast.

<opinion>In general, multicast is an attractive nuisance. Attractive, 
because it allows for a single transmitted message to be sent to many 
recipients without any special programming on the part of the sender.  A 
nuisance because we don't actually understand the security limitations 
of multicast and unfortunately, this document doesn't advance that 
understanding.

Multicast is useful as an information dissemination tool, IFF that 
information can be separately validated (e.g. application layer public 
key signatures or some other method).  It *may* be useful as a tool for 
a control protocol, but symmetric key multicast security at the L3/L4 
layer should NEVER be considered strong enough for cyber-physical 
systems that may have a health and welfare affect (e.g. power grid, 
medical, SCADA, automobile traffic management etc).</opinion>

Specific comments on the document:

1) The selection of the group key negotiation protocol.  Over the years, 
there have been at least 3 of these submitted to the IETF. Two of them 
(including the one cited in this draft) are Informational.  The other is 
standards track.  There's no discussion of why RFC3740 was selected over 
RFC4535 GSAKMP.   Ideally, there should be a group key management 
requirements document first before the group adopts an implementation 
proposal.

2) The key material should be bound to sender IP and port, not just 
sender.  There's no requirement that a multicast group serve only a 
single application and you need a way of differentiating key material 
for multiple applications.

3) The security section needs to include a discussion about the perils 
of common or group keying with respect to integrity, origin 
authentication and participant compromise.  The security section as 
written is a throw-away.  Specifically, symmetric key protected 
multicast provides no origin authentication and the compromise of a 
single node compromises the entire protections of a multicast tree. If 
the tree is small enough - e.g. something like a single house with a 
common physical perimeter and common security domain - this is 
manageable.  For something like an IOT of 10K or larger items, probably 
not manageable.

4) It's unclear that DTLS (or more specifically DTLS packet formats) are 
the proper fit for a secured multicast.  I understand why this might be 
an attractive approach (e.g. not having to actually design the formats, 
reuse of code), but a poor fit is worse that doing it at all.  As I 
noted during the discussion, at the very least, the assigned 16 bit ID 
imposes a number of limitations.

5) During the session, the author cited David McGrew's AERO proposal.  
That proposal has some interesting properties, but also has significant 
limitations.  Before going down that path, it would be better to 
understand the actual scope needed for a secure multicast design (if 
indeed it is actually needed) for the IOT. E.g. common or non-common 
security domain?  Size of multicast group? Scope of the multicast 
group?  Sparse or dense multicast?  Can each hop be re-keyed (e.g. nodes 
only share keys with neighbors rather than all nodes in a multicast tree 
sharing a key).

Mike

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Wed, 20 Nov 2013 15:22:34 +0000

Dear Mike

Thanks again for the detailed comments. See reply below

> -----Original Message-----
> From: dtls-iot [mailto:[email-masked]] On Behalf Of Michael
> StJohns
> Sent: Tuesday, November 19, 2013 1:35 AM
> To: [email-masked]
> Subject: [Dtls-iot] Comments on draft-keoh-dice-multicast-security-01
>

[SK] You are right about this and we did explain is section 3.1 that it is based on IPv6 multicast. Since we intend to secure the CoAP group communication, more details of how the group communication works is referenced to I-D.ietf-core-groupcomm. We can make it more clear in the next version.
> recipients without any special programming on the part of the sender.
> A nuisance because we don't actually understand the security
> limitations of multicast and unfortunately, this document doesn't advance that understanding.
>
> key signatures or some other method).  It *may* be useful as a tool
> for a control protocol, but symmetric key multicast security at the
> L3/L4 layer should NEVER be considered strong enough for
> cyber-physical systems that may have a health and welfare affect (e.g.
> power grid, medical, SCADA, automobile traffic management
> etc.).</opinion>

[SK] Value your opinion. There are indeed stronger multicast security protocols defined at the IP layer and if devices have the resources, we would recommend using them. The current draft is for the constrained devices which  already have DTLS for unicast (which is mandatory for CoAP) but does not have additional resources to implement yet another security protocol to secure the multicast communication. This is more to avoid that the multicast is left unsecured in such scenarios.
> 1) The selection of the group key negotiation protocol.  Over the
> years, there have been at least 3 of these submitted to the IETF. Two
> of them (including the one cited in this draft) are Informational.  The other is standards track.
> There's no discussion of why RFC3740 was selected over
[SK] We do *not* recommend or select any specific key negotiation protocol in the draft. The key management was unfortunately kept out of scope of the DICE charter. Indeed it would be ideal to reuse what IETF has already standardized if it fits the requirements. I agree we need to create a requirements document for the KMP before any implementation proposal for KMP. For the present draft, the keys are assumed to be on the devices out-of-band which needs to be replaced with the appropriate KMP. We will remove the existing small discussion on the KMP in the present draft in the new version to avoid any confusion of the present scope of the draft.
[SK] The discussion on KMP comes up again every so often and we think an extension of the scope of DICE is needed here. This probably requires a different discussion thread.
>
> 2) The key material should be bound to sender IP and port, not just sender.
> There's no requirement that a multicast group serve only a single
> application and you need a way of differentiating key material for multiple applications.
>
[SK] Agree for unicast. For multicast it should be bound to the destination IP and port. We will add the port which is missing now.

> authentication and participant compromise.  The security section as written is a throw-away.
> Specifically, symmetric key protected multicast provides no origin
> authentication and the compromise of a single node compromises the
> entire protections of a multicast tree. If the tree is small enough -
> e.g. something like a single house with a common physical perimeter
> and common security domain - this is manageable.  For something like
> an IOT of 10K or larger items, probably not manageable.

[SK] Agree, the security section needs more organization. Origin authentication issue and object based security solution has been already mentioned in the draft but we can make it more explicit in the security considerations section.
>
> 4) It's unclear that DTLS (or more specifically DTLS packet formats)
> are the proper fit for a secured multicast.  I understand why this
> might be an attractive approach (e.g. not having to actually design
> the formats, reuse of code), but a poor fit is worse that doing it at
> all.  As I noted during the discussion, at the very least, the
> assigned 16 bit ID imposes a number of limitations.
[
[SK] The 16-bit provide for about 2^(16) unique senders (not members, they can be even larger) in a single multicast group. This is quite large for all use cases of number of devices sending in a single multicast group that require this security solution. We can make the scenarios more clear to make the choice of 2 byte Sender ID more clearer.
> That proposal has some interesting properties, but also has
> significant limitations.  Before going down that path, it would be
> better to understand the actual scope needed for a secure multicast
> design (if indeed it is actually
> needed) for the IOT. E.g. common or non-common security domain?  Size
> of multicast group? Scope of the multicast group?  Sparse or dense multicast?
> Can each hop be re-keyed (e.g. nodes only share keys with neighbors
> rather than all nodes in a multicast tree sharing a key).

[SK] The AERO proposal was more an open question to the WG since it was suggested in the review by John Foley. The final impression I got during the meeting is that there is a strong need to keep the solution flexible, independent of any single crypto suite, due to different regulations in different countries.

[SK] Regarding the scope of the draft, a better description of the use cases and scenario in the next version should clarify the design decisions.
>
>
>
> Mike
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.