Re: [Ace] Group Communication Security Disagreements

[Mohit Sethi <[e-mail]>]

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