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
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
