Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

[Michael StJohns <[e-mail]>]

As I mentioned at the microphone I'm opposed to pursuing symmetric key 
multicast solutions.  WRT to the current set of proposal documents, I 
see no substantive improvement on the rejected proposals from the DICE 
(https://mailarchive.ietf.org/arch/search/?email_list=dtls-iot) working 
group.  The topic of symmetric key multicast security came up fairly 
early in the WG 
(https://mailarchive.ietf.org/arch/msg/dtls-iot/jRL-bZwFpEK-P19S0b0CFXFfMBA) 
and went on for most of the life of the working group before being 
finally killed due to an agreement that the problems could not be resolved.

For a detailed discussion of the issues, please see that archive and 
mostly substitute "ACE group communications" wherever you see "DTLS 
multicast" or similar.  The discussion points mostly apply to both.

My specific objection is that protocols that affect (or have the 
potential to affect) the physical world (e.g. by turning on lights, by 
setting off a fire extinguisher, by opening or locking doors, by turning 
on or off heating or cooling, etc), need to be secure enough to not 
present a danger to health and safety.  Using multicast, specifically 
using a symmetrically keyed multicast, to authenticate an actuator 
operation has the general property of - without specific mitigation - of 
not being secure enough in the general case.


That conclusion comes from the FACT that compromising ANY device that 
shares the multicast or group communication key is all that is necessary 
to get the key material necessary to masquerade as the controller of the 
group.  Since both the controllers and the controllees share the same 
keys, there is no secure way using only those symmetric keys to 
differentiate between controller/controllee for the purposes of 
authenticating a command.

The possible approaches for mitigation are few (and mostly discussed in 
DICE):

1) Place the multicast group key management protocol and related 
functions inside a secure element.  The work factor to penetrate any 
single secure element becomes the work factor to compromise the group.  
This particular mitigation is difficult to specify/enforce in an IETF 
protocol.

2) Use multicast group keys for confidentiality only and provide source 
authentication through the use of public key systems.

3) Limit the use of any given group key to a small group of mostly 
homogeneous actuators and controllers in a physically contiguous area.  
Basically, the work factor to penetrate any element is on the order of 
the work factor to enter the physical space at which point you probably 
manually change the state of the controlled device. This doesn't provide 
a general solution, but may be acceptable in the ACE space.  It would be 
enforced in the protocol by - for example - limiting the size of the 
node participant identifiers to 3 or 4 bits (8 or 16 elements) and by 
limiting it to 2 physical hops or so.

4) Limit the field of use by protocol and document constraints (e.g. 
Apply (3) above plus calling this the "Lighting Control Protocol Security").

5) Limit the protocol use to data transmission only - with no 
cyber-physical actuations being possible.  (E.g. no messages cause any 
changes in the real world).

It's probable that none of these are acceptable constraints for ACE - in 
which case if this work item is accepted, ACE may find itself in the 
same position of DICE in 2 years.

Mike