Re: [homenet] Securing HNCP - comments?

[Ray Hunter <[e-mail]>]

> Markus Stenberg <mailto:[e-mail]>
> 30 June 2014 09:31
> On 28.6.2014, at 10.43, Ray Hunter<[e-mail]>  wrote:
>>> 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.
>
> Same thing with WPA* too of course. So I’m very tempted to assume L2 takes care of security.. ;)
>
>> 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.
>
> S4-2 and S4-3 have same characteristics in my view - they need some (consensus) way to generate PSK, that is then either a) fed to IPsec as manually keyed SA, or b) used to encrypt-authenticate content in the protocol.
>
> S4-[45] have built-in ways of bootstrapping that are absent from S4-2/S4-3 as I see them.
>
>> 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.
>
> Yeah, I agree that this scheme (on high level) is what seems sensible _given_ the assumption you want to do the trust handling within HNCP.
>
>> I can certainly see this solution sketch requiring a lot of code.
>
> Indeed, and be also nontrivial to specify and interoperably implement. Sigh.
>
> So back to the original question, anyone have any idea if this stuff _must_ be implemented, really, beyond hand-wavy S4-1 and S4-2?  Looking at Babel, the routing protocol spec is 45 pages, and draft specification of HMAC security scheme for it is 55 pages. I sense some slight imbalance somewhere.
>
> Cheers,
>
> -Markus

To answer your question, I think you need to examine your threat model.

I think one of the major threats will likely be accidental peering, 
leading to inappropriate border selection, and thus incorrect default 
firewall settings, which in turn leads to a loss of confidentiality.

What characteristic or parameter defines a device's membership of a 
particular Homenet in HNCP?

How are you going to prevent 2 adjacent Homenet customers, that happen 
to share an ISP L2 broadcast uplink like a cable TV network, from 
peering and becoming a single Homenet?
Is this an "illegal" topology, because Homenet assumes that all ISP 
uplinks are L3, or Homenet assumes that receiving PD on an interface 
defines it as being an ISP border?

If you value ease of use higher, then you'd probably mandate that 
Homenet should rely on existence of a L2 adjacency as being sufficient 
to justify L3 adjacency, and such border interfaces in these special 
topologies require manual border interface configuration to prevent 
accidental peering.

If you value privacy higher, then you'd probably mandate that all device 
peerings have to be authorised in some way at L3 before they are accepted.

I think it's instructive to look at Bluetooth as to how this requirement 
has evolved. e.g. bluejacking -> bluesnarfing -> explicit user 
intervention required before any peering takes place.

-- 
Regards,
RayH