Subject: Re: home network security

From: [email-masked]
Date: Thu, 6 Apr 2000 06:16:30 EDT

In a message dated 00-04-05 20:34:51 EDT, [email-masked] writes:

<<Given that we can't rely on layer two protection being there, I think I 
would like to see some kind of requirement statement to the effect that 
zeroconf protocols must be securable, but that security does not need to be 
turned on by default.>>

I've entered this discussion with the assumption that "zero configuration" 
implies that we are working in an environment with *very* naive users, that 
we can expect little or no responsibility on their part to administer the 
network.

Based on my observations, many (if not most) of these naive users have little 
or NO concept of security, not even the concept that they need security. 
Based on recent experience with a DSL installation, ISPs are doing little or 
nothin to educate customers with respect to security. My cynical belief 
(which could well be erroneous) is that their legal counsel has advised them 
that they will be less liable if they say absolutely nothing about the topic.

My own conclusion is that it would be unconscionable to offer "zero 
configuration" products that do not have security enabled by DEFAULT. I think 
this is important enough that the eventual RFC state "security MUST be 
enabled by default."

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Daniel Senie <[email-masked]>
Date: Thu, 06 Apr 2000 08:33:12 -0400

> this is important enough that the eventual RFC state "security MUST be

So, your argument is: Because wireless layer 2 media has security issues
that require configuration, we should abandon zeroconf in its entirely?

Security for layer 2 wireless devices may well require configuration of
devices at layer 2. In this case, such devices are not "zeroconf"
devices. Please explain how you propose to reconcile zero configuration
with security. We've gone around on this several times.

Perhaps we should abandon much of zeroconf. We could REQUIRE a central
"house controller" which allows the homeowner to type in the serial
number (really the MAC address) of each device, including appliances,
computers, and the blender, and then provide configuration and security
via DHCP, as well as defining the trust relationship for outside access.
The DHCP server obviously becomes a single point of failure, and a
single point of security attack, but it does provide a place to deal
with all of this various issues of security.

In the end, if we want security, we have to have configuration. If we
are going to have to have configuration, then zeroconf fails, and it's
time to abandon this WG and start a new one on home networking.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Thomas Narten <[email-masked]>
Date: Thu, 06 Apr 2000 10:05:26 -0400

> time to abandon this WG and start a new one on home networking.

I think pretty much everyone agrees that there is no such thing as
real security with absolutely no configuration. However, it does not
immediately follow that we should therefore punt on security because
it invalidates the primary goal of  zeroconf.

If we define a secure mode that requires configuration, that doesn't
mean that security will need to be enabled by default in all
environments.  However, deploying a zeroconf system that has
absolutely no security and no way to enable it would be equally
irresponsible. The goals of this group should be to come up with a
resonably secure mode that can be enabled with a minimal amount of
configuration, and with configuration that can be dealt with by the
typical home user. In my mind that could mean something like:

1) point and click enablement, not typing in secrets. (there are
   plenty of ways to generate initial secrets as a starting point)
   
2) doing enablement once and having other services bootstrap from that
   initial configuration. It may well be that additional "manual
   configuration" is needed for a new service, but that service might
   be as simple as a window popping up saying "a new device just came
   online, it claims to be  a toaster. Do you want to add it to your
   set of trusted machines?" The user can then respond, presumably it
   just plugged the toaster in and so can verify that it is not a bad
   guy device.

Keep in mind also, that we're not necessarily looking for iron-clad
security. Rather, we're looking for a reasonable tradeoff in terms of
configuration/ease of enablement, protection against the most serious
threats, etc. Thus, while 2) above might leave a site vulnerable to
some attacks (i.e., bad guy chimes in right as new toaster comes
online), it protects against more serious ones (i.e., bad guy comes up
at random and is given immediate and wide-open access).

Thomas

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Thu, 06 Apr 2000 12:36:46 -0400

> with all of this various issues of security.

Hello;

   I think that a reasonable goal for zeroconfig should be : to provide Internet
connected devices that even your <insert name of favorite older relative>
COULD and WOULD use.

Pigs will fly before my Mother starts typing in all of of these serial numbers.
You could probably get her to enter her phone number and / or her address.
If you ask her for a password, she will probably use her phone number and / or her address.
If she ever hears of someone's home being broken into because someone
(say) hacked in and figured that no-one was at home because the refrigerator hadn't
been opened for 4 days, she will NEVER buy the system.

This suggests two levels of quasi-zeroconfig devices :

Benign devices, such as a stand alone Internet radio or  a printer, which can be truly
zeroconfig BECAUSE THERE IS NO DANGER IF THEY ARE COMPROMISED.

Non-benign devices, such as a home security system, which will require some
configuration, such as the entry of a ID such as a phone number,
It would probably be a good idea if such a non-benign device

1.) Only accepted commands from packets with TTL = 1 and confirmation of
the ID from a central device.
2.) Required a manual override to be controlled from outside the zeroconfig network.
(I.e., "you have to push the <security disable button> to allow us to upgrade your
fire alarm"). This manual override should be of limited duration (say, 30 minutes).

To be a benign device :

The device cannot act in such a way as to cause any physical danger based on commands from outside,
even from the zeroconfig net,  (such as instructing a stove to turn on and stay on over the net)

AND

The device cannot convey any information about the state of the users (such as the last time
the refrigerator door was opened).

Zeroconfig should therefore work to provide a specification for what makes a device benign,
and therefore subject to zeroconfig. Maybe there should be a separate WG for
security and minimum configuration for non-benign devices.

                                                                                            Regards
                                                                                            Marshall Eubanks

> time to abandon this WG and start a new one on home networking.

T.M. Eubanks
Multicast Technologies, Inc
P.O. Box 99
Clifton, Virginia 20124
Phone : 703-803-8141
Fax     : 703-222-3250
e-mail : [email-masked]