Subject: [homenet] HNCP security?

From: Markus Stenberg <[email-masked]>
Date: Fri, 12 Sep 2014 13:23:43 +0300

I decided to take a look at the homenet architecture draft and compare the requirements there with what is defined for HNCP as of now.

Section 3.6 describes security. It seems to be concerned mainly with filtering of traffic between different networks - for example, guest, home, and Internet. Section 3.8.2 adds potential need for manual provisioning of wireless keys.

Current HNCP draft provides for both automated border discovery (to determine between home and Internet being plugged on different ports) that is not really dependant on HNCP itself, but neither is it very secure, as in the zero-configuration case there is no way to authenticate ISP _or_ the hosts. Given provisioning by manufacturer/ISP, or  configuration by the end user, the automated border discovery can be disabled, and fixed categories assigned to interfaces. In that mode, HNCP fullfills the security specified in the draft.

What the draft does not cover is what is the assumption about security of protocols within it. If HNCP is run only over either physically or cryptographically secured link layer, there are no real extra requirements for HNCP.

So, question time:

1) Can we assume secure L2 and/or appropriate device configuration by the manufacturer/ISP(/user)? (This is what I can assume in my own home.)

2) If not, should the solution be some sort of pre-shared key scheme? (If not, please explain your alternative solution.)

2.1) And if so, should it be manually keyed IPsec (multicast prevents e.g. IKE)? (This is what is in the draft currently.)

2.2) Or should we roll our own in-HNCP scheme? 

Cheers,

-Markus

---

From: Michael Thomas <[email-masked]>
Date: Fri, 12 Sep 2014 07:41:30 -0700

> What the draft does not cover is what is the assumption about security of protocols within it. If HNCP is run only over either physically or cryptographically secured link layer, there are no real…

I'm pretty certain that the answer to this is going to be "no". does 
zigbee even have link layer
crypto, for example? and even if it does, new ones as they come on line 
are likely to have flaws
for a long time (cf wifi).

> 2.2) Or should we roll our own in-HNCP scheme?

It would be better to turn this around and ask what the attacks you're 
trying to defend against,
and who the actors are. Also: PSK are not very zeroconf like, and 
they're not even particularly
friendly littleconf if they are meant as strong machine-machine keying 
(rather than crappy human
to machine password-like things).

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Sep 2014 14:50:49 +1200

On 12/09/2014 22:23, Markus Stenberg wrote:
...
> 1) Can we assume secure L2 and/or appropriate device
> configuration by the manufacturer/ISP(/user)? (This is what I
> can assume in my own home.)

I'm not sure I fully understand this question, but certainly
there a vast numbers of insecure home 802.11 setups. This is
less prevalent than it was a few years ago, but it seems like a
dangerous assumption if homenet-compliant kit is mixed in with
older stuff such as wireless hubs that are open by default.

   Brian

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 13 Sep 2014 08:40:55 +0300

> older stuff such as wireless hubs that are open by default.

From my point of view, if you’re exposing part of your home network via insecure wireless, only way to secure it would be to run mandatory crypto over it both to hosts and routers. I’m not sure this is really feasible either. Just securing router-router traffic (or parts of it) does not bring significant benefit from my point of view unless you also authenticate hosts in such a case.

While securing HNCP in such a case would prevent some attacks on in-home network auto-configuration, anything else (e.g. using home resources, using home internet access, pretending to be uplink and performing MITM, the list goes on) would be still possible and I do not see the point.

Cheers,

-Markus

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 13 Sep 2014 17:16:55 +0000

I agree with Markus. The conflicting goals of self-configuration and
security seem to be a recurring theme in homenet. I reread the security
section in the ³Homenet Architecture² and it mainly covers with security
at the edges (which presumes effective edge detection). There is this
statement regarding the internal homenet:

   3.6.4.  Exfiltration concerns

   As homenets become more complex, with more devices, and with service
   discovery potentially enabled across the whole home, there are
   potential concerns over the leakage of information should devices use
   discovery protocols to gather information and report it to equipment
   vendors or application service providers.

   While it is not clear how such exfiltration could be easily avoided,
   the threat should be recognised, be it from a new piece of hardware
   or some 'app' installed on a personal device.

This is definitely something we¹ll need to come to terms with to move
forward and there may be more than one model.

Thanks,
Acee

On 9/13/14, 1:40 AM, "Markus Stenberg" <[email-masked]> wrote:

>From my point of view, if you¹re exposing part of your home network via
>insecure wireless, only way to secure it would be to run mandatory crypto
>over it both to hosts and routers. I¹m not sure this is really feasible
>either. Just securing router-router traffic (or parts of it) does not
>bring significant benefit from my point of view unless you also
>authenticate hosts in such a case.
>
>While securing HNCP in such a case would prevent some attacks on in-home
>network auto-configuration, anything else (e.g. using home resources,
>using home internet access, pretending to be uplink and performing MITM,
>the list goes on) would be still possible and I do not see the point.
>
>Cheers,
>
>-Markus
>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Michael Thomas <[email-masked]>
Date: Sat, 13 Sep 2014 10:27:23 -0700

> forward and there may be more than one model.

I think we should be clear that hijacking router-router traffic brings a 
whole
new class of breaches that home networks are probably not particularly 
susceptible
to today. An active man in the middle is a very bad thing and that seems 
trivially
doable without some precautions.

This is yet another reason why I keep saying that the goal should be 
"littleconf"
rather than "zeroconf".

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Sep 2014 08:30:36 +1200

> From my point of view, if you’re exposing part of your home network via insecure wireless, only way to secure it would be to run mandatory crypto over it both to hosts and routers. I’m not sure thi…

All true (as are the subsequent comments by Acee and Michael).
But the fact remains that we can't assume L2 is secure in the
normal case, which is a much worse situation than we traditionally
assumed for wired networks.

   Brian

> -Markus.

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 14 Sep 2014 12:01:00 +0300

On 13.9.2014, at 20.27, Michael Thomas <[email-masked]> wrote:
> I think we should be clear that hijacking router-router traffic brings a whole
> new class of breaches that home networks are probably not particularly susceptible
> to today. An active man in the middle is a very bad thing and that seems trivially

Today most home networks are simply bridged, and you can do active MITM there well enough (hello, ARP spoofing), unless it is protected against. And most home routers don’t protect against it as bridging is done on simple ASIC.

> This is yet another reason why I keep saying that the goal should be "littleconf"
> rather than “zeroconf".

I prefer idea of littleconf personally too; I wonder what  that ‘conf’ is is.

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 14 Sep 2014 12:04:05 +0300

> assumed for wired networks.

Ok, so your stance is that we can’t assume secure L2, but neither can we do anything useful without fully encrypted traffic. 

As fully encrypted traffic is not an option (computational overhead, not-so-littleconf on routers and probably impossible on current hosts), what, exactly, do you propose then? Not deploy routed home networks at all until we can assume L2 security?

Cheers,

-Markus

---

From: Michael Thomas <[email-masked]>
Date: Sun, 14 Sep 2014 07:48:20 -0700

> As fully encrypted traffic is not an option (computational overhead, not-so-littleconf on routers and probably impossible on current hosts), what, exactly, do you propose then? Not deploy routed ho…

I think you're throwing up your hands way too prematurely. I don't know 
what "fully encrypted traffic"
means in this context. If you're talking about the router-router 
signaling traffic itself (eg, ospf), symmetric
crypto (eg, aes+sha256 -- note all you might need is just integrity too) 
adds trivial process load these
days. Public key operations are similarly a drop in the bucket these 
days when used sparingly (eg, for
enrollment, session establishment, etc). Modern router boxes are not 
microvax 1's  with two fat ethernet
ports, after all.

Also: I think that HNCP needs to take care of HNCP and not worry about 
boiling the homenet security
ocean. Even if we end up with layers of crypto via L2. That's ok.

Last, without actually knowing what threats/attacks we're trying to 
defend against, it's *way* to early
to say how much configuration might be required.  Remember: WPA2 
requires the input of exactly one
passphrase per SSID. That is manifestly not an insurmountable burden. 
And that's just for starters: we
may be able to get away with leap of faith kinds of enrollment depending 
on the threats which may require
minimal user intervention (eg: "should I do this, Y|n").

So the real job here is to consider what the threats are first and 
foremost before making blanket
statements about l2, l3, processor speed, etc, etc.

Mike

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 14 Sep 2014 11:59:35 -0400

Brian, et al,

L2 never really was secure, regardless of whether we are talking about
enterprise or home networks, wired or wireless.  Sure there was a
firewall in place, but the L2 and the subnet behind the firewall was
only as secure as the least secure device that ever connected to it.
Which is to say, not at all secure.  I have yet to work at a
corporation since the mid-1990s that didn't at some point have IT
report that the local network was clogged due to a virus run rampant
behind the firewall.  This has always applied to both wired and
wireless networks.

Perhaps it is worse with wireless since any laptop or cell phone able
to connect is a potential breach that can be leveraged if L2 security
is assumed.

[So I'm agreeing with Brian, but pointing out that wired L2 was never
secure in the first place.]

Curtis

In message <[email-masked]>
Brian E Carpenter writes:
 
> > From my point of view, if you’re exposing part of your home network
> > via insecure wireless, only way to secure it would be to run mandatory
> > crypto over it both to hosts and routers. I’m not sure this is really
> > feasible either. Just securing router-router traffic (or parts of it)
> > does not bring significant benefit from my point of view unless you
> > also authenticate hosts in such a case. 
>  
> > While securing HNCP in such a case would prevent some attacks on
> > in-home network auto-configuration, anything else (e.g. using home
> > resources, using home internet access, pretending to be uplink and
> > performing MITM, the list goes on) would be still possible and I do
> > not see the point. 
> > 
> > Cheers,
> > 
> > -Markus.

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 14 Sep 2014 19:38:10 +0300

On 14.9.2014, at 17.48, Michael Thomas <[email-masked]> wrote:
> I think you're throwing up your hands way too prematurely. I don't know what "fully encrypted traffic"
> means in this context. If you're talking about the router-router signaling traffic itself (eg, ospf), symmetric
> crypto (eg, aes+sha256 -- note all you might need is just integrity too) adds trivial process load these
> days. Public key operations are similarly a drop in the bucket these days when used sparingly (eg, for
> enrollment, session establishment, etc). Modern router boxes are not microvax 1's  with two fat ethernet
> ports, after all.

Like I stated earlier in my email, if you do not assume secure L2, just securing router-to-router traffic does little to protect the homenet. 

Quote: … anything else (e.g. using home resources, using home internet access, pretending to be uplink and performing MITM, the list goes on) would be still possible and I do not see the point. 

Also, if we assume the home user does not bother to set up L2 security for their home infra (notably wireless), what are the odds they set up HNCP in a secure manner? I wouldn’t bet on it.

> Also: I think that HNCP needs to take care of HNCP and not worry about boiling the homenet security
> Last, without actually knowing what threats/attacks we're trying to defend against, it's *way* to early
> to say how much configuration might be required.  Remember: WPA2 requires the input of exactly one
> passphrase per SSID. That is manifestly not an insurmountable burden. And that's just for starters: we
> may be able to get away with leap of faith kinds of enrollment depending on the threats which may require
> minimal user intervention (eg: “should I do this, Y|n”).

Well, please write up on how you think this could be ‘easily’, without some sort of magic provisioning/hardware that cannot be assumed to be always available. (For example, Apple does nice enough user experience for configuring Airport stuff, but it works nicely if and only if both your hosts and routers are from same vendor. Not applicable here.)

> So the real job here is to consider what the threats are first and foremost before making blanket

Certainly. 

Routers themselves (regardless of what protocol traffic they are sending) as _endpoints_ of traffic constitute only minor part of attack surface of your typical home network. 

Let’s consider the parties involved:

upstream router on ISP side - no crypto with them in typical case for foreseeable future
home routers - ok, fine, we can probably do something about them
hosts - cannot assume really crypto, except maybe L2 (e.g. WPA2 or even less likely 802.1x/MACSec)

Here’s few threats and how to mitigate them from the last IETF slides (http://www.ietf.org/proceedings/90/slides/slides-90-homenet-8.pdf slide 3):

1. fake ISP (=> active MITM, active packet snooping)

As upstream router isn’t authenticated (DHCPv6 + RAs indicate it is an upstream router, nothing else), only littleconf about where upstream routers can appear protects from this. (and-or fictional DHCPv6 authentication using ISPs.)

2. access to home resources (~DoS, unprivileged access)

As hosts are not authenticated (if we can’t assume secure L2 of some kind), nothing to be done here.

3. someone actively mutating in-home routing state (=> active MITM, DoS)

Yes, this could be addressed by just securing router-to-router traffic.

[1]/[2] are not affected by _any_ magic you throw in HNCP,  and it presents exactly same threats and more besides what is in [3].

Cheers,

-Markus

---

From: Michael Thomas <[email-masked]>
Date: Sun, 14 Sep 2014 10:45:41 -0700

On 09/14/2014 09:38 AM, Markus Stenberg wrote:
> Like I stated earlier in my email, if you do not assume secure L2, 
> just securing router-to-router traffic does little to protect the 
> homenet.

The subject line says "HNCP security", so I naively thought that's what 
this was about.

> hosts - cannot assume really crypto, except maybe L2 (e.g. WPA2 or even less likely 802.1x/MACSec)

As a meta point: "crypto" != "security".

> As upstream router isn’t authenticated (DHCPv6 + RAs indicate it is an upstream router, nothing else), only littleconf about where upstream routers can appear protects from this. (and-or fictional…

Is this a threat to HNCP? I thought that HNCP was an IGP?

> As hosts are not authenticated (if we can’t assume secure L2 of some kind), nothing to be done here.

Not an HNCP threat?

> 3. someone actively mutating in-home routing state (=> active MITM, DoS)

Definitely an HNCP threat. Seems like you might want to have some sort 
of auth/authz,
but it's hard to know exactly what because I don't understand the 
expected enrollment
model.

Is that all? Maybe we can recycle security threats from OSPF, etc for a 
more comprehensive list?

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Sep 2014 08:01:17 +1200

> to connect is a potential breach that can be leveraged if L2 security

Precisely. Security is in reality always a relative term, and a network
is roughly as secure as its least secure component. The point is that
a non-secured 802.11 network welcomes MITM, so HNCP in particular needs to
resist MITM (unless you are happy if the small print on the box warns
against running non-secured 802.11). I don't think that MITM-resistance
requires encryption, though - authenticated identity should be enough.

Homenet in general needs to worry about DOS and surveillance allowed
by weak L2 security, but that's a separate topic.

   Brian

> .

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 15 Sep 2014 01:39:30 +0300

On 14.9.2014, at 20.45, Michael Thomas <[email-masked]> wrote:
> The subject line says “HNCP security”, so I naively thought that’s what this was about.

Considering security in isolation for single protocol is bit naive, I think, but I do not mind indulging you.

> As a meta point: "crypto" != “security".

Oh, really?

> Is this a threat to HNCP? I thought that HNCP was an IGP?

It is a threat to HNCP’s border discovery. In automated mode, it will determine categories of interfaces, and enable (or not) some classes of attacks.

>> As hosts are not authenticated (if we can’t assume secure L2 of some kind), nothing to be done here.

Again, see border discovery. We cannot determine ‘internal’ zone securely, unless littleconf is done by either router vendor (‘’LAN ports’), or by user. Or alternatively, throw in crypto here.

> Definitely an HNCP threat. Seems like you might want to have some sort of auth/authz,
> but it's hard to know exactly what because I don't understand the expected enrollment
> model.

Just one exchange ago you said ’some magic handwave’ would provide easy authentication/authorization bootstrap for the routers. I was hoping you would clarify it. 

> Is that all? Maybe we can recycle security threats from OSPF, etc for a more comprehensive list?

I am looking forward to your comprehensive list.

Cheers,

-Markus

---

From: Michael Thomas <[email-masked]>
Date: Sun, 14 Sep 2014 16:09:52 -0700

> Considering security in isolation for single protocol is bit naive, I think, but I do not mind indulging you.

We're not mind readers here. If you mean security for all aspect of the 
homenet, change the
subject line.

And there are plenty examples of "considering security in isolation for 
a single protocol" and
I can assure you that it is not "a bit naive".

> Just one exchange ago you said ’some magic handwave’ would provide 
> easy authentication/authorization bootstrap for the routers. I was 
> hoping you would clarify it. 

I said no such thing. And I didn't say we could use leap of faith 
"easily", I said
that depending on the threats that it might be an option.

> I am looking forward to your comprehensive list.

How exactly did this turn into a request for guidance on your part, to 
an onus for a comprehensive
list on my part?

Mike

---

From: Pierre Pfister <[email-masked]>
Date: Mon, 15 Sep 2014 08:28:13 +0200

Hello everyone, 

> 1) Can we assume secure L2 and/or appropriate device configuration by the manufacturer/ISP(/user)? (This is what I can assume in my own home.)

I think secure L2 is not enough for HNCP (and routing protocol) security. 
*Assuming* we have it, either we allow any connected device to ‘speak’ HNCP, or we require the user to configure authorized neighbors, at the L2 layer, which would be way too complex because of the variety of L2 technologies.

The problem is that I wouldn’t want any connected device to be able to participate in HNCP. L2 access is not the same as HNCP authorization. Routers are easier to secure than cloud-based IOT devices, so I would rather introduce a way of filtering authorized HNCP devices.

> 2) If not, should the solution be some sort of pre-shared key scheme? (If not, please explain your alternative solution.)

It’s a possibility. I would like to mention this proposal from last IETF: http://tools.ietf.org/html/draft-bonnetain-hncp-security-00 . Not saying it is *the* solution, but an alternative to the PSK relaying on asymmetric crypto.

In general, HNCP also needs to bootstrap the routing protocol. So I think HNCP would require some way to share secondary keys (If not the same as the primary), in order to bootstrap other protocol’s security.

Cheers,

- Pierre

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 15 Sep 2014 09:49:59 +0300

On 15.9.2014, at 2.09, Michael Thomas <[email-masked]> wrote:
> We're not mind readers here. If you mean security for all aspect of the homenet, change the
> subject line.

I assume you didn’t bother to read the initial message content. I changed the subject accordingly now so people can filter accordingly.

The original message was about HNCP security _in terms of what is specified in architecture draft_ (or realistic real-world deployment), but that sounded like a long title so I hoped someone would just read the text.

> And there are plenty examples of "considering security in isolation for a single protocol" and
> I can assure you that it is not “a bit naive".

I am sure there is lots of locksmith work going on with windows left wide open too, and I am also certain it is a good idea if you say so.

> I said no such thing. And I didn't say we could use leap of faith "easily", I said

You stated WPA2 key is not insurmountable problem, but elsewhere in the thread, the biggest problem is that (in a home, typically wireless) L2 is not secure (=WPA2 key seems to be a considerable burden or outdated WEP infrastructure is in use). Leap of faith enrollment is usually “hard”, given no vendor lock-in or dedicated hardware (and even then it can fail horribly, see WPS for examples of how it does not work out in real world even if some of the original specs were sane). 

> How exactly did this turn into a request for guidance on your part, to an onus for a comprehensive
> list on my part?

Because you sound as if you had answers to things, until asked for them, and then you ask for others to do something.

I _did_ and _do_ look for guidance; I am looking forward to your guidance on the threats here, for example. So far I am the only one who produced some output on them, and you considered them too briefly explained. You turned ‘we’ to ‘you’ easily enough. Could you consider using the ‘I’ part of ‘we’ instead?

Cheers,

-Markus

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Sep 2014 08:27:19 -0400

Michael Thomas <[email-masked]> wrote:
    > zigbee even have link layer crypto, for example? and even if it does,
    > new ones as they come on line are likely to have flaws for a long time
    > (cf wifi).

zigbeeIP mandates link layer crypto, but it's a non-sequitor, because
HNCP would run up to the ethernet/zigbee boundary, but not beyond it.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Sep 2014 09:52:12 -0400

Markus Stenberg <[email-masked]> wrote:
    markus> What the draft does not cover is what is the assumption about
    markus> security of protocols within it. If HNCP is run only over either
    markus> physically or cryptographically secured link layer, there are no
    markus> real extra requirements for HNCP.

    markus> So, question time:

    markus> 1) Can we assume secure L2 and/or appropriate device
    markus> configuration by the manufacturer/ISP(/user)? (This is what I can
    markus> assume in my own home.)

I think that we can assume that wired links are secure.
The only time we care if wireless is secured is when we want to form an
adjacency over the wireless link.   I think it is acceptable to refuse
to form an adjancency over an insecured wireless link.

I think it is acceptable to do some kind of TOFU (using IPsec with IKEv2
even)  point to point across wired links, and having done that, if there
is an adjancy later possible between those two devices over what would
otherwise be an insecure link,  that the previously exchanged keys work.
That means one can plug two routers together with a cable, and then
separate them, knowning that the two routers will remain "entangled"
(I'm making allusions to http://en.m.wikipedia.org/wiki/Quantum_entanglement)

I  further suggest that if two routers have wireless that they might well
have a WPA2/PSK available to them, and that they can and SHOULD use something
derived from that key to authenticate each other.  Could be over IKEv2, yes.

    markus> 2) If not, should the solution be some sort of pre-shared key
    markus> scheme? (If not, please explain your alternative solution.)

If we assume the abovekey, we could use it to derive a pre-shared key for a
multicast IPsec SA using AH.  Can we assume, declare, that if you don't know
the key, that you skip the AH header, and process the HNCP that is inside as
if it wasn't secured at all?  We wanted to do that for SEND, but there were
IPsec implementations that could do that, because we overspecified AH back in
2401.  Given that home routers are purpose built boxes, and not generic
random hosts, perhaps we can specify this behaviour.

    markus> 2.1) And if so, should it be manually keyed IPsec (multicast
    markus> prevents e.g. IKE)? (This is what is in the draft currently.)

Yes, if we can make this AH assumption of skipping, so that we can get TOFU
to work.

    markus> 2.2) Or should we roll our own in-HNCP scheme?

No.

I realize that there is an issue with cable modems and FTTH systems such that
the ISP boundary can be hard to recognize.  I propose that HNCP use scope-5
multicast, and that we try to convince the Broadband forum that it's cable
modems should drop scope-5 multicast, if they see it.  Further, we have the
heuristic that if we saw DHCPv6PD on that interface, it might be an ISP.
(If we also saw DHCPv6PD, and we saw authenticated HNCP, then it is internal)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 Sep 2014 08:06:41 -0700

> derived from that key to authenticate each other.  Could be over IKEv2, yes.

If I have more than one SSID, which PSK  should the router use?

And if it's a simple derivation, that means that anybody with the right PSK
can derive that key and participate in routing whether we want them to or
not, right? That is, where is the authz?

Given that I have to input my SSID passwords somehow, is it really too
much to ask that they also have to input, say, a homenet control plane 
password/key
to allow things like router updates, dns xfers, etc, to be authenticated?

> (If we also saw DHCPv6PD, and we saw authenticated HNCP, then it is internal)

Maybe we can turn the boundary problem on its head by defining it as 
"those who are in my tribe".
That is, if I can't authenticate them as a control plane speaker, they 
are definitionally "outside".

Mike

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Sep 2014 21:29:59 +0100

> to form an adjancency over an insecured wireless link.

A little side story…

I have an old house with quite thick walls. Standard 802.11 doesn't reach all rooms. Not that long ago I bought a pair of Netgear powerline Ethernet adaptors to extend coverage between rooms. I’d used an older version before, and it worked well, giving more throughout than the wireless and with the extended range. 

The interesting thing was that soon after plugging them in I noticed I’d lost connectivity on a laptop, and my desktop was behaving oddly. I looked at the network config to remind myself of the IP address of my default ADSL router. I used a browser to connect to the default router by IP to check its configuration. And got quite a surprise as it was a Sky router - a surprise as I’m not a customer of theirs! 

To cut a long story short, my powerline adaptors had formed a single network with powerline adaptors in a neighbour’s house. At which point my devices were getting responses from two DHCP servers, and some were routing out via the neighbour’s router. And that included some of my wireless devices - no point having WPA2 to protect against unwanted ‘guests’ if they can come in a power line Ethernet back door :)

Now, what I should have done, but it’s easy to get distracted and forget(!), was use the magic ‘auto configure a shared secret’ button on each of my adaptors to avoid them merging with my neighbour’s devices, or manually configure shared secrets (yuk). But clearly neither of us had done that.

The interesting thing was I could see the neighbour’s SSID from their Sky router splash screen, but having walked around the nearest streets, I couldn’t find it. I wonder how far away that house was...

There’s obviously some interesting implications of this. One is that there are insecure wired links too! 

Tim

---

From: "Mark Baugher (mbaugher)" <[email-masked]>
Date: Tue, 16 Sep 2014 23:11:21 +0000

> There’s obviously some interesting implications of this. One is that there are insecure wired links too! 

That's a good point.  And I wonder about malware on end systems as well.

Mark

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Sep 2014 08:31:40 +0200 (CEST)

> there are insecure wired links too!

Good point. I believe we're hitting the classic "secure or easy" tradeoff.

There is no way we automatically can detect what is home and what is not, 
instead there is going to have to be user interaction to say what is part 
of the home and what is not. For HNCP, this might mean some kind of 
cryptographic interaction of some kind, for instance what you suggested, 
having some kind of button, or perhaps having some kind of home "control 
panel" where new devices pop up and where they're authorized (or not).

As was presented in.. err, London?, shared secrets are bad. To really do 
this properly, we need device specific keys and some kind of list of 
"devices that are allowed to connect", perhaps by having their public keys 
in HNCP. I don't know. I am no security expert, but I believe we probably 
have to have two or three modes of security, one being "unsecure" that is 
auto everything (will give scenarios like the one Tim wrote about), one 
that is "shared secret", but where devices need to be configured using 
this shared secret (protects against accidents), and a third one where PKI 
is used, but where user policy infrastructure is available. The third one 
greatly increases scope the framework required to implement. I'm not sure 
it would even be HNCP anymore, perhaps we need a wider view than what the 
HOMENET charter has in it currently.

It wouldn't surprise me if we need another WG to tackle this. Perhaps it 
should be a more generic one based on creating a framework to handle 
access requests and control and how to distribute keys and other 
credentials, for SSH/SSL/IPSEC use, potentially? A lot of these mechanisms 
probably already exists, but they need to be put together and told how to 
interact.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Sep 2014 09:37:49 -0400

Michael Thomas <[email-masked]> wrote:
    >> I further suggest that if two routers have wireless that they might
    >> well have a WPA2/PSK available to them, and that they can and SHOULD
    >> use something derived from that key to authenticate each other.  Could
    >> be over IKEv2, yes.

    > If I have more than one SSID, which PSK should the router use?

Whichever ones authenticates the message.  The PSK is not transmitted.

    > And if it's a simple derivation, that means that anybody with the right
    > PSK can derive that key and participate in routing whether we want them
    > to or not, right? That is, where is the authz?

That's the nature of a PSK, yes.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Sep 2014 09:43:15 -0400

Tim Chown <[email-masked]> wrote:
    >> I think that we can assume that wired links are secure.  The only time
    >> we care if wireless is secured is when we want to form an adjacency
    >> over the wireless link.  I think it is acceptable to refuse to form an
    >> adjancency over an insecured wireless link.

...

    > To cut a long story short, my powerline adaptors had formed a single
    > network with powerline adaptors in a neighbour’s house.

Yes, this is an issue, and you could equally have done this over cable modem.
Or if you plugged a layer-2 ethernet/802.11 extender in to a wired port of
your router, and your neighbour did the same thing.  It's always possible
to defeat things; the question is whether or not your 1% situation should
mean that we have no security for 99% of the other times it works fine?

That's why I suggest that the wire permits a TOFU bootstrap, not that
it's forever insecure.  I don't see how your buttons, etc. would have
permitted anything, since that would have been about the wifi.

My understanding is that a new generation of powerline ethernet now
actually uses 15.4 MACs with a different PHY, and in fact runs Zigbee over
it, for exactly the situation you mentioned.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Sep 2014 06:53:51 -0700

> Whichever ones authenticates the message.  The PSK is not transmitted.

I'm about to send a routing update, or whatever message. Which WPA2 key 
does the router use?

> That's the nature of a PSK, yes.

I want to control people who I give access to my home network to 
participate in routing or not.
Overloading network access control with access to control plane 
modification sounds like a
bad idea to me.

If you wanted to overload the use of a key, it might better to derive a 
key from their admin
logins. But it would be best of all to not overload anything.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Sep 2014 07:58:39 -0700

On 09/16/2014 11:31 PM, Mikael Abrahamsson wrote:
> As was presented in.. err, London?, shared secrets are bad. To really 
> do this properly, we need device specific keys and some kind of list 
> of "devices that are allowed to connect", perhaps by having their 
> public keys in HNCP. I don't know. I am no security expert, but I 
> believe we probably have to have two or three modes of security, one 
> being "unsecure" that is auto everything (will give scenarios like the 
> one Tim wrote about), one that is "shared secret", but where devices 
> need to be configured using this shared secret (protects against 
> accidents), and a third one where PKI is used, but where user policy 
> infrastructure is available. The third one greatly increases scope the 
> framework required to implement. I'm not sure it would even be HNCP 
> anymore, perhaps we need a wider view than what the HOMENET charter 
> has in it currently.

Global symmetric keys certainly have their problems, but using public 
keys have their own.
Namely, if I want to enroll a new device each other currently enrolled 
device needs to know about
the public key of the new enrollee. For 2 devices, that's possibly 
manageable but for more I really
don't want to run around my house looking for every homenet device to 
enroll the new one.

If we were to do that, it might be nice to have a distributed database 
of homenet devices such that
I only had to enroll it on one of my homenet devices, and then it's 
distributed to the rest.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Sep 2014 13:23:42 -0400

> I'm about to send a routing update, or whatever message. Which WPA2 key

You don't use that key for that.

You use a key that IKEv2 built for you, using that key to authenticate the
IKEv2 session.   The result shows up in a list of peers, if you have turned
off TOFU, then you'd have to authorize each one.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Sep 2014 13:24:04 -0400

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Sep 2014 12:23:18 -0700

> off TOFU, then you'd have to authorize each one.

Which is "that key" here? I thought you said previously that "that key" 
was somehow
derived from a WPA2 PSK. If not, I don't understand how IKE helps with 
the enrollment
problem.

References to TOFU would be appreciated too... google is not immediately 
helpful.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Sep 2014 10:40:11 +1200

> I only had to enroll it on one of my homenet devices, and then it's

I don't think that's a "nice to have". I think it's an unavoidable
requirement, and it has to require at most trivial human intervention.

(Don't shoot me, but this happens to be a must-have for autonomic
networking too.)

   Brian

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 17 Sep 2014 23:55:16 +0000

See one inline belowŠ

>(Don't shoot me, but this happens to be a must-have for autonomic

I¹m not sure that this is a must-have but, if it were, could the autonomic
networking solution be used for homenet?

Thanks,
Acee

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Sep 2014 12:52:37 +1200

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

> networking solution be used for homenet?

Well, except that we don't have one yet ;-).

Really it's too soon to know, but the arguments about needing a strong
identity + trust model in the two cases are very similar. And some sort
of self-managing PKI seems to be needed.

However, I really don't want homenet to be stuck waiting for a non-existent
WG to get itself organized, so I think this is just something to keep in
mind for now.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Sep 2014 06:43:54 +0200 (CEST)

On Wed, 17 Sep 2014, Michael Thomas wrote:

> keys have their own. Namely, if I want to enroll a new device each other 
> currently enrolled device needs to know about the public key of the new 
> enrollee. For 2 devices, that's possibly manageable but for more I 
> really don't want to run around my house looking for every homenet 
> device to enroll the new one.
>
> of homenet devices such that I only had to enroll it on one of my 
> homenet devices, and then it's distributed to the rest.

That is exactly what I tried to propose.

---

From: Steven Barth <[email-masked]>
Date: Thu, 18 Sep 2014 08:30:54 +0200

>> If we were to do that, it might be nice to have a distributed 
>> database of homenet devices such that I only had to enroll it on one 
>> of my homenet devices, and then it's distributed to the rest.
>

I agree, if we are going to do define some sort of asymmetric crypto 
scheme for HNCP, we need to have an automated PKI management. However I 
don't think this should be a part of HNCP itself but instead a separate 
protocol.

Personally I would probably go with something IPSec-based as main 
security mechanism for HNCP for now until we have a clear view of how 
that PKI-scheme and the trust-management should look like taken into 
account that we have a some special issues here, i.e. how to do 
revocation if devices potentially don't have network access / an 
accurate clock at the time of authentication.

Also even if we define them I'm not sure as to how much complex 
PKI-based crypto-schemes will be actually implemented in practice.

Regards,

Steven

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 18 Sep 2014 08:27:27 +0000

Just to provide a pointer to a way that another org decided to handle a similar problem (and I'm not suggesting this is the right approach -- I'm just trying to provide food for thought):
http://upnp.org/specs/gw/deviceprotection1/

UPnP Device Protection uses X.509 certificates (which can be self-signed, and in order not to assume a WAN connection, really should be self-signed) and TLS.

It describes a couple of ways that initial trust and role assignment (what they are authorized to do, once authenticated) can be accomplished. These absolutely need to involve the user. But they need to be as simple as possible.

It also describes a mechanism where the list of trusted devices, their keys, and roles (authorizations) can be provided by one device to another. That allows the user to pair a new device with one other device in the network (don't care which), and then be provided the full list of all other such trusted devices, their keys, and roles.
Barbara

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 18 Sep 2014 12:35:24 +0300

> to form an adjancency over an insecured wireless link.

This can also be automated (for first-hop wireless). However, in the ‘what-if’ land, wired -> wireless bridges, and wireless -> wireless extenders that do things insecurely cannot be detected.

> (I’m making allusions to http://en.m.wikipedia.org/wiki/Quantum_entanglement)

I assume you mean: 

- On wired links: opportunistic IKEv2 attempt, fallback to non-IPsec (if no IPsec available? if no key?), and update the SPD dynamically based on successful IKEv2 attempts.
- On the wireless (all? only insecure?): force IPsec using the known good SPD entries.

That is interesting scheme. Implementation-wise, it sounds somewhat painful though. 

> derived from that key to authenticate each other.  Could be over IKEv2, yes.

I _think_ we have to assume some passwords somewhere. 

- WPA2 PSK on almost all home routers by default (most home network access these days is wireless)

- admin password (for those user actually has access to, and are not part of some super-fancy PKI scheme for authenticating administrator)

That said, I am not sure if they are really needed. 

> random hosts, perhaps we can specify this behaviour.

Hmm. I wonder if that assumption would work bidirectionally, though. That is, the not-key-knowing router sending plaintext traffic, and the others using the information? If so, what is the value of having the (optional) authentication at all?

If assumption is not bidirectional, then the distributed algorithms would not work very well over such protocol - unless the unauthenticated messages were just used for bootstrapping the trust somehow, but it is not clear to me how that would happen either. Of course, they could be used to show user some error (if the router actually had UI of some kind) but not much else that I can see.

> Yes, if we can make this AH assumption of skipping, so that we can get TOFU

If we assume some psk on all routers, we can probably bootstrap ’something’ without TOFU too?

Speaking of IPsec in general, I had a chat with Steven about this, and the conclusion was more or less this:

- (HNCP) unicast works with (opportunistic) IKEv2 or manual key fine
- (HNCP) multicast works with manual key, but currently is not used for anything sensitive (just change detection mechanism, actual state changes done via unicast due to multicast size limit)

=> From my point of view, plaintext multicast + unicast IKEv2 with (opportunistic) authentication would be perfectly fine too. And as long as confidentiality is not desired for the traffic, security properties would be actually better than for manually keyed IPsec.

If confidentiality is desired, equation changes; however, even when using manually keyed IPsec, the fact that there _are_ changes in network topology cannot be hidden, from traffic analysis, so I am not sure if it is significantly different outcome from the confidentiality-only-on-unicast.

>    markus> 2.2) Or should we roll our own in-HNCP scheme?

High five!

> (If we also saw DHCPv6PD, and we saw authenticated HNCP, then it is internal)

I think use of link-local multicast is perfectly fine. Their cable modems SHOULD/MUST configure the cable interface as external in any case, which has both firewalling implications as well as no HNCP or routing protocol traffic on the interface.

Fully bridging cable modems are different beast, but even in their case, if the border detection works fine (=there is PD prefix or IPv4 DHCP available there), the HNCP implementations should treat the interface as external based on autodetection in any case.

PD + authenticated HNCP case I am not sure what should be done with - perhaps the hybrid category, although it should not be autodetected (I lean towards external by default, using the ‘more firewalling the merrier’ logic).

So far identified security options:

1. no crypto, but fixed interface categories (no HNCP on untrusted L2 links)

2. manually keyed IPsec (using PSK, provisioned in advance)

3. {manual keys, certs, something else} IKEv2 on unicast, ignore multicast (and write in draft no state exchange based on multicast, just change notification)

4. opportunistic variant of the above, with e.g. self-signed certs, and leap of faith happening on interface type

5. web of trust in HNCP (Xavier’s draft).  The current form of _that_ draft, for the record, is not really final from my point of view but I’m talking more about the general idea. 

[4] scheme in and of itself would have no way of transmitting ’these are self-signed certs I trust’ to other nodes it does trust. Therefore, if we want to do things in opportunistic way, [5] > [4] in terms of user experience, as it would share the trust state across the whole home network _using already trusted node set_, and therefore the number of ‘pairings’ in the opportunistic scheme would be less. Of course, web of trust could be also be based on CA hierarchy or whatever, so it is definitely the flexible choice. However, it does imply quite a bit of changes to HNCP draft too (or extra draft as it is currently).

That said, I personally like [1]-[3], and [4]/[5] seem complex. 

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Sep 2014 06:34:03 -0400

> UPnP Device Protection uses X.509 certificates (which can be self-signed, and in order not to assume a WAN connection, really should be self-signed) and TLS.

I think that something like this, in combination with the promiscuous registration mechanism that I think Michael described earlier, would do the trick.   It's not clear that we need X.509 certs, since I have trouble imagining that the keys these devices have would ever be signed by a CA.   A bare key might be plenty.   But I think this is a better option than trying to shoehorn this functionality into IPsec, which was designed for a _very_ different security context.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 18 Sep 2014 11:38:18 +0000

> > UPnP Device Protection uses X.509 certificates (which can be self-signed,
> > and in order not to assume a WAN connection, really should be self-signed)
> >and TLS.

> I think that something like this, in combination with the promiscuous
> registration mechanism that I think Michael described earlier, would do the
> trick.   It's not clear that we need X.509 certs, since I have trouble imagining
> that the keys these devices have would ever be signed by a CA.   A bare key
> might be plenty.   But I think this is a better option than trying to shoehorn
> this functionality into IPsec, which was designed for a _very_ different
> security context.

X.509 certificates can be self-signed. That is, the device acts as its own CA. In fact, this is the recommended approach.
Barbara

---

From: Michael Sweet <[email-masked]>
Date: Thu, 18 Sep 2014 07:50:57 -0400

One advantage of using X.509 certs is that the code to support them is widely available with multiple implementations.

Another is that the same cert can be used for TLS negotiation in embedded web services, etc. to each device.

And of course if the registration mechanism is integrated into client OS's then those X.509 certs can easily participate in the usual trust policy stuff supported by those OS's.

> I think that something like this, in combination with the promiscuous registration mechanism that I think Michael described earlier, would do the trick.   It's not clear that we need X.509 certs, s…

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Rene Struik <[email-masked]>
Date: Thu, 18 Sep 2014 08:25:25 -0400

Dear colleagues:

I have seen a lot of emails with the "HNCP security" heading. However, 
is there a concise technical description of the security services to be 
provided, the trust lifecycle of a device and network, including 
configuration and authorization model?

The description below seems to only deal with group membership 
enlargement (adding a new device), but not with pruning membership 
(removal of a device, e.g., the one from a house guest that left). It 
may very well be that one can connect a laptop to one of two printers, 
where some user input is decided to determine which one, etc, etc.

Best regards, Rene

On 9/18/2014 12:43 AM, Mikael Abrahamsson wrote:
>> keys have their own. Namely, if I want to enroll a new device each 
>> other currently enrolled device needs to know about the public key of 
>> the new enrollee. For 2 devices, that's possibly manageable but for 
>> more I really don't want to run around my house looking for every 
>> homenet device to enroll the new one.
>>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Sep 2014 05:42:56 -0700

> And of course if the registration mechanism is integrated into client OS's then those X.509 certs can easily participate in the usual trust policy stuff supported by those OS's.

IMHO, if you're not going to use a CA, then putting x509 bits around the 
public key only serves to confuse
the issue in my experience, and makes for a much more complicated 
solution. Using raw public keys is
really quite simple codewise. And, of course, nothing prevents you from 
manufacturing those fake
x509 certs for protocols that require them, and just using the bare key 
for those that don't.

That said, it is possible to envision using local CA functionality such 
that any currently enrolled homenet
router is able to sign a new enrollee's key which allows it to present 
that cert to any other homenet
device without prior knowledge of that key and be accepted. It's just 
another way of distributing the database.

Not sure how any of this would work with revocations though.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Sep 2014 09:05:57 -0400

> X.509 certificates can be self-signed. That is, the device acts as its own CA. In fact, this is the recommended approach.

Of course.   But if there is never going to be a CA-signed key, there is no reason to have a cert at all.   Self-signed certs are essentially a way of carrying a bare key in a cert, unless you install your signer key as a CA key, in which case you have an administratively configured CA key that is signing the cert, and it's no longer really a self-signed cert.

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 18 Sep 2014 16:49:23 +0300

On 18.9.2014, at 16.05, Ted Lemon <[email-masked]> wrote:
> Of course.   But if there is never going to be a CA-signed key, there is no reason to have a cert at all.   Self-signed certs are essentially a way of carrying a bare key in a cert, unless you install your signer key as a CA key, in which case you have an administratively configured CA key that is signing the cert, and it’s no longer really a self-signed cert.

On the other hand, use of certificates facilitates also use of something like (hardware bound) device certificates, that would be much harder to generate on demand (and therefore blacklisting them might actually make sense in opportunistic scheme).

Cheers,

-Markus

---

From: Steven Barth <[email-masked]>
Date: Thu, 18 Sep 2014 16:05:34 +0200

> One advantage of using X.509 certs is that the code to support them is widely available with multiple implementations.
I guess then you could go all the way and use the whole DTLS for HNCP 
unicast traffic (and keep MC unencrypted since its more or less a 
signaling channel for UC and doesn't contain sensitive data). This would 
then avoid the need to redefine and reimplement most of the DTLS 
features in HNCP anyway.

Cheers,

Steven

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Sep 2014 08:17:27 -0700

> On the other hand, use of certificates facilitates also use of something like (hardware bound) device certificates, that would be much harder to generate on demand (and therefore blacklisting them…

With device certificates, you still have the original authz problem. 
That is, just because I can identify you
reliably tells me nothing about whether I want to participate with 
routing updates with you.  So in that
way, they not any more useful than naked keys.

Mike

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 18 Sep 2014 18:24:38 +0300

On 18.9.2014, at 18.17, Michael Thomas <[email-masked]> wrote:
> With device certificates, you still have the original authz problem. That is, just because I can identify you
> reliably tells me nothing about whether I want to participate with routing updates with you.  So in that

If the device certificate is on hardware, you cannot generate them at will, and therefore they _are_ more useful as you can e.g. blacklist device and be sure that even with leap of faith code active, it will not come out of woodwork with new certificate.

(See above.)

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 18 Sep 2014 18:31:06 +0300

Whether or not you do leap of faith, certificates _do_ provide extra value.

- you can produce them/validate via (local / cloudy) CA (which may also imply authorization in addition to authentication, or not)

- you can have them from hardware (which makes producing spurious ones much harder, assuming the hardware certificates in and of themselves are authenticable)

whether your authorization policy is leap of faithy, or strict ’these are the authorized CAs/individual certs’, there is no way to express same things with raw public keys (or you wind up with new X509, which is in nobody’s best interest).

That said, I think there is probably room for both PSK-based and some PKI-based solution here, but I do not believe that much in raw public keys any more.

Cheers,

-Markus

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Sep 2014 08:33:25 -0700

> If the device certificate is on hardware, you cannot generate them at will, and therefore they _are_ more useful as you can e.g. blacklist device and be sure that even with leap of faith code activ…

Revocations again gets back to the threat model: what attacks are we 
trying to prevent (or not).
Without knowing that, it's hard to say whether device certs help any, 
especially considering
that there are perfectly acceptable homenet routers that will never be 
born with a device cert.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Sep 2014 08:36:37 -0700

> whether your authorization policy is leap of faithy, or strict ’these are the authorized CAs/individual certs’, there is no way to express same things with raw public keys (or you wind up with new…

Anything you can do with a cert, you can do with raw public keys, and 
you don't need CA's. See RFC4871 for an example.

Mike

---

From: Rene Struik <[email-masked]>
Date: Thu, 18 Sep 2014 11:46:39 -0400

It seems that the cryptographic literature needs to be rewritten now ...

==

On 9/18/2014 11:36 AM, Michael Thomas wrote:
>> whether your authorization policy is leap of faithy, or strict ’these 
>> are the authorized CAs/individual certs’, there is no way to express 
>> same things with raw public keys (or you wind up with new X509, which 
>> is in nobody’s best interest).
>>
>
>
>
> Mike
>

---

From: David R Oran <[email-masked]>
Date: Thu, 18 Sep 2014 11:57:12 -0400

On Sep 18, 2014, at 11:46 AM, Rene Struik <[email-masked]> wrote:

> Anything you can do with a cert, you can do with raw public keys, and you don't need CA's. See RFC4871 for an example.
I would have thought it was the opposite:
anything you can do with raw keys you can do with certificates.

Raw keys cannot prove an assertion that a certain claimed name is bound to a certain key. In the case of self-signed certs you only get the advantages of having a data structure and code that is understood and well vetted, but with either a PKI or a web of trust you do get benefits from using Certs. You also get usage policy restrictions, which cannot be expressed with raw keys.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Sep 2014 09:13:36 -0700

> Raw keys cannot prove an assertion that a certain claimed name is bound to a certain key. In the case of self-signed certs you only get the advantages of having a data structure and code that is un…

Raw keys in and of themselves provide provable identifiers of the public 
key: the fingerprint itself. It remains
to be seen whether some other identity needs to be bound to it, and, of 
course, certs are hardly the only way
to do that.

Self-signed certs bring only confusion, IMO: they are nothing more than 
a raw key with an unsubstantiated claim to
another name, along with a whole lot more ASN.1 baggage beyond what is 
needed to parse the modulo
and exponent.

And you don't get usage or policy restrictions without a CA that the 
*HOMENET* trusts to assert them, nor can
that sort of policy assertion be done with device certs since I don't 
have any reason to believe fly-by-night's
routers should be allowed to do whatever it is they claim they want to do.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Sep 2014 12:06:57 -0700

> anything you can do with raw keys you can do with certificates.

FWIW, this is also true even though the rest wasn't. You can always 
strip the x509 coating
and use the raw keys, yes. Which begs the question of why use the 
coating if it's not
doing anything useful, which is pretty much the situation with 
self-signed certs.

To paraphrase:

'Some people, when confronted with a security problem, think "I know, 
I'll use certificates." Now they have two problems.'

Mike

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 18 Sep 2014 21:10:18 +0000

> Self-signed certs bring only confusion, IMO: they are nothing more than a
> raw key with an unsubstantiated claim to another name, along with a whole
> lot more ASN.1 baggage beyond what is needed to parse the modulo and
> exponent.
> 
> *HOMENET* trusts to assert them, nor can that sort of policy assertion be
> done with device certs since I don't have any reason to believe fly-by-night's

No, this would only be true if there were an implied authorization to go along with the authentication. That's why it's so important for the user to have to take an initial step of providing authorization (in the event where the user has chosen to secure homenet -- of course the use should have the option not to force homenet to run securely, just like the user can choose to run Wi-Fi without security or not to push the buttons on powerline networking devices [distinct from the buttons on Wi-Fi devices] in order to create a secure powerline network).

Since the user should be responsible for providing authorization, and authentication should be completely separated from authorization, the key is *only* for authentication. The key would only need to be revoked if it were believed that some other device were using the key (the key to device association could no longer be trusted). Revoking authorization is done by changing the role that a device using the key is allowed to perform. The user should be able to do this. And then the same mechanism used to provide new devices with the key/role list can be used to supply all devices with the updated key/role list.

If a key is associated with a "guest" role, it shouldn't be necessary to delete that entry in the key/role list unless the user really wants to make sure that the device is not allowed to come back again as a guest. A user who cares to should be able to edit the key/role list whenever they like (including deleting entries). But a user who does not choose to ever edit the list when there is no evidence of a problem would be fine. A "friendly name" is important. But that's becoming important to so many things in the home network.
Barbara

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Sep 2014 14:17:51 -0700

On 9/18/14, 2:10 PM, STARK, BARBARA H wrote:
> No, this would only be true if there were an implied authorization to go along with the authentication.

Yes, I agree and that's why self-signed and/or manufacturer certs are of 
no help.
There is no believable authz in them. A homenet would need to run its 
own CA, or
use a CA that it delegates authz to. Or does something that avoids certs 
altogether
and provides its own enrollment/authz solution.

Mike

---

From: Mark Baugher <[email-masked]>
Date: Thu, 18 Sep 2014 15:04:08 -0700

> Raw keys cannot prove an assertion that a certain claimed name is bound to a certain key. In the case of self-signed certs you only get the advantages of having a data structure and code that is un…

Agreed and this whole discussion is deju vu all over again for me, and no longer very interesting.  What's more important than the container is how keys come to get authorized or rejected, what authorization "means" and how to revoke it, do an on-line test, etc.  

As someone on this thread has asked:  Has any of this been written down?  Requirements, use cases, threat analysis should all help to inform our decision about what format to use.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Thu, 18 Sep 2014 15:07:59 -0700

And all of this was covered in the design for UPnP Device Protection that you referred to earlier and its progenitor UPnP Device Security.  I consider HNCP security to be a small subset of the UPnP device requirements.

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Sep 2014 10:39:15 +1200

> Yes, I agree and that's why self-signed and/or manufacturer certs are of

Surely they are of help for secure *identification* of devices?
Authorisation is a separate step.

> and provides its own enrollment/authz solution.

Yes, but with the identity of the devices verified by cert.

   Brian

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Sep 2014 15:45:30 -0700

> Surely they are of help for secure *identification* of devices?

No more so than the naked public key.

> Authorisation is a separate step.

Yes.

> Yes, but with the identity of the devices verified by cert.

A cert, at its heart, is used to bind a name (CN, DN, etc) to a key. You 
don't need a
human friendly name binding to identify something that possesses the 
corresponding
private key though. The public key itself is a unique identifier.

Mike

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Sep 2014 10:18:52 +0200

> I think that something like this, in combination with the promiscuous registration mechanism that I think Michael described earlier, would do the trick.   It's not clear that we need X.509 certs, s…

My own experience attempting to use IPsec as an add-on security solution (a.k.a. "pixie dust) for a protocol isn't all that positive. We tried that with L2TP, and in the process failed to kill off PPTP on windows clients. I can't tell you how many times over the years I've had to point people to the Windows Registry setting to disable IPsec with L2TP. OSPFv3 is another one where I get complaints about requiring IPsec. So, I agree with Ted; We should be wary of falling into the trap of using IPsec just because it is there.

Another lesson learned was exposing two passwords to the user vs. one. In a retail/wholesale LAC/LNS deployment model, it made perfect sense for the L2TP tunnel to have a password separate from the PPP user password (and L2TP fully supplanted L2F in these types of deployments). But when the L2TP tunnel and the PPP session are are at the same point it just looks redundant to the end user to have separate security config for each (let alone IPsec on top). Knowing the difference between a tail and a dog is important[1], and it was a very bad idea to let the protocol design influence the UI. In retrospect, allowing one protocol to bootstrap the security in another would have been a good thing for us to have considered more. 

- Mark

[1] http://www.urbandictionary.com/define.php?term=the+tail+wagging+the+dog

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 19 Sep 2014 12:06:07 +0300

> My own experience attempting to use IPsec as an add-on security solution (a.k.a. "pixie dust) for a protocol isn't all that positive. We tried that with L2TP, and in the process failed to kill off…

So DTLS it is? Because I do not want to reinvent any crypto wheels I do not have to.

From solution point of view, the only real difference is that DTLS solution cannot be used to secure other protocols between the routers (just with configuration), but I am sure we can stick in some pixie dust PSK TLVs to keep the other protocols’ (bad) security solutions (mostly) functioning.

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2014 06:28:20 -0400

> As someone on this thread has asked:  Has any of this been written down?  Requirements, use cases, threat analysis should all help to inform our decision about what format to use.

This discussion to some extent made it into the homenet architecture document, but I don't think the whole discussion was captured in any document, and that's why we're having the discussion again.   I agree that we discussed this before, but we are getting a little bit more into the details now, so I don't think that's a bad thing.   This discussion doesn't seem to have degenerated into a bunch of people talking past each other, so let's be thankful for small favors.   :)

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Sep 2014 06:53:28 -0700

On 09/19/2014 01:18 AM, Mark Townsley wrote:
>
>
> Another lesson learned was exposing two passwords to the user vs. one. 
> In a retail/wholesale LAC/LNS deployment model, it made perfect sense 
> for the L2TP tunnel to have a password separate from the PPP user 
> password (and L2TP fully supplanted L2F in these types of 
> deployments). But when the L2TP tunnel and the PPP session are are at 
> the same point it just looks redundant to the end user to have 
> separate security config for each (let alone IPsec on top). Knowing 
> the difference between a tail and a dog is important[1], and it was a 
> very bad idea to let the protocol design influence the UI. In 
> retrospect, allowing one protocol to bootstrap the security in another 
> would have been a good thing for us to have considered more.
>

If we are going to be using a password as the root means of providing 
authorization to participate in routing or
not, we can't use the same password that is used for access control to 
my network (wpa2), or to another network in
your example (ppp, l2tp) or any derived value of it. I don't want my 
local users or much worse -- my ISP's -- to be able
derive a key they already possess for one reason, and be able have at my 
infrastructure's control plane.

Best of all would not to use passwords altogether, cf the zillions of 
hacks on trivially guessable passwords ("MyDoGsPoT").

Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Sep 2014 07:00:45 -0700

> So DTLS it is? Because I do not want to reinvent any crypto wheels I do not have to.

Without a list of threats, it's impossible to know if "DTLS is it". And 
it's extremely unlikely that
DTLS will be a one-sentence "solution" even if it gets adopted because 
DTLS, IPsec, etc say nothing
about enrollment and authorization. Those are by far the hard problems 
with homenent security.

The thing that I'm curious about is whether we can use HNCP itself as a 
way to distribute authz
for itself, and potentially for other homenet related protocols, cf 
Brian's MUST a few messages ago.

Mike

---

From: Steven Barth <[email-masked]>
Date: Fri, 19 Sep 2014 16:17:32 +0200

Am 19.09.2014 um 16:00 schrieb Michael Thomas:
> And it's extremely unlikely that
I wouldn't really want to lock HNCP to any trust scheme at this point 
where we are not even sure what we want. I'd rather choose the 
underlying mechanism, either DTLS or IPsec/IKE and leave the rest 
out-of-scope. Maybe mention PSK-usage as baseline option and say various 
other certificate-based approached are possible but out-of-scope of the 
HNCP draft itself.

In practice users could probably run either their own in-home CA (e.g. 
like draft-behringer-homenet-trust-bootstrap) or we could add a 
web-of-trust-like extension to HNCP using transitive trust as proposed 
in draft-bonnetain-hncp-security or some weird combination. Either way 
it all stands and falls with the final user experience, e.g. the APP and 
the router's interaction with it for trust-bootstrap or the 
Web-UI/APP/Push-Button which let's you actively "trust" your peer in the 
web-of-trust approach. But user-experience isn't something we can really 
specify here.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Sep 2014 07:29:38 -0700

On 09/19/2014 07:17 AM, Steven Barth wrote:
>> DTLS will be a one-sentence "solution" even if it gets adopted 
>> because DTLS, IPsec, etc say nothing
>> about enrollment and authorization. Those are by far the hard 
>> problems with homenent security.
> out-of-scope. Maybe mention PSK-usage as baseline option and say 
> various other certificate-based approached are possible but 
> out-of-scope of the HNCP draft itself.
>
> it all stands and falls with the final user experience, e.g. the APP 
> and the router's interaction with it for trust-bootstrap or the 
> Web-UI/APP/Push-Button which let's you actively "trust" your peer in 
> the web-of-trust approach. But user-experience isn't something we can 
> really specify here.
>

Let's be clear: the enrollment and authorization problems are The hard 
problems. How the bits one the
wire are encrypted/authenticated is straightforward in comparison. Not 
having a standardized way of
setting this up will lead to chaos and the high likelihood that homenet 
devices will not interoperate. Doubly
so because the homenet architecture requires as little operator 
intervention as possible.

Punting on one of the hardest problems would be a travesty. There are 
plenty of people in IETF that are
plenty smart about this subject; we will never get an opportunity to do 
the right thing again if we loose
this into the wild and say "figure it out yourself." We know what 
happens then.

Mike

---

From: Steven Barth <[email-masked]>
Date: Fri, 19 Sep 2014 16:52:45 +0200

Am 19.09.2014 um 16:29 schrieb Michael Thomas:
> plenty smart about this subject; we will never get an opportunity to 
> do the right thing again if we loose
That was not my point. I'm totally happy with having a standardized way 
of doing this but I don't think that HNCP is the place where it should 
be defined since we will probably not be the only user. Don't get me 
wrong if we or anyone else comes up with a brilliant solution I'm all up 
for referencing it and using it. For HNCP itself what is more important 
to define in my mind is choosing the crypto-mechanism or at least I 
would separate those two discussions.

The other point is, it doesn't matter how technically brilliant the 
solution is in the end if the user experience isn't good enough and that 
is outside our control really. Adding to that judging from experience 
with consumer-oriented hardware, if we get HNCP adopted then the 
baseline of products will probably support no-auth or maybe PSK if we 
are lucky unless we actually forbid unencrypted HNCP and / or 
PSK-secured HNCP and I'm not sure I personally would want to go there 
really.

Cheers,

Steven

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Sep 2014 08:18:42 -0700

On 09/19/2014 07:52 AM, Steven Barth wrote:
> That was not my point. I'm totally happy with having a standardized 
> way of doing this but I don't think that HNCP is the place where it 
> should be defined since we will probably not be the only user. Don't 
> get me wrong if we or anyone else comes up with a brilliant solution 
> I'm all up for referencing it and using it. For HNCP itself what is 
> more important to define in my mind is choosing the crypto-mechanism 
> or at least I would separate those two discussions.

HNCP or Homenet in general? Given the possibility of leveraging key 
distribution and/or auth/authz information from
HNCP itself, it might not be bad to consider the homenet security issues 
organically. However, if this is a plea for
kicking this down the road to some non-existent working group, I don't 
agree at all, and nor do I think that the
architecture would permit that.

> solution is in the end if the user experience isn't good enough and 
> that is outside our control really. Adding to that judging from 
> experience with consumer-oriented hardware, if we get HNCP adopted 
> then the baseline of products will probably support no-auth or maybe 
> PSK if we are lucky unless we actually forbid unencrypted HNCP and / 
> or PSK-secured HNCP and I'm not sure I personally would want to go 
> there really.

This is the danger of saying later, or even a "YOU MUST IMPLEMENT RFC 
XXX TOO" requirement. We've seen this
way too many times in the past and it will  be a complete mess if don't 
take a hard line, IMO.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2014 11:54:19 -0400

On Sep 19, 2014, at 10:52 AM, Steven Barth <[email-masked]> wrote:
> That was not my point. I'm totally happy with having a standardized way of doing this but I don't think that HNCP is the place where it should be defined since we will probably not be the only user.

HNCP won't be the only user, but given that it's how the network figures itself out, it's really hard to imagine any other place where the process of arriving at mutual trust could happen.   If it's not in HNCP, it's going to be in a different protocol that looks a lot like HNCP, and runs alongside it, sharing a lot of the same per-device state.

---

From: Mark Baugher <[email-masked]>
Date: Fri, 19 Sep 2014 08:59:20 -0700

On Sep 19, 2014, at 8:54 AM, Ted Lemon <[email-masked]> wrote:

> HNCP won't be the only user, but given that it's how the network figures itself out, it's really hard to imagine any other place where the process of arriving at mutual trust could happen.  

How could it happen?

Mark

> If it's not in HNCP, it's going to be in a different protocol that looks a lot like HNCP, and runs alongside it, sharing a lot of the same per-device state.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2014 12:37:06 -0400

> How could it happen?

Isn't that what we've been discussing?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 19 Sep 2014 10:14:46 -0700

On Sep 19, 2014, at 7:17 AM, Steven Barth <[email-masked]> wrote:

>> DTLS will be a one-sentence "solution" even if it gets adopted because DTLS, IPsec, etc say nothing
>> about enrollment and authorization. Those are by far the hard problems with homenent security.
> I wouldn't really want to lock HNCP to any trust scheme at this point where we are not even sure what we want. I'd rather choose the underlying mechanism, either DTLS or IPsec/IKE and leave the rest out-of-scope. Maybe mention PSK-usage as baseline option and say various other certificate-based approached are possible but out-of-scope of the HNCP draft itself.
> 
> In practice users could probably run either their own in-home CA (e.g. like draft-behringer-homenet-trust-bootstrap) or we could add a web-of-trust-like extension to HNCP using transitive trust as proposed in draft-bonnetain-hncp-security or some weird combination. Either way it all stands and falls with the final user experience, e.g. the APP and the router's interaction with it for trust-bootstrap or the Web-UI/APP/Push-Button which let's you actively "trust" your peer in the web-of-trust approach. But user-experience isn't something we can really specify here.

Dear Steven,

As HNCP is deployed, there should be a sure way to ascertain a "home" network from that of outside traffic.  Wi-Fi Protected Setup (WPS) tried to allow home users an easy way to add new devices to an existing Wi-Fi network without entering long pass-phrases.  Making this easy for users, also made compromising the strategy easy for attackers.  Will NFC replace that of the vulnerable PIN?

Nor can ISP assigned prefixes be shared within a home environment without a sure way to exclude non-local traffic.  This should not depend on establishing cryptographic trust methods because this will not prevent users from being deceived; it simply changes what is being unreliably shared.  These methods must be bog standard to ensure plumbing works as expected.  One such method might attempt to establish an overlay network using the private address space defined for IPv6 and IPv4.

Regards,
Douglas Otis

---

From: Randy Turner <[email-masked]>
Date: Fri, 19 Sep 2014 13:02:23 -0400

A cert by itself is more or less a wrapper  but that¹s not the way PKI
works (certs by themselves) - you have certs and trust anchors  the anchors
being the method by verifying the identity of the person presenting the cert
 you can do proof of possession as well to very the identity supplicant
knows the private key.

Randy

From:  Michael Thomas <[email-masked]>
Date:  Thursday, September 18, 2014 at 3:06 PM
To:  David R Oran <[email-masked]>, Rene Struik
<[email-masked]>
Cc:  <[email-masked]>, Markus Stenberg <[email-masked]>
Subject:  Re: [homenet] HNCP security?

 
On 9/18/14, 8:57 AM, David R Oran wrote:

>  
> On Sep 18, 2014, at 11:46 AM, Rene Struik <[email-masked]>
> <mailto:[email-masked]>  wrote:
> 
>  
>>  
>> Anything you can do with a cert, you can do with raw public keys, and you
>> don't need CA's. See RFC4871 for an example.
>>  
>  
 
 FWIW, this is also true even though the rest wasn't. You can always strip
the x509 coating
 and use the raw keys, yes. Which begs the question of why use the coating
if it's not
 doing anything useful, which is pretty much the situation with self-signed
certs.
 
 To paraphrase: 
 
 'Some people, when confronted with a security problem, think "I know, I'll
use certificates." Now they have two problems.'
 
 Mike
 
_______________________________________________ homenet mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/homenet

---

From: Mark Baugher <[email-masked]>
Date: Fri, 19 Sep 2014 10:22:42 -0700

> Isn't that what we've been discussing?

AFAICT, we've been discussing key format or DLTS vs IPsec.  That discussion presumes that you have some way for a CPE from ISP-a to securely accept HNCP from ISP-b, or the user's new AP/router, and so forth.  How does that happen?

Mark

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2014 15:38:39 -0400

> AFAICT, we've been discussing key format or DLTS vs IPsec.  That discussion presumes that you have some way for a CPE from ISP-a to securely accept HNCP from ISP-b, or the user's new AP/router, and…

Michael Richardson had some suggestions back on the 17th.   There's definitely been more talk of keys than mechanisms since then, but that is precisely why I said what I did about the HNCP key discussion.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Sep 2014 13:05:26 -0700

> Michael Richardson had some suggestions back on the 17th.   There's definitely been more talk of keys than mechanisms since then, but that is precisely why I said what I did about the HNCP key disc…

I think the larger implication is that if HNCP has implications of 
needing to deal with
multiple different trust boundaries and how they interact, asking 
whether we need "IPsec
or DTLS and then are we done?" is profoundly premature. A home network 
is a vulnerable
and very complicated environment even today, and adding a lot more 
functionality without
plumbing the depths of the security implications will only make a bad 
situation much worse.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Sep 2014 08:24:18 +1200

On 20/09/2014 08:05, Michael Thomas wrote:
>>> AFAICT, we've been discussing key format or DLTS vs IPsec.  That
>>> discussion presumes that you have some way for a CPE from ISP-a to
>>> securely accept HNCP from ISP-b, or the user's new AP/router, and so
>>> forth.  How does that happen?
>> Michael Richardson had some suggestions back on the 17th.   There's
>> definitely been more talk of keys than mechanisms since then, but that
>> is precisely why I said what I did about the HNCP key discussion.
>>
> 

I agree. I think there are a number of steps to consider, and how
to secure an individual point-to-point communication is late in the
list. Even without a threat analysis, I can see:

1. Establish the boundary (and Tim's recent power-line story
   underlines that this isn't trivial).
2. Establish the trust anchor (you're bound to need one).
3. Establish (trusted identity + public key) for every device.
4. Authorise each device for selected roles.
5. Distribute public keys accordingly.

Do that, and it becomes a relatively minor point which crypto
protocol you choose.

   Brian

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Sep 2014 13:54:28 -0700

On 9/19/14, 3:28 AM, Ted Lemon wrote:
> This discussion to some extent made it into the homenet architecture document, but I don't think the whole discussion was captured in any document, and that's why we're having the discussion again.
>
I guess that's kind of what I've been getting at: should we capture all 
of this in a threats document?
I'm a little uncomfortable with the formality, but I'm even more 
uncomfortable with the seeming desire
by some to sweep this all under the rug.

If we did, my preference would that it not be HNCP specific.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2014 16:59:54 -0400

On Sep 19, 2014, at 4:54 PM, Michael Thomas <[email-masked]> wrote:
> I guess that's kind of what I've been getting at: should we capture all of this in a threats document?
> I'm a little uncomfortable with the formality, but I'm even more uncomfortable with the seeming desire

I think it would be worth gathering the information in a document if someone wants to write one, sure.   Just talking and not gathering the results is a waste of time.   I think there are a fair number of people who have ideas about how this should work.   I don't know if a threats document per se is the right thing to do, but a document where this discussion is tracked and recorded would definitely be helpful.   It would be a shame though if that effort derailed forward progress, as such things sometimes do.

---

From: Tim Chown <[email-masked]>
Date: Sat, 20 Sep 2014 08:17:04 +0100

> On 19 Sep 2014, at 21:59, Ted Lemon <[email-masked]> wrote:
> 

I think it would be useful to do, and needn't hold up progress. It would give us a common understanding - hopefully - of which threats are being covered and which are not. And which are handled by layers/protocols outside the scope of homenet's charter.

Tim

---

From: Steven Barth <[email-masked]>
Date: Sat, 20 Sep 2014 09:57:38 +0200

> I think it would be useful to do, and needn't hold up progress. It would give us a common understanding - hopefully - of which threats are being covered and which are not. And which are handled by…
We started a similar thread about 3 months ago here: 
http://www.ietf.org/mail-archive/web/homenet/current/msg03694.html maybe 
this can be used as a starting point.

Cheers,

Steven

---

From: Mark Baugher <[email-masked]>
Date: Sun, 21 Sep 2014 12:22:15 -0700

On Sep 20, 2014, at 12:57 AM, Steven Barth <[email-masked]> wrote:

> We started a similar thread about 3 months ago here: http://www.ietf.org/mail-archive/web/homenet/current/msg03694.html maybe this can be used as a starting point.

It would be good to limit the scope of HNCP security (the subject of this thread) and consider IETF homenet security in a companion specification that addresses the two differentiators of homenets:  Multiple authorities and absence of active management complicate authorization.  These differentiators mean there's a different set of problems for authorization than what we ordinarily have in IETF protocols.  So HNCP might punt the authorization issue like IETF protocols typically do, e.g. assume in the worst case that an authorized person installs a shared key.  But this is not a reasonable assumption in homenets, however, owing to the differences of homenets from enterprise, government, military and other environments where there typically is a single authority and active management of the network.  Thus, authorization is an unavoidable topic for Homenet, but the HNCP draft is probably not the place for that.

What I'm suggesting is more than a threats or requirements document.

Mark

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 22 Sep 2014 16:22:40 +0000

I agree with this direction. This will also let the work HCNP and Security
Threats/Requirements to go on in parallel. Of course, HCNP security may
need to be revisited once the latter is agreed upon.
Thanks,
Acee

On 9/21/14, 3:22 PM, "Mark Baugher" <[email-masked]> wrote:

>>> I think it would be useful to do, and needn't hold up progress. It
>>>would give us a common understanding - hopefully - of which threats are
>>>being covered and which are not. And which are handled by
>>>layers/protocols outside the scope of homenet's charter.
>It would be good to limit the scope of HNCP security (the subject of this
>thread) and consider IETF homenet security in a companion specification
>that addresses the two differentiators of homenets:  Multiple authorities
>and absence of active management complicate authorization.  These
>differentiators mean there's a different set of problems for
>authorization than what we ordinarily have in IETF protocols.  So HNCP
>might punt the authorization issue like IETF protocols typically do, e.g.
>assume in the worst case that an authorized person installs a shared key.
> But this is not a reasonable assumption in homenets, however, owing to
>the differences of homenets from enterprise, government, military and
>other environments where there typically is a single authority and active
>management of the network.  Thus, authorization is an unavoidable topic
>for Homenet, but the HNCP draft is probably not the place for that.
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Sep 2014 13:20:26 -0400

> This can also be automated (for first-hop wireless). However, in the
    > ‘what-if’ land, wired -> wireless bridges, and wireless -> wireless
    > extenders that do things insecurely cannot be detected.

Yes, I agree.
Let me restate that I think we can "securely" to do TOFU across the wired
link.  If that link turns into something less secure, then that's okay.

    > - On wired links: opportunistic IKEv2 attempt, fallback to non-IPsec
    > (if no IPsec available? if no key?), and update the SPD dynamically
    > based on successful IKEv2 attempts.

    > That is interesting scheme. Implementation-wise, it sounds somewhat painful though.

yes, I agree that it's probably difficult with the available implementation of openwrt
IKEv2 daemons...  I don't think it's architecturally that hard.

    > access these days is wireless)

yes, agree.  And if they have multiple routers, they likely have the same WPA2-PSK.

    > - admin password (for those user actually has access to, and are not
    > part of some super-fancy PKI scheme for authenticating administrator)

I'm less thrilled about using the admin password.  They have less likely hood
of being changed, and ideally, they are encrypted/hashed in a way that the
raw password can't be seen.

    > Hmm. I wonder if that assumption would work bidirectionally,
    > though. That is, the not-key-knowing router sending plaintext traffic,
    > and the others using the information? If so, what is the value of
    > having the (optional) authentication at all?

    > If assumption is not bidirectional, then the distributed algorithms
    > would not work very well over such protocol - unless the
    > unauthenticated messages were just used for bootstrapping the trust
    > somehow, but it is not clear to me how that would happen either. Of
    > course, they could be used to show user some error (if the router
    > actually had UI of some kind) but not much else that I can see.

That's what I would suggest: unauthenticated messages are to bootstrap trust.
Possibly that involves an item on a web page saying, "Router XYZ wants to
join Stenberg House, permit Y/N", perhaps can flash "attention" LED on front.

That would only be used if the network had been set to paranoid secure,
and/or if the wired-TOFU didn't work.

    > ’something’ without TOFU too?

I agree; but I think that TOFU would be useful here, particularly if the
router isn't wireless capable.  Maybe it is a bridge to the LLN, etc.
Maybe that router has wireless, but it's a different wireless and does not
share the same ESSID (cf: Fred's house requirements from IETF76 or something)

    > - (HNCP) unicast works with (opportunistic) IKEv2 or manual key fine
Agreed.

    > - (HNCP) multicast works with manual key, but currently is not used for
    > anything sensitive (just change detection mechanism, actual state
    > changes done via unicast due to multicast size limit)

Agreed.

    > => From my point of view, plaintext multicast + unicast IKEv2 with
    > (opportunistic) authentication would be perfectly fine too. And as long
    > as confidentiality is not desired for the traffic, security properties
    > would be actually better than for manually keyed IPsec.

Also agreed.

    > If confidentiality is desired, equation changes; however, even when
    > using manually keyed IPsec, the fact that there _are_ changes in
    > network topology cannot be hidden, from traffic analysis, so I am not
    > sure if it is significantly different outcome from the
    > confidentiality-only-on-unicast.

Given that we are talking about routers/switches that probably have direct
ethernet to wired computers, (and the router controls the promisc of the
switch) and have WEP/WPA on wireless links,  I would suggest further
confidentiality against end-hosts is redundant.

    > I think use of link-local multicast is perfectly fine. Their cable
    > modems SHOULD/MUST configure the cable interface as external in any
    > case, which has both firewalling implications as well as no HNCP or
    > routing protocol traffic on the interface.

yes.

    > Fully bridging cable modems are different beast, but even in their
    > case, if the border detection works fine (=there is PD prefix or IPv4
    > DHCP available there), the HNCP implementations should treat the
    > interface as external based on autodetection in any case.

Also agreed.
I have some concerns with that some PPPoE/DSL deployments might leak unicast
ethernet packets between houses, but no evidence that this is the case.  That
interface would be dubious to be an internal interface as it has the PPPoE on
it, and this is perhaps a case where an override would be desired if the home
owner really needs that ethernet port.

    > 3. {manual keys, certs, something else} IKEv2 on unicast, ignore
    > multicast (and write in draft no state exchange based on multicast,
    > just change notification)

    > 4. opportunistic variant of the above, with e.g. self-signed certs, and
    > leap of faith happening on interface type

    > 5. web of trust in HNCP (Xavier’s draft).  The current form of _that_
    > draft, for the record, is not really final from my point of view but
    > I’m talking more about the general idea.

    > [4] scheme in and of itself would have no way of transmitting ’these
    > are self-signed certs I trust’ to other nodes it does trust. Therefore,
    > if we want to do things in opportunistic way, [5] > [4] in terms of
    > user experience, as it would share the trust state across the whole
    > home network _using already trusted node set_, and therefore the number
    > of ‘pairings’ in the opportunistic scheme would be less. Of course, web
    > of trust could be also be based on CA hierarchy or whatever, so it is
    > definitely the flexible choice. However, it does imply quite a bit of
    > changes to HNCP draft too (or extra draft as it is currently).

    > That said, I personally like [1]-[3], and [4]/[5] seem complex.

I think that the words "manual keys" is confusing.
In [2] you mean an IPsec Multicast key Keyed using a Key Derived from the WPA2-PSK.
Perhaps we need to make up a TLA for that.... IMKDW.  (If you know the
Sandler film "Jack/Jill", that reminders of of "I'm Kidding/I'm Kidding", but
I'm not)

In [3] one uses the same WPA2-PSK to derive a key to authenticate the IKEv2
session (I mean using the "Shared Key Message Integrity Code").  Perhaps we
want to use that to bootstrap to a self-signed or raw public.  There are
advantages to leaving the WPA2-PSK behind, and there is also the TOFU and
pre-configured cases such that it would make more sense to normalize things.

(Now, I'll go read the other 39 messages in this thread)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Sep 2014 13:22:27 -0400

Mark Townsley <[email-masked]> wrote:
    > My own experience attempting to use IPsec as an add-on security
    > solution (a.k.a. "pixie dust) for a protocol isn't all that
    > positive. We tried that with L2TP, and in the process failed to kill
    > off PPTP on windows clients. I can't tell you how many times over the
    > years I've had to point people to the Windows Registry setting to
    > disable IPsec with L2TP. OSPFv3 is another one where I get complaints
    > about requiring IPsec. So, I agree with Ted; We should be wary of
    > falling into the trap of using IPsec just because it is there.

That's a poor example for several reasons that have nothing to do with HNCP,
and so I won't go into them here.  (and I do have tons of L2TP code in the
field, sadly)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Sep 2014 13:23:47 -0400

> I wouldn't really want to lock HNCP to any trust scheme at this point where
    > we are not even sure what we want. I'd rather choose the underlying
    > mechanism, either DTLS or IPsec/IKE and leave the rest out-of-scope. Maybe
    > mention PSK-usage as baseline option and say various other certificate-based
    > approached are possible but out-of-scope of the HNCP draft itself.

With respect,  if you leave the trust scheme out of scope, what you are
really doing is leaving all of the security out of scope, because it won't be
deployable.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Sep 2014 13:42:36 -0400

> really doing is leaving all of the security out of scope, because it won't be

+1

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 23 Sep 2014 17:56:17 +0000

> yes, agree.  And if they have multiple routers, they likely have the same

Possession of the WPA2 passphrases authorizes access to that particular Wi-Fi network -- nothing more and nothing less. And they authenticate nothing (because they are shared). 

If the concern is with a man-in-the-middle attack on HNCP messages, then point-to-point security, using encryption with any key that the 2 endpoints can agree on (such as simple TLS with HTTP digest authentication) makes sense. This is just about making sure the endpoints remain the same over the course of messaging and that nothing inserts itself into the conversation (or overhears the conversation). If the desire is to ensure endpoints can be identified over the course of many conversations, then consistently-used self-generated keys are sufficient. Because WPA2 passphrases are shared, they are useless here.

If the goal is to know whether an endpoint is authorized to send/receive a HNCP message WPA2-PSK is also useless. It authorizes no such thing. Users should be free to run HNCP in a manner that requires no explicit authorization. If explicit authorization to run HNCP is desired by the user, then such authorization must come from a person with physical access to the home network and its devices, and such authorization must be specific to the running of HNCP and/or a role in home network configuration.

But to be honest, I have no clue what the potential HNCP attacks and vulnerabilities (and security goals) are. What does HNCP security need to protect against? I agree that documentation of overall homenet threats and vulnerabilities isn't what's needed to understand specific HNCP threats and vulnerabilities. But is there a plan to document these for HNCP?
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Sep 2014 16:05:35 -0400

STARK, BARBARA H <[email-masked]> wrote:
    > If the concern is with a man-in-the-middle attack on HNCP messages,
    > then point-to-point security, using encryption with any key that the 2

The concern is man-in-the-middle "attacks" on HNCP messages by an outsider,
not another member of the household.  Or, more specifically, the outsider
being a misconfigured (physical) neighbour.

Possession of the WPA2 passphrase means that the router is part of my home.

    > If the goal is to know whether an endpoint is authorized to
    > send/receive a HNCP message WPA2-PSK is also useless. It authorizes no
    > such thing. Users should be free to run HNCP in a manner that requires
    > no explicit authorization. If explicit authorization to run HNCP is
    > desired by the user, then such authorization must come from a person
    > with physical access to the home network and its devices, and such
    > authorization must be specific to the running of HNCP and/or a role in
    > home network configuration.

What do you mean by "user" here.  Last I checked, my wife is a user, and I'm
sure that neither her person, nor her mobile phone, nor her chrome book need
to run HNCP.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Sep 2014 07:56:33 +0200 (CEST)

On Fri, 19 Sep 2014, Mark Townsley wrote:

> My own experience attempting to use IPsec as an add-on security solution 
> (a.k.a. "pixie dust) for a protocol isn't all that positive. We tried 
> that with L2TP, and in the process failed to kill off PPTP on windows 
> clients. I can't tell you how many times over the years I've had to 
> point people to the Windows Registry setting to disable IPsec with L2TP. 
> OSPFv3 is another one where I get complaints about requiring IPsec. So, 
> I agree with Ted; We should be wary of falling into the trap of using 
> IPsec just because it is there.

As far as I can see, there are 2 ways of doing security. Either each 
protocol does its own security completely (both auth and encryption), or 
we have generic ways of doing these. The generic ways can be either a new 
protocol and method, or a method that any protocol can use, so at least 
the method is standard.

What I have seen so far, it seems most implementations are doing things 
from scratch, but with known methods, but with little code re-use?

What I would like to see is an implementation that is generic, but perhaps 
where the information is carried over a lot of different protocols, for 
instance HNCP, ND and others.

There is no security and zero configuration at the same time. It just 
doesn't work. I still think we need user intervention to set policy for 
each device. "What trust do I put in this device and what role should it 
have" is something the user has to answer. The result of this answer sets 
policy for the devices in relation to this new device. This has to be 
really simple and easy to use. Since a lot of people have smartphones 
nowadays, I still think that the device popping up in an App they have, 
and then configuring it there, is the best way. Perhaps in combination 
with some kind of device key fingerprint using QR codes or alike to really 
make sure this is the device you're trying to configure policy for.

So my proposal is that we make HNCP capable of using several methods, one 
is unsecure, one is secure by means of a shared secret, and then add other 
optional methods using PKI that would enable the above mentioned "accept 
each device manually" more secure way.

On paper it still seems IPSEC should be able to do this (I mean, isn't 
this what Microsoft does with Direct Access, ie run IPSEC and have keys 
handled by AD? From a theoretical level, it seems bad that we can't 
implement generic security and then let other protocols run on top of 
that. What is it that IPSEC is lacking? Is it the key/auth exchange that 
is lacking?

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 24 Sep 2014 11:36:57 +0300

On 24.9.2014, at 8.56, Mikael Abrahamsson <[email-masked]> wrote:
> On paper it still seems IPSEC should be able to do this (I mean, isn't this what Microsoft does with Direct Access, ie run IPSEC and have keys handled by AD? From a theoretical level, it seems bad that we can't implement generic security and then let other protocols run on top of that. What is it that IPSEC is lacking? Is it the key/auth exchange that is lacking?

Big problem with IPsec + ‘any protocol’ is that it does not work _that_ well with multicast. Certainly, you can use manually keyed (static) IPsec SAs (although in case of Linux, out of the box, it does not work either but is easy to patch), but they have somewhat worse security properties, main things being lack of replay protection and fixed key used for crypto. 

You cannot really bootstrap them from anything else than that, though, which is a problem.http://tools.ietf.org/wg/msec/ attempted to address this, but I have not really seen it in the wild as open source (for example, no support in StrongSwan[1]). (Cisco did GDOI in e.g. DMVPN at least.)

-Markus

P.S. I’d like to be proven wrong on this front - ‘just use IKE+IPsec’ is a good story, but without equivalently good (in terms of what is used for auth*, and how secure it is) support for both unicast and multicast, I do not really think it applies as-is to anything that makes decisions that matter also based on multicast packets.

[1] https://wiki.strongswan.org/projects/strongswan/wiki/IpsecStandards

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 24 Sep 2014 11:07:28 +0200 (CEST)

On Wed, 24 Sep 2014, Markus Stenberg wrote:

> Big problem with IPsec + ‘any protocol’ is that it does not work _that_ 
> well with multicast. Certainly, you can use manually keyed (static) 
> IPsec SAs (although in case of Linux, out of the box, it does not work 
> either but is easy to patch), but they have somewhat worse security 
> properties, main things being lack of replay protection and fixed key 
> used for crypto.

How does multicast work at all with replay-protection? I am not a crypto 
guy, but is there any way of doing multicast and not have this problem?

Is there something else that'll work as transport layer security for 
multicast, or should we send a request for the IETF leadership to 
investigate if this is something that needs to be developed?

I just can't help seeing this problem popping up all over the place and 
everybody solving it by writing their own code and doing their own 
implementation. IPSEC isn't widely used because it doesn't have ports so 
it can't be NATed (so its now run over UDP to workaround that problem) and 
also because key management is hard because keys are managed by the 
operating system and not by the application?

So, do we need a mix between IPSEC and TLS that can be done on a 
per-application level, but it's still a generic framework so that someone 
can develop generic code that projects like HNCP can use, for instance by 
linking to libraries?

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 24 Sep 2014 12:20:39 +0300

On 24.9.2014, at 12.07, Mikael Abrahamsson <[email-masked]> wrote:
> How does multicast work at all with replay-protection? I am not a crypto guy, but is there any way of doing multicast and not have this problem?

Well, effectively per-source replay window _and_ rekeying to make e.g. system restarts not be vulnerable to this. I don’t remember how GSA in msec was specified anymore, but it is not intractable problem (at least in theory). It has been many years since I read msec work though.

> Is there something else that’ll work as transport layer security for multicast, or should we send a request for the IETF leadership to investigate if this is something that needs to be developed?

There is not that I know of. 

I believe msec work is somewhat outdated (based on IKEv1, and not widely deployed), but security isn’t popular, and multicast isn’t popular, so combining them is not usually win in IETF. (And especially in seeing them implemented - still not sure how many msec implementations there has been.)

> I just can't help seeing this problem popping up all over the place and everybody solving it by writing their own code and doing their own implementation. IPSEC isn't widely used because it doesn't have ports so it can't be NATed (so its now run over UDP to workaround that problem) and also because key management is hard because keys are managed by the operating system and not by the application?
> 
> So, do we need a mix between IPSEC and TLS that can be done on a per-application level, but it’s still a generic framework so that someone can develop generic code that projects like HNCP can use, for instance by linking to libraries?

TLS + (pure) multicast is more or less impossible. You could probably define pure-multicast key negotiation scheme too using multi-party D-H (for example), but I am not sure if there is any standard protocols for that. Still, it would not look like TLS so calling it e.g. MTLS would be somewhat misleading. You could use some packet encoding features, but that would be that.

I guess you could do some sort of msec GDOI-like solution for it too - perform unicast exchanges using something like DTLS encoding of TLS handshakes to agree on multicast encryption key to be used on DTLS-ish ESP-ish UDP multicast traffic with per-source replay windows. 

Cheers,

-Markus

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Sep 2014 12:38:06 +0200

> On Sep 23, 2014, at 7:22 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Michael,

Back in '97 or so, the IETF weighed draft-ietf-pppext-l2tp-sec vs. L2TP+IPsec, and chose the latter (now RFC 3193). Some of this thread reminds me of discussions we had at that time, not just HNCP+IPsec vs. "HNCPsec" on the wire, but also whether we consider key config and such within HNCP alone or more holistically. 

Everyone has their own reference historical points to draw from, that was just my own. Sorry it didn't work for you!

Cheers,

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Sep 2014 14:01:34 +0200

Thank you for all of the discussion on this important topic. 

Without declaring consensus on how far we should go scope-wise in terms of overall homenet security just yet, I'd like to know if, in terms of HNCP itself from a bits-on-the-wire protocol perspective, can we adopt this proposal proposal from Mikael? If yes, please say so. If no, please say why not (and even better if you can propose text that would alleviate your concern). 

Mikael Abrahamsson wrote:

> So my proposal is that we make HNCP capable of using several methods, one is unsecure, one is secure by means of a shared secret, and then add other optional methods using PKI that would enable the above mentioned "accept each device manually" more secure way.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Sep 2014 06:49:36 -0700

On 09/24/2014 05:01 AM, Mark Townsley wrote:
> Without declaring consensus on how far we should go scope-wise in 
> terms of overall homenet security just yet, I'd like to know if, in 
> terms of HNCP itself from a bits-on-the-wire protocol perspective, can 
> we adopt this proposal proposal from Mikael? If yes, please say so. If 
> no, please say why not (and even better if you can propose text that 
> would alleviate your concern).

No. 1) Unsecured is unacceptable. 2) Pre-shared keys suck, and don't 
addresses the authz problem. 3) PKI in the traditional
sense (eg certs) is an anti-goal.

The approach should be a more modern "start by using (naked) public keys 
as a tool to facilitate the enrollment problem that
homenet MUST solve for, and produce solutions that address the security 
threats, littleconf needs, and low-clue nature of homenets."

Mike, uncaffeinated

>> So my proposal is that we make HNCP capable of using several methods, 
>> one is unsecure, one is secure by means of a shared secret, and then 
>> add other optional methods using PKI that would enable the above 
>> mentioned "accept each device manually" more secure way.
>
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Sep 2014 09:57:32 -0400

Mark Townsley <[email-masked]> wrote:
    > Without declaring consensus on how far we should go scope-wise in terms
    > of overall homenet security just yet, I'd like to know if, in terms of
    > HNCP itself from a bits-on-the-wire protocol perspective, can we adopt
    > this proposal proposal from Mikael? If yes, please say so. If no,
    > please say why not (and even better if you can propose text that would
    > alleviate your concern).

It is essentially identical to what I am proposing.

I would motify slightly:
   1) the I in "PKI" is inappropriate.
   2) not-yet-secure nodes should be able to listen to secured traffic.

    >>one is unsecure, one is secure by means of a shared secret, and then add
    >>other optional methods using PKI that would enable the above mentioned
    >>"accept each device manually" more secure way.

---

From: Steven Barth <[email-masked]>
Date: Wed, 24 Sep 2014 16:00:58 +0200

> would alleviate your concern).

ACK. It's similar to my own proposal regarding bits-on-the-wire anyway.

Maybe adding that we should try to use an existing and well-tested 
mechanism unless there is a very good reason not to.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Sep 2014 10:05:52 -0400

On Sep 24, 2014, at 10:00 AM, Steven Barth <[email-masked]> wrote:
> Maybe adding that we should try to use an existing and well-tested mechanism unless there is a very good reason not to.

I don't think there is one, but if you think there is you should tell us!   :)

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Sep 2014 14:19:10 +0300

Markus Stenberg writes:
> > Is there something else that’ll work as transport layer security
> > for multicast, or should we send a request for the IETF leadership
> > to investigate if this is something that needs to be developed? 
>
> I believe msec work is somewhat outdated (based on IKEv1, and not
> widely deployed), but security isn’t popular, and multicast isn’t
> popular, so combining them is not usually win in IETF. (And
> especially in seeing them implemented - still not sure how many msec
> implementations there has been.)

There is also ikev2 version of group key management
(draft-yeung-g-ikev2), but the draft seems to have expired some time
ago. I still think it was supposed to be published.

If homenet needs multicast support then it might be good idea to push
that document forward. 

> > I just can't help seeing this problem popping up all over the
> > place and everybody solving it by writing their own code and doing
> > their own implementation. IPSEC isn't widely used because it
> > doesn't have ports so it can't be NATed (so its now run over UDP
> > to workaround that problem) and also because key management is
> > hard because keys are managed by the operating system and not by
> > the application?

NATs should not be problem here in the homenet, I would assume all
this runs inside the home, and the boxes in homenet are not going to
do nat for ipv6 addresses... 

> > per-application level, but it’s still a generic framework so that
> > someone can develop generic code that projects like HNCP can use,
> > for instance by linking to libraries?

I do not think replacing the IKEv2 with TLS would help at all. If you
go for application level protection then using DTLS or similar is
better than getting ESP involved at all. 

> TLS + (pure) multicast is more or less impossible. You could
> probably define pure-multicast key negotiation scheme too using
> multi-party D-H (for example), but I am not sure if there is any
> standard protocols for that. Still, it would not look like TLS so
> calling it e.g. MTLS would be somewhat misleading. You could use
> some packet encoding features, but that would be that.

If secure multicast is needed, I think going for the g-ikev2 and ESP
would most likely be best way. The g-ikev2 specification is as far as
I can see ready, so it should be something that can be published quite
soon. It will run over separate port from normal IKEv2, so it can be
deployed quite easily (meaning it does not mess up existing IPsec in
the box), and as msec was not really very widely deployed the changes
that the box already has exsiting msec implementation running on that
port, is small.

> I guess you could do some sort of msec GDOI-like solution for it too
> - perform unicast exchanges using something like DTLS encoding of
> TLS handshakes to agree on multicast encryption key to be used on
> DTLS-ish ESP-ish UDP multicast traffic with per-source replay
> windows.  

If I remember right g-ikev2 supports multiple group key management
protocols and allows download keys from the group controller / key
server (GCKS) using IKEv2 to the devices. 
-- 
[email-masked]

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 29 Sep 2014 10:39:16 +0300

> ago. I still think it was supposed to be published.

Ah, interesting, did not know about that. Thanks ;)

> If homenet needs multicast support then it might be good idea to push

How does this solution work with e.g. link-local-only littleconf-TOFU setup?

To be more precise, I am not sure which node would be GCKS, and how other nodes would find that node. Based on cursory read of the draft, it seems to assume that non-GCKS nodes know GCKS address in advance.

> better than getting ESP involved at all. 

DTLS has rather sad multicast story too (=manually keyed IPsec without IPsec and draft-only at the moment). Of course, whether or not we really have to secure multicast at all in case of HNCP is debatable. However, as a general solution, it is somewhat lacking, as leveraging same thing for e.g. bit more multicast-heavy routing protocols would not work in case of DTLS (then again, I am not sure if GDOI / G-IKEv2 are much better due to them being mostly draft-only vaporware at this point).

Cheers,

-Markus

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Sep 2014 08:50:20 +0100

Hiya,

I've not really been following this discussion sufficient
to comment in general, but just on this part...

On 29/09/14 08:39, Markus Stenberg wrote:
> DTLS has rather sad multicast story too 

The DICE WG [1] have also been discussing potential issues
with DTLS and multicast. That discussion has turned out
harder than envisaged in that the WG originally figured
a simple extension to the DTLS reccord layer might suffice
to get useful security when DTLS packets are sent via IP
multicast. Turns out to be less easy than that.

Anyway, if this WG do end up needing some multicast security
and are looking at DTLS it would be very good to co-ordinate
with the DICE WG.

Sooner would be much better than later for that as the DICE
WG are right now in the process of (re-)considering whether
they can in fact meet their chartered goals on this topic.

Thanks,
S.

[1] https://tools.ietf.org/wg/dice/

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 29 Sep 2014 14:57:17 +0300

> How does this solution work with e.g. link-local-only

I have no idea what littleconf-TOFU setup looks like, so cannot
comment.. 

> To be more precise, I am not sure which node would be GCKS, and how
> other nodes would find that node. Based on cursory read of the
> draft, it seems to assume that non-GCKS nodes know GCKS address in
> advance. 

As the G-IKEv2 uses IKE_SA_INIT from the IKEv2 for the first exchange,
the RFC5685 IKEv2 redirect with anycast address (see section 4 of
RFC5685) would work with it just fine.

I.e. the new device wanting to know the GCKS to talk to would send
anycast IKEv2 packet to the network:

       Initiator                    Responder (any VPN GW)
       ---------                    -------------------------

    (IP_I:500 -> ANYCAST:500)
    HDR(A,0), SAi1, KEi, Ni)   -->
    N(REDIRECT_SUPPORTED)

                              (ANYCAST:500 -> IP_I:500)
                          <-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)

(with G-IKEv2 the port number would be the normal G-IKEv2 port, i.e.
848, not 500).

I.e. now the router listening this link can reply to the anycast
request, with the proper gateway address (which might be his own, if
he is the one acting as GCKS).

The anycast support for redirect was meant to be used for
bootstrapping cases, i.e. where the client does not know yet who to
talk to. 

> DTLS has rather sad multicast story too (=manually keyed IPsec
> without IPsec and draft-only at the moment). Of course, whether or
> not we really have to secure multicast at all in case of HNCP is
> debatable. However, as a general solution, it is somewhat lacking,
> as leveraging same thing for e.g. bit more multicast-heavy routing
> protocols would not work in case of DTLS (then again, I am not sure
> if GDOI / G-IKEv2 are much better due to them being mostly
> draft-only vaporware at this point). 

At least the G-IKEv2 stuff is there, and the actual ESP use of
multicast has been defined for manual keys for quite long time (and is
in the RFCs already, not only drafts).

I have no idea if there is any implementations about the G-IKEv2, but
I doubt that there is anything to protect multicast ready now... 
-- 
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Sep 2014 08:58:28 -0400

> they can in fact meet their chartered goals on this topic.

Unfortunately I think at this point we are distracted by a discussion about whether to use nails or screws when we haven't settled on what kind of house we're building.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Sep 2014 14:16:10 +0100

On 29/09/14 13:58, Ted Lemon wrote:
>> Sooner would be much better than later for that as the DICE WG are
>> right now in the process of (re-)considering whether they can in
>> fact meet their chartered goals on this topic.
> 
> Unfortunately I think at this point we are distracted by a discussion
> about whether to use nails or screws when we haven't settled on what
> kind of house we're building.

Understood. And I don't want to side-track you here.

However, if your house is such that it only requires
confidentiality and data integrity of messages between
group members, but does not require origin authentication
that that'd be useful to know. What I mean by origin
authentication here is the ability for the receiver of a
multicast message to cryptographically verify exactly which
member of the group has sent a message.

If, OTOH, you can say that you would in fact also require
origin authentication, then that is also of interest. (It'd
mean that your use case could not be met by the initially
chartered work for DICE, and that factoid could be helpful
in figuring out how to handle the DICE work.)

Cheers,
S.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Sep 2014 09:24:16 -0400

> in figuring out how to handle the DICE work.)

I think we definitely need origin authentication, but I am skeptical that we need multicast TLS.   I guess if we had it it might work, though.   But I'm not convinced it's the right model.   So I'd hate to have you guys go off and invent something cool that winds up not matching the eventual design.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 29 Sep 2014 08:23:11 -0700

> I think we definitely need origin authentication, but I am skeptical that we need multicast TLS.   I guess if we had it it might work, though.   But I'm not convinced it's the right model.   So I'd…

Why might we need *in-session* origin authentication? I'm not 
questioning it, just trying to
understand the threats/requirements.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Sep 2014 11:37:17 -0400

Ted Lemon <[email-masked]> wrote:
    >> If, OTOH, you can say that you would in fact also require origin
    >> authentication, then that is also of interest. (It'd mean that your
    >> use case could not be met by the initially chartered work for DICE,
    >> and that factoid could be helpful in figuring out how to handle the
    >> DICE work.)

    > I think we definitely need origin authentication, but I am skeptical
    > that we need multicast TLS.  I guess if we had it it might work,
    > though.  But I'm not convinced it's the right model.  So I'd hate to
    > have you guys go off and invent something cool that winds up not
    > matching the eventual design.

I think that it useful if we have a simple way to authenticate the
multicast'ed communication, but I think it is acceptable to form point to
point (unicast) security associations to get the origin authentication.

The communication might go like:
    MULTICAST     DrNick: HEY EVERYBODY, I got a new PREFIX to share!
    UNICAST       Homer to DrNick: mmmm... PREFIXES.. can I have some?
    UNICAST       DrNick to Homer: sure, not a problem!

[If that sounds like DHCPv6....]

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 29 Sep 2014 20:50:53 +0300

> I have no idea what littleconf-TOFU setup looks like, so cannot

Guess I’ll come over and discuss this at some point (not sure how much you have followed the 100+ message thread here).

>       Initiator                    Responder (any VPN GW)

Hmmh. In G-IKEv2 case, I am not sure if it is this simple. Because ultimately you want there to be only one GCKS (per link), but at boot time, there is lots of raciness about who comes up first, and decides they are one. 

i.e.

router 1 boots up
-> anycast 
(no reply)

~at same time router 2 boots up
-> anycast
(no reply)

both think they can be the GCKS. I suppose one could define some robust mechanics to make sure that ultimately you have only one and/or share state between them so that it does not matter?

Cheers,

-Markus

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 30 Sep 2014 11:53:08 +0300

Markus Stenberg writes:
> Guess I’ll come over and discuss this at some point (not sure how
> much you have followed the 100+ message thread here). 

I have skimmed through some of the emails, but not that well, so the
security model of the bootstrap process is still unclear for me (I am
not sure if it clear for anybody). 

> Hmmh. In G-IKEv2 case, I am not sure if it is this simple. Because
> ultimately you want there to be only one GCKS (per link), but at
> boot time, there is lots of raciness about who comes up first, and
> decides they are one.  
> 
> i.e.
> 
> router 1 boots up
> -> anycast 
> (no reply)
> 
> both think they can be the GCKS. I suppose one could define some
> robust mechanics to make sure that ultimately you have only one
> and/or share state between them so that it does not matter? 

I think there needs to be some kind of voting process to select the
master for each network. This is something that is not really part of
the multicast security or security in general, it needs to be defined
by the homenet. Also the problem is not just simultaneous boot, but
also partitions and reconnects, i.e. when someone unplugs ethernets
and partitions the home network in two parts, both of the parts still
need to function, i.e. both of parts need to make sure each of them
have one master. When user then plugs them back together there is need
to select new one.

I do not know if that can be combined to the routing information, i.e.
routers will know when the links go down and start the process of
making sure connected parts of the network is served by master, and
starting corrective actions when new links are connected. The
corrective operations would most likely be run over unicast, i.e. when
new network is connected the two parts have different multicast keys,
so those cannot be used, so the master of network 1 could simply
connect master of network 2 and they could agree who continues to be
master, redistribute new keys, and rekey peers multicast keys so the
whole new network has common keys.

G-IKEv2 and IKEv2 or whether security protocol is used there, are just
tools for such protocol, I do not think that protocol should be part
of the the security protocol.
-- 
[email-masked]