On Tue, 16 Sep 2014, Tim Chown wrote:

There’s obviously some interesting implications of this. One is that there are insecure wired links too!

Good point. I believe we're hitting the classic "secure or easy" tradeoff.

There is no way we automatically can detect what is home and what is not, instead there is going to have to be user interaction to say what is part of the home and what is not. For HNCP, this might mean some kind of cryptographic interaction of some kind, for instance what you suggested, having some kind of button, or perhaps having some kind of home "control panel" where new devices pop up and where they're authorized (or not).

As was presented in.. err, London?, shared secrets are bad. To really do this properly, we need device specific keys and some kind of list of "devices that are allowed to connect", perhaps by having their public keys in HNCP. I don't know. I am no security expert, but I believe we probably have to have two or three modes of security, one being "unsecure" that is auto everything (will give scenarios like the one Tim wrote about), one that is "shared secret", but where devices need to be configured using this shared secret (protects against accidents), and a third one where PKI is used, but where user policy infrastructure is available. The third one greatly increases scope the framework required to implement. I'm not sure it would even be HNCP anymore, perhaps we need a wider view than what the HOMENET charter has in it currently.

It wouldn't surprise me if we need another WG to tackle this. Perhaps it should be a more generic one based on creating a framework to handle access requests and control and how to distribute keys and other credentials, for SSH/SSL/IPSEC use, potentially? A lot of these mechanisms probably already exists, but they need to be put together and told how to interact.

--
Mikael Abrahamsson    email: swm...@swm.pp.se
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to