Subject: zeroconf security - conclusions

From: Erik Guttman <[email-masked]>
Date: Wed, 3 May 2000 17:20:33 +0200 (MET DST)

I have reviewed the thread on home networking security.  There has
been some excellent discussion.  This is an attempt to see what the
concensus was.

Remember that the primary goal of security work in the ZEROCONF
WG is to not make IP networking any less secure than it already is.

0 Scope of discussion:

  0.1) The ZEROCONF WG is working on 4 protocol areas - host
       configuration, service discovery, name to address resolution
       and multicast address allocation.  Application level protocols
       (including device control) are out of scope.

  0.2) The threats which have been discussed and broadly agreed upon
       are:

       . masquerading (A host uses zeroconf protocols to fool others
         by sending messages it shouldn't)
       . hoarding (A host subverts zeroconf protocols by pretending to
         have resources it doesn't have)
       . antagonistic server (This server undermines hosts because it
         uses a protocol which automatically configures hosts which
         use 'zeroconf protocols')

       Additional threats which were mentioned were:

       . Inventory attack - ZeroConf protocols (especially service 
         discovery) would allow thieves to take inventory very easily.
       . Evesdropping attack - Capturing ZC protocol messages issued by
         hosts use could inform about what the network is used for, how much 
         it is used, etc.         
       . Denial of service attack - But is there anything specific to
         Zero Configuration networking here? 

  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.
       
       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.

       We have to assume that an attacker can send and receive messages
       on the local network since in important cases Zero Configuration
       protocols will be used on shared access links (RF, power line,
       'neighborhood area network' cable subnets, etc.)

1 Conclusions of discussion:

  1.1)  Punting is not an option.  Security does require configuration.
        So, we have to consider the best, minimal configuration 
        requirements. The ZEROCONF charter includes the following text:

      ZEROCONF requirements will make networking as easy as possible, but
      no easier.  In some cases other considerations may dominate ease of 
      use.  For example, network security requires some configuration which 
      may not be as easy as the unacceptable alternative of 'no security.'    

  1.2)  We are only discussing security for ZC protocols and transitions
        to 'configured' protocol behavior.  Security for application level
        (device control) protocols is out of scope.  It may be that app 
        level protocols can share the same mechanisms, but that is not a
        requirement.

  1.3)  There is concern about the default value.

        - Security enabled means nothing works until it is configured.
        - Security disabled means many systems will be vulnerable (as
          one cannot expect all users to do security configuration).
        
        It was suggested that there can't be a hard and fast rule - for
        some applications 'ease of use' demands no security by default.
        In other cases, safety demands security by default.

   1.4) It was suggested that the ability to authenticate messages as
        having come from a peer with a shared secret may not be enough.
        Encryption capability, to provide privacy, was suggested as
        being important.

2 Requirements arising from discussion:

   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.

           Protecting against IP address hoarding is NOT a requirement
           for IPv4, since it would mean securing ARP.  That is the 
           concensus of the DHC WG.

         + Masquerading attack.  Service discovery, name to address
           resolution and multicast address allocation services MUST 
           support a mechanism so that legitimate and illigitimate 
           responses can be differentiated.  (Note that in the case 
           of name to address resolution, this protects against a
           'hoarding attack.' A malevolent host couldn't respond
           to all names to prevent 'nameless' host from picking a 
           unique name.)

         + Antagonistic server attack.  The host MUST be able to determine
           whether a discovered DHCP server, DNS server, SLP DA (or 
           whatever) or MADCAP server is to be used or not.

           NOTE:  This requirement *looks good,* but how many systems in 
           practice are enabled to use DHCP authentication, DNSSec, SLP
           authentication and MADCAP security?  We are 'raising the bar'
           by requiring this, not avoiding 'making IP less secure' which
           is our guiding principal.  

        Hosts MAY implement security mechanism to protect them against
        the following threats:

          + Evesdropping attack.  The host MAY be able to encrypt
            service discovery, name to address resolution messages.
            Host configuration (ie. ARP and DHCP) and multicast 
            address allocation messages (ie. MADCAP) do not require 
            encryption as there is little to be learned from them.

   2.2) Hosts MUST be configurable to use that security, as easily
        as possible.
 
   2.3) It is not specified in the requirements whether security is
        on by default or not.  Note that if security is on by default
        and the host is unconfigured that implies that the host is not
        usable *until it has been configured.*  Some devices (such
        as those which are dangerous) should require a priori 
        configuration.  It is out of the scope of the WG to do more
        than point this out.

   2.4) Security mechanisms used for the four protocol areas covered
        by Zero Configuration requirements should be the same if         
        possible so they can:
         + share common implementation
         + share common configuration
         + be as easily administered as possible
     
Please send your feedback.  If there is broad agreement, I will
turn this into an internet draft.  Whether we ultimately separate
out the security requirements for ZC networking from the current
document or not, I would like to focus attention on it so we can
make rapid progress.

Once we complete our 'requirements' work, we can work on defining
the security mechanisms to fulfill the requirements.  Whether this
should take place in the current ZEROCONF WG or a new WG needs to 
be chartered is a separate discussion.   Stay tuned.

Erik

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 3 May 2000 09:56:24 -0700

>Antagonistic server attack.  The host MUST be able to determine

>       authentication and MADCAP security? 

If one assumes that all of these services reside on a home
gateway, it may be quite reasonable to come up with a 
relatively simple way of securing all of them. However,
saying that the host MUST be able to use it seems like
raising the bar too high, given that very few hosts can
do this today.

---

From: Peter Johansson <[email-masked]>
Date: Wed, 03 May 2000 22:52:35 -0700

At 05:20 PM 5/3/00 +0200, Erik Guttman wrote:

<<2.3) It is not specified in the requirements whether security is on by
default or not.  Note that if security is on by default and the host is
unconfigured that implies that the host is not usable *until it has been
configured.*  Some devices (such as those which are dangerous) should
require a priori  configuration.  It is out of the scope of the WG to do
more than point this out.>>

I think a useful zero configuration draft is going to have to do more than
make the observation that, "Well, you can have security enabled or you can
have it disabled."

The key element is informed consent of the user. If I buy a device labeled
"SECURE" or "INSECURE" there need to be some minimal behavioral
expectations upon which I can rely. I don't single out this WG for
criticism---I think the problem of inadequate disclosure of security risks
is rampant in the current rush to deploy broadband---but I don't think the
working gruop can punt on this one, either.

I'm sorry I don't have a ready-made solution, but I do think more
discussion will be needed on this issue, that it's not sufficient to
describe the pros and cons.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Peter Johansson <[email-masked]>
Date: Wed, 03 May 2000 22:52:17 -0700

<<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.>>

If I have been tripped up by some subtle meaning of the word "remote" above
(and consequently misunderstand the conclusion) please excuse me.

But if I read it correctly, I don't feel at all secure that I have adequate
social mechanisms for addressing security transgressions by my neighbors!
Adequate "social mechanisms" work just fine when the problem is as minor as
your neighbor's annoying, constantly barking dog or incessant wind
chime---no lasting harm is done in the interval that social mechanisms
yield a resolution. If the social mechanisms fail, the continuing harm done
is of a relatively minor scale.

But if we're talking about my private and sensitive data, I am not willing
to wait to apply "social mechanisms" until after a sociopathic neighbor has
made off with the goods! or regularly and consistently denied me use of my
system!

So, someone, please tell me I've completely misunderstood what has been said.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Erik Guttman <[email-masked]>
Date: Thu, 4 May 2000 16:30:33 +0200 (MET DST)

> raising the bar too high, given that very few hosts can

SHOULD?  MAY?  Or is this really out of scope?  

Would we be specifying requirements for clients of *non-zeroconf* 
protocols?

Erik

---

From: Erik Guttman <[email-masked]>
Date: Thu, 4 May 2000 16:41:37 +0200 (MET DST)

> social mechanisms for addressing security transgressions by my neighbors!
...
> I am not willing to wait to apply "social mechanisms" until after a
> sociopathic neighbor has made off with the goods! 
...
> So, someone, please tell me I've completely misunderstood what has been said.

You didn't misunderstand.  Is your claim is that normal social mechanisms
are OK for noise, smells and so on, as they 'stay on the other side of
the fence (are clearly coming from your neighbor's place, etc)?'  But 
with shared access media (wireless, power line, network area cable 
subnets) we have no 'walls' between us an our neighbors?  

In this case, should we modify the scenario to be a binary 'insider' / 
'outsider' model.  Like those who you give a housekey to, and those you
don't?  (Is the problem with the 'close' / 'remote' model is that trust
and effective reprisal mechanisms aren't 'proximity' based, they're more
'who knows which flower pot the house key is hidden in' based?

Erik

---

From: Steve Hanna <[email-masked]>
Date: Thu, 04 May 2000 10:57:27 -0400

Thanks for a good summary, Erik. Clearly, there are still some
unresolved issues. But agreeing on which protocols are in scope and
providing a list of generally agreed-upon threats is a good start.

>        'neighborhood area network' cable subnets, etc.)

If an attacker can send and receive messages on the local network (and I
agree with that), that's the important thing from a security
perspective. Whether the attacker is a neighbor or not is not important.
I suggest you drop the first paragraph here, unless you can explain some
way in which it changes the security analysis.

...

>            is our guiding principal.

If we don't protect against IP address hoarding and we don't protect
against an antagonistic server attack, we're leaving two big holes in
our security system.

I agree that securing ARP and authenticating servers isn't easy. But we
can't just stick our heads in the sand.

What about a simple solution like link-level encryption using a shared
key (such as 802.11 WEP)? Or layer 3 crypto with a shared key (IPsec
without IKE)? This would secure all network access with a single
mechanism. Admittedly, it doesn't have all of the features of
protocol-specific security, but it *is* fairly simple! And it addresses
all of the threats we have listed.

-Steve

---

From: Peter Johansson <[email-masked]>
Date: Thu, 04 May 2000 10:12:45 -0700

At 04:41 PM 5/4/00 +0200, Erik Guttman wrote:
<<Is your claim is [sic] that normal social mechanisms are OK for noise,
smells and so on, as they 'stay on the other side of the fence (are clearly
coming from your neighbor's place, etc)?'  But with shared access media
(wireless, power line, network area cable subnets) we have no 'walls'
between us an our neighbors?>>

Yes, just so.

<<In this case, should we modify the scenario to be a binary 'insider' /
'outsider' model.  Like those who you give a housekey to, and those you
don't?  (Is the problem with the 'close' / 'remote' model is that trust and
effective reprisal mechanisms aren't 'proximity' based, they're more 'who
knows which flower pot the house key is hidden in' based?>>

Yes, the "neighbor" defined by proximity is not necessarily manageable. But
the "neighbor" that I can pick and choose, can elect to tell the location
of the digital flower pot that holds the key, is manageable. And, as Jesse
Walker observed, one can always call the "locksmith" ...

Regards,

Peter Johansson

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

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

[email-masked]

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 5 May 2000 06:36:20 -0700

>key (such as 802.11 WEP)? 

This can work as long as you assume that the hosts all attach to a
central bridge, as with 802.11 access points. However, if it is
possible for outsiders to attach to the same LAN segment as
insiders, without an intervening bridge, then this will not help. 

This is one of the reasons that I am uncomfortable with powerline
and phoneline networks -- particularly since the cost of 802.11
is declining so rapidly. This makes the security risks seem hardly
worth the delta in cost (which may soon be zero or even negative). 

>Or layer 3 crypto with a shared key (IPsec
>without IKE)? 

I think you actually mean manual keying. Pre-shared keying 
does require IKE. 

While I've always liked the idea of securing hosts via IPSEC,
I don't know how reasonable it is to require that devices
secure themselves this way.

---

From: Erik Guttman <[email-masked]>
Date: Fri, 5 May 2000 16:06:55 +0200 (MET DST)

Bernard, Steve,

> insiders, without an intervening bridge, then this will not help. 

I am concerned about proposals for L2 security ZC requirements.  The
IETF works at L3 and above.  Also, many link layers are not secure 
(and never will be).

> secure themselves this way. 

Let's pursue this.  Would it be feasible to counter the 
identified threats and meet our goals with a L3 layer 
security mechanism (IPSec)? 

Erik

---

From: Daniel Senie <[email-masked]>
Date: Fri, 05 May 2000 10:55:04 -0400

> IETF works at L3 and above.  Also, many link layers are not secure

The IETF most certainly works on problems below layer 3. PPP, for
example, is not a layer 3 item. There are many other examples.

I am not in favor of mandating IPSec in ZC. It would be an admission of
defeat for this WG, since IPSec will require configuration. 

I believe wired Ethernets are secure enough if physical security is
maintained. 802.11 networks with WEP is being pitched as safe. After
all, that WEP is "wire equivalent privacy." Can someone tap your wires?

The question here is whether ZC should specify the minimum required
capabilities for the link layer. This is not below IETF's venue. Look at
the PILC working group for an example. Phil Karn and company are
producing a document to explain to link layer technology developers the
kinds of facilities that must be present to run IP successfully.
Recommendations that 802.11 WEP be employed in ZC networks seems to be
in a similar vein.

> security mechanism (IPSec)?

Sure. With configuration. Runs counter to the name of the working group,
me thinks.

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 5 May 2000 08:31:27 -0700

>security mechanism (IPSec)? 

IPSEC solves a lot of the threats that you described, 
plus a bunch of other ones that are out of scope but
still important. Personally, I would rather we look
at IPSEC than worrying about multicast address
hoarding attacks, for example. 

Since we're talking about some subset of IPSEC
functionality, it's probably appropriate to have
some discussion of what it is possible to do
on what devices. On a host, I would argue that
there is no need for a subset; a consumer machine
can do IPSEC with IKE as easily as IPSEC with
manual keying and the former is more secure, so
there's little point in reducing functionality. 

However, on a device there may be issues.
I'm curious to understand what these are
exactly before we start chopping. For example 
are there issues with implementation of cert 
handling, cryptosuites, IKE, etc. Some set
of base assumptions would be helpful.

---

From: Erik Guttman <[email-masked]>
Date: Fri, 5 May 2000 18:15:59 +0200 (MET DST)

> Sure. With configuration. Runs counter to the name of the working group,

The charter says:

  ZEROCONF requirements will make networking as easy as possible, 
  but no easier.  In some cases other considerations may dominate 
  ease of use. For example, network security requires some
  configuration which may not be as easy as the unacceptable 
  alternative of 'no security.' 

Erik

---

From: Peter Johansson <[email-masked]>
Date: Fri, 05 May 2000 09:39:44 -0700

The charter says: "ZEROCONF requirements will make networking as easy as
possible, but no easier.  In some cases other considerations may dominate
ease of use. For example, network security requires some configuration
which may not be as easy as the unacceptable  alternative of 'no security.'"

Let's face it, marketing-think and marketing-speak have surreptitiously
co-opted our habits in many other fields of endeavor. As the charter
states, the real goal is "minimal configuration"---but MINCONF just ain't
as catchy, sexy or snappy as ZEROCONF. Even though it's more accurate.

What customer wouldn't prefer to buy a "zero configuration kit" for
anything rather than a "minimal configuration kit"? Maybe only a customer
who's been educated to understand there is no such thing as a free lunch.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Steve Hanna <[email-masked]>
Date: Fri, 05 May 2000 17:03:52 -0400

> of base assumptions would be helpful.

I would be pleased to use IPSEC for ZC, if possible. I have two primary
concerns: performance and configuration.

First, performance. Public key crypto is too slow for most low-end
devices. Performing a single public key operation can take hours or days
on a slow 8-bit controller with no hardware crypto assist. And moving to
a faster processor or one with hardware assist will increase cost too
much for a low-end device. I think we need to stick with symmetric key
crypto for this application. For IPSEC, I guess that means manual
keying, probably using a group key shared by all zeroconf devices in the
zeroconf domain.

Second, configuration. We want to keep things as close to zero
configuration as possible. Configuring a group key will be painful, but
maybe we can explore a few ideas for making that configuration easier.

One big plus with IPSEC is that it can span multiple links. Also, there
are lots of libraries available.

-Steve

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 5 May 2000 14:24:50 -0700 (PDT)

> concerns: performance and configuration.
Does IPsec has everything what ZC needs ? I am referring to the
Erik's mail where he had listed the threats. 

-mohan

---

From: Peter Johansson <[email-masked]>
Date: Fri, 05 May 2000 14:44:43 -0700

At 05:03 PM 5/5/00 -0400, Steve Hanna wrote:

<<I think we need to stick with symmetric key crypto for this application.
For IPSEC, I guess that means manual keying, probably using a group key
shared by all zeroconf devices in the zeroconf domain.>>

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

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 09 May 2000 13:04:28 -0700

>        real threat is the anonymous stranger attacking from afar.

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.

E.g., consider how a a user might set up a new, 'shrink-wrapped' network 
appliance (that he just bought from Wal-Mart, e.g.).  One can imagine the 
user plugging the appliance into his home network and turning it on, and 
having it then be automatically reachable from his home's control center - 
i.e., "zeroconf".  However, in order to continue to use the appliance, the 
user could then be required to 'configure' it from his control center - 
e.g., to set up keys.  Only then would he be able to use the appliance's 
full functionality.

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.)

Stepping back now and taking a wider view: I'm worried that this group may 
be biting off more than it can chew.  I thought that one of the initial 
motivations for this working group (at least, as Stuart Cheshire described 
it) was the ability to easily, and without explicit configuration, form "ad 
hoc" networks of nodes that *aren't* connected to the global Internet - 
e.g., two or more friends meeting in a coffee shop with their wireless 
laptops and wanting to share data.  In this sort of scenario, security is 
less of an issue.

Perhaps we should begin by defining (& documenting) how 
non-Internet-connected "ad hoc" networks would work.  This seems like a 
much easier task.  Having done this, we could *then* continue on to 
defining how such networks could become connected to the global Internet...

         Ross.

---

From: Peter Johansson <[email-masked]>
Date: Tue, 09 May 2000 14:28:07 -0700

At 01:04 PM 5/9/00 -0700, Ross Finlayson wrote:

<<I.e., "zeroconf" in this case would apply only to the device's ability to
an acceptable threat.>>

If there's some way for the "proper" source of configuration to detect
whether or not tampering has occurred in that window and if there's some
easy way for a consumer to reset the device so as to undo the tampering,
then this might be workable.

In an ideal world, it would be useful for a user to be able to temporarily
"quarantine" her home network while configuring a new purchase. The concept
of such a "sterile procedure" should not be too hard to explain in the
user's guide that comes with the new product. I think that the ability, at
times, to sever one's connection with the larger Internet (perhaps to run a
diagnostic from the "zero" configuration control center) would be useful.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Tue, 09 May 2000 22:37:00 -0400

> >        real threat is the anonymous stranger attacking from afar.

I can just wait for the divorce cases where, in addition to cleaning out the bank
account, the disaffected spouse sets the radio to change channels every 30 seconds,
the TV to only play porn, and all of the kitchen appliances to fail at
1:30 in the afternoon on Thanksgiving,  (I have seen worse  happen in real
divorce cases...)

> e.g., to set up keys.  Only then would he be able to use the appliance's

This would definitely fail the "my mother" test (i.e., a zero config device
should be simple enough for < insert name of favorite older relative > to
use). I suspect that my actual mother would either not do it, or
would call in an expert.

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 ?!?

> defining how such networks could become connected to the global Internet...

I would agree with this, especially as I suspect that the real security concerns
will only become obvious with time.

--
                                 Regards
                                 Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : [email-masked]

---

From: Aidan Williams <[email-masked]>
Date: Wed, 10 May 2000 16:37:09 +1000

> What does "manual keying" implicitly require of a low-end device's user

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.

If you have lots of devices on a network sharing the same
symmetric key,  and you transfer the key over the network
each time you configure a new device, the risk of someone
grabbing a copy of the key goes up.  It becomes a waiting
game, and someone will write the equivalent of a password
sniffer which will do the waiting for you.

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?

regards
	aidan
____
:wq!

---

From: Steve Hanna <[email-masked]>
Date: Wed, 10 May 2000 12:54:43 -0400

> diagnostic from the "zero" configuration control center) would be useful.

Quarantining a *wireless* network isn't easy. As Aidan Williams wrote,

> <snip>

Establishing keys on a temporary secure net (like a wire) is a good
idea. You bring home your toaster, plug the AC plug into your home
controller's special outlet, and it gives the manual key to the toaster. 

Alternatively, the toaster could come with a sealed slip of paper
printed with a barcoded secret. You scan the barcode into your home
controller, which encrypts the manual key with the barcoded secret and
sends the result to the toaster. This transmission can happen in the
clear. This makes it easy to rekey (when merging nets or when the manual
key has been compromised) and it also avoids the need for the temporary
secure net (the wire), which may reduce cost by reducing the number of
interfaces needed. The barcoded secret acts as a device master key.

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Wed, 10 May 2000 12:54:07 -0400

Ross Finlayson wrote:
> ... two or more friends meeting in a coffee shop with their wireless

Not if there are any nasty folks lurking about, using their own wireless
laptops to snoop traffic.

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Wed, 10 May 2000 14:33:04 -0400

> use). I suspect that my actual mother would either not do it, or

I believe that we will need to accept that some (most?) devices will
ship with zeroconf security turned off. And many users will not turn on
zeroconf security until they see a need (after they are burned,
probably). Some devices (especially safety-critical devices) may disable
zeroconf networking until security has been configured (allowing only
direct control of the devices), but many devices (such as radios) will
probably allow non-secured zeroconf by default.

Most people don't read manuals. They pick up a device and plug it in. If
it doesn't work (or they can't figure out how to use it), they return
it. Zeroconf networking will have to work the same way or only nerds
will use it. Security requires *some* configuration (as we've seen). So
security will need to be off by default or the devices won't sell.

-Steve

---

From: Peter Johansson <[email-masked]>
Date: Wed, 10 May 2000 12:09:24 -0700

At 02:33 PM 5/10/00 -0400, Steve Hanna wrote:

<<Most people don't read manuals. They pick up a device and plug it in. If
it doesn't work (or they can't figure out how to use it), they return it.
Zeroconf networking will have to work the same way or only nerds will use
it. Security requires *some* configuration (as we've seen). So security
will need to be off by default or the devices won't sell.>>

While I can't disagree with your premises, I very much disagree with your
conclusion.

We have an obligation not to expose users to hazards, whether the user is
naive or not. Setting security off by default is an invitation to product
liability lawsuits. One such has already been initiated against Pacific
Bell / Pacific Bell Internet for its alleged failure to warn customers of
the security risks inherent in a 24/7 DSSL connection.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Thu, 11 May 2000 10:27:22 -0400

I think this is an oversimplification.  You can get better security
with more configuration but some threats can be defeated with lower
levels of security.  You can defend against passive eavesdropping with
unauthenticated Diffie-Hellman and it even helps a lot against
spoofing if it is difficult for the attacker to achieve a
man-in-the-middle status.

How much "configuration" is impractical for "my mother"?  Would an
alert when a new device appears on the net asking the yes/no question
of whether you just turned on or plugged in such a device be too much?
I wouldn't think so.

Donald

From:  Steve Hanna <[email-masked]>
Message-ID:  <[email-masked]>
Date:  Wed, 10 May 2000 14:33:04 -0400
Organization:  Sun Microsystems, Inc.
References:  <[email-masked]> <3918CB4D.EEC6D50D@21
rst-century.com>

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Thu, 11 May 2000 18:43:16 -0400

> of whether you just turned on or plugged in such a device be too much?

No, especially if it was an audible request and she could respond verbally :)

It sounds like you assume the existence of a home "console" with (presumably) some sort of
GUI. The people who have "12:00 " blinking on their VCRs will not pay attention
to a home console. My (late) father NEVER read manuals - never. If it
couldn't be figured out by inspection, it never got used.

I agree with the sentiment that this group has bitten off more than it can (should) chew. I would suggest
that :

> zero config is not suitable for any home security device or any really non-benign device <

and, conversely,

> any non-benign device or home security gizmo will require some config <

and

> for some people, that will mean that they will have to call in an installer or other
expert help.  There is no way that you can have manual config so simple that some will
not balk at it. <

I would therefore suggest that security be put off till the next round.

Regards
Marshall

P.S. I am convinced that there will be a major local industry of home device installation and
configuration. I currently have a leaky pipe in
my kitchen. I could (I hope) fix it, given some free hours. I could also make a mess. What I will
do is call a plumber. I configured my own ISDN line, though. Having spent 3+ hours at a time
on the phone with Bell Atlantic more than once in the process, I would certainly consider calling in
a digital plumber if such existed. I give this about 3-4 years to become commonplace. Having a
standardized "minimum-config" would really help this develop, and, therefore, will help people like
my Mother to get web-enabled appliances.

T.M. Eubanks

---

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

> 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.

> E.g., consider how a a user might set up a new, 'shrink-wrapped'
> network appliance (that he just bought from Wal-Mart, e.g.).  One
> can imagine the user plugging the appliance into his home network
> and turning it on, and having it then be automatically reachable
> from his home's control center - i.e., "zeroconf".  However, in
> order to continue to use the appliance, the user could then be
> required to 'configure' it from his control center - e.g., to set up
> keys.  Only then would he be able to use the appliance's full
> functionality.

This approach would seem to make sense because I can imagine it being
usable by a real consumers. No, it is not "zero config", but I think
we all understand the "zeroconfig" and "real security" don't go
together.  Of course, the 'configuration' that has to be done needs to
be really easy for the end-user, but I think we (as protocol
designers) can make this step easy enough that a GUI can do the
rest. For example, your home LAN might have a "security manager". When
the new device first connects things might go something like:

1) new device finds this manager, opens a connection to it, negotiates
a session key (so that all remaining communication is encrypted and
not sniffable), then the new device says "hi, I'm your new TV, may I
connect to your network?".

2) A message appears somewhere on the users window saying "this new TV
just appeared and wants you to allow it to connect to your network. Do
you agree?"

3) User must click either "OK" or "No".

All the grubby details about keys and such are hidden from the
user. The user just clicks yes or no.

Do folks think this can pass the "my mother" test? I think it
can. There will of course be some education involved, but folks can be
(indeed, must be) made to understand that "clicking OK" is the
equivalent of giving out the combination to the lock on your network
and all the machines connected to it. If you haven't bought a TV
lately, click "no".

Thomas

---

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

>            for IPv4, since it would mean securing ARP.  That is the 

One thing I don't follow here. Why is securing ARP a requirement to
protect against address hoarding?  Protecting against address hoarding
would seem to require that the DHCP server have a way to distinguish
bogus from legitimate requests for addresses.  I'm not sure how to do
that absent realy crypto authentication whereby legitimate clients
authenticate themselves when requesting addresses.

Having said that, I'm not disagreeing with the basic point that
protecting against address hoarding need not be a requirement.

>         configuration.  It is out of the scope of the WG to do more

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.

Thomas

---

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

> sniffer which will do the waiting for you.

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.

Thomas

---

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

> >whatever) or MADCAP server is to be used or not.

Well, nobody has implemented secure dhcp as there is no RFC for
it. Hopefully that will change soon (there is an almost-finished WG
draft).

Secure (resolver) DNS implementations are also in short supply at this
point.

> raising the bar too high, given that very few hosts can

The general bar the IESG has is that an end user MUST be able to turn
on security and have it work. That means it MUST be implemented, but
the end user has the choice of whether to enable it or not. Anything
lower than MUST implies that products don't have to implement the
security part in order to be compliant with a spec. This leads to the
all-too-common problem whereby a customer may want to enable security
(i.e., after being targetted), but find their house (i.e, product) has
no locks on its doors as the vendor took a shortcut to save costs.

Thomas

---

From: Peter Johansson <[email-masked]>
Date: Fri, 12 May 2000 09:42:20 -0700

At 01:55 PM 5/11/00 -0400, Thomas Narten wrote:

<<An alternate way of looking at this is that by default 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.>>

A very useful observation, Thomas. I agree wholeheartedly. What's left is a
discussion about the guidance provided the user when the network is first
established and a policy decision must be taken.

Does the knowledge as to whether or not a particular is in "secure mode"
reside in a central entity? Or is it distributed throughout the network?

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Richard Johnson <[email-masked]>
Date: Tue, 16 May 2000 18:29:57 -0700 (PDT)

> presumably already decided.

This idea of securing the network instead of the device could really
help zeroconf.  I could easily see one or more programs which could be
installed on your Windows and Mac systems as a Control Panel, and on
Unix as a daemon, which would implement a "secure network" protocol.
When a new device is attached, it would see this protocol was
installed on the net and would request "joining the network".

When you buy a device, it could be advertised as "secure net enabled", 
meaning that understands the "secure net" protocol.  If you want a
secure net, you would be willing to even pay a little extra to get the 
device with this capability as opposed to the cheaper one which didn't 
have it.

In short, all zeroconf needs to really say is the text above; that a
device will be able to detect when running a secure version of the
protocol is needed, and will be able to do so if it's capable of it.

/raj

---

From: Aidan Williams <[email-masked]>
Date: Fri, 19 May 2000 09:20:03 +1000

> secretly. So this should be a non-problem in practice.

I don't think anyone is suggesting that keys be transferred
in the clear.

The issue arose in the context of devices which might not
have enough grunt to do public key crypto.  In that context
various suggestions were made which created an out of band
channel over which the key could be transferred: a power socket
in the home controller into which you plug your new device,
a network formed by touching devices together, and the idea
of a device key on a barcode which could be read by the
"control device" and used to protect the key transfer.

No doubt these kinds of schemes may not make sense to
standardise in the IETF.  Although I am entirely in favour of
using Diffie-Hellman for key exchange, I would not want to
mandate a key exchange scheme which would be impractical
for low powered embedded devices.

regards
	aidan
____
:wq!