IETF Logo Mail Archive

Re: [Ace] Group Communication Security Disagreements

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 27 July 2016 21:56 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 1259D12D98C for <ace@ietfa.amsl.com>; Wed, 27 Jul 2016 14:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level:
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 4eKHCoVqedko for <ace@ietfa.amsl.com>; Wed, 27 Jul 2016 14:56:36 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6294D12D98F for <ace@ietf.org>; Wed, 27 Jul 2016 14:56:36 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 86DB6200A3; Wed, 27 Jul 2016 18:06:31 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A169A638BE; Wed, 27 Jul 2016 17:56:35 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "ace@ietf.org" <ace@ietf.org>
In-Reply-To: <CAHbuEH4u=AF1LSoDq+YfLwt+VX1OOrj54331GuZmyjLswHvNnw@mail.gmail.com>
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>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 27 Jul 2016 17:56:35 -0400
Message-ID: <3271.1469656595@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/1QSJp_UYT3fJ8zE8R2tSijKdLBo>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
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 21:56:38 -0000

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?

And ACE has the right mechanisms to make this work well.

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.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.35.0 | Report a Bug | By Email | System Status