Re: [Ace] Group Communication Security Disagreements

Eliot Lear <lear@cisco.com> Wed, 14 September 2016 10: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 02BB912B274 for <ace@ietfa.amsl.com>; Wed, 14 Sep 2016 03:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.03
X-Spam-Level:
X-Spam-Status: No, score=-16.03 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=-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 9rXUtSn-I7Ul for <ace@ietfa.amsl.com>; Wed, 14 Sep 2016 03:10:05 -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 85D1312B059 for <ace@ietf.org>; Wed, 14 Sep 2016 03:10:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4953; q=dns/txt; s=iport; t=1473847804; x=1475057404; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=xUd1Fd+ATFp/xKihLYxQ2BFJBXvDXCrtiYFMCIy5leE=; b=Ki29Tku7A0P2z9crW852pZY8rE01PEkgpW8VoL9H3LsrX4SWTN6qDsnu OUr+fzGM/erg/UD2Lek6bSsR27kcYYJVSP6cf4CyIvQjMV+ERuJL1CBSm 6rxCuTMgp/7JwAqR1zlfnVf3vLjb1VBu9Ppb9vJnmUd5nqvmvOzHKy6Gj U=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1AQCCINlX/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBgzoBAQEBAXUqUo0zqyWCAxkLhXoCggMUAQIBAQEBAQEBXieEYgEBBAEBASBLGwsYKgICJzAGAQwGAgEBF4gvDq9YjDsBAQEBAQEBAQEBAQEBAQEBAQERCQWIKoJWhBILBgECgxyCWgEEmWiDQIF1gy6GcYFuhGCDE4YBkFYeNoRrOjSEJw4XgggBAQE
X-IronPort-AV: E=Sophos;i="5.30,333,1470700800"; d="asc'?scan'208";a="688223528"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2016 10:10:02 +0000
Received: from [10.61.64.112] (ams3-vpn-dhcp112.cisco.com [10.61.64.112]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u8EAA2BN021970; Wed, 14 Sep 2016 10:10:02 GMT
To: Somaraju Abhinav <abhinav.somaraju@tridonic.com>, "ace@ietf.org" <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>
From: Eliot Lear <lear@cisco.com>
Message-ID: <d86dbf18-9caa-a621-aca7-ffc85317f443@cisco.com>
Date: Wed, 14 Sep 2016 12:10:00 +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: <HE1PR0601MB2203647255579D1B1D7C6E9EFCF10@HE1PR0601MB2203.eurprd06.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="AX1sUXGxEc68lxUxqbSJNQS96IEsTw7Uj"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ctCtj9QT0WwBDki7vxgVeYVzFaI>
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, 14 Sep 2016 10:10:08 -0000

Hi Abhinav,

Thanks for this email.  I think this is pretty close to what I think is
necessary.  To be sure, vendors and developers have very little power to
limit where their products will be placed.  Thus it is important to
state strongly that source authentication is necessary at other layers
when it is not used at this layer.  To me that would cover all
circumstances.  With that approach, I would strongly support the
adoption of your document as a WG document and would of course review it
and provide comments (as I have ;-).

Regards,

Eliot



On 9/14/16 11:33 AM, Somaraju Abhinav wrote:
> Hi all,
>
> Thank you all for the feedback on the group communication security discussion.
>
> We noticed that two concerns have been raised with the current specification.
> 1)   Symmetric keys do not provide source authentication. Here, most people on the mailing list agreed that symmetric keys provides basic security and is sufficient for lighting applications. It is not intended to be used in the wider internet for more sensitive group communication security use-cases.
> 2)   How to ensure that the symmetric key group communication security solution is not used in situations it is not designed for?
>
> We propose to address the received feedback by making the following modifications to the document:
>
> 1)   We will add an additional section where we specify how asymmetric cryptography can be used for secure group communication. This will help for all those cases where source authentication is desired.
> 2)   Add a security considerations section where we explain that the asymmetric key solution is the recommended approach but that there are situations where low latency group communication makes it difficult to use asymmetric cryptography and where source authentication is less important. You could call it an applicability statement.
>
> If this proposed modifications makes sense then we can try to submit a new draft with these changes.
>
> Abhinav
> ________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>