Subject: Re: [Ace] Group Communication Security Disagreements

From: Michael StJohns <[email-masked]>
Date: Fri, 9 Sep 2016 15:44:21 -0400

Hi -

It's been over a month since there's been any further discussion on this 
topic.   Given the record I would suggest a lack of consensus to proceed 
on basis of two items:  1) A roughly even split on the vocal yays and 
nays on the subject of symmetric key multicast for control functions and 
2) a failure to address the specific concern of "How do you enforceably 
keep a cheap, unsafe-in-the-broader-internet security mechanism off the 
broader internet?"

Your mileage may vary.

Mike

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 12 Sep 2016 09:32:15 +0200

> keep a cheap, unsafe-in-the-broader-internet security mechanism off the

Can we at least agree to work on group communication with source 
authentication?

/Ludwig

-- 
Ludwig Seitz, PhD   SICS Swedish ICT AB
Ideon Science Park, Building Beta 2
Scheelevägen 17, SE-223 70 Lund
Phone +46(0)70-349 92 51

The RISE institutes SP, Swedish ICT and Innventia are merging in order 
to create a unified institute sector and become a stronger innovation 
partner for businesses and society. At the end of the year we will 
change our name to RISE. Read more at www.ri.se/en/about-rise

---

From: Eliot Lear <[email-masked]>
Date: Tue, 13 Sep 2016 11:34:22 +0200

Hi Ludwig and Mike,

In thinking about this problem, I wonder if the challenge here really is
a matter of layering.  First of all, if we were to do source
authentication, what would that mean?  Would it mean that all messages
were signed?  If so, what sort of format would we be talking about? 
IPSEC-AH?  Higher?  I state this because typically, although by no means
always, we have at least some separation between protocol and content. 
I just wonder where that line would be here.

I agree that source authentication is important, both in terms of group
joins and in terms of message content for all the reasons previously
stated.  I just wonder if we need to specify all of that in this WG, or
if we can state what we think the right answer is above or below.**

Eliot

On 9/12/16 9:32 AM, Ludwig Seitz wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Somaraju Abhinav <[email-masked]>
Date: Wed, 14 Sep 2016 09:33:28 +0000

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.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Sep 2016 12:10:00 +0200

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

---

From: Michael StJohns <[email-masked]>
Date: Thu, 15 Sep 2016 11:36:18 -0400

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.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 16 Sep 2016 12:03:34 +0200

Hi Mike,

On 9/15/16 5:36 PM, Michael StJohns wrote:
>   * Cyber Physical control functions (C)  require source
>     authentication  (A):  (C -> A)
>     securely by Symmetric Key Multicast (^B):  (D -> C) ( C -> A) (D
>     -> C -> A) ( D->A) (A -> ^B) (D -> ^B).
>
All of this seems about right to me, but with two big caveats:

 1. We are, I think, talking about group-based communications and not
    necessarily group-based authorization for device control.  There is
    a difference, albeit subtle.  One could reasonably envision
    borrowing from lower layers to satisfy device authorization
    requirements.

 2. The question here is whether this is the right level to address the
    problem.  And I'll ask my clarifying question again: is there a more
    logical place to anchor identity, like above or below this layer?

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Fri, 16 Sep 2016 12:39:35 -0400

On 9/16/2016 6:03 AM, Eliot Lear wrote:
>>   * Turning on and off lights (D) is a Cyber Physical Control
>>     Function (C):  (D -> C)
>     necessarily group-based authorization for device control.  There
>     is a difference, albeit subtle.  One could reasonably envision
Sorry - we've really been talking about using symmetric key multicast 
for control functions.  (cf all the discussions on lighting control and 
the ever reducing maximum latency requirement).   Authorization is 
really about whether or not a given entity accepts and acts on a given 
authenticated message.  Trying to parse this as group comms (which I 
took you to mean "secure group comms") vs group authorization is really 
a red herring here as you can't have meaningful authorization without 
meaningful authentication and so far, we haven't gotten that far.

>  1. The question here is whether this is the right level to address
>     the problem.  And I'll ask my clarifying question again: is there
>     a more logical place to anchor identity, like above or below this
>     layer?
>

This is mostly an irrelevant question at this point.  Once we agree that 
symmetric key multiparty (N>2 or 3 in the case of a kerberos system) 
authentication is off the table, then talking about which level to put 
this reduces down to either per application  or per device and the 
associated protocols for each of those.  It's entirely possible a 
message might be authenticated by credentials at multiple protocol 
layers depending on who owns what in the mesh.

Later, Mike