On 9/26/2016 12:10 PM, Eliot Lear wrote:
Hi Mike,
Just one clarification:
On 9/26/16 5:41 PM, Michael StJohns wrote:
With respect to Eliot's comment, it doesn't really matter if the key
management protocol is asymmetric if the multicast session keys are
symmetric and used for control.
This doesn't really capture my position which leads me to believe I've
muddled it. The key question is whether every transaction needs to be
authenticated to a unique device *within this protocol* or is it
sufficient that such authentication exists at other layers, e.g., either
in content or at lower layers? I recognize that there are some big
risks to adding such a dependency, because there is no certainty that
implementations will follow that guidance.
Hi Eliot -
Ah - sorry, I didn't understand what you meant.
Let me discuss a few more things and hopefully that will clarify things.
Multicast traffic falls into three broad groups: Content (e.g.
broadcast audio/video etc), sensor and control.
Of these three, only the first has a real (non-mitigated) symmetric key
story: if you can break into an end node to steal its copy of the
multicast key, you can break into an end node to steal the content, so
the compromise of the multicast key and the compromise of the node have
similar impacts. In other words, the risk of using symmetric key
multicast is no worse than the risk of using symmetric key unicast.
For the other two, it comes down to source authentication: being able
to forge either a control command or a sensor datum can have *bad*
consequences (e.g. having the sensor tell you that the coolant level in
the cooling pond for nuclear rods is too high so you pump out what you
think is the excess; having a key extracted from an actuator node
telling the pump to go on). In the latter two cases, breaking into the
node can allow you to do more than the node is legitimately authorized
to do, and can allow you to masquerade as any node that uses that key
for authentication. In this case, using symmetric key multicast is
*MUCH* worse than using symmetric key unicast with respect to the
security guarantees.
So far so good?
In the instant case - lighting - there's really no secret content to
speak of, and hence the content confidentiality model of multicast with
symmetric keys is really inapplicable. So, if confidentiality isn't a
really a requirement, and you can't achieve source authentication
(required for sensor or control) with symmetric key multicast, why do it?
The analysis of this can pretty much ignore the key management piece
and start with 100 controllers and 1000 actuators with pre-shared keys
to consider the threat and mitigation models. Which analysis - AFAICT
- no one has actually done. Basically, if you can't secure this
100/1000 system and keep it secure with respect to control functions,
I would argue that the rest of it (e.g. key management) is meaningless
window dressing.
The question in this context again, is whether it all has to happen at
this layer?
Can you figure out any way to prevent implementers and designers from
using the symmetric multicast key for authentication? If so, then the
answer is yes, If not, then no. This is what I've been talking about
when I say "crippling" the protocol to prevent the abuses. You might as
well do an all in one secure protocol at this level rather than leaving
this an exercise for the student. That's not to say that application
layer protocols might not also have their own authentication.
Later, Mike
Eliot
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
