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

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Nov 2016 07:11:27 +0900

see inline as well.

In the summary, it was unclear if I was against the symmetric method or not.
I will admit that I'm sitting on the fence here.  I would prefer not to have
a standardized symmetric method.

My preference would be to start running code that shows the price/performance
of asymmetric methods in a lighting context.  It would have to be done by a
sufficiently resourced group motivated to show positive results.

Michael StJohns <[email-masked]> wrote:
    >> 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.

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

I realize that this thread is months old: I haven't seen any newer
conversation, so I'll continue anyway.

I would concur with MSJ's view that having an informational draft might be a
way to let this work go forward, but I suggest instead the right track might
be experimental.

I'm less sure that I agree with the subsequent view that we can't adopt this
item until we have assurance; I'd say that asking for the issue to be
addressed as part of the adoption process is reasonable, and objecting at
WGLC if it has not been addressed is the right way.

I will say I'm scared that garage door actuators and doors and security
systems will be sold with "lighting" interfaces.  This same thing happened in
USB space: zillions of inappropriate USB devices were given HID designations
because the windows drivers were easier to write/get-signed.

---

From: Michael StJohns <[email-masked]>
Date: Sat, 12 Nov 2016 20:35:48 -0500

> way to let this work go forward, but I suggest instead the right track might
I suggested Informational as the IETF has a long history of republishing 
things developed elsewhere as "Here's how we did it documents".  
Experimental documents generally describe ideas either where we know 
there is a way forward, but we're not sure which of several paths work, 
or ideas where the general utility may not be readily apparent.    I 
could live with experimental/non-WG.

> WGLC if it has not been addressed is the right way.

http://www.techworm.net/2016/11/researchers-use-drones-hijack-philips-hue-smart-lights.html 
describes how the use of multi-party symmetric key systems weakens even 
minimal security guarantees in a IOT system.  In this article, its noted 
that the HUE lights have firmware that's signed/encrypted by a symmetric 
key (which - by definition then needs to be included in every device to 
decrypt/verify the firmware), and that the attackers were able to 
extract the key from a lightbulb with relative ease; craft their own 
firmware and cause the lightbulbs to load it in a chain reaction.

There really isn't a lot of difference in the key extraction attack for 
the above vs extracting a symmetric key used for group communications.  
The only saving grace in group comms is that the group is smaller than 
unity.

So I'd turn this around and ask for a offer of proof that we can find a 
way to do this safely *BEFORE* having the IETF invest time and resources 
in the work.  I don't expect a fully fleshed out solution, but I haven't 
seen even a hint that anyone knows how to mitigate the risks.

> because the windows drivers were easier to write/get-signed.

At least most of those weren't cyber physical (except maybe the USB nerf 
turret and its ilk 
http://weburbanist.com/2009/11/18/truly-geeky-gadgets-15-usb-weapons-from-fail-to-fantastic/).

Mike

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Nov 2016 16:42:54 +0900

Michael StJohns <[email-masked]> wrote:
    >> I'm less sure that I agree with the subsequent view that we can't
    >> adopt this item until we have assurance; I'd say that asking for the
    >> issue to be addressed as part of the adoption process is reasonable,
    >> and objecting at WGLC if it has not been addressed is the right way.

    > minimal security guarantees in a IOT system.  In this article, its
    > noted that the HUE lights have firmware that's signed/encrypted by a
    > symmetric key (which - by definition then needs to be included in every
    > device to decrypt/verify the firmware), and that the attackers were
    > able to extract the key from a lightbulb with relative ease; craft
    > their own firmware and cause the lightbulbs to load it in a chain
    > reaction.

I had read all about this, and I wondered how they had gotten the bogus
firmware accepted; I thought that this was the "bug", but I hadn't read (or I
had missed) that the firmware was symmetric signed.  That's really really dumb.

    > way to do this safely *BEFORE* having the IETF invest time and
    > resources in the work.  I don't expect a fully fleshed out solution,
    > but I haven't seen even a hint that anyone knows how to mitigate the
    > risks.

I see your point.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Kepeng Li" <[email-masked]>
Date: Wed, 16 Nov 2016 22:08:28 +0800

Hello all,  
We had a long discussion about group communication security topic since the previous F2F meeting.
Hannes and I have tried to make a summary about the discussion as follows:
·       The solution needs to define both, symmetric and an asymmetric group key solution. 
·       The security consideration section needs to explain under what circumstances what solution is appropriate. 
If this is not accurate, please let us know.
Kind Regards

Kepeng & Hannes
BTW: it is a pity that I can't attend this meeting due to personal reasons, and hope you all have a nice meeting in Seoul!

---

From: "Kepeng Li" <[email-masked]>
Date: Wed, 16 Nov 2016 22:29:42 +0800

Hello all,
We are still missing some slides for some of the agenda items.
Document authors / presenters, please send your slides to us (co-chairs and acting chairs) ASAP.
BTW: draft agenda is below.
Kind Regards

Kepeng
ACE WG Meeting

IETF 97 - Seoul

Thursday, 17 Nov, 2016, 15:20 - 17:50 

Chairs: Kepeng Li, Hannes Tschofenig

Acting chairs: Barry Leiba, Nancy Cam-Winget
* Agenda Bashing (Chairs, 5 min)
* Actors (Carsten Bormann, 5 min)

- http://datatracker.ietf.org/doc/draft-ietf-ace-actors/
* CBOR Web Token (Michael B. Jones, 5 mins)

- https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/
* Authorization using OAuth 2.0 (Ludwig Seitz, Remote, 30 min)

- https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
* Security for Low-Latency Group Communication (TBD, 30 mins)

- https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/
* Ephemeral Diffie-Hellman Over COSE (John Mattsson, 20 mins)

- https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/
* OSCOAP profile of ACE  (Francesca Palombini, 20 min)

- https://datatracker.ietf.org/doc/draft-seitz-ace-oscoap-profile/
* DTLS Profile for ACE (Carsten Bormann, 20 mins)

- https://datatracker.ietf.org/doc/draft-gerdes-ace-dtls-authorize/
* Lightweight Authenticated Time (LATe) Synchronization Protocol (Renzo Navas, Remote, 10 mins)

- https://datatracker.ietf.org/doc/draft-navas-ace-secure-time-synchronization/
* Wrap-up (Chairs, 5 min)

---

From: Michael StJohns <[email-masked]>
Date: Thu, 17 Nov 2016 00:50:00 -0500

> ·       The solution needs to define both, symmetric and an asymmetric 

There is no case (absent hardware mitigation) in which a symmetric group 
key solution can be made secure/safe and no one has made an offer of 
proof that they can make it secure.    I've asked repeatedly - no one 
has come forward with more than "oh we can lock the symmetric key stuff 
in a corner and make sure it isn't used for anything important".

Given the recent attacks on the internet by IOT botnets, there is a 
further consideration that should be undertaken - whether the symmetric 
group key solution applied to 10s of 1000s of IOT devices is an active 
threat to the rest of the internet (e.g. enabling DDOS, cyber physical 
issues, etc)?

The multiparty (group) symmetric key solution is only wanted for a 
single corner of the solution space - low latency, no cost systems. E.g. 
lightbulbs.  Given there is a worked example of the insecurity of 
multiparty symmetric key systems (e.g. the attack on the symmetric 
signing key of the HUE lights), I'm unclear why anyone at all would 
think that pursuing a known bad solution in the IETF is a good idea.

> ·       The security consideration section needs to explain under what 
> circumstances what solution is appropriate.
>

Security consideration sections generally only address the threat *to* 
the system from security choices.  In this case, symmetric key group 
comms reduces down to the same security analysis you would use with 
shared default passwords across 1000s of devices.   An IOT security 
consideration section in the future probably needs to address the threat 
*FROM* the IOT solution to the broader internet.

Mike

> BTW: it is a pity that I can't attend this meeting due to personal 
> reasons, and hope you all have a nice meeting in Seoul!
>
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 16:28:39 +0900

Michael StJohns <[email-masked]> wrote:
    > single corner of the solution space - low latency, no cost
    > systems. E.g. lightbulbs.  Given there is a worked example of the
    > insecurity of multiparty symmetric key systems (e.g. the attack on the
    > symmetric signing key of the HUE lights), I'm unclear why anyone at all
    > would think that pursuing a known bad solution in the IETF is a good
    > idea.

Also, there is the question about cost, so look at:

  https://www.ietf.org/proceedings/97/slides/slides-97-lwig-2-lightweight-crypto-00.pdf

From this morning.

261ms for k163 on a specific device.

---

From: Rene Struik <[email-masked]>
Date: Thu, 17 Nov 2016 09:26:32 -0500

Dear colleagues:

Just a reminder re perceived technical hurdles for using signatures:
a) time latency of signing:
One can pre-compute ephemeral signing keys, so as to reduce online key 
computation to a few finite field multiplies.
Please see my email to the list of July 26, 2016: 
https://mailarchive.ietf.org/arch/msg/ace/iEb0XnAIMAB_V3I8LjMFQRj1Fe0
b): further speed-ups/tricks, etc:
One can try and be smarter by clever implementations.
Please see my email to the list of July 21, 2016: 
https://mailarchive.ietf.org/arch/msg/ace/iI58mT_DDzKImL1LP_bUQ7TzooI

This seems to take the time latency argument away. The only other 
technical hurdles I can see are
(i) signature size {is 64B too much?};
(ii) cost of public key crypto implementations {quite some small, nifty 
designs out there (NaCl etc.}.

As to (i) - one should view signature sizes in perspective: as an 
example, key sizes in the key pre-distribution scheme HIMMO (as promoted 
by Philips) has key sizes of 6.25 kB and up, according to Table 3 of the 
paper that massages parameters to thwart new attacks on their scheme, 
see http://eprint.iacr.org/2016/152.

So, security arguments that favor asymmetric solutions aside, there also 
do not seem to be too many other objections that would hold in the world 
anno 2016 {except for "sunk investment" arguments", but that is a 
corporate mindset issue}.

On 11/17/2016 12:50 AM, Michael StJohns wrote:
> There is no case (absent hardware mitigation) in which a symmetric 
> group key solution can be made secure/safe and no one has made an 
> offer of proof that they can make it secure.    I've asked repeatedly 
> - no one has come forward with more than "oh we can lock the symmetric 
> key stuff in a corner and make sure it isn't used for anything important".
>
>
> further consideration that should be undertaken - whether the 
> symmetric group key solution applied to 10s of 1000s of IOT devices is 
> an active threat to the rest of the internet (e.g. enabling DDOS, 
> cyber physical issues, etc)?
>
> single corner of the solution space - low latency, no cost systems.  
> E.g. lightbulbs.  Given there is a worked example of the insecurity of 
>> ·       The security consideration section needs to explain under 
>> what circumstances what solution is appropriate.
>>
>
> consideration section in the future probably needs to address the 
> threat *FROM* the IOT solution to the broader internet.
>
> Mike
>
>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: [email-masked]
Date: Fri, 18 Nov 2016 09:00:25 +0900

Is anyone willing to work on a draft to be ready in advance of the Chicago meeting so we have a concrete proposal for asymmetric keys?

Thanks,
Kathleen 

Please excuse typos, sent from handheld device 

> On Nov 17, 2016, at 11:26 PM, Rene Struik <[email-masked]> wrote:
> 
> Dear colleagues:
> 
> One can pre-compute ephemeral signing keys, so as to reduce online key computation to a few finite field multiplies. 
> Please see my email to the list of July 26, 2016: https://mailarchive.ietf.org/arch/msg/ace/iEb0XnAIMAB_V3I8LjMFQRj1Fe0
> Please see my email to the list of July 21, 2016: https://mailarchive.ietf.org/arch/msg/ace/iI58mT_DDzKImL1LP_bUQ7TzooI
> 
> This seems to take the time latency argument away. The only other technical hurdles I can see are 
> (ii) cost of public key crypto implementations {quite some small, nifty designs out there (NaCl etc.}.
> 
> As to (i) - one should view signature sizes in perspective: as an example, key sizes in the key pre-distribution scheme HIMMO (as promoted by Philips) has key sizes of 6.25 kB and up, according to Table 3 of the paper that massages parameters to thwart new attacks on their scheme, see http://eprint.iacr.org/2016/152.
> 
> So, security arguments that favor asymmetric solutions aside, there also do not seem to be too many other objections that would hold in the world anno 2016 {except for "sunk investment" arguments", but that is a corporate mindset issue}.
> 
>> There is no case (absent hardware mitigation) in which a symmetric group key solution can be made secure/safe and no one has made an offer of proof that they can make it secure.    I've asked repeatedly - no one has come forward with more than "oh we can lock the symmetric key stuff in a corner and make sure it isn't used for anything important".
>> 
>> 
>> Given the recent attacks on the internet by IOT botnets, there is a further consideration that should be undertaken - whether the symmetric group key solution applied to 10s of 1000s of IOT devices is an active threat to the rest of the internet (e.g. enabling DDOS, cyber physical issues, etc)?
>> 
>> The multiparty (group) symmetric key solution is only wanted for a single corner of the solution space - low latency, no cost systems.  E.g. lightbulbs.  Given there is a worked example of the insecurity of multiparty symmetric key systems (e.g. the attack on the symmetric signing key of the HUE lights), I'm unclear why anyone at all would think that pursuing a known bad solution in the IETF is a good idea.
>> 
>> Security consideration sections generally only address the threat *to* the system from security choices.  In this case, symmetric key group comms reduces down to the same security analysis you would use with shared default passwords across 1000s of devices.         An IOT security consideration section in the future probably needs       to address the threat *FROM* the IOT solution to the broader internet.
>> 
>> Mike
>> 
>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 18 Nov 2016 03:56:11 +0000

Kathleen,

I will put up a proposal before the Chicago meeting.

-Tiru

From: Ace [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, November 18, 2016 5:30 AM
To: Rene Struik <[email-masked]>
Cc: Michael StJohns <[email-masked]>; [email-masked]
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion

Thanks,
Kathleen

On Nov 17, 2016, at 11:26 PM, Rene Struik <[email-masked]<mailto:[email-masked]>> wrote:
Dear colleagues:

Hello all,

Mike

Kind Regards
Kepeng & Hannes

Ace mailing list

[email-masked]<mailto:[email-masked]>

Ace mailing list

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 17 Nov 2016 22:59:48 -0500

> I will put up a proposal before the Chicago meeting.

Thank you.

>
>
> -Tiru
>
>
>
> *From:* Ace [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Friday, November 18, 2016 5:30 AM
> *To:* Rene Struik <[email-masked]>
> *Cc:* Michael StJohns <[email-masked]>; [email-masked]
> *Subject:* Re: [Ace] Summary of ACE Group Communication Security
> Discussion
>
>
>
> Is anyone willing to work on a draft to be ready in advance of the Chicago
> meeting so we have a concrete proposal for asymmetric keys?
>
>
>
> Thanks,
>
> Kathleen
>
> As to (i) - one should view signature sizes in perspective: as an example,
> key sizes in the key pre-distribution scheme HIMMO (as promoted by Philips)
> has key sizes of 6.25 kB and up, according to Table 3 of the paper that
> massages parameters to thwart new attacks on their scheme, see
> http://eprint.iacr.org/2016/152.
>
> anno 2016 {except for "sunk investment" arguments", but that is a corporate
> mindset issue}.
>
> key solution can be made secure/safe and no one has made an offer of proof
> that they can make it secure.    I've asked repeatedly - no one has come
> forward with more than "oh we can lock the symmetric key stuff in a corner
> and make sure it isn't used for anything important".
>
>
> The multiparty (group) symmetric key solution is only wanted for a single
> corner of the solution space - low latency, no cost systems.  E.g.
> multiparty symmetric key systems (e.g. the attack on the symmetric signing
> key of the HUE lights), I'm unclear why anyone at all would think that
> pursuing a known bad solution in the IETF is a good idea.
>
>
> Security consideration sections generally only address the threat *to* the
> system from security choices.  In this case, symmetric key group comms
> reduces down to the same security analysis you would use with shared
> default passwords across 1000s of devices.   An IOT security consideration
> section in the future probably needs to address the threat *FROM* the IOT
> solution to the broader internet.
>
> Mike
>
>
>

-- 

Best regards,
Kathleen

---

From: Göran Selander <[email-masked]>
Date: Fri, 18 Nov 2016 08:00:15 +0000

Kathleen and all,

I believe all necessary drafts for a solution based on asymmetric keys are already in place.

With "a solution based on asymmetric keys” I understand a solution where each member of the group can sign messages with its private key for source authentication but where confidentiality is protected with a symmetric key shared between the members of the group.

[1] describes how to distribute and use symmetric keys, using a KDC for distributing the symmetric keys, and references OSCOAP for securing the group communication. [2] shows how to secure group communication for CoAP based on asymmetric keys as described above. As far as I understand, the only thing missing is a mechanism for distributing the public keys of the members, but it seems natural to extend the KDC with this functionality.

[1] https://tools.ietf.org/html/draft-somaraju-ace-multicast-01
[2] https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-00

However, I don’t agree with all conclusions of the asymmetric key proponents.

It is not news that asymmetric key techniques are feasible for use in many embedded device applications, but it is good that the knowledge is being spread. But execution times and message sizes may still be prohibitive for some applications. To address Rene’s question "is 64B too much?": Adding the countersignature to COSE messages such as those used in multicast OSCOAP would increase the size from the order of 20 bytes to the order of 85-90 bytes which in turn may add significant latency depending on link layer technology used, independently of processor capacity.

Without neglecting the issues raised, I do think that there is a role for symmetric key based group communication for the class of actuators in scope of [1]. I agree it is an issue if compromising one device and extracting one key let's you turn off 1000 lamps (not saying it has to, but just as an example). But that doesn't automatically turn the lightbulbs into bots.  The security considerations in this case should e.g. include things like restricting capabilities associated with the possession of a shared key.

Independent of this discussion, symmetric key solutions for these use cases will continue to be deployed. I fear we may create greater damage by not analysing and providing guidance to these use cases when applied in a symmetric key setting, at the same time as specifying an asymmetric key solution.

Göran

From: Ace <[email-masked]<mailto:[email-masked]>> on behalf of Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Date: Friday 18 November 2016 at 04:59
To: "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>>
Cc: Michael StJohns <[email-masked]<mailto:[email-masked]>>, Rene Struik <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion

On Thu, Nov 17, 2016 at 10:56 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Kathleen,

Thank you.

-Tiru

From: Ace [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, November 18, 2016 5:30 AM
To: Rene Struik <[email-masked]<mailto:[email-masked]>>
Cc: Michael StJohns <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion

Thanks,
Kathleen

Hello all,

Mike

Kind Regards
Kepeng & Hannes

Ace mailing list

Ace mailing list

--

--

Best regards,
Kathleen

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 18 Nov 2016 08:13:00 +0000

Hi Göran, Kathleen and all

Extending on the comment “but it seems natural to extend the KDC with this functionality”, the new version of the draft-somaraju-ace-multicast [1] submitted a week back includes now the asymmetric version as the recommended version for most application except the low latency applications (to be achieved in low resource device).
@Kathleen: what you have asked is already in the new draft and the aspects regarding OSCOAP in [2] which can be easily merged into [1]. Are you asking for something else?

Sandeep

From: Ace [mailto:[email-masked]] On Behalf Of Göran Selander
Sent: Friday, November 18, 2016 9:00 AM
To: Kathleen Moriarty <[email-masked]>; [email-masked]
Cc: Michael Richardson <[email-masked]>; Michael StJohns <[email-masked]>; Rene Struik <[email-masked]>; Tirumaleswar Reddy (tireddy) <[email-masked]>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion

Kathleen and all,

Göran

Thank you.

-Tiru

Thanks,
Kathleen

Hello all,

Mike

Kind Regards
Kepeng & Hannes

Ace mailing list

Ace mailing list

--

--

Best regards,
Kathleen

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Shahid Raza <[email-masked]>
Date: Fri, 18 Nov 2016 09:21:58 +0100

The question regarding distribution of asymmetric keys was raised in the ACE working group before under the tread https://www.ietf.org/mail-archive/web/ace/current/msg01825.html <https://www.ietf.org/mail-archive/web/ace/current/msg01825.html> , where we mentioned that SICS and neXus are working on enrollment using IoT protocols. We have already implementing this on the CA side and also on Contiki side and tested with Class II IoT devices. 

/Shahid

> On 18 Nov 2016, at 09:13, Kumar, Sandeep <[email-masked]> wrote:
> 
> From: Ace [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Göran Selander
> To: Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: Michael Richardson <[email-masked] <mailto:[email-masked]>>; Michael StJohns <[email-masked] <mailto:[email-masked]>>; Rene Struik <[email-masked] <mailto:[email-masked]>>; Tirumaleswar Reddy (tireddy) <[email-masked] <mailto:[email-masked]>>
> [1] https://tools.ietf.org/html/draft-somaraju-ace-multicast-01 <https://tools.ietf.org/html/draft-somaraju-ace-multicast-01>
> [2] https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-00 <https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-00>
>  
>  
>  
> From: Ace <[email-masked] <mailto:[email-masked]>> on behalf of Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>
> To: "Tirumaleswar Reddy (tireddy)" <[email-masked] <mailto:[email-masked]>>
> Cc: Michael StJohns <[email-masked] <mailto:[email-masked]>>, Rene Struik <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Thu, Nov 17, 2016 at 10:56 PM, Tirumaleswar Reddy (tireddy) <[email-masked] <mailto:[email-masked]>> wrote:
> Kathleen,
>  
> From: Ace [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
> To: Rene Struik <[email-masked] <mailto:[email-masked]>>
> Cc: Michael StJohns <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Nov 17, 2016, at 11:26 PM, Rene Struik <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Dear colleagues:
> 
> Please see my email to the list of July 26, 2016: https://mailarchive.ietf.org/arch/msg/ace/iEb0XnAIMAB_V3I8LjMFQRj1Fe0 <https://mailarchive.ietf.org/arch/msg/ace/iEb0XnAIMAB_V3I8LjMFQRj1Fe0>
> Please see my email to the list of July 21, 2016: https://mailarchive.ietf.org/arch/msg/ace/iI58mT_DDzKImL1LP_bUQ7TzooI <https://mailarchive.ietf.org/arch/msg/ace/iI58mT_DDzKImL1LP_bUQ7TzooI>
> 
> As to (i) - one should view signature sizes in perspective: as an example, key sizes in the key pre-distribution scheme HIMMO (as promoted by Philips) has key sizes of 6.25 kB and up, according to Table 3 of the paper that massages parameters to thwart new attacks on their scheme, see http://eprint.iacr.org/2016/152 <http://eprint.iacr.org/2016/152>.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
>  
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
>  
>  
> 
> -- 
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
> 
> 
>  
> --
>  
> Best regards,
> Kathleen
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 23 Nov 2016 13:21:58 -0500

On 11/17/2016 7:00 PM, [email-masked] wrote:
> Is anyone willing to work on a draft to be ready in advance of the 
> Chicago meeting so we have a concrete proposal for asymmetric keys?

I'm just catching up on old mail after getting over a cold.

Mostly, this could be as simple as a two to four paragraph draft:

1) Use CORE section 5 for message formats. (e.g. public key signed 
messages) using one of several defined specific set of algorithms (e.g. 
sha256withecdsa and p256 or something smaller) chosen by the application.
2) The authentication bare public key is a configuration item for the 
end devices and placement is beyond the scope of this draft.
3) Tracking of a message ID from (1) to prevent command replay attacks.
4) Minimum numbers of controllers (e.g. public keys and actuation events 
or message ids) that an end system has to track.

(2) could be folded into a draft about configuring end devices.

A more complex model would be:
1) Place a root certificate on all end systems via configuration (also 
out of scope)
2) Describe the certification path algorithm (e.g. profile RFC5280)
3) Describe how the cert path certificates are carried in CORE section 5 
messages.
4) plus 3 & 4 above.
5) plus how to operate in the presence of clock time.

Unlike symmetric key systems, there really doesn't need to be a key 
management/agreement/transport protocol per se.  It's all about a) what 
constitutes a valid message, and b) what do you do with the valid 
message once you get it.

An application specific draft would include message formats for things 
included in a CORE section 5 message (e.g. the specific values for 
turning on and off lightbulbs or setting their hues or intensity), but 
that's not really an ACE thing per se.

Mike

>> One can pre-compute ephemeral signing keys, so as to reduce online 
>> key computation to a few finite field multiplies.
>> example, key sizes in the key pre-distribution scheme HIMMO (as 
>> promoted by Philips) has key sizes of 6.25 kB and up, according to 
>> Table 3 of the paper that massages parameters to thwart new attacks 
>> on their scheme, see http://eprint.iacr.org/2016/152.
>>
>> So, security arguments that favor asymmetric solutions aside, there 
>> also do not seem to be too many other objections that would hold in 
>> the world anno 2016 {except for "sunk investment" arguments", but 
>> that is a corporate mindset issue}.
>>
>>> offer of proof that they can make it secure.    I've asked 
>>> repeatedly - no one has come forward with more than "oh we can lock 
>>> the symmetric key stuff in a corner and make sure it isn't used for 
>>> anything important".
>>>
>>>
>>> symmetric group key solution applied to 10s of 1000s of IOT devices 
>>> is an active threat to the rest of the internet (e.g. enabling DDOS, 
>>> E.g. lightbulbs.  Given there is a worked example of the insecurity 
>>> of multiparty symmetric key systems (e.g. the attack on the 
>>> symmetric signing key of the HUE lights), I'm unclear why anyone at 
>>> all would think that pursuing a known bad solution in the IETF is a 
>>> good idea.
>>>
>>> Security consideration sections generally only address the threat 
>>> *to* the system from security choices.  In this case, symmetric key 
>>> group comms reduces down to the same security analysis you would use 
>>> with shared default passwords across 1000s of devices.   An IOT 
>>> security consideration section in the future probably needs to 
>>> address the threat *FROM* the IOT solution to the broader internet.
>>>
>>> Mike
>>>
>>>
>> email:[email-masked]  | Skype: rstruik

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Nov 2016 15:09:42 +0100

Hi Mike

> in a corner and make sure it isn't used for anything important".

Security is not a black and white thing. What has been clear is that any
solution that was proposed for symmetric keys did not meet your
expectation.

> threat to the rest of the internet (e.g. enabling DDOS, cyber physical

The recent attack was made possible because all devices were provisioned
with the same password, which was publically known.

What we are proposing here is a key distribution protocol where
* each device is provisioned with unique keys (symmetric or asymmetric
keys),
* uses those keys to authenticated to the trusted third party (the KDC),
and
* then gets provisioned with temporary shared secrets for used with
group communication (whereby non-persistent symmetric keys are used for
different groups, keys change over time and where there is an
authorization step before you can join a group).

> think that pursuing a known bad solution in the IETF is a good idea.

While the lighting sector is only one part of the IoT industry I think
it is OK to standardize a solution for one industry that consists of
different vendors.

The hack against the HUE lightbulbs you are referring to was also
different. The issue there was that the entire product series was using
the same shared secret provisioned during manufacturing. What we are
doing, however, is to utilize a key distribution protocol to dynamically
create shared secrets. So, each device has unique keys to authenticate
to the KDC and then gets group keys dynamically provisioned. Note that
the security difference here is huge.

I know that you are aware of the differences between the attacks and
what we do in the ACE working group. Hence I am a bit disappointed that
you are trying to make others in the group, who are less knowledgeable
in security, believe that these attacks are actually related.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 24 Nov 2016 15:22:34 +0100

On 24 Nov 2016, at 15:09, Hannes Tschofenig <[email-masked]> wrote:
> 
> Security is not a black and white thing.

+1

The discussion is very tiring.

If we can have only military-level security in the IoT, then the real world IoT will simply happen without benefitting from the Internet.  I still don’t wear a bullet-proof vest when giving my lectures, and we need appropriate, usable security.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Thu, 24 Nov 2016 15:59:42 -0500

Comments inline. Also see particularly, the comments underlined and in bold.

> solution that was proposed for symmetric keys did not meet your

This is a fairly null-value and disingenuous statement, _*but it helped 
me realize that you (plural) haven't actually stated any security 
requirements for a group  control system protocol*_. What you have 
stated are constraints (low cost, low latency) that you believe inform 
the choice of security solutions - but these are NOT security 
requirements.   Unfortunately, without stating your actual security 
requirements, its difficult for you to realize that the solution 
intersection of your constraints with any reasonable security 
requirements is probably the empty set.

The analysis of whether a particular solution meets or exceeds the 
requirements for the system *is* actually a pretty black and white thing 
- it involves physics, math, cryptography and probability and an 
analysis of threats vs strengths.

So let me put forth what I believe is a reasonable minimum security 
requirement for this group control system:

"Compromise of a single device shall not result in an attacker having 
more privileges that nominally are assigned to that device." or less 
nuanced: "Compromise of a single device shall not result in the 
compromise of the entire system."

Now you can put forth your minimum security requirements and we can 
decide as a group if those minimums are acceptable, and then figure out 
if your proposed solutions meet the requirements in any meaningful manner.

> with the same password, which was publically known.

Seriously?   If you'd had 10,000 devices with the same password, but 
that the password wasn't known to anyone at manufacture, the result 
wouldn't have been any different.  The attacker would have grabbed one 
of the devices, and extracted the password and controlled 10K 
devices.    Alternately, buy 10k devices, set an identical new password 
on each of them and deploy.  Same result.

> authorization step before you can join a group).

Again, 1) compromise a device, 2) have it pass on any symmetric key it 
is given to an attacker. 3) Attacker controls the system. Lather, rinse, 
repeat.  It *DOES NOT MATTER* how the symmetric keys get to the 
device,_*it only matters that more than two devices at time T share the 
same symmetric key and the attacker can get to one of those devices.*__*
*_
> the same shared secret provisioned during manufacturing.
They were using the same shared symmetric firmware signing/encrypting 
key.  Which allowed an attacker to create "valid" firmware and use a 
zigbee stack flaw to cause it to be loaded.

Again - a symmetric key shared between more than two entities led to a 
fatal flaw in the system.

> What we are

No, it's actually not and no reasonable cryptographic protocol designer 
would say otherwise.

> in security, believe that these attacks are actually related.

And I'm a bit disappointed that you're trying to claim that the attacks 
are not. I'm also a bit disappointed about the personal attack - but 
that's irrelevant to the discussion. The only difference between the HUE 
attack and attacking a multi-party symmetric key system is where and how 
you get the group key (or signing key).    In general, in both, attack a 
single device and you can extract the multi-party shared secret.

In terms of threat analysis they are exactly the same order of attack:  
Compromise one device, compromise the system that the device belongs 
to.  In the HUE attack all the HUE devices belonged to the same firmware 
system.  In an attack on group symmetric key multicast, all the devices 
belong to the same  multicast group.

The details for the attacks may differ.  The actual impacts to a 
successful attacks may differ (re-writing firmware vs turning on and off 
things), but the security analysis are exactly the same.

Mike

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 25 Nov 2016 15:52:26 +0000

Hi Mike,

Thanks for pointing out all the issues with a symmetric key approach to group communication.  However, can you also give any thoughts on the specific vulnerability to the CA and certificates in the asymmetric key approach for IoT?  After all, there has been some well-known attacks on PKI infrastructure in the last few years such as:

https://en.wikipedia.org/wiki/DigiNotar#Issuance_of_fraudulent_certificates

Do you think it will be better or worse if IoT infrastructure start using certificates on a massive scale?  Or is it outside the scope of IETF standards and more of a deployment and operational issue?

/Akbar

From: Ace [mailto:[email-masked]] On Behalf Of Michael StJohns
Sent: Wednesday, November 23, 2016 1:22 PM
To: [email-masked]; Rene Struik <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion

On 11/17/2016 7:00 PM, [email-masked]<mailto:[email-masked]> wrote:
Is anyone willing to work on a draft to be ready in advance of the Chicago meeting so we have a concrete proposal for asymmetric keys?

1) Use CORE section 5 for message formats. (e.g. public key signed messages) using one of several defined specific set of algorithms (e.g. sha256withecdsa and p256 or something smaller) chosen by the application.
2) The authentication bare public key is a configuration item for the end devices and placement is beyond the scope of this draft.
3) Tracking of a message ID from (1) to prevent command replay attacks.
4) Minimum numbers of controllers (e.g. public keys and actuation events or message ids) that an end system has to track.

A more complex model would be:
1) Place a root certificate on all end systems via configuration (also out of scope)
2) Describe the certification path algorithm (e.g. profile RFC5280)
3) Describe how the cert path certificates are carried in CORE section 5 messages.
4) plus 3 & 4 above.
5) plus how to operate in the presence of clock time.

Unlike symmetric key systems, there really doesn't need to be a key management/agreement/transport protocol per se.  It's all about a) what constitutes a valid message, and b) what do you do with the valid message once you get it.

An application specific draft would include message formats for things included in a CORE section 5 message (e.g. the specific values for turning on and off lightbulbs or setting their hues or intensity), but that's not really an ACE thing per se.

Mike

Thanks,
Kathleen

Hello all,

Mike

Kind Regards
Kepeng & Hannes

Ace mailing list

Ace mailing list

--

---

From: Michael StJohns <[email-masked]>
Date: Fri, 25 Nov 2016 12:47:19 -0500

Hi Akbar -

This comes under the heading of a rat hole question for this discussion 
- sorry.

Basically, the use of public key systems vs whether to use public key 
systems with certificates are separate questions.  In a typical 
relatively closed group control system using public keys, you would 
generate key pairs on the controllers (switches) and provide the bare 
public keys to the actuators to validate control messages.  Since the 
public keys have no life outside of the local domain/group, there's 
really no reason to deal with CAs, certificates et al.

Some designs *may* want to include digital certificates for chaining and 
management of credentials, but again typically, these are closed systems 
that do not/will not/should not depend on public PKI for their security 
guarantees.   And in fact, the form of the digital certificate in these 
types of systems may bear little resemblance to an X.509 certificate 
(e.g. a signed public key blob with a fixed length, fixed fields, fixed 
offset format).

In general, you use public PKI stuff when you want your credentials to 
have somewhat of a global reach.

So - public PKI certificate question + IOT ==>  rat hole for this 
discussion.

Mike

On 11/25/2016 10:52 AM, Rahman, Akbar wrote:
>
> Hi Mike,
>
> Thanks for pointing out all the issues with a symmetric key approach 
> to group communication.  However, can you also give any thoughts on 
> the specific vulnerability to the CA and certificates in the 
> asymmetric key approach for IoT?  After all, there has been some 
> well-known attacks on PKI infrastructure in the last few years such as:
>
> Do you think it will be better or worse if IoT infrastructure start 
> using certificates on a massive scale?  Or is it outside the scope of 
> IETF standards and more of a deployment and operational issue?
>
> /Akbar
>
>
>
>
> <http://idcc.me/2e6xDgc>
>
> This e-mail is intended only for the use of the individual or entity 
> to which it is addressed, and may contain information that is 
> privileged, confidential and/or otherwise protected from disclosure to 
> anyone other than its intended recipient. Unintended transmission 
> shall not constitute waiver of any privilege or confidentiality 
> obligation. If you received this communication in error, please do not 
> review, copy or distribute it, notify me immediately by email, and 
> delete the original message and any attachments. Unless expressly 
> stated in this e-mail, nothing in this message or any attachment 
> should be construed as a digital or electronic signature.
>
>
> *From:*Ace [mailto:[email-masked]] *On Behalf Of *Michael StJohns
> *Sent:* Wednesday, November 23, 2016 1:22 PM
> *To:* [email-masked]; Rene Struik 
> <[email-masked]>
> *Cc:* [email-masked]
> On 11/17/2016 7:00 PM, [email-masked] 
> <mailto:[email-masked]> wrote:
>
> messages) using one of several defined specific set of algorithms 
> (e.g. sha256withecdsa and p256 or something smaller) chosen by the 
> application.
> 4) Minimum numbers of controllers (e.g. public keys and actuation 
> events or message ids) that an end system has to track.
>
> management/agreement/transport protocol per se.  It's all about a) 
> what constitutes a valid message, and b) what do you do with the valid 
> message once you get it.
>
>         One can pre-compute ephemeral signing keys, so as to reduce
>         online key computation to a few finite field multiplies.
>         (ii) cost of public key crypto implementations {quite some
>         small, nifty designs out there (NaCl etc.}.
>
>         As to (i) - one should view signature sizes in perspective: as
>         an example, key sizes in the key pre-distribution scheme HIMMO
>         (as promoted by Philips) has key sizes of 6.25 kB and up,
>         according to Table 3 of the paper that massages parameters to
>         thwart new attacks on their scheme, see
>         So, security arguments that favor asymmetric solutions aside,
>         there also do not seem to be too many other objections that
>         would hold in the world anno 2016 {except for "sunk
>         investment" arguments", but that is a corporate mindset issue}.
>
>                 We had a long discussion about group communication
>                 security topic since the previous F2F meeting.
>
>             There is no case (absent hardware mitigation) in which a
>             symmetric group key solution can be made secure/safe and
>             no one has made an offer of proof that they can make it
>             secure.    I've asked repeatedly - no one has come forward
>             with more than "oh we can lock the symmetric key stuff in
>             a corner and make sure it isn't used for anything important".
>
>
>             Given the recent attacks on the internet by IOT botnets,
>             there is a further consideration that should be undertaken
>             - whether the symmetric group key solution applied to 10s
>             of 1000s of IOT devices is an active threat to the rest of
>             the internet (e.g. enabling DDOS, cyber physical issues, etc)?
>
>             The multiparty (group) symmetric key solution is only
>             wanted for a single corner of the solution space - low
>             latency, no cost systems.  E.g. lightbulbs.  Given there
>             is a worked example of the insecurity of multiparty
>             symmetric key systems (e.g. the attack on the symmetric
>             signing key of the HUE lights), I'm unclear why anyone at
>             all would think that pursuing a known bad solution in the
>             IETF is a good idea.
>
>
>                 ·       The security consideration section needs to
>                 explain under what circumstances what solution is
>                 appropriate.
>
>
>             Security consideration sections generally only address the
>             threat *to* the system from security choices.  In this
>             case, symmetric key group comms reduces down to the same
>             security analysis you would use with shared default
>             passwords across 1000s of devices.   An IOT security
>             consideration section in the future probably needs to
>                 BTW: it is a pity that I can't attend this meeting due
>                 to personal reasons, and hope you all have a nice
>                 meeting in Seoul!
>
>
>
>
>         email:[email-masked] <mailto:[email-masked]>  | Skype: rstruik
>