On 16.9.2014, at 16.52, Michael Richardson <[email protected]> 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. > 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. > 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) - admin password (for those user actually has access to, and are not part of some super-fancy PKI scheme for authenticating administrator) That said, I am not sure if they are really needed. > 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. > 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? Speaking of IPsec in general, I had a chat with Steven about this, and the conclusion was more or less this: - (HNCP) unicast works with (opportunistic) IKEv2 or manual key fine - (HNCP) multicast works with manual key, but currently is not used for anything sensitive (just change detection mechanism, actual state changes done via unicast due to multicast size limit) => From my point of view, plaintext multicast + unicast IKEv2 with (opportunistic) authentication would be perfectly fine too. And as long as confidentiality is not desired for the traffic, security properties would be actually better than for manually keyed IPsec. If confidentiality is desired, equation changes; however, even when using manually keyed IPsec, the fact that there _are_ changes in network topology cannot be hidden, from traffic analysis, so I am not sure if it is significantly different outcome from the confidentiality-only-on-unicast. > markus> 2.2) Or should we roll our own in-HNCP scheme? > No. High five! > I realize that there is an issue with cable modems and FTTH systems such that > the ISP boundary can be hard to recognize. I propose that HNCP use scope-5 > multicast, and that we try to convince the Broadband forum that it's cable > modems should drop scope-5 multicast, if they see it. Further, we have the > heuristic that if we saw DHCPv6PD on that interface, it might be an ISP. > (If we also saw DHCPv6PD, and we saw authenticated HNCP, then it is internal) I think use of link-local multicast is perfectly fine. Their cable modems SHOULD/MUST configure the cable interface as external in any case, which has both firewalling implications as well as no HNCP or routing protocol traffic on the interface. Fully bridging cable modems are different beast, but even in their case, if the border detection works fine (=there is PD prefix or IPv4 DHCP available there), the HNCP implementations should treat the interface as external based on autodetection in any case. PD + authenticated HNCP case I am not sure what should be done with - perhaps the hybrid category, although it should not be autodetected (I lean towards external by default, using the ‘more firewalling the merrier’ logic). So far identified security options: 1. no crypto, but fixed interface categories (no HNCP on untrusted L2 links) 2. manually keyed IPsec (using PSK, provisioned in advance) 3. {manual keys, certs, something else} IKEv2 on unicast, ignore multicast (and write in draft no state exchange based on multicast, just change notification) 4. opportunistic variant of the above, with e.g. self-signed certs, and leap of faith happening on interface type 5. web of trust in HNCP (Xavier’s draft). The current form of _that_ draft, for the record, is not really final from my point of view but I’m talking more about the general idea. [4] scheme in and of itself would have no way of transmitting ’these are self-signed certs I trust’ to other nodes it does trust. Therefore, if we want to do things in opportunistic way, [5] > [4] in terms of user experience, as it would share the trust state across the whole home network _using already trusted node set_, and therefore the number of ‘pairings’ in the opportunistic scheme would be less. Of course, web of trust could be also be based on CA hierarchy or whatever, so it is definitely the flexible choice. However, it does imply quite a bit of changes to HNCP draft too (or extra draft as it is currently). That said, I personally like [1]-[3], and [4]/[5] seem complex. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
