Subject: RE: zeroconf protocol security

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 14 Jan 2000 09:21:07 -0800

I also prefer option 1.

-myron

> > 4.2.1  IP Host Configuration
> >
> >    Hosts MUST be able to be configured to use DHCP authentication.
> >
> >    Option 1:
> >
> >       No provision is made for securing IP Host Configuration using
> >       the ZeroConf protocol for IP Host Configuration.
> >
> >    Option 2:
> >
> >       Hosts MUST be able to be configured to use a ZeroConf protocol
> >       for host configuration securely.  For example, a 
> claim and defend
> >       protocol used for host configuration would have to 
> include security 
> >       data with all messages.  A host in the ZeroConf 
> network could verify
> >       that another host's claim was legitimate or not.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 15 Jan 2000 10:16:36 -0800

> >    Hosts MUST be able to be configured to use DHCP authentication.

I'm curious as to whether the intent of the above is to add DHCP
authentication support as a Host Requirement, since you can't
configure a host to use DHCP authentication unless the host supports
the protocol in the first place. I might substitute something
along the lines "if the host supports DHCP Authentication then
it must be configurable to use it in a zeroconf environment."

I'd also note that DHCP authentication comes in several flavors.
In the Appendix of the draft there is a "Universal secret" proposal
which allows all DHCP keys to be derived from a single master secret. 
This isn't particularly secure (since everyone knows the master
secret) but it is simple. Is this what folks had in mind?

---

From: Erik Guttman <[email-masked]>
Date: Sun, 16 Jan 2000 19:42:18 +0100 (MET)

> secret) but it is simple. Is this what folks had in mind? 

I added this mainly to provoke discussion.  The basic question is do
we specify mandatory support for security capabilities or not?  Would
it be acceptable (to the IESG, IETF, etc.) if ZC didn't specify how to
transition to secure operation from insecure zero configuration protocols
for each protocol area?

Erik

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 18 Jan 2000 12:40:35 -0800

>Would it be acceptable (to the IESG, IETF, etc.) if ZC didn't specify how
to
>transition to secure operation from insecure zero configuration protocols

It would be useful to be able to take a work laptop that was
configured securely and bring it home  without having to
reconfigure everything. I hope we can achieve that.

I think this raises some interesting questions though. To make this
transition, you need to have an idea of where you are. If the
protocols involved don't allow this to be communicated, or if
credentials can't be negotiated, then this kind of graceful
transition between locations will be difficult to achieve.

I don't want to pick on DHCP authentication, but I think it's
a good example of the issues that you can run into. Ideally,
I'd want to be able to bring my laptop to work and have it
authenticate there, but when it comes how where my DHCP is
*unauthenticated* I'd want it to work there too.

Let's assume I bring the laptop home, where there is no
DHCP authentication. My laptop doesn't know it's home and
so it is set for authenticated DHCP. Unless it will
accept unauthenticated DHCPOFFERs I am going to refuse
all DHCPOFFERs and end up auto-configuring my IP address.
Configuring the laptop to always accept unauthenticated
offers might not make sense for my office environment, so
unless I can know for *sure* that I am home, I'll have
a problem.

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 18 Jan 2000 21:28:07 -0500

Bernard, et. al.,

I came into this discussion late, my apologies, so
I don't have a lot of historical reference on what has
been discussed on the mailing list thus far.

Having said that, I'm a little concerned on the "obsession"
with authenticated autoconfig, at least in the short term.
It would appear to me (personal opinion only) that trying to
achieve "perfect" or "near-perfect" encrypted autoconfig as
a first phase deployable protocol is a non-starter, and not
reasonable for this working group as a deliverable to satisfy
what is need in the short-term.

And, having said that, I would be quite content to see an
in-home, or end-user, device use simple DHCP as an autoconfig
mechanism in the short-term (perhaps with some extensions), and
worry about secure autoconfig cruft as a longer-term issue, perhaps
on the order of a year, or two. There are standards & deployment
issues outside the scope of the WG which deal with the issues (which
we cannot directly control) which may not "bake out" completely
for ZC to be a "secure" service from Day 1.

As I said, I've missed all the discussion prior to today, and I'm
happy to entertain any reasoning on why I'm completely off-base.

Thanks,

- paul

---

From: Erik Guttman <[email-masked]>
Date: Thu, 20 Jan 2000 10:35:48 +0100

Paul,

The underlying concern is that we don't make IP *less* secure
by adding ZeroConfig features.

There are basicly two possibilities.  The WG could assert that:

 * Host autoconfiguration should be done without security
   as autoconfiguration is used precisely on networks with 
   zero or very little administration

 * Dynamic host configuration (ie. DHCP) will define its
   own mechanisms and requirements for authentication -
   it is beyond the scope of the ZEROCONF WG to define these
   requirements

Or:

 * Host autoconfiguration protocols have to include configurability
   for secure operation so that it is possible to restrict access
   to network resources 

 * DHCP security is a requirement for ZeroConf protocol hosts
   since without it any host masquerading as a DHCP server 
   could disrupt ZeroConf operation

What do you all think?  Note that there is an analogous set of
choices to be made for DNS, MADCAP and {SLP,SSDP,???}.

Paul, I agree that if we do require authenticated autoconf from the 
beginning we will raise the bar and complicate standardization &
deplyability.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Thu, 20 Jan 2000 11:29:14 +0100

> unless I can know for *sure* that I am home, I'll have

Let's follow this through:  If I set up security parameters, I expect 
my computer to use them - as the default.  I get configured as long as 
I am at work, but when I come home - I don't.  

If I *automatically* switch to zero-security operation, I will not be 
secure at work any more.  

IMO if you configure a system, you have to configure it again to get its
behavior to change.  

The human interface issue is like *I've put a padlock* on my system's
fuse 
box.  Its my choice to *take the padlock off* and open the system up for 
anyone to rewire it.

Erik

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 20 Jan 2000 06:01:33 -0500

>by adding ZeroConfig features.

Agreed.

But let's examine this for a second. What feature(s) of IP
would be made less secure by making it possible for a device
to plugged into a ZC-capable segment and autoconfigured? I'm
not so sure this isn't a simple access-control issue.

>    could disrupt ZeroConf operation

Gut reaction: I'd personally opt for the former. The latter
would tend to lead towards feeping creaturism.

>beginning we will raise the bar and complicate standardization &

Ditto.

- paul

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 20 Jan 2000 08:34:28 -0500

> choices to be made for DNS, MADCAP and {SLP,SSDP,???}.

Here's one vote for the first alternative.

- Matt

---

From: Bob Quinn <[email-masked]>
Date: Thu, 20 Jan 2000 12:27:56 -0500

I would echo Paul's sentiments (below).  I have trouble 
imagining security without manual configuration, and since the 
goal here is zero configuration that would seem to rule out a 
security requirement (at least initially).  This seems reasonable 
since physical connection to the network is the first line
of defense and vulnerable connection-less media (e.g., wireless) 
typically have their own (configurable) security at the MAC layer.

With regards to Bernard's question, I think Erik's analogy to 
a padlock is fitting.  Security, in this respect, is binary: 
once turned-on it must require manual intervention to turn it off.  

rgds,
bq

---

From: "Myron Hattig" <[email-masked]>
Date: Thu, 20 Jan 2000 10:04:07 -0800

> Here's one vote for the first alternative.

I agree, the first alternative is the best and I think this will be true for
domain name resolution, multicast address allocation, and service discovery.
The gateway will have to provide secure access to the zeroconf network. In
addition, host-based security will utilize service specific security, virus
detection, etc., but these are outside the scope of the WG.

Going beyond the first alternative either violates our
non-user-configuration requirement or security requirements of whatever
protocol we are molding to be zeroconf. The example of bringing a laptop
home from work where authenticated DHCP is used illustrates this.

First note that if a laptop is using *non-authenticated* DHCP at work, then
using autonet at home does not violate any work-related security
expectations. Autonet *does* violate expectations of a host using
authenticated DHCP because autonet could be invoked on the secure network to
bypass the authentication server. A really paranoid authenticated DHCP
service administrator would not allow the laptop user to connect the laptop
to any network using autonet. A less paranoid administrator may provide a
tool to allow the laptop user to turn authenticated DHCP on or off (thus
turning autonet off or on).

This example shows two things: 1) either security requirements get violated
or our no-user-configuration requirement is violated; 2) this is a problem
for someone designing the authenticated DHCP service - not us.

-myron

---

From: Erik Guttman <[email-masked]>
Date: Fri, 21 Jan 2000 18:01:56 +0100 (MET)

> not so sure this isn't a simple access-control issue.

Say we have a wireless LAN and anyone within range may do address
autoconf, etc. and join.  Say that this LAN connects your thermostat,
garage door, etc.  I think that some access control to the services
and indeed to the network is desirable.  

The draft talks about 3 threats:  Hoarding, Masquerading and 
Antagonistic Server.  These are above and beyond access control.
Note that we are *not* talking about denial of service attacks
which is a problem we are not going to solve in ZEROCONF.  

The point is not that we should mandate security - we can't.
Nor that zeroconf networks should be automatically secure - this 
isn't possible unless they are configured.  The point is whether 
we should mandate that a host compliant with ZC requirements has 
a *way of being configured* so that it *could be secured* against 
the threats above.

Imagine I have buy a network enabled refrigerator.  I want it to be
able to be secured.  I may have to read the manual and set a dip
switch in the back or something.  But I don't want anyone but me to
defrost it. This is fundamentally an *application layer* issue and
out of scope of the ZEROCONF WG, right?

The other question is whether I care if someone else can claim to be 
the refrigerator, hoard all the addresses so the fridge can't configure 
on my network, etc.  I'm not sure about this & hope folks in the WG
can help me.  This would be in the scope of the ZEROCONF WG.

Part of the problem with this discussion is that it is quite abstract.
Hopefully we will see some discussion of specific mechanisms which 
are easy to configure, computationally non-intensive, and provide the 
basis protection against the threats we are discussing.

Erik

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 21 Jan 2000 13:05:53 -0500

> From: Erik Guttman

> a *way of being configured* so that it *could be secured* against

ZeroConf crosses a number of layer boundaries, and I don't think
that answers are the same at all of them.  At the IP layer, where
Hoarding and so on are the issues, I don't see an answer and so
don't think that we can mandate that one be provided.  At the
services layers the answers are different because the threats are
different.  I think it reasonable to say that we must allow for
mechanisms that keep my neighbors from even discovering that I have
an image repository named 'wedding night', or what model TV I have,
even if we share the same apartment building power-line LAN.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 21 Jan 2000 19:34:07 -0800

>I am at work, but when I come home - I don't.

This logic, if applied to its fullest extent, may require
reconfiguration of a device when it is moved
from location to location. That may not be practical for an
appliance.

>IMO if you configure a system, you have to configure it again to get its

Other zeroconf mechanisms, such as IP address autoconfig don't require
manual re-configuration, they just work.

>fuse box.  Its my choice to *take the padlock off* and open the system up
for
>anyone to rewire it.

Many of the devices that will be operating in the home and enterprise will
not have any UI or way of configuring them manually. Think about an IP
telephone or an IP toaster. You want to plug it in and have it function
correctly.

In many cases, this implies the ability of the device to ascertain what
regime it is in (zeroconf or non-zeroconf). However, in going through
a few different cases, (such as IP addr auto-conf, multicast auto-conf,
etc.)
we've found that the definition of the regimes needs to be clearly thought
through so that one can go back and forth between zeroconf and non-zeroconf
scenarios without problems.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 21 Jan 2000 19:22:04 -0800

>with authenticated autoconfig, at least in the short term.

Actually, my concern was not with authenticated autoconfig
at all. I'm perfectly happy to have zeroconfig
unauthenticated. 

My "obsession" (ok, I admit it!) is in making sure that
leaving zeroconf unauthenticated doesn't create problems
with machines such as laptops that may need to operate 
in both zeroconf and non-zeroconf environments. It would
appear that in many cases the trickiest part about
designing a zeroconf solution is not in figuring out how
to make it work, but rather in figuring out when to
apply it.

---

From: "Myron Hattig" <[email-masked]>
Date: Sat, 22 Jan 2000 13:01:32 -0800

Comments below ..

> from location to location. That may not be practical for an

I agree with both points - it may be required and may be impratical. Thus we
have a conflict.

> manual re-configuration, they just work.

At least as long as you do not introduce the need for authentication of an
IP addr.  ;-)

> scenarios without problems.

In the case of IP host config, a regime that has authenticated DHCP and
authenticated autonet are additional regimes beyond just zeroconf and
non-zeroconf ... I'd like to be proven wrong, but I don't think there will
be an "authenticated autonet", thus we won't be able to do anything these
regimes.

Stepping through your examples more ...
I think devices that need a dip switch or UI will provide it (e.g. IP
telephone, palm pilot) and those that don't won't  (e.g. IP toaster,
refrigorator, wireless remote).

Basically, I don't see any value-add from zeroconf for these cases ...
either authenticated DHCP is always required by the DHCP administator or the
admin allows the user to toggle authenticated DHCP off and on (maybe done
with other security measures such as encrypting sensitive data).

-myron