Re: [homenet] HNCP security?
Markus Stenberg markus.stenb...@iki.fi wrote: markus 1) Can we assume secure L2 and/or appropriate device markus configuration by the manufacturer/ISP(/user)? (This is what I can markus assume in my own home.) I think that we can assume that wired links are secure. The only time we care if wireless is secured is when we want to form an adjacency over the wireless link. I think it is acceptable to refuse to form an adjancency over an insecured wireless link. This can also be automated (for first-hop wireless). However, in the ‘what-if’ land, wired - wireless bridges, and wireless - wireless extenders that do things insecurely cannot be detected. Yes, I agree. Let me restate that I think we can securely to do TOFU across the wired link. If that link turns into something less secure, then that's okay. I think it is acceptable to do some kind of TOFU (using IPsec with IKEv2 even) point to point across wired links, and having done that, if there is an adjancy later possible between those two devices over what would otherwise be an insecure link, that the previously exchanged keys work. That means one can plug two routers together with a cable, and then separate them, knowning that the two routers will remain entangled (I’m making allusions to http://en.m.wikipedia.org/wiki/Quantum_entanglement) I assume you mean: - On wired links: opportunistic IKEv2 attempt, fallback to non-IPsec (if no IPsec available? if no key?), and update the SPD dynamically based on successful IKEv2 attempts. - On the wireless (all? only insecure?): force IPsec using the known good SPD entries. That is interesting scheme. Implementation-wise, it sounds somewhat painful though. yes, I agree that it's probably difficult with the available implementation of openwrt IKEv2 daemons... I don't think it's architecturally that hard. I further suggest that if two routers have wireless that they might well have a WPA2/PSK available to them, and that they can and SHOULD use something derived from that key to authenticate each other. Could be over IKEv2, yes. I _think_ we have to assume some passwords somewhere. - WPA2 PSK on almost all home routers by default (most home network access these days is wireless) yes, agree. And if they have multiple routers, they likely have the same WPA2-PSK. - admin password (for those user actually has access to, and are not part of some super-fancy PKI scheme for authenticating administrator) I'm less thrilled about using the admin password. They have less likely hood of being changed, and ideally, they are encrypted/hashed in a way that the raw password can't be seen. markus 2) If not, should the solution be some sort of pre-shared key markus scheme? (If not, please explain your alternative solution.) If we assume the abovekey, we could use it to derive a pre-shared key for a multicast IPsec SA using AH. Can we assume, declare, that if you don't know the key, that you skip the AH header, and process the HNCP that is inside as if it wasn't secured at all? We wanted to do that for SEND, but there were IPsec implementations that could do that, because we overspecified AH back in 2401. Given that home routers are purpose built boxes, and not generic random hosts, perhaps we can specify this behaviour. Hmm. I wonder if that assumption would work bidirectionally, though. That is, the not-key-knowing router sending plaintext traffic, and the others using the information? If so, what is the value of having the (optional) authentication at all? If assumption is not bidirectional, then the distributed algorithms would not work very well over such protocol - unless the unauthenticated messages were just used for bootstrapping the trust somehow, but it is not clear to me how that would happen either. Of course, they could be used to show user some error (if the router actually had UI of some kind) but not much else that I can see. That's what I would suggest: unauthenticated messages are to bootstrap trust. Possibly that involves an item on a web page saying, Router XYZ wants to join Stenberg House, permit Y/N, perhaps can flash attention LED on front. That would only be used if the network had been set to paranoid secure, and/or if the wired-TOFU didn't work. markus 2.1) And if so, should it be manually keyed IPsec (multicast markus prevents e.g. IKE)? (This is what is in the draft currently.) Yes, if we can make this AH assumption of skipping, so that we can get TOFU to work. If we assume some psk on all routers, we can probably bootstrap ’something’ without TOFU too? I agree; but I think that TOFU would be useful here, particularly if the router isn't wireless capable. Maybe it is a bridge to
Re: [homenet] HNCP security?
Steven Barth cy...@openwrt.org wrote: And it's extremely unlikely that DTLS will be a one-sentence solution even if it gets adopted because DTLS, IPsec, etc say nothing about enrollment and authorization. Those are by far the hard problems with homenent security. I wouldn't really want to lock HNCP to any trust scheme at this point where we are not even sure what we want. I'd rather choose the underlying mechanism, either DTLS or IPsec/IKE and leave the rest out-of-scope. Maybe mention PSK-usage as baseline option and say various other certificate-based approached are possible but out-of-scope of the HNCP draft itself. With respect, if you leave the trust scheme out of scope, what you are really doing is leaving all of the security out of scope, because it won't be deployable. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpf_Imlo3UTo.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 23, 2014, at 1:23 PM, Michael Richardson mcr+i...@sandelman.ca wrote: With respect, if you leave the trust scheme out of scope, what you are really doing is leaving all of the security out of scope, because it won't be deployable. +1 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Randy Turner rtur...@amalfisystems.com wrote: Are we assuming that the home router is purchased retail, and not fulfilled or provided by an ISP? The method to establish trust relationships would hinge on the answer 1) if there only one home router from the ISP, then there is no problem. 2) ISP-provided router has to be willing to trust retail purchased router, or nothing works. 3) ISP-A-provided router has to be willing to trust ISP-fullfilled router from ISP-B-provided router. If you have secrets (including WPA-PSK keys) that are on your ISP-fullfilled router, that you want to keep secret from your ISP, then you lost. If you don't trust your ISP, then you can't use your ISP provided router. So the answer does *not* hinge on the answer. It has to work, and I think we can make it work. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpxs_cjQQrXo.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On 9/23/14, 10:59 AM, Michael Richardson wrote: 2) ISP-provided router has to be willing to trust retail purchased router, or nothing works. So what about the other way around? To what degrees should my homenet trust ISP-maintained CPE? Or more succinctly, what are the things the ISP and Retail CPE need to collaborate on and what are the things they need to take an adversarial stance on? Neither me, nor my ISP are similarly motivated, after all. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
Michael Thomas m...@mtcc.com wrote: 2) ISP-provided router has to be willing to trust retail purchased router, or nothing works. So what about the other way around? To what degrees should my homenet trust ISP-maintained CPE? That's up to you. Seriously. Your ISP-maintained CPE totally p0wns your network. If you don't trust them, even just a little bit, then you can't use their equipment. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpH9HSCmZ7vR.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group draft adoptions
Late, but: I have read draft-pfister-homenet-prefix-assignment. Adopt it. I thought I read it before, but maybe not. It all seems familiar, but what's with all the IPv4 stuff? I guess we are doing an IPv4 thing, because we can, and it's useful to be able to turn off detect that have multiple potential DHCPv4 servers, and turn them off if we can. I think that we should remove: If the delegated prefix is too small given the size of the network, prefixes of arbitrary lengths may be used. and stick to 64-bit for all the why-64 reasons. Let's not talk about any other options.This document also seems to interoperate with (CableLabs) HIP. draft-mglt-homenet-front-end-naming-delegation draft-mglt-homenet-naming-architecture-dhc-options I have read previous versions of these documents, and upon looking again, I see lots of shiny new text, and I like it all. While there are many people who are very scared of having home devices in DNS, and many are worried that they will be forced somehow to do so, I don't think any such comments matter. This is, like almost all protocols the IETF creates, optional to enable. Please adopt these documents. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 23, 2014, at 3:39 PM, Michael Thomas m...@mtcc.com wrote: On 9/23/14, 1:07 PM, Michael Richardson wrote: Michael Thomas m...@mtcc.com wrote: 2) ISP-provided router has to be willing to trust retail purchased router, or nothing works. So what about the other way around? To what degrees should my homenet trust ISP-maintained CPE? That's up to you. Seriously. Your ISP-maintained CPE totally p0wns your network. If you don't trust them, even just a little bit, then you can't use their equipment. And there's nothing we can do about that, even if we define a boundary such that they are outside it? Do they *have* to participate in the IGP in order for homenet routing to work? I'm no expert here, but it seems to me that the normal first hop ISP router doesn't have these characteristics of p0nwage for in-home traffic? Dear Michael, Actually, it is better to assume there is a long list of vulnerable home routers being p0wned by entities beyond their ISP. Leaving that problem aside and assuming this can be handled using a KISS approach, even setting up firewalls when their are multiple routers involved becomes somewhat problematic whenever overlaid networking is not being used. After all, how can each router's assigned prefixes be exchanged. How can mDNS proxy information be communicated? It is important to consider many of the contained devices might be vulnerable to Internet access. Not all devices are updated beyond their warranty period. In some cases, this period might be a 20/20 guarantee, 20 feet or 20 seconds, whichever comes first. While some printers might be able to handle direct Internet access, most can't. Many of these devices announce their routable address via mDNS, hence the need for a network overlay. By using a network overlay, Trust on First Use (TOFU) is less essential although nice to have as an additional layer of protection. Regards, Douglas Otis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Sep 23, 2014, at 7:57 PM, Douglas Otis doug.mtv...@gmail.com wrote: Actually, it is better to assume there is a long list of vulnerable home routers being p0wned by entities beyond their ISP. This is to some extent true, but not something we can really address in homenet. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP security?
On Fri, 19 Sep 2014, Mark Townsley wrote: My own experience attempting to use IPsec as an add-on security solution (a.k.a. pixie dust) for a protocol isn't all that positive. We tried that with L2TP, and in the process failed to kill off PPTP on windows clients. I can't tell you how many times over the years I've had to point people to the Windows Registry setting to disable IPsec with L2TP. OSPFv3 is another one where I get complaints about requiring IPsec. So, I agree with Ted; We should be wary of falling into the trap of using IPsec just because it is there. As far as I can see, there are 2 ways of doing security. Either each protocol does its own security completely (both auth and encryption), or we have generic ways of doing these. The generic ways can be either a new protocol and method, or a method that any protocol can use, so at least the method is standard. What I have seen so far, it seems most implementations are doing things from scratch, but with known methods, but with little code re-use? What I would like to see is an implementation that is generic, but perhaps where the information is carried over a lot of different protocols, for instance HNCP, ND and others. There is no security and zero configuration at the same time. It just doesn't work. I still think we need user intervention to set policy for each device. What trust do I put in this device and what role should it have is something the user has to answer. The result of this answer sets policy for the devices in relation to this new device. This has to be really simple and easy to use. Since a lot of people have smartphones nowadays, I still think that the device popping up in an App they have, and then configuring it there, is the best way. Perhaps in combination with some kind of device key fingerprint using QR codes or alike to really make sure this is the device you're trying to configure policy for. So my proposal is that we make HNCP capable of using several methods, one is unsecure, one is secure by means of a shared secret, and then add other optional methods using PKI that would enable the above mentioned accept each device manually more secure way. On paper it still seems IPSEC should be able to do this (I mean, isn't this what Microsoft does with Direct Access, ie run IPSEC and have keys handled by AD? From a theoretical level, it seems bad that we can't implement generic security and then let other protocols run on top of that. What is it that IPSEC is lacking? Is it the key/auth exchange that is lacking? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
