Re: [Ace] Group Communication Security Disagreements

[Hannes Tschofenig <[e-mail]>]

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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>
>>
>> _______________________________________________
>> Ace mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ace
> 
> 
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>