I Agree. Thanks /--Mohit
On 07/25/2016 01:06 PM, Hannes Tschofenig wrote:
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 HannesEliot _______________________________________________ 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
