Subject: summary of 'zeroconf security - conclusions'

From: Erik Guttman <[email-masked]>
Date: Tue, 27 Jun 2000 15:53:14 +0200 (MET DST)

The following is a long overdue wrap up of the thread last month:

  'zeroconf security - conclusions'

I will post a revised set of conclusions following this message.

I am omitting calls for either not supporting security or claiming
that it is out of scope, since security (configuration) *is* on the
WG charter.

Erik

---
1) Should we consider securing ARP to protect address configuration 
   against a 'hoarding attack'?  The DHC WG says no.

   ARP is not the only issue.

   DHCP servers would have to be able to distinguish between bogus
   and a legitimate requests for addresses.  This is not possible now.

Thomas Narten <[email-masked]>
  http://www.merit.edu/mail.archives/zeroconf/msg00659.html

---
2) Securing the network or securing the device?

Erik Guttman <[email-masked]> proposed:
> It is not specified in the requirements whether security is
> on by default or not.  ...  It is out of the scope of the WG
> to do more than point this out.
  http://www.merit.edu/mail.archives/zeroconf/msg00616.html

Thomas Narten <[email-masked]> replied:
> I'm not sure it makes complete sense to talk about security being on
> or off by default. If a home user decides he wants his network to be
> secure, new devices shouldn't just work when plugged in until they
> have been properly secured. This is regardless of whether the new
> device is configured to be secure or not out of the box.
>
> An alternate way of looking at this is that by defualt all new devices
> MUST be able to determine whether security is enabled or not (on the
> network to which it is connected) and if so, do the necessary things
> to configure itself to operate in a secure environment. I.e., the
> device doesn't get to decide, the network to which it attaches has
> presumably already decided.
  http://www.merit.edu/mail.archives/zeroconf/msg00659.html

Agreement with Thomas from Peter Johansson <[email-masked]> 
  http://www.merit.edu/mail.archives/zeroconf/msg00663.html
and Richard Johnson <[email-masked]>
  http://www.merit.edu/mail.archives/zeroconf/msg00664.html

Ross Finlayson <[email-masked]> added:
> Jeff also made another good point at Adelaide: It may be acceptable
> (in some cases) for zeroconf systems be without security *initially*,
> but then require some minimal configuration soon afterwards to set
> security parameters.
 -<snip>-
> I.e., "zeroconf" in this case would apply only to the device's ability
> to announce itself to the rest of the network after initially being
> turned on, and start up in "Here I am, but now I need to be configured"
> mode.  Now it's true that this creates a window of vulnerability
> (between turning the device on and configuring it for security) where
> an attacker could intervene and (mis)configure the device for himself,
> but this may often be an acceptable threat.  (This was the essence of
> Jeff's comment, I think.)
  http://www.merit.edu/mail.archives/zeroconf/msg00641.html

Thomas Marshall Eubanks <[email-masked]> was more pessimistic:
> This would definitely fail the "my mother" test
 -<snip>-
> Also, does this mean that such a device would require reconfiguration 
> every time it was moved from one net to another ? If I take my radio 
> on vacation, I have to re-enter a password ?!?
  http://www.merit.edu/mail.archives/zeroconf/msg00644.htm

Thomas Narten <[email-masked]> suggested how this could be
implemented in an intuitive way, for consumers.
  http://www.merit.edu/mail.archives/zeroconf/msg00658.html

Donald E. Eastlake 3rd <[email-masked]> agreed with Thomas's
suggestion's being simple enough.
  http://www.merit.edu/mail.archives/zeroconf/msg00656.html

Peter Johansson <[email-masked]> was concerned about the risk at 
the time of configuration, and suggested quaranting the network.
  http://www.merit.edu/mail.archives/zeroconf/msg00643.html

Steve Hanna <[email-masked]> suggested instead a 'secure
network' especially for configuration, and other mechanisms.
  http://www.merit.edu/mail.archives/zeroconf/msg00648.html

---
3) ZEROCONF requirements will be silent to whether hosts implement
   security mechanisms for *non-zeroconf protocols* (DHC, DNS, SLP DAs,
   MADCAP, etc.)

   http://www.merit.edu/mail.archives/zeroconf/msg00618.html
   http://www.merit.edu/mail.archives/zeroconf/msg00622.html
   http://www.merit.edu/mail.archives/zeroconf/msg00662.html

---
4) Can we concentrate on the remote threats and allow social
   mechanisms to counter threats due to sharing a network with
   physically close neighbors?

   No.

Peter Johansson <[email-masked]> 
   http://www.merit.edu/mail.archives/zeroconf/msg00626.html
Steve Hanna <[email-masked]> 
   http://www.merit.edu/mail.archives/zeroconf/msg00625.html

---
5) Use of link level security or IPSec with a shared key to secure 
   zero configuration protocols?

Suggested by Steve Hanna <[email-masked]> 
   http://www.merit.edu/mail.archives/zeroconf/msg00625.html

Bernard Aboba <[email-masked]> replied that link-level security
requires all access points be secure.  He liked the idea of using 
IPsec to secure ZC protocols, but thought it may not be reasonable to
require that devices implement it.
  http://www.merit.edu/mail.archives/zeroconf/msg00627.html
  http://www.merit.edu/mail.archives/zeroconf/msg00630.html

---
6) What does "manual keying" implicitly require of a low-end 
   device's user interface capabilities?

From Peter Johansson <[email-masked]> 
  http://www.merit.edu/mail.archives/zeroconf/msg00635.html

Aidan Williams <[email-masked]> wrote:
> For symmetric keys, you need a way of getting the key
> to your devices without other people being about to
> snarf a copy as it goes by.
 -<snip>-
> My feeling is that manual keying really means that
> device devices will use contact/touch/a wire or a really
> short range wireless link to provide an out-of-band channel
> over which manual keying can be performed.
>
> People aren't going to type in strings of hex digits,
> and besides, where's the keyboard?
  http://www.merit.edu/mail.archives/zeroconf/msg00645.html

Thomas Narten <[email-masked]> wrote:
> The key doesn't get transferred in the clear. Ever. There are
> standard ways of generating session keys (e.g., diffie-hellman)
> that allow two unknowns to create a private channel over which
> they can communicate secretly. So this should be a non-problem
> in practice.
http://www.merit.edu/mail.archives/zeroconf/msg00660.html

---
7) Securing the LAN?  Is local encryption needed?

Thomas Narten <[email-masked]> argues that it may be
unacceptable to have arbitrary traffic sent in the clear.  He
proposes that maybe ZEROCONF or another WG should look at the
problem of 'securing a LAN' (or set of LAN segments) where 
everyone on the 'inside' trusts each other and all traffic
will be encrypted and authenticated.  Key distribution
will be 'interesting' since we want it to be as minimal to
configure as possible.
  http://www.merit.edu/mail.archives/zeroconf/msg00661.html

Richard Johnson <[email-masked]> believes that link-layer 
mechanisms may provide enough security at L2.
  http://www.merit.edu/mail.archives/zeroconf/msg00665.html

Rose, William <[email-masked]> agrees with Richard Johnson
but adds that there are other considerations:  (1) traffic
analysis, (2) manual intervention - so that a device can only
join the network if it is physically 'set up' (at the minimum
a button pressed, etc.) 
  http://www.merit.edu/mail.archives/zeroconf/msg00666.html