Re: [Ace] Summary of ACE Group Communication Security Discussion
Michael StJohns <mstjohns@comcast.net> Mon, 26 September 2016 15:41 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 1A60F12B2D3 for <ace@ietfa.amsl.com>; Mon, 26 Sep 2016 08:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.016
X-Spam-Level:
X-Spam-Status: No, score=-5.016 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, 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 ennA3GMptcu5 for <ace@ietfa.amsl.com>; Mon, 26 Sep 2016 08:41:52 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 C6BFB12B1DF for <ace@ietf.org>; Mon, 26 Sep 2016 08:41:52 -0700 (PDT)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-08v.sys.comcast.net with SMTP id oXzMbOza584vjoY2SbKLdJ; Mon, 26 Sep 2016 15:41:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1474904512; bh=QUczLg4b7/g7GVqbJxgJUReJfgwmFylOjgG8vYtv4xU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=cKZ8WEGm2yOW67F9vO03vDaundAdqwColptJSbus4Wbf91JZzqYX14nx9cnww/ggJ /SGJy8zX9AQVuJ++E1BfgWBlKzr8hcLHh3VVbIf50g991g9dyixGgoTnzxgkZjcAGb oJMHFwNLlfxIEQLfidkRa5hVlbho5RUksoEdIIqynAi/gYLS+yuJ1ND/rSy7Vn3hFE C9rnCUn65IBTWSmkIWB7rON2e1XZDx2d+MoyNp1rUu+cvxkfQ2oUC111SmDAAIz736 lFy3hDsmE55Km2kVGJKDFRVQda549ZAYf0tosWfnTYPdxAgC5q50c0P6NrvleMw9jR y7cSuLfVYeOSA==
Received: from [IPv6:2601:148:c000:10a4:cdb3:c1d0:3c22:ab2d] ([IPv6:2601:148:c000:10a4:cdb3:c1d0:3c22:ab2d]) by resomta-ch2-10v.sys.comcast.net with SMTP id oY2RbEFft8W1PoY2RbSfX9; Mon, 26 Sep 2016 15:41:52 +0000
To: ace@ietf.org
References: <D40F1535.451DD%kepeng.lkp@alibaba-inc.com> <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <b69552fc-97c1-bc8f-6282-c3d42bf081c0@comcast.net>
Date: Mon, 26 Sep 2016 11:41:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfGOX28oK+XYNZMWQZ/LORT8w6uZN0fRJPq+atZISxlMWkny1RUDVejZTTkdM7WgIaBoacPnuzoAC1MuXV/3MeRZ3CYjGrjrxou2+rOHlV6WZc+dUIIRP f6lqtFLCIAXa2faeFIf8QLDd5gj5gKaOSWYjw4loMMwiA5v6EAY5b9R1GbKH1VweRH7o6Irtm0fj2A==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/TG8cc3pQ_Mgjek_tBonucBww63A>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion
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: Mon, 26 Sep 2016 15:41:55 -0000
On 9/26/2016 8:30 AM, kathleen.moriarty.ietf@gmail.com 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. With respect to Abhinav's proposal, we've already got several group key manager systems - we don't actually use any of them for control systems, and you might want to inquire as to the reason. [RFC2093,2094] [RFC4046] [RFC4535] With respect to Eliot's comment, it doesn't really matter if the key management protocol is asymmetric if the multicast session keys are symmetric and used for control. The analysis of this can pretty much ignore the key management piece and start with 100 controllers and 1000 actuators with pre-shared keys to consider the threat and mitigation models. Which analysis - AFAICT - no one has actually done. Basically, if you can't secure this 100/1000 system and keep it secure with respect to control functions, I would argue that the rest of it (e.g. key management) is meaningless window dressing. Later, Mike ps - do you *really* want to reinvent SCADA and all its security issues? > > Kathleen > > Please excuse typos, sent from handheld device > >> On Sep 26, 2016, at 7:11 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote: >> >> I noticed that Eliot also expressed support for the approach presented by Abhinav, see https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxgVeYVzFaI >> >> Ciao >> Hannes >> >>> On 09/26/2016 07:11 PM, Kepeng Li wrote: >>> Hi all, >>> >>> >>> We went through all email exchanges again in order to see where we are. >>> Abhinav also proposed a way forward in his email to the list, >>> see https://www.ietf.org/mail-archive/web/ace/current/msg01961.html, >>> where he proposed to standardize a solution based on public key as well >>> as symmetric key cryptography. >>> >>> >>> Here is our impression of the views presented by various people. >>> >>> >>> Mike seems to think the only acceptable solution is to use messages >>> signed using public key crypto and is strongly against working on a >>> symmetric key group communication protocol. >>> >>> >>> Paul Duffy and Michael Richardson are in favor of defining a public key >>> crypto solution but it is not clear whether they are against specifying >>> a symmetric key solution as well. >>> >>> >>> Walter, Abhinav, Sandeep, Hannes are in favor of working on a symmetric >>> key group communication security protocols (as co-authors of the work). >>> Oscar Garcia (Philips) is also in favor of the work. >>> >>> >>> In this mail to the list, >>> see https://www.ietf.org/mail-archive/web/ace/current/msg01931.html, >>> Robert Cragie (ARM) expressed a view that public key crypto is the >>> preferred solution but others based on symmetric crypto are still worthy >>> of consideration. >>> >>> >>> Markus Grunwald (Osram) also appears to be in favor of the proposed >>> approach, see >>> >>> https://www.ietf.org/mail-archive/web/ace/current/msg01932.html >>> >>> >>> >>> Akbar Rahman also seems to be in favor of working on a group >>> communication security protocol, see >>> >>> https://www.ietf.org/mail-archive/web/ace/current/msg01873.html >>> >>> >>> >>> Ned Smith also seems to be in favor of working on a group communication >>> security protocol, as expressed in his mail to the list: >>> >>> https://www.ietf.org/mail-archive/web/ace/current/msg01872.html >>> >>> >>> >>> The opinion of the following persons in the discussion appear unclear to me: >>> >>> - Mohit Sethi >>> >>> - Ludwig Seitz >>> >>> - Carsten Bormann >>> >>> - Stephen Farrell >>> >>> - Jim Schaad (offered clarifications regarding the use of COSE) >>> >>> >>> >>> Pascal Urien and Rene Struik provided performance data but they didn't >>> appear to have expressed a strong view about the question regarding >>> symmetric vs. asymmetric crypto for group communication security. >>> >>> Derek Atkins offered performance data for public key crypto but refers >>> to new techniques (rather than RSA/ECC). >>> >>> >>> >>> Please correct us if we are wrong in our interpretation of your mail >>> postings. >>> >>> >>> >>> Ciao >>> >>> Hannes & Kepeng >>> >>> >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace
- [Ace] Summary of ACE Group Communication Security… Kepeng Li
- Re: [Ace] Summary of ACE Group Communication Secu… Eliot Lear
- Re: [Ace] Summary of ACE Group Communication Secu… Hannes Tschofenig
- Re: [Ace] Summary of ACE Group Communication Secu… kathleen.moriarty.ietf
- Re: [Ace] Summary of ACE Group Communication Secu… Michael StJohns
- Re: [Ace] Summary of ACE Group Communication Secu… Eliot Lear
- Re: [Ace] Summary of ACE Group Communication Secu… kathleen.moriarty.ietf
- Re: [Ace] Summary of ACE Group Communication Secu… Michael StJohns
- Re: [Ace] Summary of ACE Group Communication Secu… Michael StJohns
- Re: [Ace] Summary of ACE Group Communication Secu… kathleen.moriarty.ietf
- Re: [Ace] Summary of ACE Group Communication Secu… Michael Richardson
- Re: [Ace] Summary of ACE Group Communication Secu… Michael StJohns
- Re: [Ace] Summary of ACE Group Communication Secu… Michael Richardson
- [Ace] Summary of ACE Group Communication Security… Kepeng Li
- [Ace] Slides for the Seoul F2F meeting Kepeng Li
- Re: [Ace] Summary of ACE Group Communication Secu… Michael StJohns
- Re: [Ace] Summary of ACE Group Communication Secu… Michael Richardson
- Re: [Ace] Summary of ACE Group Communication Secu… Rene Struik
- Re: [Ace] Summary of ACE Group Communication Secu… kathleen.moriarty.ietf
- Re: [Ace] Summary of ACE Group Communication Secu… Tirumaleswar Reddy (tireddy)
- Re: [Ace] Summary of ACE Group Communication Secu… Kathleen Moriarty
- Re: [Ace] Summary of ACE Group Communication Secu… Göran Selander
- Re: [Ace] Summary of ACE Group Communication Secu… Kumar, Sandeep
- Re: [Ace] Summary of ACE Group Communication Secu… Shahid Raza
- Re: [Ace] Summary of ACE Group Communication Secu… Michael StJohns
- Re: [Ace] Summary of ACE Group Communication Secu… Hannes Tschofenig
- Re: [Ace] Summary of ACE Group Communication Secu… Carsten Bormann
- Re: [Ace] Summary of ACE Group Communication Secu… Michael StJohns
- Re: [Ace] Summary of ACE Group Communication Secu… Rahman, Akbar
- Re: [Ace] Summary of ACE Group Communication Secu… Michael StJohns