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

Michael StJohns <> Mon, 26 September 2016 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40B0F12B2FE for <>; Mon, 26 Sep 2016 10:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.016
X-Spam-Status: No, score=-5.016 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SkduftNZX5J2 for <>; Mon, 26 Sep 2016 10:00:06 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89F2A12B24B for <>; Mon, 26 Sep 2016 10:00:05 -0700 (PDT)
Received: from ([]) by with SMTP id oZFvbFCXrTaLwoZG8bagIG; Mon, 26 Sep 2016 17:00:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1474909204; bh=/BYxUl6iNCGy6+6D1GaGj6huOGlZNccHAbhwxQF3IQs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=NXdfmiehgtkPBvbgcUgIkHWyTeRtWof2qQY6wL976mVHV9TJH+8iTg1tyy2Z9G0bz rsc3wP/aqHOJaOvfFTsTp79vUKvrQpRgIjM7iqutZQuSY+LesHj5DCYVZUzb7c7yxD Pgc1w+ErGnKxYRKmy7TStB87e0Hl8L775u4zSIubaZv5cvT51z+Hyv6dwedDjj/q7z rnQopI60K6DW2lHflocrPbhP2H7jJ3esbTBpPYl6/Odl0tCQAufpQbRGezgbAVJ51P c68mMTu9bpgxaKdrCddBK1Z2ufiESfKM2PtmlXiByiVOYtUACCcV8sKxT3cCrOGcSd fdld4JyKqR+4Q==
Received: from [] ([]) by with SMTP id oZG7bvJm8VK25oZG8bg9aO; Mon, 26 Sep 2016 17:00:04 +0000
To: Eliot Lear <>,
References: <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Mon, 26 Sep 2016 12:59:23 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfEjAZQrYWn3dwdgXai3rGoleE1nO9XXCG7xNpz5ucboARKVvtNNCujHtuoG3xaB+0J4Mbb2iOCDcYCpLJoM6SESQ09aCV4+7jd1ZsIfijFfVGT2At/OQ 1kMkH2BeFX8P5w92bUCIdX/QPwsfNDxpSVRszY7CwnORZns6RTuv8bYxXsw+NCTTGpWzHC+SSJbbxQ==
Archived-At: <>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Sep 2016 17:00:10 -0000

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