Re: [Ace] Group Communication Security Disagreements

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 25 July 2016 17:06 UTC

Return-Path: <hannes.tschofenig@gmx.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 3EEED12D90C for <ace@ietfa.amsl.com>; Mon, 25 Jul 2016 10:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level:
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 6ekUn4kSEUEE for <ace@ietfa.amsl.com>; Mon, 25 Jul 2016 10:06:20 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B2C12D907 for <ace@ietf.org>; Mon, 25 Jul 2016 10:06:19 -0700 (PDT)
Received: from [192.168.10.131] ([195.149.223.151]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Me86g-1bfQjf0hiA-00PvJ7; Mon, 25 Jul 2016 19:06:09 +0200
To: Mohit Sethi <mohit.m.sethi@ericsson.com>, Eliot Lear <lear@cisco.com>, 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>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <579646FF.5050902@gmx.net>
Date: Mon, 25 Jul 2016 19:06:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="kmFkmXcaM07DCnG8GI8CPEjTLfA5vbPgc"
X-Provags-ID: V03:K0:Wv61PNyHfTsQyq+SJaKS6B/UOTSW845CJp2osjiiUSOQ/L/2DUC /W30Ko9s6D6S1h+z65YJsQW801jUEvPz1lSD2QXaBJ0KVp0pjNuXFuk7WbuDbQ0sMAlFsxV h5ncLQjX5+UK4AYY3k/XVx9dsv+SYdflwi4fL1r9cFHlmITAVIA4ZyDf4osEXNTcg7Se5ok +yIokt9utTRkOt9xPXeKw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:CcwOwWn7pxw=:6tS5qs0pks6bNRlqeJ6EvF HWOzrBbK5dUKKHZAJIlPrsLT9THxn3DO0BSCns1iP10pNAwtOYVW4t8OubtEl95jZKb6fqJrF SDcRbLFDMKnffebSH0mI0Q0PLhZPwTBu/tIeDG3mX6bd1B2n4YLgLbzum+2gYhrsj6H4u5bpq yOw9kt4gLezwTglkx/bC00gZwJApGpTIi5dxF7AosgssPhOmrsAG95nHbAgL8QnD2rTz3lPXG g9VFZk5AW55k+zF7+aE1gqFyyDeOT8HxKSlsrmIJYCpXYk60Z+OAcW5sgaT16bxKT+G/GqSkY QffEqC2DHYxpu9RPcE1QhQJlkiDIAOSiB/XZYpHXFdH4kfKNUd1EpxSrHtTslgrlvqejoU0km U+8JVSN9Oqlbjv1pFgrx6YvPyxmqd+rrqrqgJdbQSK4VQdPIHHaH3ay8c0dFzjKZu0arGYpmF W0bAN0d5aYBbXRi6074LJOmUfAOe+dqWkf75QHCLIZK095s3WrDd21cHEdZbgSXtPUwahhGAr mqPM0+PFe+FqeUdNy76ePJ0upAJbegoaQJOEr1AxKJcoYGK0Jk5eLlMsWyaRvWn94C5Hobijo MdxYbq2ivDKzZconSIi+Uipq96QZpuuIsj1MdctbwjSWNBxeWQRfPj+c6V1IHYhhADs5hLy2K UlhXgOA9bU1dw4TvJoweGC3Goe9CHepSNMFws06N7D6NF82B83nJtYW8gsQ/qcnmIzgaFKua2 WfwnpGqMZ2reTXNmo0H0DDThZovrnK/DNmXUt2hcfQ5z2hL5ResWEhNaV2U=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/slX5cr2HEO7zNUGfrH-Q3GOqYfE>
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: Mon, 25 Jul 2016 17:06:22 -0000

Hi Mohit,

there are always things that can go wrong.

I have not seen a solution where nothing can go wrong.

Even not standardizing anything isn't a preventing companies, or
developers designing their own solutions. We know how well that works.

Ciao
Hannes

On 07/25/2016 06:36 PM, Mohit Sethi wrote:
> Hi
> 
> A quick comment. Developers often end up using
> things/protocols/technologies which were not
> 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).
> 
> Thanks
> /--Mohit
> On 07/25/2016 11:47 AM, Hannes Tschofenig wrote:
>> Hi Eliot,
>>
>> a quick response.
>>
>> On 07/25/2016 05:12 PM, Eliot Lear wrote:
>>>
>>> On 7/21/16 3:48 PM, Michael StJohns wrote:
>>>> Without unique source identification (and for that matter role
>>>> identification either inband or implicit) any compromised device
>>>> results in your attacker being able to act as a controller for the
>>>> group.  Again, not a large problem (but a problem nonetheless) for a
>>>> small group of lights inside an office behind locked doors. But a very
>>>> large problem for a system that's possibly controlling 100 or 1000
>>>> lights in a group.
>>> +1, and I'm not even sure if it's not a problem for a small group of
>>> lights behind locked doors if wireless is involved.
>> In order for the attack to work a luminary and a door lock need to be in
>> the same group and share the same group key.
>>
>> For me the question is (from an authorization point of view) why the
>> door lock as well as a luminary belong to the same group. Would a door
>> lock participate in a group communication interaction altogether?
>>
>>>> As I said at the microphone, if I thought you could just do this as
>>>> the "ACE protocol for group control of lights" and keep people from
>>>> using it for other things I'd be a lot less concerned (but still
>>>> there's the whole threat of turning off all the lights in a building
>>>> all at once).  But the reality is this protocol will be used for
>>>> control of things beyond lights and it would be irresponsible to
>>>> standardize a protocol with a real possibility for direct real-world
>>>> negative impacts on safety and health.
>>>>
>>> Yes, but I would go further and say that network owners ask two questions:
>>>
>>>  1. What is this Thing?
>>>  2. And what access does it require/not want?
>>>
>>> Absent device identity they cannot answer the 2nd question.  This is as
>>> important for lighting as for any other application, because it is how a
>>> network will distinguish what those applications are.
>>>
>> In ACE we don't care what the network does. This is outside the scope of
>> the charter, intentionally. The identifier for the device is what the
>> device uses to authenticate itself to the authorization server in our
>> setup. We don't call this "device identity" though.
>>
>> The authorization server is, as the name indicates, about storing
>> authorization decisions typically provided by some human. This human
>> could be a user in a home network or could as well an administrator in
>> an enterprise network. We don't care that much. Call it policy.
>>
>>>> The way to solve this for a general involves public key cryptography -
>>>> that's just how the security and physics and math work out.
>>>>
>>> Yes.  And as I believe has also been discussed, use of PSK seems to
>>> cause us to muddle the authentication and authorization aspects of
>>> OAUTH, for instance.
>> I am not sure this is a fair summary of the work in OAuth. OAuth 2.0 as
>> used today on the Web and in smart phone applications with bearer tokens
>> makes heavy use of public key cryptography. It just has to work in a
>> fragile environment -- the Web.
>>
>>
>> Ciao
>> Hannes
>>
>>
>>> Eliot
>>>
>>>
>>> _______________________________________________
>>> 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 mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>