Subject: [Ace] Summary of ACE Group Communication Security Discussion

From: "Kepeng Li" <[email-masked]>
Date: Tue, 27 Sep 2016 01:11:01 +0800

Hi all, 

We went through all email exchanges again in order to see where we are.
Abhinav also proposed a way forward in his email to the list, see
https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, where he
proposed to standardize a solution based on public key as well as symmetric
key cryptography. 

Here is our impression of the views presented by various people.

Mike seems to think the only acceptable solution is to use messages signed
using public key crypto and is strongly against working on a symmetric key
group communication protocol.

Paul Duffy and Michael Richardson are in favor of defining a public key
crypto solution but it is not clear whether they are against specifying a
symmetric key solution as well.

Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric key
group communication security protocols (as co-authors of the work). Oscar
Garcia (Philips) is also in favor of the work.

In this mail to the list, see
https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, Robert
Cragie (ARM) expressed a view that public key crypto is the preferred
solution but others based on symmetric crypto are still worthy of
consideration.

Markus Grunwald (Osram) also appears to be in favor of the proposed
approach, see 
https://www.ietf.org/mail-archive/web/ace/current/msg01932.html
 
Akbar Rahman also seems to be in favor of working on a group communication
security protocol, see
https://www.ietf.org/mail-archive/web/ace/current/msg01873.html
 
Ned Smith also seems to be in favor of working on a group communication
security protocol, as expressed in his mail to the list:
https://www.ietf.org/mail-archive/web/ace/current/msg01872.html
 
The opinion of the following persons in the discussion appear unclear to me:
- Mohit Sethi
- Ludwig Seitz
- Carsten Bormann
- Stephen Farrell 
- Jim Schaad (offered clarifications regarding the use of COSE)
 
Pascal Urien and Rene Struik provided performance data but they didn't
appear to have expressed a strong view about the question regarding
symmetric vs. asymmetric crypto for group communication security.
Derek Atkins offered performance data for public key crypto but refers to
new techniques (rather than RSA/ECC).
 
Please correct us if we are wrong in our interpretation of your mail
postings.
 
Ciao
Hannes & Kepeng

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Sep 2016 13:04:43 +0200

Hi,

> Please correct us if we are wrong in our interpretation of your mail

Perhaps my middle ground didn't seem important, but I had thought it was
a good way forward: require asymmetric for group admission (as Abhinav &
co do), group keying for communication and require source authentication
at other layers.  I otherwise supported his proposal.

I do take Mike's point that the standard wouldn't be self-contained, and
there are risks of it being used without that additional layer beyond
its applicatbility.  I still think the middle ground approach is best,
given some of the use cases.

Eliot

Subject: Re: [Ace] Group Communication Security Disagreements
From: Eliot Lear <[email-masked]>
To: Somaraju Abhinav <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 14 Sep 2016 12:10:00 +0200
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Sep 2016 13:11:00 +0200

I noticed that Eliot also expressed support for the approach presented 
by Abhinav, see 
https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxgVeYVzFaI

Ciao
Hannes

On 09/26/2016 07:11 PM, Kepeng Li wrote:
> Abhinav also proposed a way forward in his email to the list,
> see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html,
> where he proposed to standardize a solution based on public key as well
> as symmetric key cryptography.
>
>
> Mike seems to think the only acceptable solution is to use messages
> signed using public key crypto and is strongly against working on a
> symmetric key group communication protocol.
>
>
> crypto solution but it is not clear whether they are against specifying
> a symmetric key solution as well.
>
>
> Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric
> key group communication security protocols (as co-authors of the work).
> Oscar Garcia (Philips) is also in favor of the work.
>
>
> In this mail to the list,
> see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html,
> Robert Cragie (ARM) expressed a view that public key crypto is the
> preferred solution but others based on symmetric crypto are still worthy
> of consideration.
>
>
> Akbar Rahman also seems to be in favor of working on a group
> communication security protocol, see
>
> Derek Atkins offered performance data for public key crypto but refers
> to new techniques (rather than RSA/ECC).
>
>
>

---

From: [email-masked]
Date: Mon, 26 Sep 2016 08:30:35 -0400

Without a hat on, you can add my support to Abhinav's proposal.  Perfect is ideal, but you often can not make any progress if you accept nothing less.  The security considerations section will have to be thorough.

Kathleen 

Please excuse typos, sent from handheld device 

> On Sep 26, 2016, at 7:11 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> I noticed that Eliot also expressed support for the approach presented by Abhinav, see https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxgVeYVzFaI
> 
> Ciao
> Hannes
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 26 Sep 2016 11:41:52 -0400

> Without a hat on, you can add my support to Abhinav's proposal.  Perfect is ideal, but you often can not make any progress if you accept nothing less.  The security considerations section will have…

Hi Kathleen et al -

To attain "rough consensus", RFC 7282 requires that "all issues be 
addressed" even if not all issues are accommodated.  So far the basic 
issues of "this is unsafe as a mechanism for 'securing' a control 
protocol" or even "how the heck do we keep this off the broader 
internet" have not been addressed.

I once again suggest that the lighting folk go off and write something 
that they implement as a group, and bring it back to the IETF as an 
informational "here's how we did it" document, rather than adopting this 
as a WG item.  The ONLY thing that even argues for considering symmetric 
key multicast (vice asymmetric key multicast) is the latency claims for 
lighting.  I haven't yet heard of another use case with the particular 
combination of cheapness and latency of lighting which would suggest 
this particular combination is useful elsewhere.

With respect to Abhinav's proposal, we've already got several group key 
manager systems - we don't actually use any of them for control systems, 
and you might want to inquire as to the reason. [RFC2093,2094] [RFC4046] 
[RFC4535]

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.  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.

Later, Mike

ps - do you *really* want to reinvent SCADA and all its security issues?

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Sep 2016 18:10:21 +0200

Hi Mike,

Just one clarification:

On 9/26/16 5:41 PM, Michael StJohns wrote:
> 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.

> 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?

Eliot

---

From: [email-masked]
Date: Mon, 26 Sep 2016 12:31:24 -0400

This time as AD.

> On Sep 26, 2016, at 11:41 AM, Michael StJohns <[email-masked]> wrote:
> 
> To attain "rough consensus", RFC 7282 requires that "all issues be addressed" even if not all issues are accommodated.  So far the basic issues of "this is unsafe as a mechanism for 'securing' a control protocol" or even "how the heck do we keep this off the broader internet" have not been addressed.

This can be addressed in a draft security considerations.  The scope can be made applicable to what's needed to constrain its use.

The chairs haven't put out a decision and your concerns have been heard.  They are working to assess consensus.

Best regards,
Kathleen 

> 
> I once again suggest that the lighting folk go off and write something that they implement as a group, and bring it back to the IETF as an informational "here's how we did it" document, rather than adopting this as a WG item.  The ONLY thing that even argues for considering symmetric key multicast (vice asymmetric key multicast) is the latency claims for lighting.  I haven't yet heard of another use case with the particular combination of cheapness and latency of lighting which would suggest this particular combination is useful elsewhere.
> 
> With respect to Abhinav's proposal, we've already got several group key manager systems - we don't actually use any of them for control systems, and you might want to inquire as to the reason. [RFC2093,2094] [RFC4046] [RFC4535]
> 
> 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.  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.
> 
> Later, Mike
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 26 Sep 2016 12:59:23 -0400

> 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 question in this context again, is whether it all has to happen at

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

---

From: Michael StJohns <[email-masked]>
Date: Mon, 26 Sep 2016 13:17:43 -0400

> This can be addressed in a draft security considerations.  The scope can be made applicable to what's needed to constrain its use.

With respect - no.  The issue is with respect to the discussion of 
whether or not to adopt this as a WG item.  To "address" the issue, 
there has to be an offer of proof that someone actually knows how to 
address it  - BEFORE the item is adopted.   I may have missed that offer 
of proof, but I don't think so.

You're suggesting that the way of addressing this is to ignore the 
issues, adopt it the work item, and at some far distant future point 
make sure there is a security considerations section that says something 
that might or might not be meaningful.   "I will gladly pay you Tuesday 
for a hamburger today" - J Wellington Wimpy.

An interesting approach, but probably not in keeping with correct process.

> The chairs haven't put out a decision and your concerns have been heard.  They are working to assess consensus.

The counter point to my concerns being heard is them being "addressed" 
as part of assessing consensus.  It says so right there in RFC 7282.

Later, Mike

---

From: [email-masked]
Date: Mon, 26 Sep 2016 14:48:58 -0400

> On Sep 26, 2016, at 1:17 PM, Michael StJohns <[email-masked]> wrote:
> 
> With respect - no.  The issue is with respect to the discussion of whether or not to adopt this as a WG item.  To "address" the issue, there has to be an offer of proof that someone actually knows how to address it  - BEFORE the item is adopted.   I may have missed that offer of proof, but I don't think so.
> 
> You're suggesting that the way of addressing this is to ignore the issues, adopt it the work item, and at some far distant future point make sure there is a security considerations section that says something that might or might not be meaningful.   "I will gladly pay you Tuesday for a hamburger today" - J Wellington Wimpy.
> 

No Mike, that's not what I said.  Please let the chairs do their job and let's see what they come back with.  Your points may be addressed in their response.

If adopted, it is fully recognized that there are security issues and that will need to be addressed.  The chairs are working on this adoption call and your points are in consideration.  There is a real problem to be solved and if it's not perfect, and has some security holes, that will be stated clearly.  It is okay to have an imperfect solution.

Kathleen 

> The counter point to my concerns being heard is them being "addressed" as part of assessing consensus.  It says so right there in RFC 7282.
> 
> Later, Mike
> 
>> 
>> Best regards,
>> Kathleen
>>