Subject: [Homenet-babel-sec] What's up with HNCP security?

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 28 May 2017 23:18:42 +0200

Dear Ted, dear list,

(Babel list in copy of this mail.)

There are two facets to Homenet security: HNCP and Babel.  We, at Babel
towers, are planning to implement Stenberg-style security for Babel during
the month of July (earlier is not possible due to my prospective interns
having to sit their exams).  When we're done, we can compare this aproach
to the existing HMAC security, and see which of the two approaches is more
suitable for Homenet.

For the Babel work to be useful for Homenet security, HNCP needs to be
extended with two features:

  - the ability to signal other HNCP nodes that a given link requires
    authentication and/or encryption, and to securely signal any private
    keys;
  - the ability to protect HNCP traffic over an untrusted link.

Pierre has mentioned that HNCP already supports all or most of that, but
somebody needs to write down the relevant protocol bits and check whether
everything is implemented.

I'd much prefer that this work be done before we start extending Babel,
since having the HNCP bits ready would help us ensure that we're meeting
all of the Homenet requirements.

I'm leaving for a short holiday tomorrow, so please don't worry if I'm not
very responsive during the next week.  I've got exams the week after, so
please don't worry if I'm not very responsive the week after that.  Pleae
expect me to be my usual annoyingly chatty and opinionated self in two
weeks' time.

Regards,

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 29 May 2017 00:28:13 +0200

> I am not holding my breath on my motivation to add support for the
> shared keys in HNCP to hnetd, as I still believe in security-by-l2-zones
> design that I am running in my home and not l3+ security for each protocol.

As you know, you've convinced me.

> (or very hefty bribe,

Please share with your friends.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 May 2017 19:13:01 -0400

> expect me to be my usual annoyingly chatty and opinionated self in two

Deadlines are good.   I will do my best (and might bug Markus, if he's willing).

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 May 2017 19:14:48 -0400

On May 28, 2017, at 5:53 PM, Markus Stenberg <[email-masked]> wrote:
> HNCP supports negotiating network-wide shared keys for arbitrary services (such as RPs). If my hncp_proto.h has valid values, TLV to look for is number 42, ironically enough.
> 
> hnetd the implementation does not implement this yet, as I am not convinced it is a good idea. I welcome merge requests though if someone wants to implement it. (it is one of the few missing parts of the spec from hnetd)

The idea is to have key pairs, not network wide keys (this is why Juiliusz needs unicast hellos in Babel).   Network wide keys are useless.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 29 May 2017 03:19:12 +0200

> The idea is to have key pairs, not network wide keys

If it can be done without too much complexity, sure.

> (this is why Juiliusz needs unicast hellos in Babel).

I was under the (perhaps mistaken) impression that asymmetric signing can
be done just as well over multicast.  The reasons people want unicast
hellos are multiple:

  - leverage DTLS (Stenberg-style) or IKE (Schinazi-style);
  - run Babel over NBMA (Cullen-style);
  - avoid multicast noise (Taht-Høiland-style).

Even for Stenberg-Schinazi security, it's not obvious to me why we need
unicast Hellos -- it's only Updates that really need to be protected, if
an attacker manages to fake a Hello he'll only be able to disrupt the
link-quality estimation algorithm (which is only a DoS vector).

And Margaret is doing NBMA in RFC 6126 just fine, by sending unicast
Hellos simultaneously to all neighbours and hence avoiding seqno
desyncrhonisation.

In short -- if we don't get unicast Hellos into 6126bis, I'll be happy
enough.  If we do, and they're done well, I'll be happier.

> Network wide keys are useless.

Depends on the size of the network, I guess.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 May 2017 21:27:09 -0400

> be done just as well over multicast.  The reasons people want unicast

We concluded that asymmetric signing was too expensive, IIRC.

> link-quality estimation algorithm (which is only a DoS vector).

I will rely on your expertise here.   However, if the point is to identify the attacker, then being able to identify the attacker in a DoS attack is just as important.

> Depends on the size of the network, I guess.

Yes.   For networks with only two hosts, network-wide keys are adequate...

;)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 29 May 2017 11:15:00 +0200

> My _home_ network has plenty of network-wide shared keys (e.g. SSID
> PSKs) and I do not consider them useless; while they are low barrier to
> entry, I am not aware of any good alternatives that most of my devices
> would support 

Yes, I too am somewhat puzzled by Ted's very strong stance about avoding
shared keys, and cannot but wonder if it reflects WG consensus.  However,
it is my (perhaps mistaken) understanding that Stenberg-Schinazi security
gives us asymmetric keying basically for free, as far as additions to the
Babel protocol are concerned, so I suggest waiting for Ted's prototype
before deciding whether the added complexity is acceptable.

> (and SSID per device is not realistic).

Now don't you tempt me.

(Increase the beaconing interval, hack the wifi firmware to store more
keys, use a master SSID with a cool protocol to securely negotiate keys
with individual devices... and watch bitterly as nobody adopts your
protocol.)

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 29 May 2017 12:24:06 +0200

Juliusz Chroboczek <[email-masked]> writes:

> use a master SSID with a cool protocol to securely negotiate keys with
> individual devices...

Aren't you basically describing "enterprise" (802.1X) WPA here?

> and watch bitterly as nobody adopts your protocol.

Apart from enterprises, universities and anyone who bothers to install
freeradius, you mean? ;)

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 May 2017 09:22:24 -0400

On May 29, 2017, at 3:14 AM, Markus Stenberg <[email-masked]> wrote:
> My _home_ network has plenty of network-wide shared keys (e.g. SSID PSKs) and I do not consider them useless; while they are low barrier to entry, I am not aware of any good alternatives that most of my devices would support (and SSID per device is not realistic).

Shared pre-shared-keys are useful if the need for trust is minimal.   We use them all the time at IETF, and my home network uses WPA2/PSK, not WPA2/enterprise.   But the point is that there is no expectation of privacy or authenticity in this case.

In the case we are talking about, a shared key doesn't work because if any device on the network is pwned, it can masquerade as any other device to escape detection.   You or I could do a fault isolation process to figure out which device has been pwned, but we can't expect homenet users to be able to do that.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 29 May 2017 16:02:37 +0200

> In the case we are talking about, a shared key doesn't work because if any
> device on the network is pwned, it can masquerade as any other device to
> escape detection. You or I could do a fault isolation process to figure out
> which device has been pwned, but we can't expect homenet users to be able to
> do that.

I think we're all well aware of the advantages of per-device keys.  I think
we're also well aware that there are tradeoffs between functionality and
complexity, and that sometimes it is worth giving up on features in order
to keep complexity at a manageable level.  (Radius, sheesh.)

I think we'd need a prototype in order to make an informed judgement.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 29 May 2017 00:53:56 +0300

>  - the ability to protect HNCP traffic over an untrusted link.

hnetd supports this and it has even been tested at some point in distant past. No idea of current status of the code, as I nowadays use the Python HNCP implementation and not the C one. 

> all of the Homenet requirements.

I am not holding my breath on my motivation to add support for the shared keys in HNCP to hnetd, as I still believe in security-by-l2-zones design that I am running in my home and not l3+ security for each protocol. However, I welcome merge requests on github :) (or very hefty bribe, smirk, but I am working on some other tinfoil hat stuff at the moment.)

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 29 May 2017 10:14:42 +0300

Cheers,

-Markus