Subject: RE: home network security

From: "Rose, William" <[email-masked]>
Date: Mon, 3 Apr 2000 15:53:06 -0400

I agree the internal threats are best left alone. However, everyone in the
home automation and home networking industry is expecting external access to
their products for monitoring, control, service information (as in the
advertisement for the refrigerator that calls for service automatically),
etc. Without a secure connection, these applications will be forced to use
their own security solutions. And if each use their own solutions, it will
be very unfriendly to the customer (multiple passwords/keys) and very
difficult to get interoperable applications such as a personal WEB page with
unified access to all enabled devices as well as push services for news,
finance, entertainment, etc. I understand (I think) that a zeroconfig
network might become configured when connected externally but an unconnected
home network is not very useful for the products being planned by the
product manufacturers. 

I think that ignoring the security issue is a mistake. Make it an option if
necessary but define a minimal solution at least by reference. Regardless of
what happens in the future (years from now), the first home products (other
than PCs and PC like products) will not be sitting directly on an IP
network. They will be on a cluster network and link to an IP network through
a proxy or other "black box" (I am trying not to use the wrong term for the
interface device). I hear that the necessary code etc. will only require a
small increase in memory and processor cycles but the fact is the cost to
connect devices is still a major issue. Even 10baseT is expensive for these
devices and it requires new wires. The reality is power line carrier or low
speed wireless (kbps)for retrofit homes and RS485 over CAT 5 for new homes.
A proxy for the cluster will connect them to the external world. It is that
connection to external world that needs some level of security defined so
every cluster network interface can depend on a consistent minimal security
approach. Producers can add more if they want. Let the system come up with
security on by default and let the customer turn it off if that is their
choice but don't "punt". 

Bill Rose
-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Monday, April 03, 2000 3:09 PM
To: [email-masked]
Subject: RE: home network security

It's hard to tell if we're "punting" until the threats are
clearly identified. Then at least we'll be able to say
what threats we are and are not addressing. So it seems
like a security analysis is needed here.

I liked Jeff Schiller's take on the threats: in a home
environment, one should assume that the threats are mostly
"external"; we do not necessarily need to go to a great deal
of effort to protect parents against denial of service
attacks by their children.

However, it is not as easy to define "external" as it might
seem. Defining this purely as someone outside the home
makes it difficult to support scenarios such as
connecting to the home network from the office.
For example, is it completely unreasonable that
someone might want to check on the status of their water heater
while at work?

I would also note that most of the threats are
not specific to zeroconf. That is, they exist
as much or more in a non-zeroconf home environment (say, running
NAT on ADSL or cable modem) as they do in a network that is running
on prefix 169.254/16. So we are really talking about a security
analysis of home networking.

Some thoughts on what kinds of threats might be worth addressing:

a. Threats of "external" parties bridging to the home network, either
   by design or without consent.

b. Threats of external parties controlling internal devices or hosts.

c. Threats of internal hosts being tricked into using bogus external
   services.

The above issues seem to boil down to first, putting some kind of firewall
capability in place and then making sure that an "external" party cannot get
around it by bridging to the inside network.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 3 Apr 2000 21:54:58 -0700

RE: home network securityI agree that foreclosing external access to the
home network is too drastic. As you state, the home automation
industry is looking forward to enabling Internet access to network-enabled
appliances. This is critical for allowing
maintenance to be done inexpensively. For example, if an engineer can
monitor the performance of dozens of
building or home security and energy conservation systems without visiting
the sites that is going to save a lot
of time and money.

The question is how to enable this key scenario without compromising
security. One approach that I've seen
is to have some sort of applications layer gateway. For example, a web page
that authenticates access and
then allows the authenticated user to control and monitor the appliances on
the other side of the gateway. The
question is whether such a gateway solution is too limiting. Might there be
situations in which the engineer
might want direct access to the device? I think there are probably such
scenarios.
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf
Of Rose, William
  Sent: Monday, April 03, 2000 12:53 PM
  To: [email-masked]
  Subject: RE: home network security

  I think that ignoring the security issue is a mistake. Make it an option
if necessary but define a minimal solution at least by reference. Regardless
of what happens in the future (years from now), the first home products
(other than PCs and PC like products) will not be sitting directly on an IP
network. They will be on a cluster network and link to an IP network through
a proxy or other "black box" (I am trying not to use the wrong term for the
interface device). I hear that the necessary code etc. will only require a
small increase in memory and processor cycles but the fact is the cost to
connect devices is still a major issue. Even 10baseT is expensive for these
devices and it requires new wires. The reality is power line carrier or low
speed wireless (kbps)for retrofit homes and RS485 over CAT 5 for new homes.
A proxy for the cluster will connect them to the external world. It is that
connection to external world that needs some level of security defined so
every cluster network interface can depend on a consistent minimal security
approach. Producers can add more if they want. Let the system come up with
security on by default and let the customer turn it off if that is their
choice but don't "punt".

  Bill Rose
  -----Original Message-----
  From: Bernard Aboba [mailto:[email-masked]]
  Sent: Monday, April 03, 2000 3:09 PM
  To: [email-masked]
  Subject: RE: home network security

  The above issues seem to boil down to first, putting some kind of firewall
  capability in place and then making sure that an "external" party cannot
get
  around it by bridging to the inside network.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 04 Apr 2000 06:24:31 -0400

Bernard wrote:

>I agree that foreclosing external access to the home network is too drastic.

I'd add to this: "But should be easily and explicitly configurable in
some fashion by the home user."

>As you state, the home automation industry is looking forward to enabling >Internet access to network-enabled appliances. This is critical for allowing
>maintenance to be done inexpensively. For example, if an engineer can monitor >the performance of dozens of building or home security and energy >conservation systems without visiting the sites that is going to save a lot >of time and money. 

That may well be, but I want to be VERY clear, that the homeowner or
building owner MUST have the ability to regulate this. There will be
those who do NOT wish this type of access to their homes or other
structures.

Applicances which need to send alerts can send OUTBOUND messages through
a tight firewall without allowing someone outside to poll the device.
It's up to the appliance manufacturer to decide which way they'd like to
implement their code, of course, but it's also up to the individual how
they'd like to implement their firewalls.
 
>The question is how to enable this key scenario without compromising >security.

Agree. And a question of whether there's a trust relationship with the
manufacturer or servicer of an appliance.

>One approach that I've seen is to have some sort of applications layer >gateway. For example, a web page that authenticates access and then allows >the authenticated user to control and monitor the appliances on the other >side of the gateway. The question is whether such a gateway solution is too >limiting.

Even in a gateway scenario, there are concerns. A general lack of trust
in large corporations to refrain from pushing the limits of the trust
relationship is a concern. How long before the marketing department
finds a way to use the data extracted from your refrigerator to market
additional services? First time that happens, there'll be users pulling
plugs.

>Might there be situations in which the engineer might want direct access to >the device? I think there are probably such scenarios.

I think the privacy folks will continue to make this an issue.

I'd like to see Zeroconf make headway, and am not sure getting into
defining the trust relationships with General Electric, Whirlpool, Sears
and other such companies is a good use of that time.
-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 4 Apr 2000 06:15:08 -0700

>some fashion by the home user."

If we are allowed to do configuration then a lot of things become easier :)

>those who do NOT wish this type of access to their homes or other

Sure. The question is how to enable granting of such access. In general,
packet filtering firewalls aren't very good at enabling secure inbound
access. For example, you'd need to know the IP address of the 
maintenance person, and even if this could be known and updated
(unlikely) it would be vulnerable to spoofing. VPN technologies
(such as IPSEC) are typically more secure for this kind of problem
as well as more flexible. For example, you wouldn't need to know or
care about what IP address the IPSEC packet is coming from,
only the identity as expressed in the cert. This means that IPSEC
may actually be EASIER to configure than a packet filtering firewall,
assuming that the PKI obstacles can be overcome. 

Of course, there is then the question of how the certs are obtained
and set up. However, I'm not convinced this is really so hard. See
Steve Bellovin's proposal, draft-bellovin-ipsra-getcert-00.txt.

---

From: Steve Hanna <[email-masked]>
Date: Thu, 06 Apr 2000 09:30:30 -0400

I'm pleased to see so much discussion of zeroconf security. This is an
important issue and I'm glad we're discussing it.

I think Bernard Aboba hit the nail on the head when he said that we need
a threat analysis. This is the most basic first step. Until we agree on
a threat analysis, any discussion of security measures is pointless.

> attacks by their children.

But as Bernard pointed out, "external" is a vague word here. Using a
firewall to define who's trusted and who's not causes problems when a
trusted user wants to access devices from outside the firewall. The
firewall model also breaks down when the "internal" network is not
secure. Many home networks are based on wireless or powerline
technology, which are usually not secure at all. So I think we need to
toss out the firewall model and go back to the threat analysis.

First, let's agree what we're trying to secure. Our charter restricts
our focus to four basic network functions: host configuration,
name-to-address translation, service discovery, and multicast address
allocation. Application layer protocols are not in scope here, I
believe.

Next, let's look at what we're trying to secure against. Our
requirements document lays out three types of threats:

   Hoarding: Hosts claim all available resources, whether they plan
   to use them or not.  This is a form of denial of service attack.

   Masquerading: Hosts can respond to requests that they should not
   so they can masquerade as another host.

   Antagonistic Server: A server could offer support for a critical
   service but intentionally misconfigure hosts on the network.

This seems like a reasonable set of threats to start with. The hoarding
attack pertains to host configuration, name-to-address resolution, and
multicast address allocation. The masquerading attack pertains to
name-to-address resolution and service discovery. The antagonistic
server attack probably pertains to all four functions (host
configuration, name-to-address translation, service discovery, and
multicast address allocation), since all zeroconf protocols are designed
to transition to non-zeroconf protocols when a server is detected.

Are there other threats that we should be considering?

Do we need to preserve the confidentiality of these basic network
messages? Maybe you don't want your neighbors to know what services you
use and when.

> c. Threats of internal hosts being tricked into using bogus external

I would argue that we should take threat a as a fact of life. A home
network is not secure. Assume that malicious parties can send and
receive on the home network at will. Any other assumption is doomed to
failure.

Threat b is out of scope, since we are not considering device control
protocols.

Threat c is very appropriate. That is the Antagonistic Server threat
cited in our requirements. 

-Steve

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 7 Apr 2000 02:45:50 -0700

>receive on the home network at will. Any other assumption is doomed to

I'm not quite this pessimistic, but I would agree that "defense in
depth" is probably a sounder approach. However, to get there one
needs to start looking at things like IPSEC as a personal firewall.
Are we willing to go down that road?

>messages? Maybe you don't want your neighbors to know what services you

It's probably something that should be possible, though not necessarily
required.

>Threat b is out of scope, since we are not considering device control

I wasn't referring to device control per se, more to end-to-end security
in general.

---

From: Daniel Senie <[email-masked]>
Date: Fri, 07 Apr 2000 10:11:26 -0400

> Are we willing to go down that road?

IPSec is a non-starter today in home networking. Due to the business
policies and practices of the broadband providers, NAT is a key fixture
in most home networks. IPSec is unable to traverse NAT, and so is not
useful in this environment. Perhaps someday in the future if IPv6 ever
becomes viable in the broadband market, or if the work to make IPSec
less dependent on checking source and destination IP addresses sees the
light of day, we'll have a shot at it.

In the mean time, application level security is likely to be the only
workable scheme in the home market.

---

From: Steve Hanna <[email-masked]>
Date: Fri, 07 Apr 2000 11:19:16 -0400

> Are we willing to go down that road?

IPSEC is not the only solution. There are lots of other security
protocols.

But let's not jump into an implementation discussion. We're still at the
requirements stage. I am arguing that, when analyzing security threats,
we should assume that malicious parties can send and receive on the home
network at will. I'm sure this won't always be the case. But it will be
common and we need to design for it.

> It's probably something that should be possible, though not necessarily

Agreed.

I suspect that we will end up making zeroconf security optional. Maybe
mandatory to implement, but can be off by default. That will allow
people to buy a device, take it home, and plug it in without bothering
with whatever extra work is required for key establishment. Folks who
are concerned about security can turn it on. And security-critical
devices (what Marshall is calling non-benign), security will be always
on.

> I wasn't referring to device control per se, more to end-to-end security

I don't understand what you mean here. Could you elaborate?

-Steve

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 7 Apr 2000 12:58:18 -0700

>IPSec is unable to traverse NAT, and so is not useful 

There are several configuration in which this is not an issue,
such as use of IPSEC on the NAT itself, to permit authenticated
access to the inner network. 

>workable scheme in the home market.

Not sure why you think that application layer security will work
either. Most NATs do not allow transit of externally initiated 
incoming SSL/TLS or even HTTP connections. So if ability to allow 
transit of incoming connections across today's NAT solutions is 
a criteria, the solution may be the null set.

---

From: Daniel Senie <[email-masked]>
Date: Fri, 07 Apr 2000 16:38:39 -0400

> access to the inner network.

To set this up, one must be able to convince applications to trust the
gateway. Yes, this is what RSIP is about, but we're not there yet, and
there's a LOT of NAT gear already deployed...

Doing IPSec from the gateway does offer LAN-to-LAN possibilities, but
that still can be problematic for the telecommuter... especially if
there's more than one telecommuter in the household.

> a criteria, the solution may be the null set.

Incoming connections are NOT the issue. Beyond the technical issues, the
contracts for cable modems and many DSL services specifically forbid
hosting services. I'm talking about end users who sit in their houses
and look to the outside.

Yes, other parts of this conversation have talked about the outside
looking in. Guess what... with NAT (really NAPT, which is what's in use
with DSL and cable modems most commonly), you're QUITE limited in terms
of having any services up anyway.

We're getting somewhat far afield from the base topic, other than the
fact that Zeroconf gateways (which have been discussed in the context of
devices that don't want to shift to public addresses, even when a DHCP
server shows up) would have all the same characteristics of other NAT
applications.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 9 Apr 2000 17:52:14 -0700

>Incoming connections are NOT the issue. 

Wasn't that the whole point of Jeff Schiller's argument? 
That external threats were the most important ones? 
The context was that devices might be auto-configured
and that this might protect them from external threats.

>hosting services. 

Yes, but they don't prohibit me checking my water heater from
the office.

---

From: Daniel Senie <[email-masked]>
Date: Sun, 09 Apr 2000 22:57:27 -0400

> Yes, but they don't prohibit me checking my water heater from

Let's do something of a reality check here... Perhaps I missed something
major. I seem to recall zeroconf devices giving themselves addresses by
one means or another (an example being the 169.254/16 assignments
supported by Win95/98).

For you to access your water heater, it would need to either:

1. Autoconfigure itself onto a publicly routable IP address

2. configure itself via DHCP onto a publicly routable IP address (in
which case we're out of zeroconf, and more or less out of scope for the
WG).

3. Reachable through a gateway that's handling the traffic across a NAT
or some such.

Before we continue down this path of figuring out security for accessing
these various devices in the house, can we figure out where the
addresses assigned to your water heater came from?

---

From: Paul Ferguson <[email-masked]>
Date: Sun, 09 Apr 2000 23:11:40 -0400

>addresses assigned to your water heater came from?

Ditto. I think a major reality check is needed here.

- paul