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
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
