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