Re: [Ace] Group Communication Security Disagreements

[Mohit Sethi <[e-mail]>]

I Agree.

Thanks
/--Mohit

On 07/25/2016 01:06 PM, Hannes Tschofenig wrote:
> 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
>>