Hi Elliot et al -
Sorry, I think you're still missing the point:
* Source Authentication (A) cannot be accomplished securely by
Symmetric Key Multicast (^B): (A -> ^B)
* Cyber Physical control functions (C) require source authentication
(A): (C -> A)
* Turning on and off lights (D) is a Cyber Physical Control Function
(C): (D -> C)
* Therefore Turning on and off lights (D) requires source
authentication (B): (D -> C -> A) (D -> A)
* Therefore Turning on and off lights (D) cannot be accomplished
securely by Symmetric Key Multicast (^B): (D -> C) ( C -> A) (D ->
C -> A) ( D->A) (A -> ^B) (D -> ^B).
Apologies if I got the formal logic wrong - its been a while.
The above seems to be pretty clear. You might argue the second line,
but if you do, you pretty much argue that some forms of cyber physical
control require no security at all. In which case, defining a security
protocol which implements symmetric key multicast for control function
authentication still makes no sense and is probably still not a useful
candidate for adoption.
What I'd suggest at this point is that *_the lighting folk go away and
huddle together to produce a document that they submit independently as
an "Informational" _*"this is how *we* do it" document rather than
trying to turn this into an Internet Standard. Given that there seems
(seems ~= I haven't heard any other group step up claiming they'd find
this approach both useful (and mandatory - cf latency and cost issues)
for their specific problem) to be no other use case besides lighting,
that may be the best approach overall.
This is either a general purpose protocol, in which case it needs to be
at least conditionally secure for all cases, or it is a protocol that
applies to a very very limited set of functionality in which case it is
probably not an IETF problem to be solving.
Later, Mike
ps - so far this discussion hasn't varied much from the discussion in DICE.
On 9/14/2016 6:10 AM, Eliot Lear wrote:
Hi Abhinav,
Thanks for this email. I think this is pretty close to what I think is
necessary. To be sure, vendors and developers have very little power to
limit where their products will be placed. Thus it is important to
state strongly that source authentication is necessary at other layers
when it is not used at this layer. To me that would cover all
circumstances. With that approach, I would strongly support the
adoption of your document as a WG document and would of course review it
and provide comments (as I have ;-).
Regards,
Eliot
On 9/14/16 11:33 AM, Somaraju Abhinav wrote:
Hi all,
Thank you all for the feedback on the group communication security discussion.
We noticed that two concerns have been raised with the current specification.
1) Symmetric keys do not provide source authentication. Here, most people on
the mailing list agreed that symmetric keys provides basic security and is
sufficient for lighting applications. It is not intended to be used in the
wider internet for more sensitive group communication security use-cases.
2) How to ensure that the symmetric key group communication security solution
is not used in situations it is not designed for?
We propose to address the received feedback by making the following
modifications to the document:
1) We will add an additional section where we specify how asymmetric
cryptography can be used for secure group communication. This will help for all
those cases where source authentication is desired.
2) Add a security considerations section where we explain that the asymmetric
key solution is the recommended approach but that there are situations where
low latency group communication makes it difficult to use asymmetric
cryptography and where source authentication is less important. You could call
it an applicability statement.
If this proposed modifications makes sense then we can try to submit a new
draft with these changes.
Abhinav
________________________________________________________ The contents of this
e-mail and any attachments are confidential to the intended recipient. They may
not be disclosed to or used by or copied in any way by anyone other than the
intended recipient. If this e-mail is received in error, please immediately
notify the sender and delete the e-mail and attached documents. Please note
that neither the sender nor the sender's company accept any responsibility for
viruses and it is your responsibility to scan or otherwise check this e-mail
and any attachments.
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
