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 > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
