Hi Mohit, there are always things that can go wrong.
I have not seen a solution where nothing can go wrong. Even not standardizing anything isn't a preventing companies, or developers designing their own solutions. We know how well that works. Ciao Hannes On 07/25/2016 06:36 PM, Mohit Sethi wrote: > 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ace >>> >> >> >> _______________________________________________ >> Ace mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ace > > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
