Subject: Re: [homenet] Next steps for draft-behringer-homenet-trust-bootstrap?

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 14 Mar 2013 15:40:05 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tim Chown
> Sent: 13 March 2013 16:36
> To: [email-masked] Group
> Subject: Re: [homenet] Next steps for draft-behringer-homenet-trust-
> bootstrap?
> 
> On 5 Mar 2013, at 17:52, Michael Behringer (mbehring)
> <[email-masked]> wrote:
> 
> > Our draft shows a way to do that in a relatively simple and secure way. I
> believe this is a fundamental requirement in a homenet; there are other
> ways to more or less achieve this goal - that needs to be discussed. But we
> should have the discussion.
> 
> If you have text to propose for the arch text, please do so.

There will be cases where two homenets are adjacent, or where a visitor plugs in a device that doesn't belong to the homenet. We need to be able to control that. 

I suggest a subsection in the security section (3.6) to address this. This could sound something like: 

--
3.6.6. Device ownership

There must be a way to administratively assert whether a device belongs to a homenet or not. The goal is to allow the establishment of borders, for example between two adjacent homenets or between the service provider and the homenet; and to avoid unauthorized devices from participating in the homenet. 

The homenet architecture MUST support a way for a homenet owner to claim ownership of his devices in a reasonably secure way. This could be achieved by a pairing mechanisms, by for example pressing buttons simultaneously on an authenticated and a new homenet device. Or by an enrolment process, as described in [draft-behringer-homenet-trust-bootstrap].
--

Thoughts? 
Michael 

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 08:48:16 -0700

> I suggest a subsection in the security section (3.6) to address this. This could sound something like:

In today's world access control is gated at L2 via wpa or similar. Are you
suggesting that we have a L3 equivalent? In addition? In replacement?

Mike

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 14 Mar 2013 17:03:09 +0000

> From: Michael Thomas [mailto:[email-masked]]
[...]
> suggesting that we have a L3 equivalent? In addition? In replacement?

We need a solution to this problem. I think this is the first important thing to note, and so far it isn't noted (or I missed it). Which solution is open for discussion. 

Can we agree thus far? 

Then, the referenced draft [draft-behringer-homenet-trust-bootstrap] is what we were thinking about, high level. We're happy to work on a more detailed version of what we're proposing, but before we'd like to understand whether it's actually in scope or not? ;-) 

Michael

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 14:42:38 -0700

> We need a solution to this problem. I think this is the first important thing to note, and so far it isn't noted (or I missed it). Which solution is open for discussion.

Well, it seems to me that we have a solution today at L2, at
least for wireless which is the most pressing need. Am I missing
something? Or are talking about remote access into your homenet?

Mike

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 15 Mar 2013 00:16:20 +0000

> Sent: 14 March 2013 17:43
> To: Michael Behringer (mbehring)
> Cc: Tim Chown; [email-masked] Group
> >> In today's world access control is gated at L2 via wpa or similar.
> >> Are you suggesting that we have a L3 equivalent? In addition? In
> replacement?
> > We need a solution to this problem. I think this is the first important thing
> to note, and so far it isn't noted (or I missed it). Which solution is open for
> discussion.
> >
> > Can we agree thus far?
> 
> Well, it seems to me that we have a solution today at L2, at least for
> wireless which is the most pressing need. Am I missing something? Or are
> talking about remote access into your homenet?

No, it's not primarily for remote access. 

Even if we have something, the architecture doc should describe that this is an issue and needs to be addressed, and which solutions fit (including existing). 

But I think the need goes beyond wireless. If I have visitors, I may not like it if they plug in a device into the Ethernet socket in the guest room, and the device has full access to everything. I think we need a simple way to accept/deny a new device onto the network, independent of the media type. 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Mar 2013 08:09:26 +0000

> But I think the need goes beyond wireless. If I have visitors, I may not like it if they plug in a device into the Ethernet socket in the guest room, and the device has full access to everything. I…

And preferably a method that doesn't involve asking your visitor for her
MAC address, or giving her a password that you don't want to leak.

On the other hand, a Bluetooth-like method that involves opening access
for a few minutes while you automatically register the MAC address might
be good enough for home use (but unacceptable for professional use).

What is unlikely to work in the real world is a complex cryptographically
sound mechanism, even though it might be fun to design and debug.

    Brian

---

From: Robert Cragie <[email-masked]>
Date: Fri, 15 Mar 2013 11:04:39 +0000

On 14/03/2013 9:42 PM, Michael Thomas wrote:
>>> Are you
>> We need a solution to this problem. I think this is the first 
>> important thing to note, and so far it isn't noted (or I missed it). 
>> Which solution is open for discussion.
>>
>> Can we agree thus far?
>
L2 access is fine if the authenticator is one hop away. It won't work 
otherwise. We had this issue with mesh networks using RPL where 
authentication needs to be relayed through the existing network to the 
authenticator and access control is performed by RPL routers on the 
boundary of the network. We solved it using the PANA relay function (RFC 
6345). I also have some ideas for more complex network admission using 
multiple authenticators in a mesh network which could apply here. I will 
try and get the ideas down in a digestible form.

Robert

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 15 Mar 2013 11:12:19 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
[...]
> > But I think the need goes beyond wireless. If I have visitors, I may not like
> it if they plug in a device into the Ethernet socket in the guest room, and the
> device has full access to everything. I think we need a simple way to
> accept/deny a new device onto the network, independent of the media
> type.
> 

Before we dive into the solution space, Brian, do you agree that the framework draft should include this requirement? 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Mar 2013 11:48:42 +0000

> Before we dive into the solution space, Brian, do you agree that the framework draft should include this requirement? 

Yes, but I think that simplicity of deployment and management is part of the requirement.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 15 Mar 2013 11:50:52 +0000

> Behalf Of Brian E Carpenter
[....]
> > Before we dive into the solution space, Brian, do you agree that the
> framework draft should include this requirement?
> 

Absolutely agree!

Michael

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Mar 2013 11:49:38 -0700

On 03/15/2013 04:04 AM, Robert Cragie wrote:
> L2 access is fine if the authenticator is one hop away. It won't work otherwise. We had this issue with mesh networks using RPL where authentication needs to be relayed through the existing network to the authenticator and access control is performed by RPL routers on the boundary of the network. We solved it using the PANA relay function (RFC 6345). I also have some ideas for more complex network admission using multiple authenticators in a mesh network which could apply here. I will try and get the ideas down in a digestible form.

So I guess where this is going is "should AAA be a part of the homenet
architecture". Yes? (fsvo: AAA).

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Mar 2013 08:00:52 +0000

On 15/03/2013 18:49, Michael Thomas wrote:
>> boundary of the network. We solved it using the PANA relay function
>> (RFC 6345). I also have some ideas for more complex network admission
>> using multiple authenticators in a mesh network which could apply
>> here. I will try and get the ideas down in a digestible form.
> 

Yes for Authorisation. It's much less clear to me that (cryptographic)
Authentication is a requirement, and fairly clear to me that Accounting
isn't.

    Brian

---

From: Russ White <[email-masked]>
Date: Wed, 20 Mar 2013 08:47:40 -0400

>> Yes, but I think that simplicity of deployment and management is part of the

+1

One thing to think about --what if we just assumed some sort of layer 2
overlay used _only_ for control traffic among all the devices on the
network --or a layer 3 multicast group that was "location specific," in
some way?

A lot of the problems we seem to have here revolve around coordinating
what device is doing what, what services are available, where the edges
are, etc. Maybe if we could figure out a single control channel for all
devices on the network, whether it's by tagging on to the routing
protocol, or by setting up a well known local multicast group, or by
setting up a layer 2 "control channel," or even an "out of band
bluetooth control channel," or whatever, we could make progress using
the existence of a such a control channel as an underlying assumption?

Russ