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

Eliot Lear <lear@cisco.com> Mon, 26 September 2016 16:10 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 B26C512B310 for <ace@ietfa.amsl.com>; Mon, 26 Sep 2016 09:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.838
X-Spam-Level:
X-Spam-Status: No, score=-16.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, 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 uRljx8gt5cxD for <ace@ietfa.amsl.com>; Mon, 26 Sep 2016 09:10:49 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273A512B24C for <ace@ietf.org>; Mon, 26 Sep 2016 09:10:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2914; q=dns/txt; s=iport; t=1474906249; x=1476115849; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=byfzZr8b5qWTGNhCdTAUzysEP+YpUcJZ053mwhCKnOM=; b=X1hAcNZnnwkaLttm6VUWZyydQiuAt7rWgpTVawIj4vRN3bY4OWAwcR5j G4ONWIkZBKPhHRuX6kIGmxHCxYntgoKt/SSxzC/nslehzkHv/xv2N7uqq jq9TMsm8MLEMfUPqR4lFHnVPSfRhER9hyctIg+w7G5fhn+9zwsxx8Njv9 0=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B8BABDSOlX/xbLJq1dGQEBAQEBAQEBAQEBBwEBAQEBgz0BAQEBAYEfuVSCBIYeAoIYEgECAQEBAQEBAV4nhGEBAQEDASNbCwsYKgICVwYBDAgBAYg/CLIIjGABAQEBAQEBAwEBAQEBAQESDogzgliHSIJaAQSZdoNBgXaKMYlmhgWQZyQBL4UHPIgaAQEB
X-IronPort-AV: E=Sophos;i="5.30,400,1470700800"; d="asc'?scan'208";a="688521372"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2016 16:10:22 +0000
Received: from [10.61.210.79] ([10.61.210.79]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u8QGAMar005698; Mon, 26 Sep 2016 16:10:22 GMT
To: Michael StJohns <mstjohns@comcast.net>, 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> <b69552fc-97c1-bc8f-6282-c3d42bf081c0@comcast.net>
From: Eliot Lear <lear@cisco.com>
Message-ID: <3dbd8a79-ca4b-3f71-d838-e30beda754be@cisco.com>
Date: Mon, 26 Sep 2016 18:10:21 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <b69552fc-97c1-bc8f-6282-c3d42bf081c0@comcast.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="i0OUE7tlNLh8SF3UEEWDf2g5wkfJdLwBO"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/xQPBflgs0pSUaSoJX2at696ZKmc>
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 16:10:51 -0000

Hi Mike,

Just one clarification:


On 9/26/16 5:41 PM, Michael StJohns wrote:
>
> 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.  

This doesn't really capture my position which leads me to believe I've
muddled it.  The key question is whether every transaction needs to be
authenticated to a unique device *within this protocol* or is it
sufficient that such authentication exists at other layers, e.g., either
in content or at lower layers?  I recognize that there are some big
risks to adding such a dependency, because there is no certainty that
implementations will follow that guidance.

> 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.

The question in this context again, is whether it all has to happen at
this layer?

Eliot