I haven't had a chance to comment on the document, but I have a few
comments on the below that will depend on getting the requirements correct.
In the introduction of the document you list three requirements and Jim
has taken you to task for them. There are actually four requirements,
one of which no one is willing to state in this document. The fourth
being "The security can't cost anything in terms of either latency or
hardware assistance" - or something similar. Otherwise, we wouldn't be
having the argument about symmetric key multicast.
Finally, we're missing an actual security requirement that may or may
not be optional: "The compromise of any given end point will not give
the attacker more privileges in the group that the compromised end point
nominally has been granted". This one is where the applicability
statement comes in.
On 2/6/2017 3:00 PM, Somaraju Abhinav wrote:
Jim, All,
please see a proposal for the Applicability statement that can be used
as a starting point for the Webex.
Abhinav
5.1 Applicability statement
This document describes two architectures based on symmetric group
keys in Section 3 and asymmetric keys in Section 4.
The symmetric key solution is based on a group key that is shared
between all group members including senders and receivers. As all
members of the group posses the same key, it is only possible to
authenticate group membership for the source of a message. In
particular, it is not possible to authenticate the unique source of
a message and consequently it is not possible to authorize a single
node to control a group. This implies in particular that any hacked
receiver in a group could then be used to control all the receivers in
the group.
Moreover, because the group key is shared across multiple nodes, it
may be easier for an attacker to determine the group key by attacking
any member of the group (note that this group key is dynamically
generated and is usually stored in volatile memory which offers some
additional protection). The probability of a stolen key increases with
the number of nodes that are in possession of the key. Moreover,
subsequent to such an attack, it is also difficult to determine which
of the group members was compromised and this makes it difficult to
return the system to normal operation after an attack.
The asymmetric key solution distinguishes between a sender in the
group and the receivers. In particular, the sender is in possession of
a private key and the receivers are in possession of the corresponding
public key. This allows the unique source of any group message to be
authenticated. Moreover, an attacker cannot compromise the system by
breaking into any of the receiving nodes. However, for constrained
devices, the asymmetric key solution comes at a processing cost with
cryptographic computations taking rather long.
See below - you need to provide some proof of this. Or at least figure
out the asymmetric key size and implementation where it takes too long.
Therefore, it is recommended that whenever possible, the architecture
with source authentication SHOULD be used to secure all multicast
communication. However, in less sensitive applications where
low-latency group communication is important (e.g. controlling
luminaires in non-emergency applications), the architecture without
source authentication MAY be used. In sensitive applications such as
health and safety, building security and emergency applications the
symmetric key based solution SHOULD not be used.
This paragraph is pretty much wishful thinking and hand waving. It makes
an unproved assumption that source authentication is too expensive (in
latency or hardware) and that some measure of security may be gained by
using the group key to protect the group message integrity - including
the control messages.
Even a weak asymmetric key (which evidence suggests *can* be used in a
manner to meet latency requirements) will provide a more secure source
authentication mechanism than a symmetric key system.
When using the symmetric key solution two mitigating factors could
improve system security. It is possible to achieve source
authentication of messages at lower layers by requiring unique MAC
layer keys for all devices within the network. The symmetric group
keys are dynamically generated and therefore SHOULD be stored in
volatile memory.
Seriously - no. To validate a MAC signed object, you need the MAC key
which means you can forge things as if they came from the MAC key
owner. Unless you're talking specifically about pair-wise MAC keys,
this makes no sense whatsoever.
For the meeting, what I'd like to hear about is:
1) The actual minimum latency value and how it was picked.
2) The target minimum hardware and how it was picked.
3) The security policy for "Controlling luminaries in a non-emergency
application". E.g. Do you actually care about security here, or is this
just marketing? Or put another way, what security assurances do you get
from implementing symmetric key multicast in a control system? What is
the liability to the product provider if the system is hacked? What's
the detection mechanism for figuring out you've been hacked (besides the
obvious one of the lights going on and off without the switch being
thrown)? Can this protocol be used in this specific mode for any other
application - and if so, which ones?
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
