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

[Shahid Raza <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:[e-mail] <mailto:[e-mail]>] On Behalf Of Göran Selander
> Sent: Friday, November 18, 2016 9:00 AM
> To: Kathleen Moriarty <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Cc: Michael Richardson <[e-mail] <mailto:[e-mail]>>; Michael StJohns <[e-mail] <mailto:[e-mail]>>; Rene Struik <[e-mail] <mailto:[e-mail]>>; Tirumaleswar Reddy (tireddy) <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion
>  
> 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 <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>
>  
>  
>  
> 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 <[e-mail] <mailto:[e-mail]>> on behalf of Kathleen Moriarty <[e-mail] <mailto:[e-mail]>>
> Date: Friday 18 November 2016 at 04:59
> To: "Tirumaleswar Reddy (tireddy)" <[e-mail] <mailto:[e-mail]>>
> Cc: Michael StJohns <[e-mail] <mailto:[e-mail]>>, Rene Struik <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion
>  
>  
>  
> On Thu, Nov 17, 2016 at 10:56 PM, Tirumaleswar Reddy (tireddy) <[e-mail] <mailto:[e-mail]>> wrote:
> Kathleen,
>  
> I will put up a proposal before the Chicago meeting.
>  
> Thank you. 
>  
> -Tiru
>  
> From: Ace [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of [e-mail] <mailto:[e-mail]>
> Sent: Friday, November 18, 2016 5:30 AM
> To: Rene Struik <[e-mail] <mailto:[e-mail]>>
> Cc: Michael StJohns <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> 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 
> 
> Please excuse typos, sent from handheld device 
> 
> On Nov 17, 2016, at 11:26 PM, Rene Struik <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 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 <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 <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 <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:
> On 11/16/2016 9:08 AM, Kepeng Li wrote:
> 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.
> 
> 
> 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
> 
> 
> 
> 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!
> 
> 
> 
> 
> _______________________________________________
> Ace mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
>  
> 
> 
> 
> 
> _______________________________________________
> Ace mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
>  
>  
> 
> -- 
> email: [e-mail] <mailto:[e-mail]> | Skype: rstruik
> cell: [phone] | US: [phone]
> _______________________________________________
> Ace mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>
> 
> 
>  
> --
>  
> 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.
> _______________________________________________
> Ace mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ace <https://www.ietf.org/mailman/listinfo/ace>