Subject: [homenet] Securing HNCP - comments?

From: Markus Stenberg <[email-masked]>
Date: Fri, 27 Jun 2014 09:34:59 +0300

(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

---

From: Dave Taht <[email-masked]>
Date: Thu, 26 Jun 2014 23:51:01 -0700

I have been watching this draft evolve now for a while, on
authenticated routing exchanges. Perhaps it would provide some insight
on 3 and 4 below.

http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication-09

running code (in quagga, only, at present).

> [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…

To me an authenticated exchange could add meat to the "I'm home", or
"at work" concepts much like how windows works today. Homeplug
devices, for example, have the concept of "pairing", as does
bluetooth, and a few other technologies.

We're still screwed on rogue routers by things like mac spoofing, but
at a higher level you could periodically be doing a challenge/response
to the gateway router to ensure you are talking to the right thing, or
(as per the above link) prefer authenticated routes.

> [1]: Any resource in-home _can_ be accessed and there is not much that can be done given access to a non-guest link.

What often happens today is a mac filter list, which is somewhat effective.

> [2,3]: Any traffic on the Internet is public (and what else is new?).

How does this bear on hncp?

> [4]: If impersonation is possible, man-in-the-middle and potentially denial of service attacks on home network become possible.

impersonation in a routed environment has some interesting subtleties to it.
Take a world where you have a rogue device participate in the local
routing protocol and announce that it's on 75.75.75.75 (comcast's
dns), or 8.8.8.8, but is really acting as a dns server and sending
upstream requests to a rogue dns server (a-la dnschanger)

(this is partially why I made a big push to put bcp38 on, on, in
cerowrt, by default)

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: Ray Hunter <[email-masked]>
Date: Sat, 28 Jun 2014 09:43:05 +0200

inline

> 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: wha…
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

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 30 Jun 2014 10:31:04 +0300

On 28.6.2014, at 10.43, Ray Hunter <[email-masked]> wrote:
> 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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 30 Jun 2014 12:53:22 +0200

>> Powerline Ethernet devices have built in encryption,

> takes care of security.. ;)

Guest networks?

However, I think it is premature to define a secure variant of HNCP before
we have some operational experience with the protocol.  It's only after
we've played with it for some time that will we get a feel for what are
reasonable and unreasonable operations to perform.

> just use e.g. IPsec with manual keying

Vulnerable to replay if done naively.  Not sure about the configuration
protocol, but definitely an issue for a routing protocol -- just capture
a default route announcement with a low metric, and you've won.

> [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.

It appears that you are only looking at hop-to-hop security.

I'm speaking off the top of my head here, so I'm probably saying something
stupid.  What about end-to-end solutions, where only routers with
a trusted key can originate configuration information?  This could perhaps
be combined with a leap-of-faith model (a la ssh).

> Looking at Babel, the routing protocol spec is 45 pages, and draft
> specification of HMAC security scheme for it is 55 pages.

Yeah, wouldn't it be nice if we had a common layer 3 security protocol?
(We would make sure that it's actually usable before standardisation, of
course.)

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jun 2014 12:23:36 -0400

> a default route announcement with a low metric, and you've won.

If one goes with 64-bit replay counters, and enable the replay protection,
and we have a relatively low data rate, we can get some protection, but we
have to plan that we eventually rekey.

    > be combined with a leap-of-faith model (a la ssh).

Yes, it's a very good idea, if you use authentication mode only.

There are two points:
      1) 4301 and previous did not say what to do with an AH header with an
      unrecognized SPI.  This is why SEND doesn't use it.
      If we can say that the correct answer is to skip the AH, and pretend
      it wasn't there at all, then new routers can join as leafs, insecurely,
      and then join the group (symmetric) key.

      2) and/or we can define an assymetric method for AH.

    > (We would make sure that it's actually usable before standardisation, of

I think that we could use IPsec, and yes, even manually keyed, and maybe even
insist on sane definition of unknown AH SPI, given that the set of devices
that we are dealing with does not need to interop with anything already
deployed, and that these are custom function devices.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ray Hunter <[email-masked]>
Date: Mon, 30 Jun 2014 21:32:41 +0200

> Markus Stenberg <mailto:[email-masked]>
> 30 June 2014 09:31
> On 28.6.2014, at 10.43, Ray Hunter<[email-masked]>  wrote:

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