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

From: Michael StJohns <[email-masked]>
Date: Mon, 09 Dec 2013 13:45:28 -0500

Sorry for the delay in responding - holidays and other things intruded.

On 11/20/2013 10:22 AM, Kumar, Sandeep wrote:
> 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
>>
>> 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.
> [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.
>> <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>
> [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.

I'm not convinced this is a viable approach for various reasons. First 
figure out *exactly* what your multicast applications are, figure out if 
they are control applications or information applications, etc.  Then 
figure out how to secure the application. Don't just throw in multicast 
DTLS because you don't want to implement yet another security protocol.  
If the devices are too small for another protocol, then don't expect 
them to play in multicast either.

>> 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.
> [SK] We do *not* recommend or select any specific key negotiation protocol in the draft.
Section 2.2 (i) reads as if you're suggesting building on 3740 and 4046 
- as if that path has already been decided.
> 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.
Before we start getting to key management, let's ensure that multicast 
is actually required to meet the application needs.  Given that most of 
what you're talking about is L3 store and forward multicast, then its 
unclear why the link layer keys between neighbors isn't sufficient 
security and why a multicast specific security mechanism is required.  
At the most (maybe useful for efficiency) having a sending node share a 
common key with each of its neighbors for any "multicast" packet it 
sends may be a reasonable tweak.

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

Actually, why not bind it to source/destination address/port like all 
other security mechanisms?

>
>> 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.
> [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's one example, but not what I actually meant.  DTLS has its own set 
of assumptions in its design and those assumptions do not necessarily 
stretch to cover multicast.  Given that DTLS was pretty much crafted out 
of TLS which was definitely a two party protocol, its unclear DTLS 
should even be the starting point for a multicast based solution.  Its 
probably overly optimistic to declare DTLS as the starting point and not 
expect substantial restructuring to actually accomplish the multicast goals.

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

Ideally, the next draft should not mention DTLS at all and instead focus 
on "Multicast requirements for IOT devices in small (5-50), medium 
(50-500) and large (500+) clusters"

Just a thought -

Mike

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

---

From: peter van der Stok <[email-masked]>
Date: Mon, 16 Dec 2013 09:43:50 +0100

Hi Mike,

Just a small answer to the questions you ask about the necessity for 
multicast.
In the Roll working group I submitted the expired draft 
draft-vanderstok-roll-mcreq-02.
Also you find some motivation in the ietf-core-groupcomm draft.
In short:
multicast is needed by a sensor or switch to send commands over a 
wireless network to a group of nodes (lights for our purposes)
Multicast source and MC destinations often are within the same wireless 
network.
The end to end delay should be less than 250 ms.
The source may be outside the wireless network and the request passes 
the border router before being distributed to all sources.
Doing the multicast with a set of unicasts is not workable (takes too 
long, takes too many resources).
With the right parameter settings MPL seems to do the job in networks 
where the number of hops is limited to 10.

We intend to use CoAP/UDP for transport of the Multicast message. CoAP 
brings along the use of DTLS.

Other multicast requirements come from the use of mDNS (but the time 
constraints and security constraints are different).

Does this answer some of your concerns?

Greetings,

peter

> figure out *exactly* what your multicast applications are, figure out
> if they are control applications or information applications, etc.
> Then figure out how to secure the application. Don't just throw in
> multicast DTLS because you don't want to implement yet another
> security protocol.  If the devices are too small for another protocol,
> then don't expect them to play in multicast either.
> 
> is actually required to meet the application needs.  Given that most
> of what you're talking about is L3 store and forward multicast, then
> its unclear why the link layer keys between neighbors isn't sufficient
> At the most (maybe useful for efficiency) having a sending node share
> a common key with each of its neighbors for any "multicast" packet it
> Ideally, the next draft should not mention DTLS at all and instead
> focus on "Multicast requirements for IOT devices in small (5-50),
> medium (50-500) and large (500+) clusters"
> 
> Just a thought -
> 
> Mike