(This could have been a draft too, but I’m starting my vacation soon and I don’t want to post any more of those. Sorry.-Markus)
Current HNCP draft specifies security very vaguely, as it was originally based on just some napkin thoughts last year on ‘it would be nice to have authenticated TLVs’. However, what are we protecting against, how, and should we go through the trouble at all? For all of these attacks, we have to assume _some_ network level access to a home network. Let us consider potential attacks and their applicability on a home network: [1] Pretend to be a client: no, we cannot protect against this, all clients are not currently authenticated and not in foreseeable future either. 802.1x not to even mention MACSec support on wired ports is mostly nonexistent in home routers. [2] Replace upstream router on the upstream link. We cannot do anything about this, and as your packets already go to e.g. NSA, assumption of privacy is moot so this battle is lost. This attack may be harder to mount due to upstream link being typically wired, hard to reach, etc. [3] Pretend to be upstream router on some other link. We can protect against this with fixed categories of interfaces, but securing HNCP has nothing to do with it as upstream router doesn’t talk HNCP. [4] Pretend to be an inner router. What are their implications? [1]: Any resource in-home _can_ be accessed and there is not much that can be done given access to a non-guest link. [2,3]: Any traffic on the Internet is public (and what else is new?). [4]: If impersonation is possible, man-in-the-middle and potentially denial of service attacks on home network become possible. How could [4] be prevented then? In ascending order of complexity.. [S4-1] Manual configuration of categories overriding automated border discovery. Defining either in the actual router product, or via configuration which interfaces to talk HNCP (and RP) on, where potential upstream links may never be, can be or always are. [S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual keying as currently specified in the draft. Setting up the shared PSK for the set of routers is left to the as manual configuration exercise for the owner of the devices. [S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as [S4-2], may be able to get rid of manually keyed IPsec dependency. [S4-4] Some public key cryptography solution operating with just raw keys (there is a draft in the works on how to do this in HNCP) [S4-5] Some public key cryptography solution with CA hierarchy (similar to behringer-bootstrap) The big question is, are the S4-3+ really worth it? And what is the sane way to do it if they are? Can we actually become RFC with just S4-1 and S4-2? In case we go for public key-cryptography: what do we do about routing protocols mostly relying on shared secrets for authentication? - Markus and Steven _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
