Subject: RE: home network security

From: "Rose, William" <[email-masked]>
Date: Thu, 6 Apr 2000 17:30:16 -0400

>I'm glad to see we're getting back to the threat analysis.

I am certain not all are zeroconfig threats but the thinking was as follows:

>> · Unauthorized access
No explanation needed. Obvious threat.

>> · Eavesdropping
Allows outsider to determine lifestyle, do home/away analysis for break-in,
access in-home cameras, etc. 

>> · Intercept/Alter (Info is intercepted and altered)
Intercepting a message such as "arm security system" and resend later as
"disarm security system"

>> · Masquerade (spoofing or acting as a legitimate device
Numerous issues if the sender cannot be authenticated. Unlocking doors,
opening garage doors, etc.

>> · Replay (Eavesdropped message is replayed at a later time)
With in-the-clear messages, any command can be replayed such as "disarm
security system", "open garage door" etc.

>> · Denial of Service
More of a nuisance than a threat unless it keeps a critical message from
being sent or received.

>> · Resource exhaustion
Overloading a device with minimal resources

>> · Service Spoofing
>> · Trojan Horse
Particularly dangerous in Java type systems which will transfer executable
code to a JVM.

>> · Repudiation

There is another potential issue. Just knowing what services are available
lets someone know what devices are in the house and therefore how profitable
a break-in might be. A DTV might have a list of storage (VCR, TIVO/Replay,
PC), playback (DVD, PC, TIVO/Replay), audio (surround sound, MP3 player),
etc. services listed. In the world of home systems, these are the types of
services that are part of the discovery process and can be accessed by other
devices to see what is available for use at a given time.

Bill Rose

---

From: Rajesh Krishnan <[email-masked]>
Date: Thu, 6 Apr 2000 20:03:19 -0400 (EDT)

1. Need for crypto on every zeroconf host 

Fundamentally zeroconf deals with Layer 3 aspects of host configuration 
such as the acquistion of address/netmask/defaultroutes by a host. (Sure,
there are some Layer 4+ overlays such as service discovery.)

To be consistent, it is a good idea to require that all zeroconf hosts 
should support host-level security capabilities applicable to Layer 3, 
such as basic cryptographic functionality for providing information 
security.  This is almost as fundamental as the ability to create and 
forward IP packets.  I would recommend adding this requirement to 
draft-03's successor. 

Infrastructure security (eg., preventing threats such as hoarding via
authentication) will depend on this basic crypto functionality being 
available in every host.  No matter how (or whether) group keys are 
pre-configured, host keys and certificate information are pre-configured, 
or gossip-based protocols are used, basic crypto functionality is required 
in every host.  In other words, the issue of key configuration/management 
being zeroconf or not is orthogonal. 

2. Seamless session migration on renumbering

Session encryption is useful if we choose to optionally support secure, 
seamless migration of sessions to the new address on renumbering (provided 
only one of two peers has renumbered and the peers remain reachable from 
each other).  Just because two zeroconf nets merged (a flaky router/bridge 
comes back online) and as a result of conflict resolution my host got 
renumbered, it does mean that my data flow (streaming audio/video, game 
session etc.,) has to be interrupted as well.  

The risk of session hijacking (by exploiting migration) will be high, 
when not using encryption.  Of course, I am assuming that initially 
the session was established securely (which requires the presence of
a chain of trust).

Bootstrapping chains of trust in a purely ad hoc environment is a hard 
problem.  Dynamic solutions to this problem will probably be approximate 
and may require sociological or socio-biological paradigms.  However, 
such solutions will still need cryptography.  

The ability to whisper (encrypt) is useful and is orthogonal to the ability 
to always determine if the ear being whispered into is the correct one 
(trust/authentication).  In my opinion, we need encryption in all zeroconf 
hosts. 

-Rajesh

---

From: Steve Hanna <[email-masked]>
Date: Fri, 07 Apr 2000 12:02:15 -0400

Thanks for the elaboration.

Perhaps I should have been clearer in stating that many of my questions
were about whether these threats pertain to items within the scope of
this working group: host configuration, name-to-address translation,
service discovery, and multicast address allocation.

> No explanation needed. Obvious threat.

How do you see this playing out in each of our application domains: host
configuration, name-to-address translation, service discovery, and
multicast address allocation?

> >> · Eavesdropping
> Allows outsider to determine lifestyle, do home/away analysis for
> break-in, access in-home cameras, etc.

I have become convinced that this is an important threat, which should
be added to the list of basic threats in our requirements document.

> Intercepting a message such as "arm security system" and resend later
> as "disarm security system"

This is one form of masquerading. Having an existing message to alter
may make it easier to masquerade, but it's still the same basic issue.

> Numerous issues if the sender cannot be authenticated. Unlocking
> doors, opening garage doors, etc.

Agreed, although your examples all relate to device control, which is
out of scope. A more pertinent example would be masquerading as a
printer to capture print jobs.

> With in-the-clear messages, any command can be replayed such as
> "disarm security system", "open garage door" etc.

Yes. Although your examples still pertain to device control.

> >> · Denial of Service
> More of a nuisance than a threat unless it keeps a critical message
> from being sent or received.

If you can jam the security system so that the window sensor can't
notify the central unit that the window has been broken, this would be a
big problem. But this can be designed around. The central unit should
assume that if it hasn't heard from a given sensor in a while, there is
a problem. Still, we should add this to the threat analysis.

> Overloading a device with minimal resources

Isn't this a form of denial of service?

> >> · Trojan Horse
> Particularly dangerous in Java type systems which will transfer
> executable code to a JVM.

I don't think that any of the areas this working group is chartered to
cover will involve downloading executable code (Java or otherwise). Do
you disagree?

> There is another potential issue. Just knowing what services are
> available lets someone know what devices are in the house and
> therefore how profitable a break-in might be. A DTV might have a list
> of storage (VCR, TIVO/Replay, PC), playback (DVD, PC, TIVO/Replay),
> audio (surround sound, MP3 player), etc. services listed. In the world
> of home systems, these are the types of services that are part of the
> discovery process and can be accessed by other devices to see what is
> available for use at a given time.

Yes. This is a good point. That's why it's important to restrict who can
access the service discovery system and encrypt traffic so people can't
see that you're resolving the name "Super Sony DVD 13". But it occurs to
me that seeing any zeroconf traffic at all (even encrypted) indicates
that the household is likely to be a good burglary target. To deal with
this, people should probably use wired networking or spread-spectrum
wireless to avoid detection. We might want to mention this threat as
well (detection of traffic as threat).

-Steve