Subject: RE: zeroconf security - conclusions

From: "Walker, Jesse" <[email-masked]>
Date: Wed, 3 May 2000 11:43:52 -0700

Erik:

Very nice summary. I agree with most of it, and so raise questions about
only a handful of the statements from your text.

  0.3) The scenario in which these threats occur is 'remote access.'
       As Jeff Schiller pointed out in Adelaide, there are social 
       mechanisms for security at home and between neighbors.  The
       real threat is the anonymous stranger attacking from afar.

Wireless is changing this, unless people install their wireless LANs
outside their home firewalls. It is a very large leap of faith to
assume people will do this.
       
       Configuration for such networks can be very simple (such as
       a group key) since we don't have to differentiate between users
       and devices on a zeroconf network.

It is not evident that group keys can provide any kind of a useful
solution for many problems, especially because of the emergence of
wireless. Use of group keys means LAN users need to reconfigure all
the devices relying on these keys to reestablish security in the event
of divorce or betrayal by a previously trusted friend. If wireless
indeed makes easy revocation a requirement, as I think it does, then
it is unfortunately hard to imagine anything short of a credentials
management scheme being part of the solution. If this is the case,
the proper requirement is that the credentials management scheme has
to be simple to use.

   2.1) Hosts MUST implement a security mechanism (or mechanisms) to 
        protect against the following threats:

         + Hoarding attack.  A host MUST be able to determine whether a
           multicast address allocation claim (used in a claim and defend
           protocol) is legitimate or not.

Depending on your assumptions about overall network size and credentials
management schemes deployed, this might not be feasible except by using
asymmetric key techniques. My guess is the low end market will be
unwilling to pay the computational and administrative costs associated
with existing asymmetric key techniques for a very long time. Perhaps
this requirement should be a MAY; or it may simply require more
discussion to narrow the requirement sufficiently to something vendors
can implement and users will actually deploy.

   2.2) Hosts MUST be configurable to use that security, as easily
        as possible.

My concern with this is we need to specify what we means by "security".
Without doing that, this is a very open-ended requirement, and we will
never be able to determine when implementations do or do not conform.
 
Jesse Walker
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro, OR  97214-5961

(503) 712-1849
[email-masked]

---

From: Erik Guttman <[email-masked]>
Date: Thu, 4 May 2000 17:00:39 +0200 (MET DST)

Walker,

> Use of group keys means LAN users need to reconfigure all

Is easy revocation a requirement?  Or does easy configuration (and
reconfiguration, say contingent upon physical access to the device) 
satisfy this?  After a break up, just call the locksmith.  You don't
need restraining orders, revised contracts, etc. normally.

I am concerned that if the security requirements are complicated we
won't make any headway.  If they really are complicated, good to know.
But maybe we can keep this simple.
 
> can implement and users will actually deploy.
 
Or can we drop this requirement?  The DHC WG agreed that ARP security was
a non-starter.  Service discovery and name to address resolution aren't
subject to hoarding attacks.  How vital is it to protect networks from 
multicast allocation hoarding attacks? 

I did not mention that some work has gone into protecting neighbor discovery
in IPv6 (which would defend against hoarding attacks as a result).

Dan, do you want to say something about this?

> never be able to determine when implementations do or do not conform.

That's what I'm trying to specify in section 2.1.  These are requirements
we are discussing, so the specification is necessarily high level.  If
there are too few or too many security features in that list - let's
discuss it now.

Erik

---

From: Thomas Narten <[email-masked]>
Date: Thu, 11 May 2000 13:53:16 -0400

>        real threat is the anonymous stranger attacking from afar.

I think the point Jeff is making is that the real threats people are
dealing with today are not folks *physically* close by, but random
hackers at random places in the network that target addresses at
random (i.e., probing) looking for vulnerabilities. zeroconf
absolutely can't be vulnerable to random attacks from outside. Note
that in these scenarios, remote hackers don't see the packets going
back and forth on the wire.

> assume people will do this.

I agree that wireless will change the rules. But I believe the two
cases are still somewhat different. With wireless LANs, targetted
attacks from folks physically nearby become feasible. But this is a
different kind of threat and in many (most?) cases won't be a
problem. But it likely will be enough of a problem in specific cases
that just ignoring it isn't acceptable.

I'm thinking that one of the potential big unacceptables will be
having arbitratry traffic be sent in the clear on the wire. Do you
trust your software and protocols to not accidentally make it possible
for neighbors with sniffers to read your credit card reports, tax
returns, bank statements, everything sent to your printer, etc.?

Protecting against this kind of threat I think needs some
thinking. Perhaps this is a new type of threat that zeroconf will need
to deal with *not* because it is *caused* by zeroconf, but because
wireless is assumed to be a big part of zeroconf deployment, so it
becomes a concern in the zeroconf environment.

I wonder if zeroconf (or another WG) should look specifically at the
problem of securing a "LAN" (where I mean "LAN" in the sense of a set
of nodes, maybe even involving a few LANs segments). That is,
developing the protocols necessary to make it straightforward to build
a network in which everyone *inside* the network trusts each other
(i.e., they aren't attacking each other), but trusts no one outside of
the "trusted" network. All intra-LAN traffic could be
encrypted/authenticated. 

This is probably doable with IPsec and symetric keys (multicasting
will be a bit tricky). Key distribution would also be interesting,
since this needs to be as close to zeroconf as possible.

But it seems like we have a problem here that just can't responsibly
be ignored.

Thomas

---

From: Richard Johnson <[email-masked]>
Date: Tue, 16 May 2000 17:59:46 -0700 (PDT)

> that just ignoring it isn't acceptable.

I'm beginning to think that wireless networks shouldn't really change
things wrt. zeroconf.  I understand this is a radical change from the
prevailing opinion here, so let me explain.

Sniffing packets as well as injecting packets by simply being "close
by", simply because you're using a wireless LAN, is very similar
to plugging a computer directly into the physical LAN.  This means
that for all practical purposes having a wireless LAN card allows
you all of the same privileges as being inside the building!  This
is exactly why wireless companies have already come up with WEP
(Wired Equivalent Privacy) and other types of encryption.  By
addressing the wireless need for encryption at the lowest layer,
it means that all layers above that are automatically taken care
of.

That is, assuming you believe that the low layer encryption on the
wireless LAN is "good enough".  If you don't, then you have an
argument for a better encryption method on wireless LANs (and thus a
market).

This statement in no way should be taken as meaning that I believe
security is not needed.  Just that wireless LANs don't, by themselves,
necessitate security in the protocols involved.

/raj