Re: [Ace] Group Communication Security Disagreements

Eliot Lear <lear@cisco.com> Fri, 16 September 2016 10:03 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 176F512B017 for <ace@ietfa.amsl.com>; Fri, 16 Sep 2016 03:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.029
X-Spam-Level:
X-Spam-Status: No, score=-16.029 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.508, 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 zMVdujv041gh for <ace@ietfa.amsl.com>; Fri, 16 Sep 2016 03:03:38 -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 52A9C12B094 for <ace@ietf.org>; Fri, 16 Sep 2016 03:03:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6325; q=dns/txt; s=iport; t=1474020217; x=1475229817; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=ZDcrtnKNce9C5fCoH28I88MYKOC0gB7kcrJiL7+Jx/I=; b=eyLRv8s2B3wXBMS3UhT/ysugum8wwJVJM51t+aifkRSnKfBNEroe2fZ/ pI5Pp9fBcSoNZlIgu0aaLwMNX2+QN5t/K03XhURmvPEvg74EEVRfHlWRz kftdZflVWr4lBCyHkX2pZEKlbxQ/hC3dsW38KgxIIBTC39qaOXeqbZDd5 Q=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BLAgB3wttX/xbLJq1UCRkBAQEBAQEBAQEBAQcBAQEBAYM6AQEBAQGBH44Fph2FD4IDhh4Cgg8UAQIBAQEBAQEBXieEYgEBBCMEYgsEFCoCAlcGAQwIAQGIRrNdjEIBAQEBAQEBAQIBAQEBAQEBAQEBAQ4OiCoIgk6EGYMpgloBBJltg0CBdYoliWOGA5BaHjaEbDyHPQEBAQ
X-IronPort-AV: E=Sophos;i="5.30,344,1470700800"; d="asc'?scan'208,217";a="646744774"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Sep 2016 10:03:35 +0000
Received: from [10.61.81.127] (ams3-vpn-dhcp4480.cisco.com [10.61.81.127]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u8GA3Y5S013839; Fri, 16 Sep 2016 10:03:35 GMT
To: Michael StJohns <mstjohns@comcast.net>, 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> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <13663.1469714549@obiwan.sandelman.ca> <9a4153f1-6a96-0ae6-020b-0f0f966aecdf@cisco.com> <95997f84-2715-3287-39d3-45d6ff5f3ea0@comcast.net> <463a5cce-9dd1-5d68-bd97-0f08d0719960@sics.se> <HE1PR0601MB2203647255579D1B1D7C6E9EFCF10@HE1PR0601MB2203.eurprd06.prod.outlook.com> <d86dbf18-9caa-a621-aca7-ffc85317f443@cisco.com> <97bfa890-da35-8db6-9a11-207f40883e42@comcast.net>
From: Eliot Lear <lear@cisco.com>
Message-ID: <47ad4e37-4747-0150-07da-6994b4dfb0a8@cisco.com>
Date: Fri, 16 Sep 2016 12:03:34 +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: <97bfa890-da35-8db6-9a11-207f40883e42@comcast.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="N3KJD8ub4Wox1sEM6S8tGx5i1QD69oMeN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/E06b5gKmysBR5h5MhIACB12TSQc>
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: Fri, 16 Sep 2016 10:03:40 -0000

Hi Mike,


On 9/15/16 5:36 PM, Michael StJohns wrote:
> Hi Elliot et al -
>
> Sorry, I think you're still missing the point:
>
>   * Source Authentication (A) cannot be accomplished securely by
>     Symmetric Key Multicast  (^B):   (A -> ^B)
>   * Cyber Physical control functions (C)  require source
>     authentication  (A):  (C -> A)
>   * Turning on and off lights (D) is a Cyber Physical Control Function
>     (C):  (D -> C)
>   * Therefore Turning on and off lights (D) requires source
>     authentication (B):  (D -> C -> A) (D -> A)
>   * Therefore Turning on and off lights (D) cannot be accomplished
>     securely by Symmetric Key Multicast (^B):  (D -> C) ( C -> A) (D
>     -> C -> A) ( D->A) (A -> ^B) (D -> ^B).
>
> Apologies if I got the formal logic wrong - its been a while.
>
All of this seems about right to me, but with two big caveats:

 1. We are, I think, talking about group-based communications and not
    necessarily group-based authorization for device control.  There is
    a difference, albeit subtle.  One could reasonably envision
    borrowing from lower layers to satisfy device authorization
    requirements.

 2. The question here is whether this is the right level to address the
    problem.  And I'll ask my clarifying question again: is there a more
    logical place to anchor identity, like above or below this layer?

Eliot