Re: [Ace] Group Communication Security Disagreements

[Hannes Tschofenig <[e-mail]>]

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
>