Re: [Ace] Group Communication Security Disagreements

Michael StJohns <mstjohns@comcast.net> Wed, 27 July 2016 23:21 UTC

Return-Path: <mstjohns@comcast.net>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D339812DA43 for <ace@ietfa.amsl.com>; Wed, 27 Jul 2016 16:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv7g_S8aZtsz for <ace@ietfa.amsl.com>; Wed, 27 Jul 2016 16:21:16 -0700 (PDT)
Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DB512D9F3 for <ace@ietf.org>; Wed, 27 Jul 2016 16:21:15 -0700 (PDT)
Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-01v.sys.comcast.net with SMTP id SY84bLSYkucHZSY8YbpXni; Wed, 27 Jul 2016 23:21:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1469661674; bh=9K37ciuVqggTdbPin1JigFbmltadXJ7kpL58ygl9x3M=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=tKoQyp3umxOaZXBylzqeyqDDPzv9LxiZyd/58d7LdXtFgIkxiqQFu9V/DqOOMB+p3 EPzrXuuCTfNaIEg+6X+jZ4yLaBiEMiae1QT+vTJR6T9idNBLAwNTTtasoiN5RaoQmE elpHYeYOs7LRv1toAMKS07x0E45egGIl+qVel4EmuBrzoHVNQw7ZcsQ1LS4snG8Hal MXhsotPd3B+bAYSzP2GoMER7makyKrFWTcZZ6U6FEcloO+YYkITRp6bNbYoiRZR+eW SaBtCsgckM7t0Ip1j9wOtmyjwd+DLc1P7VbHDOgJIPNyhNBNYDpBAC0RYdRTiDklFn RlPnOfNFH6QQQ==
Received: from [IPv6:2601:148:c000:1951:ccd7:589d:2636:a1d] ([IPv6:2601:148:c000:1951:ccd7:589d:2636:a1d]) by comcast with SMTP id SY8XbXSBuULT2SY8YbgYRG; Wed, 27 Jul 2016 23:21:14 +0000
To: ace@ietf.org
References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <CAHbuEH4u=AF1LSoDq+YfLwt+VX1OOrj54331GuZmyjLswHvNnw@mail.gmail.com> <3271.1469656595@obiwan.sandelman.ca>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net>
Date: Wed, 27 Jul 2016 19:21:24 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <3271.1469656595@obiwan.sandelman.ca>
Content-Type: multipart/alternative; boundary="------------D2807F98A1B86E1F866ADFD8"
X-CMAE-Envelope: MS4wfDaCPHfFU/fkiYLB+FmcgtgDb15Yw5OrVU65ym2b6etgAsajMP7fZMig9P1v9QcAaixAPEUvwnX/4GlfsQubfL9JCZ0oF6ETyiWLvR3jzAQAu9s6RClW NFfKc+eTE0SRf/5UNgtIfogxlk7NYGG6QFWHbzS3qi4FrV3Wlm199PnlpziMs9nrXs6rwd4s/kYdHA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/KXuiP547boYo69Vjme2emVlPCY4>
Subject: Re: [Ace] Group Communication Security Disagreements
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2016 23:21:18 -0000

On 7/27/2016 5:56 PM, Michael Richardson wrote:
> Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>      >> Mohit Sethi <mohit.m.sethi@ericsson.com> wrote:
>      >> > designed/developed/specified for their use-case. I could definitely
>      >> > see some IoT startup building a solution that switches on the lights
>      >> > in a room as soon as you unlock the door (thus keeping them in the
>      >> > same group).
>      >>
>      >> Or perhaps more usefully, turning the lights (and the oven) off when you
>      >> leave the house.
>
>      > Good points, but you could do this without them being in the same
>      > group with some controller that managed the interactions with each.
>      > This would be a good set of examples for the security considerations
>      > sections, providing guidance to use a controller rather than group
>      > keys to perform useful functions like these.
>
> I agree.
> Perhaps we could convince Mike St.Johns to write that section?
Probably not - as long as symmetric key group communications is used as 
a control protocol.

>
> And ACE has the right mechanisms to make this work well.
I agree - public key systems.  But that seems to be out of scope here.


>
> We've had a thread now on performance of asymmetrical crypto, and it seems
> that controllers ought to be able to talk to other controllers quickly enough
> to make this workable.
>
> We should also consider whether we can use hash-chains, like S/KEY did, to
> authenticate messages that should only go out in emergencies.  Such messages
> would clearly *need* to be multicast, but once used, they can never be
> reused.  They can't be originated by more than one sender though.... so it's
> really the message stored by the "EMERGENCY STOP" button.

That's an interesting idea - but AIRC, hash chains could be originated 
by anyone that held the signing/verification key.

Again - if you don't touch the physical world, I'm pretty much not 
worried about how screwed up the protocol is.  But you touch the 
physical world.

Let's do this the right way.  Let's not bow to the "tyranny of the light 
switch" in accepting solutions that are NOT secure, even for the limited 
scope they are proposing.

Later, Mike

>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
>
>
>
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace