Subject: RE: Zeroconf security

From: [email-masked]
Date: Sun, 26 Mar 2000 13:25:34 -0600

At the November IETF meeting I tried to raise this issue
and the majority (or at least the majority of people who spoke
up) seemed to feel that the group should punt on security
for Zeroconf networks. Part of the argument was that by 
limiting the scope of the WG, it will be able to finish its
tasks quickly.

The risk is that Zeroconf networks without adequate security
might seem like a bad idea to enough people to create a real
obstacle to the acceptance and deployment of Zeroconf technology.

I think that if the Zeroconf WG feels that it is the wrong group
to work towards simple, secure networks (as oppossed to zeroconf),
then we need to consider the creation of a complementary WG that
is chartered to deal with simple, secure networks.

Franklin Reynolds
Nokia Research Center

> -----Original Message-----
> From: EXT Steve Hanna [mailto:[email-masked]]
> Sent: Friday, March 24, 2000 9:19 AM
> To: [email-masked]
> Subject: Zeroconf security
> 
> 
> I would like to comment on one of the open issues Erik 
> Guttman recently
> posted:
> 
> - Is 0 admin, 0 security OK or is this "punting?"
> 
> IMHO, leaving security out of zeroconf networking would be similar to
> building a car with no locks. It's an invitation for mischief and a
> dangerous thing.
> 
> Perhaps you'll say "But zero config is only for home systems and small
> business. What harm will it do to leave out security?"
> 
> Pranksters will flip on people's alarm clocks at 2:00 AM. Peeping toms
> will flip on lights at inappropriate times. Criminals will drive down
> the street, opening doors and disabling alarms. And vandals may even
> burn down houses by repeatedly triggering the self-clean 
> cycle on ovens.
> 
> OK, maybe things won't be so bad. But we have an obligation to build
> secure protocols. If a user doesn't want to use security, they don't
> have to. But we have to build it in as an option.
> 
> Security MUST be included in all zeroconf protocols, it MUST be
> mandatory to implement (although it can be off by default), 
> and it MUST
> be easy to use. I recognize that security can never be truly zeroconf.
> But we can get pretty close (I'd be glad to elaborate, if you like).
> 
> Comments?
> 
> Steve
>

---

From: James Kempf <[email-masked]>
Date: Mon, 27 Mar 2000 07:55:58 +0-1000

Here's a bit of a reality check about trying to do security with zero 
configuration (and I mean "zero" literally).

Last year, I worked with a group on designing a management installation
agent that installs system management software without any initial configuration.
The idea is that a company buys a computer and the OS comes preinstalled with
this agent that goes out and installs system management software (like
Tivoli for example) when the machine first boots. I don't want to go into
the details of how this works, we came up with a credible design but 
it is unimportant for this discussion.

The important point is that we had to back off our initial attempt to do
security without configuration because we couldn't figure out how to 
get an organization that would be willing to assume the legal risk of a compromised
key. The initial design assumed that there was an organization like Verisign
that would hand out a global public key that would be embedded in every
agent. We talked about using a cert chain, but every design we could think
of would require some kind of initial configuration on the computer before
it could work. When we looked into the issue, we found that Verisign and
others have expressed a reluctance in the past to take on the legal risk
involved in managing such a system.

Finally, what we decided to do was require the company buying the computer 
and the company selling it arrange to have the buyer's public key installed
in the agent at the time the computer is configured by the seller. This
requires some configuration, but the important information can be prearranged,
like credit card numbers, so that it doesn't have to occur with every purchase.
The legal risk in this case is clearly defined and partitioned so that 
ajudication in the event of a dispute would be much easier.

Probably there are other ways this could have been done, and I've simplified
this description some, but the point I'm trying to make is that doing
real zero conf security is a hard (and perhaps unsolvable) problem not
for any technical reason but because of legal and organizational reasons.

			jak

>Steve Hanna wrote:
>> 
>> I would like to comment on one of the open issues Erik Guttman recently
>> posted:
>> 
>> burn down houses by repeatedly triggering the self-clean cycle on ovens.
>> 
>> mandatory to implement (although it can be off by default), and it MUST
>I'd like an explanation of how you intend to implement security
>(certificates, etc.) in a zeroconf network. The problem you get into is
>that this requires configuration. It's that configuration requirement
>which runs counter to zeroconf.
>
>It is NOT clear that there is a need or desire to run secure protocols
>in this case.
>
>It is my contention that anyone requiring secure protocols and the like
>can implement configured (not zeroconf) networks, and implement the
>security as needed in that context. I'm not convinced we need to
>reinvent all of that in zeroconf.
>
>-- 
>-----------------------------------------------------------------
>Daniel Senie                                        [email-masked]
>Amaranth Networks Inc.                    http://www.amaranth.com
>

---

From: Steve Hanna <[email-masked]>
Date: Mon, 27 Mar 2000 10:08:06 -0500

As Rajesh pointed out, many zeroconf networks will use wireless media.
Without security, such a system is outrageously vulnerable. Powerline
networking is often similarly insecure.

Instead of the gossip- or certificate-based protocols mentioned by
Rajesh and Jim, I would suggest a simple group key model. When you buy a
new toaster, you download a group key to it (perhaps by plugging it into
a power outlet on the front of your home controller). When the toaster
needs to send an IP packet (for service discovery or whatever), it
includes a keyed hash using the group key. And it ignores all received
IP packets unless they include such a keyed hash.

Added cost: a few bits of non-volatile storage to store the key.
Calculating the keyed hash is trivial on any processor that can run IP.
Added configuration: plugging the toaster into the home controller
before you put it in the kitchen. For large appliances, you can bring
the home controller to the appliance or use a card (smart card, etc.) to
transfer the key. Don't send the group key over the wireless net,
though. Then it won't be a secret any more!

People who don't care about zeroconf security can just skip the part
about plugging the toaster into the home controller. Then it will accept
all IP packets.

-Steve

P.S. If we want to be standards-based, we can put the keyed hash in an
IPsec format. Just don't mess with IKE! Or the 4-bit processor on your
toaster will *really* start smoking!

---

From: "Rose, William" <[email-masked]>
Date: Mon, 27 Mar 2000 10:47:35 -0500

Coming at this from a Home Networks perspective, clocks, ovens, lights, and
other similar devices will be on subnetworks or clusters that are
(hopefully) connected to the zeroconfig network. They will not be on the
zeroconfig directly. This is a reality due to the costs associated with the
devices and the media they will run on. In many if not most cases, these
cluster networks will have their own security requirements. Especially since
they will often run on shared media such as powerline and wireless. And
since there are numerous protocols for the clusters, LonWorks, CEBus, Home
PnA, Home RF, Bluetooth, etc., they will not necessarily have compatible
security methodologies. We are discussing this issue at the CEA/VESA HN
subcommittee which is working on an IP 1394 backbone standard. While we have
not reached a consensus, it appears that there are only a limited number of
options:
A.	There could be a requirement for a single approach to security that
will be forced on all devices
B.	Anything wishing to control a device on a different cluster could be
forced to know that cluster's security approach, keys, etc. 
C.	Security within a cluster network could be stripped off by the
gateway/bridge/router connecting the cluster to other dissimilar clusters
and the rest of the world

There are problems with each. 
1.	If a single security approach is mandated, then all cluster
protocols must conform and use a common key (similar to one key to all of
your doors). Not likely to happen, especially for legacy devices. 
2.	If a single security approach is not mandated but the security stays
with the messages, then anyone wishing to control a device from outside the
cluster would have to know that cluster's security system. This seems
unacceptable since there would be multiple keys and approaches required for
every home requiring a great deal of configuration.
3.	If there is no single approach, and security is stripped at the
connection to the cluster, then there needs to be some security added to the
connections to the home that would then be stripped as it connects to the
clusters. Even if there is no connection to the rest of the world, there
will be connections on the outside of the house (a deck, at the pool, etc.).
These need to be secure.

I don't have the answer, I am just pointing out the reality. The industry
needs an answer to this sooner rather than later. 

Bill Rose
Chair, CEA Home Network Committee

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, March 26, 2000 2:26 PM
To: [email-masked]; [email-masked]
Subject: RE: Zeroconf security

Franklin Reynolds
Nokia Research Center