Re: [Ace] Group Communication Security Disagreements

[Eliot Lear <[e-mail]>]

Hi Hannes,


On 7/25/16 5:47 PM, Hannes Tschofenig wrote:
> 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?a

I agree in part (the part that if you have a clean separation of
authorization and authentication it *should* be possible to authorize
specific devices into a group and then determine which specific device
is misbehaving).  Also see Mike St. John's email, and I had thought what
you were asking about is what sort of transitive trust is granted.

>
>>> 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.

Point taken, but even so, this isn't a matter of what the network does,
but how the device identifies itself to other devices, including network
devices.

>
> 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.

Ok.

>
>>> 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.

Use: yes as a means to authenticate transactions.  Not as authorization
itself.

Eliot