Re: [Ace] Group Communication Security Disagreements
Eliot Lear <lear@cisco.com> Wed, 03 August 2016 07:47 UTC
Return-Path: <lear@cisco.com>
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 8628F12D98E for <ace@ietfa.amsl.com>; Wed, 3 Aug 2016 00:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level:
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 MFqj5__9ecyC for <ace@ietfa.amsl.com>; Wed, 3 Aug 2016 00:47:14 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A5512D8F5 for <ace@ietf.org>; Wed, 3 Aug 2016 00:47:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13108; q=dns/txt; s=iport; t=1470210433; x=1471420033; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=PnFmqAo+WTMpYOZhWw8cjk+7QzthtrtkV+SB45PeEr4=; b=ZdC4ZPOOFvYQW/2Uu2Ck69yBpcZyzLbwfo025VLUBTEQ1Zm5Liy4BhwS CTir9m+Z/VgDKBEMGkMcKLj1TrictYqjX0TxcKjw0x9n0WBUK1ZcmTdSK nADXCOCC5QyBUbPeUQFm9T/yNZ/F0kLOpTbUFHnFqDay2nnQk8ahkLuG4 A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CpDwAIoaFX/xbLJq1dhBsqUq0Jhx+HAySCQoM3AoIRAQEBAQEBXidBDgGEDwEFAQEhSwsQCxgqAgIhBjAGAQwGAgEBF4d8AxcOr0SLWg2DTQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4JBYgiglWCQ4FZAYMkgloFmQA0gzqBcIcggjWJU4VsiCuEBYN3VIIRARyBTjoyAYRogi4BASQHgRgBAQE
X-IronPort-AV: E=Sophos;i="5.28,465,1464652800"; d="asc'?scan'208,217";a="639259215"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 07:46:49 +0000
Received: from [10.61.216.250] ([10.61.216.250]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u737knhq009965; Wed, 3 Aug 2016 07:46:49 GMT
To: Michael Richardson <mcr+ietf@sandelman.ca>, Michael StJohns <mstjohns@comcast.net>
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> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca>
From: Eliot Lear <lear@cisco.com>
Message-ID: <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com>
Date: Wed, 03 Aug 2016 09:47:11 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <13663.1469714549@obiwan.sandelman.ca>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="pedi4d7GWjS1oxLAcFvimlfCvqDdaqdm2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Judi0SXNXz4oJMU9NI-kH4JxPrU>
Cc: ace@ietf.org
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, 03 Aug 2016 07:47:16 -0000
Hi, Reflecting on this discussion and the adoption of the related draft, if the draft is adopted I would suggest that before it goes forward an auditing section should be added to security considerations so that appropriate advice is given in the case a member of a group is compromised. I could envision several mechanisms to address that concern. Here are a few examples that would need to be considerably fleshed out: * An audit system is admitted to the group and records IP addresses and times of messages received. This may be compared to IPFIX records or packet logs to determine the veracity of sources. * Lower level source validation may be employed to determine the veracity of a source IP address. This validation might take the form of IPSEC-AH. * Endpoints might log transmission and receipt of messages so that information may be compared. Other approaches may be employed as well. On additional authorization methods, one approach to protect group membership would be to use a well known L3 multicast address and a separate application port for communications, thus permitting normal network filtering based on pre-authorization of the device at lower layers. The combination of these mechanisms should at least limit potential risk and the threat surface. Eliot On 7/28/16 4:02 PM, Michael Richardson wrote: > Michael StJohns <mstjohns@comcast.net> wrote: > > 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. > > mcr> I agree. > mcr> Perhaps we could convince Mike St.Johns to write that section? > > msj> Probably not - as long as symmetric key group communications is used > msj> as a control protocol. > > Well, who other than Nixon could go to China? > > mcr> And ACE has the right mechanisms to make this work well. > > msj> I agree - public key systems. But that seems to be out of scope here. > > I'm not convinced. What I have taken home is that people think they want to > use symmetric keys, and perhaps it might be safe among completely equivalent > devices. I take your point (strongly) that this bubble will be broken, with > catastrophic results. We need asymmetric methods between bubbles, and we > need to define that early. > > mcr> We should also consider whether we can use hash-chains, like S/KEY did, to > mcr> authenticate messages that should only go out in emergencies. Such messages > mcr> would clearly *need* to be multicast, but once used, they can never be > mcr> reused. They can't be originated by more than one sender though.... so it's > mcr> really the message stored by the "EMERGENCY STOP" button. > > msj> That's an interesting idea - but AIRC, hash chains could be originated > msj> by anyone that held the signing/verification key. > > Yes, provided they distributed the initial (asymmetrically signed) h^n(k) > value out in advance, and gave all the devices enough time to verify that > signature. Plus flash to store the n-th hash. > > For the single sender/controller, multiple receiver/actuator situation this > would be almost as fast as the symmetric group key, yet much more secure. > > For the multiple sender situation, you need to replicate things n-times. > But it's still not n*m keys. > > msj> Let's do this the right way. Let's not bow to the "tyranny of the > msj> light switch" in accepting solutions that are NOT secure, even for the > msj> limited scope they are proposing. > > +1. > > -- > 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
- Re: [Ace] Group Communication Security Disagreeme… Michael Richardson
- Re: [Ace] Group Communication Security Disagreeme… Mohit Sethi
- Re: [Ace] Group Communication Security Disagreeme… Hannes Tschofenig
- Re: [Ace] Group Communication Security Disagreeme… Mohit Sethi
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Hannes Tschofenig
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Hannes Tschofenig
- Re: [Ace] Group Communication Security Disagreeme… Derek Atkins
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns
- [Ace] (on signature verification times) Re: Group… Rene Struik
- [Ace] Group Communication Security Disagreements Hannes Tschofenig
- Re: [Ace] Group Communication Security Disagreeme… Derek Atkins
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Paul Duffy
- Re: [Ace] Group Communication Security Disagreeme… Michael Richardson
- Re: [Ace] Group Communication Security Disagreeme… Grunwald, Markus
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns
- Re: [Ace] Group Communication Security Disagreeme… Michael Richardson
- Re: [Ace] Group Communication Security Disagreeme… Kathleen Moriarty
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns
- Re: [Ace] Group Communication Security Disagreeme… Ludwig Seitz
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Somaraju Abhinav
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns