Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <4ea05c82.8010...@isi.edu>
Joe Touch writes:
 
> Hi, Curtis,
>  
> On 10/19/2011 8:50 PM, Curtis Villamizar wrote:
> ...
> > We want to assume that *all* AP are configured as routers except the
> > legacy ones that want to be a dumb bridge with NAT to one port.
>  
> AFAICT, you want to assume that:
>  
> - all AP routers are configured as per homenet
>  
> - all other APs are bridges only
>  
> I.e., if IP routing is supported then homenet is supported.
>  
> I would prefer if that were true, but I don't think it's a reasonable 
> assumption to make in an home environment, because...

Possible confusion here due to overload of the word "configured".

All AP routers which are capable as per homenet are zero config
routers out of the box.

Hope that all legcacy stuff is bridges only, but recognized that some
may insist on trying to NAT on one port.

Note that some product is so stupid as to always announce default
route to the "LAN side", even with nothing connected on the uplink
port (and then blackhole the traffic) and won't let a default route be
configured or accepted by a routing protocol on any port except the
designated uplink.  Being backward compatible with anything that
stupid may not be possible.  Grandma may have to toss that one in the
recycle bin.

> >>> On BSD and I suspect Linux as well, the default for:
> >>>
> >>> net.inet.ip.forwarding
> >>> net.inet6.ip6.forwarding
> >>>
> >>> are both zero.
> >>
> >> Right, but that cannot be the default for a homenet box.
> >
> > You are mixing the discussion of what we want in routers with what we
> > don't want enabled by default in every *legacy* PC, toaster and coffee
> > maker.  If the coffee maker is a competent IPv6 router with extensions
> > to let it autoconfig, then let it be a router.
>  
> I would like to make the same assumption, but we all know that Linux 
> doesn't listen to the IETF standards. For any Linux parameter, we ought 
> to assume that it *will* change and we need to deal with it.

sysctl is meant for changing it.

> Since Linux is used in even dumb APs, that means that "future legacy" 
> (i.e., non-homenet) APs *will* end up routing at some point, and will 
> not support homenet.

Today's dumb(est) APs that run Linux NAT and bridge or just bridge.
If the box says router it does NAT (and is useless IMHO) if its just
an AP it bridges to it's (usually one) Ethernet.

Some of these NAT boxes run RIP on the "LAN side" and call that
routing and enable it by default.  Fortunately we can detect this
brain damage too.  If it speaks RIP only, it's not homenet aware.

> We need to deal with that eventuality too.
>  
> Joe

Maximizing backwards compatibility to all reasonable devices is
clearly one of the biggest challenges.  Some devices out there may be
just plain too braindead to work with unless the vendor can offer a
firmware upgrade and then I can't see Grandma loading a new flash
image on her router.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Joe Touch]

Hi, Curtis,

On 10/19/2011 8:50 PM, Curtis Villamizar wrote:
...

We want to assume that *all* AP are configured as routers except the
legacy ones that want to be a dumb bridge with NAT to one port.


AFAICT, you want to assume that:

- all AP routers are configured as per homenet

- all other APs are bridges only

I.e., if IP routing is supported then homenet is supported.

I would prefer if that were true, but I don't think it's a reasonable 
assumption to make in an home environment, because...



On BSD and I suspect Linux as well, the default for:

net.inet.ip.forwarding
net.inet6.ip6.forwarding

are both zero.


Right, but that cannot be the default for a homenet box.


You are mixing the discussion of what we want in routers with what we
don't want enabled by default in every *legacy* PC, toaster and coffee
maker.  If the coffee maker is a competent IPv6 router with extensions
to let it autoconfig, then let it be a router.


I would like to make the same assumption, but we all know that Linux 
doesn't listen to the IETF standards. For any Linux parameter, we ought 
to assume that it *will* change and we need to deal with it.


Since Linux is used in even dumb APs, that means that "future legacy" 
(i.e., non-homenet) APs *will* end up routing at some point, and will 
not support homenet.


We need to deal with that eventuality too.

Joe
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <4e9f3e69.90...@isi.edu>
Joe Touch writes:
 
> On 10/19/2011 12:30 PM, Curtis Villamizar wrote:
> >
> > In message<28269.1318994...@marajade.sandelman.ca>
> > Michael Richardson writes:
> >
> >>
> >>> "Curtis" == Curtis Villamizar  writes:
> >>  Curtis>  A WiFi AP will not connect to another AP and wireless
> >>  Curtis>  routers are typically AP by default.  So if two wireless
> >>  Curtis>  routers autoconfig to being AP and using open routing, then
> >>
> >> OUT OF THE BOX:  not every device plugged into a home network have
> >>  no prior configuration.  For instance, someone bringing a newsed
> >>  device to grandma's house.
> >
> > He who configures it needs to fix it.  Or press the factory default
> > button (if there is one).  The example is two AP.  Most AP can be
> > restored to factory default with a button press.
>  
> What happens if you have two of them and they're BOTH configured to boot 
> as the "master" home access point?


Master home access point?  What is that?  We are not talking about
today's primitive NAT boxes that pretend to be routers.

They either have a default route to the Internet or they don't.  If
they have a defailt route and they are at equal distance to that
default route, then there are some arbitrary tie breakers.

Worst case for AP might be if they are hard configed to the same
channel and are very close to each other so they have about the same
S/N and hosts can't decide which one to associate with, plus the
interference with each other.

In any case a press of the factory settings button should fix it.

> ...
> >>  Curtis>  there is only a risk if something that is an WiFi client is
> >>  Curtis>  also a configured to be a router.
>  
> Yes, but we want to assume that at least one of these will be configured 
> as a router as a default, which means we KNOW someone will turn on two 
> of them

We want to assume that *all* AP are configured as routers except the
legacy ones that want to be a dumb bridge with NAT to one port.

> > On BSD and I suspect Linux as well, the default for:
> >
> >net.inet.ip.forwarding
> >net.inet6.ip6.forwarding
> >
> > are both zero.
>  
> Right, but that cannot be the default for a homenet box.

You are mixing the discussion of what we want in routers with what we
don't want enabled by default in every *legacy* PC, toaster and coffee
maker.  If the coffee maker is a competent IPv6 router with extensions
to let it autoconfig, then let it be a router.

I really don't want my dumb old kitchen appliances trying to NAT for
each other.  But that new IPv6 espresso maker that knows how to act as
a router - that would be OK.  :-)

You lost the context.  You snipped out the statement I was replying
to.  A little too much trimming on the response.  It happens.

> Joe

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Joe Touch]

On 10/19/2011 12:30 PM, Curtis Villamizar wrote:


In message<28269.1318994...@marajade.sandelman.ca>
Michael Richardson writes:




"Curtis" == Curtis Villamizar  writes:

 Curtis>  A WiFi AP will not connect to another AP and wireless
 Curtis>  routers are typically AP by default.  So if two wireless
 Curtis>  routers autoconfig to being AP and using open routing, then

OUT OF THE BOX:  not every device plugged into a home network have
 no prior configuration.  For instance, someone bringing a newsed
 device to grandma's house.


He who configures it needs to fix it.  Or press the factory default
button (if there is one).  The example is two AP.  Most AP can be
restored to factory default with a button press.


What happens if you have two of them and they're BOTH configured to boot 
as the "master" home access point?


...

 Curtis>  there is only a risk if something that is an WiFi client is
 Curtis>  also a configured to be a router.


Yes, but we want to assume that at least one of these will be configured 
as a router as a default, which means we KNOW someone will turn on two 
of them



On BSD and I suspect Linux as well, the default for:

   net.inet.ip.forwarding
   net.inet6.ip6.forwarding

are both zero.


Right, but that cannot be the default for a homenet box.

Joe
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <28269.1318994...@marajade.sandelman.ca>
Michael Richardson writes:
 
>  
> > "Curtis" == Curtis Villamizar  writes:
> Curtis> A WiFi AP will not connect to another AP and wireless
> Curtis> routers are typically AP by default.  So if two wireless
> Curtis> routers autoconfig to being AP and using open routing, then
>  
> OUT OF THE BOX:  not every device plugged into a home network have
> no prior configuration.  For instance, someone bringing a newsed
> device to grandma's house.

He who configures it needs to fix it.  Or press the factory default
button (if there is one).  The example is two AP.  Most AP can be
restored to factory default with a button press.  Grandma may toss it
or call in a geek before figuring out some of the hidden "restore to
factory default" procedures like the unmarked "press, hold, and power
cylce while holding" trick.  This is sort of like the old BIOS that
had "secret" ways to get in, different across vendors.  They now have
a very clear "to enter BIOS do this" to avoid those support calls.

> Curtis> there is only a risk if something that is an WiFi client is
> Curtis> also a configured to be a router.
>  
> laptop, smartphone, wii, stereo mp3 player, ...


I don't have any windows systems or wii on hand (what's the plural of
wii, wiii?).  And my portable mp3 is (*really old* and only used
occasionally on an airplane and ..) USB only.  But ...

On BSD and I suspect Linux as well, the default for:

  net.inet.ip.forwarding
  net.inet6.ip6.forwarding

are both zero.

A router forwards IP traffic.  By default no routing protocols are
enabled on a host such as a BSD or Linux system.  Even if enabled, a
host may run a routing protocol but not forward packets not destined
to itself from one interface to another.  I would be surprised if any
of the devices you have listed above have forwarding enabled by
default today, except a smartphone which has been configured to act as
a WiFi hub (which itself is not a default).

If we define the zeroconf defaults well, then it would be OK if they
all forward.  As I pointed out in a prior email, the best routing
protocol for wired and the best for wireless may not be the same.

There will be legacy stuff and we can be compatible with it.  We can't
work in any arbitrarily misconfigured legacy environment, because you
can already make that not work without adding anything.  Even with
zeroconfig support, we can't work in any arbitrarily misconfigured
environment, and maybe the best we can do is provide better hints on
what is wrong.  [example: a graphical dump of addressing/routing.]

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Michael Richardson]

> "Curtis" == Curtis Villamizar  writes:
Curtis> A WiFi AP will not connect to another AP and wireless
Curtis> routers are typically AP by default.  So if two wireless
Curtis> routers autoconfig to being AP and using open routing, then

OUT OF THE BOX:  not every device plugged into a home network have
no prior configuration.  For instance, someone bringing a newsed
device to grandma's house.

Curtis> there is only a risk if something that is an WiFi client is
Curtis> also a configured to be a router.

laptop, smartphone, wii, stereo mp3 player, ...

-- 
]   He who is tired of Weird Al is tired of life!   |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video 
   then sign the petition. 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

On Oct 13, 2011, at 9:13 PM, Lorenzo Colitti wrote:
> I'd say that electrical systems are as susceptible to rogue devices just as 
> much as zeroconf routing systems are. If you plug a short into a socket, you 
> trip a circuit breaker and you deny service to other appliances (i.e., "your 
> house goes dark").

This is true, but I think I hear the sound of shrieking as you torture this 
poor analogy...   :)

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Lorenzo Colitti]

On Wed, Oct 12, 2011 at 05:33, Ted Lemon  wrote:

> The second reason is that electrical systems are essentially topology-free.
>   Any point on the system is essentially equivalent to any other.   This is
> not true of a home network with routing.   What we are talking about is
> essentially the possibility of rogue distribution panels intentionally or
> accidentally being connected to your distribution system.
>

I'd say that electrical systems are as susceptible to rogue devices just as
much as zeroconf routing systems are. If you plug a short into a socket, you
trip a circuit breaker and you deny service to other appliances (i.e., "your
house goes dark").
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Russ White]

>> It is best to find some reasonable ground where 90% of the people in
>> the world will find the security acceptable, and then let the 10% who
>> care configure the rest.
>>  
>> But I would also point out that the argument you're making can be
>> applied to applications as well as network gear.

> We are talking about whether to bring up routing.  The risk is theft
> of service.  This is like locking the screen door if the inside door
> deadbolt is already locked.

No, we're talking about what sort of reachability to provide once
routing is up.

> It is only an issue if the inside door has no locks or has very
> ineffective locks and even then locking the screen door doesn't really
> help much anyway.

I completely disagree. Even a screen door can be an effective component
of an overall security system. Having a system is the key, not a single
component that handles all security of all types in all situations.

:-)

Russ
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Russ White]

> Following that analogy, the door locks built my certain OS vendors are
> both flimsy and easily picked.
> 
> And we should not enable tftp and point it at the root directory and
> hope that some smart network appliance will somehow firewall us.

My point is that you need both. This is not an either/or situation, it's
a both/and situation. The network needs to provide some pieces of the
security, and the devices some more, and the applications some more.

Putting all your eggs in one basket will just mean a lot more broken
eggs in the end.

> The operations staff for the T3-NSFNET had no firewall and was
> security audited by some of the best in the field.  Of course we did
> not allow the use of a PC with Windows in operations.  No such thing
> could sit on the same subnet.

And you're willing to lend out that staff, free, to anyone and everyone
who needs a secure network?

Again, throwing the security problem at the application isn't a good
solution.

:-)

Russ

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

On Oct 13, 2011, at 7:02 PM, Curtis Villamizar wrote:
> And therefore risk there is mostly theft of service as I have already
> pointed out.

No, that is a side issue.   The risk is that two networks will self-configure 
into a single topology without being told to do so. 

> Some would call that a feature, not a failure mode.  :-)

Your optimism is charming.   However, the more likely case is that the network 
topology that automatically forms will not work, or will direct all traffic out 
a single internet link and go over someone's service limits.   And there will 
be nobody within shouting distance of this fiasco who will be qualified to even 
guess what might be happening, much less fix it.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <7d42549b-0ec1-463e-8e62-765c295a2...@fugue.com>
Ted Lemon writes:
 
> On Oct 13, 2011, at 5:23 PM, Curtis Villamizar wrote:
> > And I responded to that in the same email and you trimmed that part of
> > the response in this email.
>  
> The problem has to do with customer-owned devices and
> customer-neighbor-owned devices forming networks together.  It's got
> nothing to do with the ISP.  Chances are, the ISP link is the one
> thing that won't be gotten wrong here, because only one device you own
> will be connected to it (at least in typical networks today).

And therefore risk there is mostly theft of service as I have already
pointed out.

A WiFi AP will not connect to another AP and wireless routers are
typically AP by default.  So if two wireless routers autoconfig to
being AP and using open routing, then there is only a risk if
something that is an WiFi client is also a configured to be a router.

> Of course, if your devices unintentionally include your neighbor in
> the home network topology, your network will suddenly be multihomed,
> but this is an artifact of the failure mode I'm talking about.
> Eliminating that failure mode would solve the multihoming problem as
> well.

Some would call that a feature, not a failure mode.  :-)

But it usually does violate the service provider agreement and
therefore open routing (or bridging) over wireless creates a potential
theft of service.  Ignoring that AP don't talk to AP.

This is really an issue for wireless not for wired and is nothing new.
AFAIK all wireless products today ship "open" and configured as an
"AP" and have to be changed to enable some form of authentication.
And many users never bother to change this.

So what is new about a wireless router vs existing wireless bridges
that do this?

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ray Bellis]

On 11 Oct 2011, at 18:13, Stephen Farrell wrote:

> When various devices in the home figure out which does what,
> and do that periodically to handle changes, there's clearly
> the potential that a zombied host tries to try take over
> stuff with undesirable consequences.
> 
> My question is whether this group are planning to think
> about that now, or later, or never? (Or don't even think
> there's a problem worth attempting to address.)
> 
> Note - I'm not trying to argue for any particular level of
> security and certainly not for some unachievable fort knox
> everywhere, I'm just asking what's the plan?

We're certainly expecting to think about it.

However mandating any particular mechanism for how a device can identify itself 
as part of the "trusted" home would likely be out of scope.

Ray

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

On Oct 13, 2011, at 5:23 PM, Curtis Villamizar wrote:
> And I responded to that in the same email and you trimmed that part of
> the response in this email.

The problem has to do with customer-owned devices and customer-neighbor-owned 
devices forming networks together.   It's got nothing to do with the ISP.   
Chances are, the ISP link is the one thing that won't be gotten wrong here, 
because only one device you own will be connected to it (at least in typical 
networks today).

Of course, if your devices unintentionally include your neighbor in the home 
network topology, your network will suddenly be multihomed, but this is an 
artifact of the failure mode I'm talking about.  Eliminating that failure mode 
would solve the multihoming problem as well.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Mark Townsley]

On Oct 13, 2011, at 5:23 PM, Curtis Villamizar wrote:

> 
> In message <300ce19e-b3d6-4742-82ed-02f8167c9...@fugue.com>
> Ted Lemon writes:
> 
>> On Oct 13, 2011, at 2:35 PM, Curtis Villamizar wrote:
>>> You've said what the problem *isn't*, so what *is* the problem on a
>>> homenet?
>> 
>> I did say what the problem is:
>> 
 If you autoconfigure a routing topology, you have to make sure that
 you don't accidentally autoconfigure it to include routers that
 weren't intended to have been included.

That's part of the "border discovery" aspect that, if we can't nail down, 
everything else we do is pretty much moot. 

- Mark

> 
> 
> And I responded to that in the same email and you trimmed that part of
> the response in this email.
> 
> Curtis
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <300ce19e-b3d6-4742-82ed-02f8167c9...@fugue.com>
Ted Lemon writes:
 
> On Oct 13, 2011, at 2:35 PM, Curtis Villamizar wrote:
> > You've said what the problem *isn't*, so what *is* the problem on a
> > homenet?
>  
> I did say what the problem is:
>  
> >> If you autoconfigure a routing topology, you have to make sure that
> >> you don't accidentally autoconfigure it to include routers that
> >> weren't intended to have been included.


And I responded to that in the same email and you trimmed that part of
the response in this email.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <4e96cf0b.8060...@riw.us>
Russ White writes:
 
>  
> > Is it better to leave the possibility of theft of service or is it
> > better to have the device unusable by default (until configured)?  
>  
> This is a false dichotomy, as well...
>  
> It is best to find some reasonable ground where 90% of the people in
> the world will find the security acceptable, and then let the 10% who
> care configure the rest.
>  
> But I would also point out that the argument you're making can be
> applied to applications as well as network gear.
>  
> :-)
>  
> Russ


We are talking about whether to bring up routing.  The risk is theft
of service.  This is like locking the screen door if the inside door
deadbolt is already locked.

It is only an issue if the inside door has no locks or has very
ineffective locks and even then locking the screen door doesn't really
help much anyway.

Every WiFi product I ever bought was open WiFi as shipped.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <4e96ce51.7020...@riw.us>
Russ White writes:
 
>  
> > Should the applications be insecure and rely on a firewall?
> > (Microsoft advocated this in the 1990s and it has stuck to a large
> > extent).  Or should the network be open and the applications secure?
> > 
> > I'm strongly with you on this.  The applications should take care of
> > any security that is necessary *for that application*.
>  
> In other words, we should abandon door locks and make certain that
> anything you don't want stolen is individually secured --because only
> the device manufacturer could ever know how valuable it is, and how best
> to prevent it being stolen?

Following that analogy, the door locks built my certain OS vendors are
both flimsy and easily picked.

And we should not enable tftp and point it at the root directory and
hope that some smart network appliance will somehow firewall us.

> In your own words:
>  
> > No. No. No.
>  
> Security is layered in the physical world, and it should be layered in
> the network, as well. That I argue for a default "domain based" posture,
> where all machines within a given "domain" are all fully reachable, but
> those outside the "domain" are not reachable unless specific actions are
> taken to make them reachable, doesn't mean I don't think individual
> computers need security at all, or that all security should rely on the
> firewall.
>  
> "All security must be on the firewall or in the applications" is a false
> dichotomy.

Ideally the firewall should be unnecessary.  In some cases a firewall
is out of the question.  For example, a router cannot rely on sitting
behind a firewall.  That is not to say that packet filters at the
border don't serve as a valuable denial of service protection against
pure traffic based attacks.

Firewalls more often get in the way than do any good.  They also give
a false sense of security which results in the occasional "our LAN is
currently swamped as a result of the latest virus run amuck on our
LAN" coming from IT.

> > Security is not a layer-2 function.  Security is an application
> > function.  You had it right the first time.  Key exchanges and
> > certificates are not layer-2 functions.
>  
> Security is an application function, yes. Security is also a network
> function, and security is a machine level function. All of these have a
> role to play in security.
>  
> :-)
>  
> Russ

The operations staff for the T3-NSFNET had no firewall and was
security audited by some of the best in the field.  Of course we did
not allow the use of a PC with Windows in operations.  No such thing
could sit on the same subnet.

Another division in ANS that relied on a firewall was the only part of
the company that even had to have all computers taken down and
scrubbed before they could be used again.  [Requirement at that time
of having certain government customers].  Every computer had to be
physically removed, rebooted from other media, backed up, reinstalled,
user files restored from a backup prior to the breach, and returned to
the rack or the user's desk.  Users had to fetch any lost work from
the backups and were supposed to insure that no changes where made to
recovered source code.  Sound painful and costly?  It was!

Network protection of insecure host applications is false security.
It takes just one host breach to compromise the whole internal
network.  I've seen it first hand many times.  [not quite first hand
since my computers never relied on a firewall for security but a few
times on the corporate LAN they were sitting on.]

IPSEC also got it wrong.  The application really is the right place
for security.

:-)

btw- Anti-virus software is a cruel hoax.  [that someone makes money on]

:-)

> > It is entirely possible that the same computer has pictures of Grandma
> > that I'm OK with you seeing and has a printer hanging off it that I
> > don't want anyone in the world to be able to print on.  Same MAC
> > address.  So that can't be a layer-2 function.
> > 
> > And port filtering at a firewall is a lame excuse for security.  The
> > bug in relying on a firewall in an enterprise (a little less so for a
> > home) is that once any one user downloads malware, that malware has
> > access to everthing behind the firewall largely because of the
> > assumption that security is not needed because there is a firewall.
> > 
> > Lets not enshine the dumbest practices of the IT world.
> > 
> >> I think homenet should focus on L3. (and be clear on what it expects
> >> from the other layers with regards to security).
> >>  
> >> cheers,
> >> Ole
> > 
> > Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

On Oct 13, 2011, at 2:35 PM, Curtis Villamizar wrote:
> You've said what the problem *isn't*, so what *is* the problem on a
> homenet?

I did say what the problem is:

>> If you autoconfigure a routing topology, you have to make sure that
>> you don't accidentally autoconfigure it to include routers that
>> weren't intended to have been included.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <8031f94c-66bf-4748-aa97-5efa12bb8...@fugue.com>
Ted Lemon writes:
 
> If you autoconfigure a routing topology, you have to make sure that
> you don't accidentally autoconfigure it to include routers that
> weren't intended to have been included.
>  
> The concern is not for grandma running Windows 98, and the whole hard
> shell/gooey center debate is completely beside the point.


You've said what the problem *isn't*, so what *is* the problem on a
homenet?

Surely the provider is not going to accept a unauthenticated
auto-config hello request and start peering, nor will it accept a
hello from a legacy router configured with router-id and a "be
adjacent to anything" policy.

If the electric meter wants to be a router with a slow link on the
power line, then it needs to act like a provider router, but perhaps
only advertising reachability to the electric utility, not the whole
Internet.  The more specific prefix (than default) should get the
attention of the water heater if it has to try to reach the electric
utility.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

If you autoconfigure a routing topology, you have to make sure that you don't 
accidentally autoconfigure it to include routers that weren't intended to have 
been included.

The concern is not for grandma running Windows 98, and the whole hard 
shell/gooey center debate is completely beside the point.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Russ White]

> Is it better to leave the possibility of theft of service or is it
> better to have the device unusable by default (until configured)?  

This is a false dichotomy, as well...

It is best to find some reasonable ground where 90% of the people in the
world will find the security acceptable, and then let the 10% who care
configure the rest.

But I would also point out that the argument you're making can be
applied to applications as well as network gear.

:-)

Russ

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Russ White]

> Should the applications be insecure and rely on a firewall?
> (Microsoft advocated this in the 1990s and it has stuck to a large
> extent).  Or should the network be open and the applications secure?
> 
> I'm strongly with you on this.  The applications should take care of
> any security that is necessary *for that application*.

In other words, we should abandon door locks and make certain that
anything you don't want stolen is individually secured --because only
the device manufacturer could ever know how valuable it is, and how best
to prevent it being stolen?

In your own words:

> No. No. No.

Security is layered in the physical world, and it should be layered in
the network, as well. That I argue for a default "domain based" posture,
where all machines within a given "domain" are all fully reachable, but
those outside the "domain" are not reachable unless specific actions are
taken to make them reachable, doesn't mean I don't think individual
computers need security at all, or that all security should rely on the
firewall.

"All security must be on the firewall or in the applications" is a false
dichotomy.

> Security is not a layer-2 function.  Security is an application
> function.  You had it right the first time.  Key exchanges and
> certificates are not layer-2 functions.

Security is an application function, yes. Security is also a network
function, and security is a machine level function. All of these have a
role to play in security.

:-)

Russ

> 
> It is entirely possible that the same computer has pictures of Grandma
> that I'm OK with you seeing and has a printer hanging off it that I
> don't want anyone in the world to be able to print on.  Same MAC
> address.  So that can't be a layer-2 function.
> 
> And port filtering at a firewall is a lame excuse for security.  The
> bug in relying on a firewall in an enterprise (a little less so for a
> home) is that once any one user downloads malware, that malware has
> access to everthing behind the firewall largely because of the
> assumption that security is not needed because there is a firewall.
> 
> Lets not enshine the dumbest practices of the IT world.
> 
>> I think homenet should focus on L3. (and be clear on what it expects
>> from the other layers with regards to security).
>>  
>> cheers,
>> Ole
> 
> Curtis
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message 
Ted Lemon writes:
 
> On Oct 12, 2011, at 4:48 AM, Ole Troan wrote:
> > using the electricity network as an analogy, can we make a
> > distinction between "safety" and "security"?
> > the electricity network in the home is somewhat self protecting with
> > breakers and earthing.
> > a home network must protect 'itself', i.e. handle any device plugged
> >into it, in any topology, external and internal attacks
> > and so on.
>  
> I am highly sympathetic to the desire not to try to solve this
> problem.  However, unfortunately network topology isn't the same as
> electrical topology, for a couple of reasons.
>  
> The first reason is that electrical systems are generally set up by
> professionals.  Yes, you plug devices into the electrical wiring of
> your house, but someone skilled set it up (or if not, I hope you sleep
> in asbestos pajamas).  The devices we are talking about are more
> analogous to circuit distribution panels than to toasters.
>  
> The second reason is that electrical systems are essentially
> topology-free.  Any point on the system is essentially equivalent to
> any other.  This is not true of a home network with routing.  What we
> are talking about is essentially the possibility of rogue distribution
> panels intentionally or accidentally being connected to your
> distribution system.  =20

The electricity analogy is not very useful.  Maybe best to drop it.

> Which is a result of the third reason: home networks are typically
> wireless, or partially wireless, and so there is no physical security,
> unlike an electrical network in a house, which is secure by virtue of
> being entirely enclosed by the house.
>  
> I think what you are getting at is that we cannot be responsible for
> securing the network.  And that is probably true.  But if the system
> doesn't have a built-in mechanism for distinguishing between friend
> and stranger, the autoconfiguration mechanism will create topologies
> that aren't desired, either by accident or because a stranger wants
> access to the network.

If applications are secure, the only threat to a wide open network is
theft of service.

WPA provides a knob to stop that.  The only question is whether WPA or
any WiFi security should be enabled by default.

Is it better to leave the possibility of theft of service or is it
better to have the device unusable by default (until configured)?  For
provider equipment that is always configured, the latter (unusable
until configured).  For home equipment where the customer wants to
unpack the box, plug it in and use it, the former is better (make it
usabled but allow possible theft of service).

Every WiFi product I ever bought was open WiFi as shipped.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <4e955c94.3060...@cs.tcd.ie>
Stephen Farrell writes:
 
> On 10/12/2011 09:48 AM, Ole Troan wrote:
> >> I've been reading the list with interest and have a question.
> >>
> >> When various devices in the home figure out which does what,
> >> and do that periodically to handle changes, there's clearly
> >> the potential that a zombied host tries to try take over
> >> stuff with undesirable consequences.
> >>
> >> My question is whether this group are planning to think
> >> about that now, or later, or never? (Or don't even think
> >> there's a problem worth attempting to address.)
> >>
> >> Note - I'm not trying to argue for any particular level of
> >> security and certainly not for some unachievable fort knox
> >> everywhere, I'm just asking what's the plan?
> >
> > can we explore some fundamental principles of how and what we need to 
> > "secure"?
> >
> > using the electricity network as an analogy, can we make a distinction 
> > between "safety" and "security"?
> > the electricity network in the home is somewhat self protecting with 
> > breakers and earthing.
> > a home network must protect 'itself', i.e. handle any device plugged into 
> > it, in any topology, external and internal attacks
> > and so on.
> >
> > I don't think it is the networks job to control who has access to the 
> > pictures of my grandmother or who can print to my printer. that's 
> > application policy.
> >
> > is it the networks job to control who has access to the network? no, I 
> > think that is a layer 2 function.
> >
> > I think homenet should focus on L3. (and be clear on what it expects from 
> > the other layers with regards to security).
>  
> Reasonable points. However, if the zeroconf stuff provides an easy
> way for a bad device to take over the homenet and get everything
> interesting routed via it, that seems like a bad thing. That's
> really what I was asking about, not application layer security,
> nor layer 2 (though some layer 2 security can probably help a bit
> if its turned on).
>  
> Again, I'm not asking for some complex new scheme to be invented
> here, I'm just asking whether the group are planning to address
> this issue and roughly when. (In the hope that the answers are
> something close to "yes" and "as an integrated part of the work":-)
>  
> S.



You concern may boil down to.

  Should we be worried that Grandma is still running Windows 98?

  [Or that the same company that gave us Windows 95 and 98 can't get
  their act together with security after being beat up about it for
  over a decade.]

Application layer security over a sound foundation is the right place
for security.  A practical consequence of horribly insecure OS code
from one major supplier for more than a decade is that firewall
functionality is also more than just nice to have in enterprise and
home network equipment.

OTOH - If the PC user runs flash for example, there is no way the
network can protect them from the myriad of security holes that keep
popping up and getting fixed all too slowly.  ... and then there are
the discount brokerages that run flash on their web sites insuring
that their users will have flash installed and enabled and probably
won't disable it when going elsewhere on the web.  [oh well].

The network cannot protect the world from really bad application (or
OS) programmers.  Recognizing this may be a first step to solving it
the right way - with a robust OS and more secure applications.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <78ce7d95-48c9-4de4-9707-f11ac2a05...@cisco.com>
Ole Troan writes:
 
> > I've been reading the list with interest and have a question.
> > 
> > When various devices in the home figure out which does what,
> > and do that periodically to handle changes, there's clearly
> > the potential that a zombied host tries to try take over
> > stuff with undesirable consequences.
> > 
> > My question is whether this group are planning to think
> > about that now, or later, or never? (Or don't even think
> > there's a problem worth attempting to address.)
> > 
> > Note - I'm not trying to argue for any particular level of
> > security and certainly not for some unachievable fort knox
> > everywhere, I'm just asking what's the plan?
>  
> can we explore some fundamental principles of how and what we need to
> "secure"?

Yes.  Please do.

> using the electricity network as an analogy, can we make a distinction
> between "safety" and "security"?  the electricity network in the home
> is somewhat self protecting with breakers and earthing.  a home
> network must protect 'itself', i.e. handle any device plugged into it,
> in any topology, external and internal attacks and so on.
>  
> I don't think it is the networks job to control who has access to the
> pictures of my grandmother or who can print to my printer. that's
> application policy.

Exactly.  This is a multi-decade old debate.

Should the applications be insecure and rely on a firewall?
(Microsoft advocated this in the 1990s and it has stuck to a large
extent).  Or should the network be open and the applications secure?

I'm strongly with you on this.  The applications should take care of
any security that is necessary *for that application*.

> is it the networks job to control who has access to the network? no, I
> think that is a layer 2 function.

No. No. No.

Security is not a layer-2 function.  Security is an application
function.  You had it right the first time.  Key exchanges and
certificates are not layer-2 functions.

It is entirely possible that the same computer has pictures of Grandma
that I'm OK with you seeing and has a printer hanging off it that I
don't want anyone in the world to be able to print on.  Same MAC
address.  So that can't be a layer-2 function.

And port filtering at a firewall is a lame excuse for security.  The
bug in relying on a firewall in an enterprise (a little less so for a
home) is that once any one user downloads malware, that malware has
access to everthing behind the firewall largely because of the
assumption that security is not needed because there is a firewall.

Lets not enshine the dumbest practices of the IT world.

> I think homenet should focus on L3. (and be clear on what it expects
> from the other layers with regards to security).
>  
> cheers,
> Ole

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <159dbf45-107c-4c12-ae01-9bb494e8e...@fugue.com>
Ted Lemon writes:
 
> On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote:
> > However, I am thinking that we can perhaps bootstrap equipment that has
> > never been configured (or has been factory reset) in some fashion such
> > that if the equipment is "virginal" that it can essentially always try
> > some default keys, and bring up enough networking to let all equipment
> > be discovered and identified.  There would be strong nag screens to get
> > the user to up a network password.
>  
> A pre-shared key that is pre-shared to every device is the same as no
> key.  So you might as well not bother with that complexity.
> Conceivably CGA could be used to publish public/private key pairs
> allowing devices to automatically recognize each other and present
> their relationships in a UI for the end user to approve, but that's
> not precisely plug and play.


Agree completely on this.

For example, having bumping the factory default button on a wireless
camera open access to everyone would really be a bad idea.


> I think the simplest thing would be to require that each device be
> able to talk to a USB drive.  Each device collects all the public keys
> on the USB drive, and stores their own there.  Devices then share
> their public key with other devices identified on the USB drive, so
> that as each device joins the network, the other devices learn about
> it.  This isn't bulletproof=97an infected PC that's configured with
> these keys could be used to gain access to the keys, for example.  But
> it's a lot better than a well-known key.
>  
> Of course, this isn't quite as plug and play as you seem to want, and
> it requires that each device have a USB port, which might not be
> acceptable.  Plus, it would mean that the IETF would have to talk
> about hardware, which seems like a bit of a non-starter.  But I think
> it's the right way to solve the problem.


Mandating USB is not practical.

For example I have a set of DECT phones with a single SIP base
station.  You can bond the phone to the base station but you have to
enter a menu on the phone and do something on the base station
(through the web interface or otherwise) within 10 seconds.  Not
perfect, but it works.

There are too many cases like bonding the garage door opener to the
clicker, or bonding the speakers to the audio system, etc, don't need
to store keys on a USB as a boot strap.  For some things USB would be
fine.

And my water heater, as facinating as it might be to the electrical
utility, need not have the key to my garage door opener or my audio
speakers, even though I might want to turn the hot water up or down a
few degrees through a remote device some day.

I would say that reinventing the kerberos KDC with ticket granting
tickets and service tickets is probably overkill and should be out of
scope.  But it would be a truly wonderful thing if the interface could
be made simple enough for a consumer to set up.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Curtis Villamizar]

In message <4e94bf91.4060...@cs.tcd.ie>
Stephen Farrell writes:
 
>  
> Hi,
>  
> I've been reading the list with interest and have a question.
>  
> When various devices in the home figure out which does what,
> and do that periodically to handle changes, there's clearly
> the potential that a zombied host tries to try take over
> stuff with undesirable consequences.
>  
> My question is whether this group are planning to think
> about that now, or later, or never? (Or don't even think
> there's a problem worth attempting to address.)
>  
> Note - I'm not trying to argue for any particular level of
> security and certainly not for some unachievable fort knox
> everywhere, I'm just asking what's the plan?
>  
> S.


Watch out for autoconfig of microphones and cameras.  :-)

I call it bonding.  Some ritual has to be performed before specific
types of devices trust each other.  Like the garage door opener and
the clicker thingie.  Same should be true of the audio system and the
wireless speakers.  The TV and remote use IR.  The routers just route,
but they need to be a bit more picky about who can configure them.

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

On Oct 12, 2011, at 8:46 AM, Ole Troan wrote:
> I think we can figure out a way of "pairing" devices. whatever layer that 
> ends up being done at.
> it will be much more difficult to protect against hostiles injecting default 
> routes, or pretending to be DHCP servers and so on.

I think pairing and general network security are largely the same problem.   Of 
course if someone is granted access to the network, they can then inject routes 
or pretend to be a DHCP server, but that's not the issue I'm concerned with.   
I'm more concerned with the scenario Jim Gettys talked about in a subsequent 
message, where a bunch of things clump together and start talking to each other 
essentially accidentally.   And of course I'm also somewhat concerned about 
attackers, although I think that's probably going to happen less often than 
accidental clumping.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ole Troan]

Ted,

>> using the electricity network as an analogy, can we make a distinction 
>> between "safety" and "security"?
>> the electricity network in the home is somewhat self protecting with 
>> breakers and earthing.
>> a home network must protect 'itself', i.e. handle any device plugged into 
>> it, in any topology, external and internal attacks
>> and so on.
> 
> I am highly sympathetic to the desire not to try to solve this problem.   
> However, unfortunately network topology isn't the same as electrical 
> topology, for a couple of reasons.
> 
> The first reason is that electrical systems are generally set up by 
> professionals.   Yes, you plug devices into the electrical wiring of your 
> house, but someone skilled set it up (or if not, I hope you sleep in asbestos 
> pajamas).   The devices we are talking about are more analogous to circuit 
> distribution panels than to toasters.
> 
> The second reason is that electrical systems are essentially topology-free.   
> Any point on the system is essentially equivalent to any other.   This is not 
> true of a home network with routing.   What we are talking about is 
> essentially the possibility of rogue distribution panels intentionally or 
> accidentally being connected to your distribution system.   
> 
> Which is a result of the third reason: home networks are typically wireless, 
> or partially wireless, and so there is no physical security, unlike an 
> electrical network in a house, which is secure by virtue of being entirely 
> enclosed by the house.
> 
> I think what you are getting at is that we cannot be responsible for securing 
> the network.   And that is probably true.   But if the system doesn't have a 
> built-in mechanism for distinguishing between friend and stranger, the 
> autoconfiguration mechanism will create topologies that aren't desired, 
> either by accident or because a stranger wants access to the network.

I do agree with that.
I think we can figure out a way of "pairing" devices. whatever layer that ends 
up being done at.
it will be much more difficult to protect against hostiles injecting default 
routes, or pretending to be DHCP servers and so on.

cheers,
Ole
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

On Oct 12, 2011, at 4:48 AM, Ole Troan wrote:
> using the electricity network as an analogy, can we make a distinction 
> between "safety" and "security"?
> the electricity network in the home is somewhat self protecting with breakers 
> and earthing.
> a home network must protect 'itself', i.e. handle any device plugged into it, 
> in any topology, external and internal attacks
> and so on.

I am highly sympathetic to the desire not to try to solve this problem.   
However, unfortunately network topology isn't the same as electrical topology, 
for a couple of reasons.

The first reason is that electrical systems are generally set up by 
professionals.   Yes, you plug devices into the electrical wiring of your 
house, but someone skilled set it up (or if not, I hope you sleep in asbestos 
pajamas).   The devices we are talking about are more analogous to circuit 
distribution panels than to toasters.

The second reason is that electrical systems are essentially topology-free.   
Any point on the system is essentially equivalent to any other.   This is not 
true of a home network with routing.   What we are talking about is essentially 
the possibility of rogue distribution panels intentionally or accidentally 
being connected to your distribution system.   

Which is a result of the third reason: home networks are typically wireless, or 
partially wireless, and so there is no physical security, unlike an electrical 
network in a house, which is secure by virtue of being entirely enclosed by the 
house.

I think what you are getting at is that we cannot be responsible for securing 
the network.   And that is probably true.   But if the system doesn't have a 
built-in mechanism for distinguishing between friend and stranger, the 
autoconfiguration mechanism will create topologies that aren't desired, either 
by accident or because a stranger wants access to the network.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Stephen Farrell]

On 10/12/2011 09:48 AM, Ole Troan wrote:

I've been reading the list with interest and have a question.

When various devices in the home figure out which does what,
and do that periodically to handle changes, there's clearly
the potential that a zombied host tries to try take over
stuff with undesirable consequences.

My question is whether this group are planning to think
about that now, or later, or never? (Or don't even think
there's a problem worth attempting to address.)

Note - I'm not trying to argue for any particular level of
security and certainly not for some unachievable fort knox
everywhere, I'm just asking what's the plan?


can we explore some fundamental principles of how and what we need to "secure"?

using the electricity network as an analogy, can we make a distinction between "safety" 
and "security"?
the electricity network in the home is somewhat self protecting with breakers 
and earthing.
a home network must protect 'itself', i.e. handle any device plugged into it, 
in any topology, external and internal attacks
and so on.

I don't think it is the networks job to control who has access to the pictures 
of my grandmother or who can print to my printer. that's application policy.

is it the networks job to control who has access to the network? no, I think 
that is a layer 2 function.

I think homenet should focus on L3. (and be clear on what it expects from the 
other layers with regards to security).


Reasonable points. However, if the zeroconf stuff provides an easy
way for a bad device to take over the homenet and get everything
interesting routed via it, that seems like a bad thing. That's
really what I was asking about, not application layer security,
nor layer 2 (though some layer 2 security can probably help a bit
if its turned on).

Again, I'm not asking for some complex new scheme to be invented
here, I'm just asking whether the group are planning to address
this issue and roughly when. (In the hope that the answers are
something close to "yes" and "as an integrated part of the work":-)

S.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ole Troan]

> I've been reading the list with interest and have a question.
> 
> When various devices in the home figure out which does what,
> and do that periodically to handle changes, there's clearly
> the potential that a zombied host tries to try take over
> stuff with undesirable consequences.
> 
> My question is whether this group are planning to think
> about that now, or later, or never? (Or don't even think
> there's a problem worth attempting to address.)
> 
> Note - I'm not trying to argue for any particular level of
> security and certainly not for some unachievable fort knox
> everywhere, I'm just asking what's the plan?

can we explore some fundamental principles of how and what we need to "secure"?

using the electricity network as an analogy, can we make a distinction between 
"safety" and "security"?
the electricity network in the home is somewhat self protecting with breakers 
and earthing.
a home network must protect 'itself', i.e. handle any device plugged into it, 
in any topology, external and internal attacks
and so on.

I don't think it is the networks job to control who has access to the pictures 
of my grandmother or who can print to my printer. that's application policy.

is it the networks job to control who has access to the network? no, I think 
that is a layer 2 function.

I think homenet should focus on L3. (and be clear on what it expects from the 
other layers with regards to security).

cheers,
Ole



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Riccardo Bernardini]

2011/10/12 Joel jaeggli 

> On 10/11/11 18:38 , Ted Lemon wrote:
> > On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote:
> >> However, I am thinking that we can perhaps bootstrap equipment that has
> >> never been configured (or has been factory reset) in some fashion such
> >> that if the equipment is "virginal" that it can essentially always try
> >> some default keys, and bring up enough networking to let all equipment
> >> be discovered and identified.  There would be strong nag screens to get
> >> the user to up a network password.
> >
> > A pre-shared key that is pre-shared to every device is the same as no
> > key.
>
> Not really, it could serve an important hygenic function, notionaly, it
> could be filtered by default on all non-home-network gear. that is
> serves the purpose of identifying a well-known-service. there are of
> course other perhaps better ways to implment that.
>
> >  So you might as well not bother with that complexity.
> > Conceivably CGA could be used to publish public/private key pairs
> > allowing devices to automatically recognize each other and present their
> > relationships in a UI for the end user to approve, but that's not
> > precisely plug and play.
> >
> > I think the simplest thing would be to require that each device be able
> > to talk to a USB drive.   Each device collects all the public keys on
> > the USB drive, and stores their own there.   Devices then share their
> > public key with other devices identified on the USB drive, so that as
> > each device joins the network, the other devices learn about it.   This
> > isn't bulletproof—an infected PC that's configured with these keys could
> > be used to gain access to the keys, for example.   But it's a lot better
> > than a well-known key.
>

What about ID-based signature?

Just improvising (so forgive me for any naivety): the ID of the device could
be a triplet (producer-ID, product-ID, serial-number); the "key generator"
could be the producer itself (avoiding in this way the key escrow problem
related to ID-based cryptography) and a certificate with the public key of
the producer could be downloadable from some well-known host (alternatively,
the key of most known producers could be "built in" the device).

The authentication procedure would follow  the usual challenge scheme: the
device receives a challenge string, it appends to it a nonce and signs the
result with its private key (hardwired at production time).  If the
authentication is positive, then you know that you are talking to that type
of device, produced by that producer (if you trust the producer is another
matter).  Of course, this simple scheme would fall to a device-in-the-middle
attack, but maybe in this  context it is not a likely attack.

>
> > Of course, this isn't quite as plug and play as you seem to want, and it
> > requires that each device have a USB port, which might not be
> > acceptable.   Plus, it would mean that the IETF would have to talk about
> > hardware, which seems like a bit of a non-starter.   But I think it's
> > the right way to solve the problem.
> >
> >
> >
> > ___
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Joel jaeggli]

On 10/11/11 18:38 , Ted Lemon wrote:
> On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote:
>> However, I am thinking that we can perhaps bootstrap equipment that has
>> never been configured (or has been factory reset) in some fashion such
>> that if the equipment is "virginal" that it can essentially always try
>> some default keys, and bring up enough networking to let all equipment
>> be discovered and identified.  There would be strong nag screens to get
>> the user to up a network password.
> 
> A pre-shared key that is pre-shared to every device is the same as no
> key. 

Not really, it could serve an important hygenic function, notionaly, it
could be filtered by default on all non-home-network gear. that is
serves the purpose of identifying a well-known-service. there are of
course other perhaps better ways to implment that.

>  So you might as well not bother with that complexity.  
> Conceivably CGA could be used to publish public/private key pairs
> allowing devices to automatically recognize each other and present their
> relationships in a UI for the end user to approve, but that's not
> precisely plug and play.
> 
> I think the simplest thing would be to require that each device be able
> to talk to a USB drive.   Each device collects all the public keys on
> the USB drive, and stores their own there.   Devices then share their
> public key with other devices identified on the USB drive, so that as
> each device joins the network, the other devices learn about it.   This
> isn't bulletproof—an infected PC that's configured with these keys could
> be used to gain access to the keys, for example.   But it's a lot better
> than a well-known key.
> 
> Of course, this isn't quite as plug and play as you seem to want, and it
> requires that each device have a USB port, which might not be
> acceptable.   Plus, it would mean that the IETF would have to talk about
> hardware, which seems like a bit of a non-starter.   But I think it's
> the right way to solve the problem.
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Ted Lemon]

On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote:
> However, I am thinking that we can perhaps bootstrap equipment that has
> never been configured (or has been factory reset) in some fashion such
> that if the equipment is "virginal" that it can essentially always try
> some default keys, and bring up enough networking to let all equipment
> be discovered and identified.  There would be strong nag screens to get
> the user to up a network password.

A pre-shared key that is pre-shared to every device is the same as no key.   So 
you might as well not bother with that complexity.   Conceivably CGA could be 
used to publish public/private key pairs allowing devices to automatically 
recognize each other and present their relationships in a UI for the end user 
to approve, but that's not precisely plug and play.

I think the simplest thing would be to require that each device be able to talk 
to a USB drive.   Each device collects all the public keys on the USB drive, 
and stores their own there.   Devices then share their public key with other 
devices identified on the USB drive, so that as each device joins the network, 
the other devices learn about it.   This isn't bulletproof—an infected PC 
that's configured with these keys could be used to gain access to the keys, for 
example.   But it's a lot better than a well-known key.

Of course, this isn't quite as plug and play as you seem to want, and it 
requires that each device have a USB port, which might not be acceptable.   
Plus, it would mean that the IETF would have to talk about hardware, which 
seems like a bit of a non-starter.   But I think it's the right way to solve 
the problem.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] security question for zeroconf stuff inside the homenet...

[Michael Richardson]

> "Stephen" == Stephen Farrell  writes:
Stephen> I've been reading the list with interest and have a question.

Stephen> When various devices in the home figure out which does what,
Stephen> and do that periodically to handle changes, there's clearly
Stephen> the potential that a zombied host tries to try take over
Stephen> stuff with undesirable consequences.

We have throught about this.

Stephen> My question is whether this group are planning to think
Stephen> about that now, or later, or never? (Or don't even think
Stephen> there's a problem worth attempting to address.)

We think that the most sophisticated security we can hope for is that
all pieces of equipment can be provided with a "network password"
For devices which have WIFI, this will essentially be the WPA/PSK key,
but used to key other protocols as well.

However, I am thinking that we can perhaps bootstrap equipment that has
never been configured (or has been factory reset) in some fashion such
that if the equipment is "virginal" that it can essentially always try
some default keys, and bring up enough networking to let all equipment
be discovered and identified.  There would be strong nag screens to get
the user to up a network password.

At this point, I think that many users are used to having a network
password. 

Stephen> Note - I'm not trying to argue for any particular level of
Stephen> security and certainly not for some unachievable fort knox
Stephen> everywhere, I'm just asking what's the plan?

I agree: we need something.  It needs to be just enough, and it's okay
if there are ways of subverting the system if you have physical access.

Having said that, I'd like to see optional (MAY) support for stronger
systems, for the Bill Gates-type/Yari Arko-type home...



pgpJqGMikC2iQ.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] security question for zeroconf stuff inside the homenet...

[Stephen Farrell]

Hi,

I've been reading the list with interest and have a question.

When various devices in the home figure out which does what,
and do that periodically to handle changes, there's clearly
the potential that a zombied host tries to try take over
stuff with undesirable consequences.

My question is whether this group are planning to think
about that now, or later, or never? (Or don't even think
there's a problem worth attempting to address.)

Note - I'm not trying to argue for any particular level of
security and certainly not for some unachievable fort knox
everywhere, I'm just asking what's the plan?

S.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet