Markus Stenberg <mailto:[email protected]>
30 June 2014 09:31
On 28.6.2014, at 10.43, Ray Hunter<[email protected]> 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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
