Re: [homenet] Securing HNCP - comments?

[Ray Hunter <[e-mail]>]

inline

Markus Stenberg wrote:
> (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
Powerline Ethernet devices have built in encryption, so I think 
consumers do expect some level of protection from accidental 
neighbouring. I agree with you questioning whether this should be solved 
at L2 or L3 and above.

Assuming the solution has to be defined at L3 and above, I think due to 
the lack of any hierarchy, or root node, that you're going to have to 
have individual keys/signatures per device, and that you cannot assume 
existence of a central keying repository.

S4-1 could work but relies on consumers plugging in devices into the 
correct ports. S4-2 does not meet the requirement for 
auto-configuration. S4-3 could work if you could bootstrap it, but that 
is not trivial either because it is chicken/egg. I don't see S5-5 
flying: there is no natural root node or root CA.

The problem seems to boil down to "how can we bootstrap the trust" 
regardless of the encryption technology. Assuming S4-3 or S4-4, when a 
new device is added to the network (as opposed to existing devices being 
replugged) you could check it against a (distributed) DB of existing 
pairing keys (via TBD service discovery technology). If a device hasn't 
paired to at least one other homenet device, HNCP messages from this 
device is ignored until it has. Initiating the pairing should be as 
simple for the end user as pressing a button on 2 connected devices 
(nearly) simultaneously (one new and one already in the web of trust) so 
that both devices go into pairing mode and learn a new HNCP pairing. 
Once homenet is (relatively) stable, you would also be able to flood the 
new pairing to all other devices in the web of trust for potential long 
term storage. At some point you might end up seeing old devices you've 
given to your neighbour, so there should also be a way of clearing the 
pairing DB for a specific device, or automatically flushing entries for 
devices that have not been seen since time X. Alternative is that you 
have to put all devices in homenet into pairing mode simultaneously, but 
that may become less practical as the number of routers increases.

IF you can establish trust using HNCP (an expensive operation), it could 
be the basis for all other trust in the Homenet, so it is potentially a 
big win. e.g. To negotiate any necessary shared key for routing or other 
common Homenet wide parameters: think election of the root bridge in 
802.1 and then that root device chooses a common shared key. Obviously 
distribution of the resulting shared keys from the root is going to have 
to be encrypted.

I can certainly see this solution sketch requiring a lot of code.

-- 
Regards,
RayH