Subject: Security issues in zeroconf-v4-linklocal-05

From: Erik Guttman <[email-masked]>
Date: Wed, 22 May 2002 01:09:07 -0700 (PDT)

Keith, Bernard,

> Keith wrote:
> > Issue 4: The document (still) makes misleading claims about security
> > Section 2.8 is still misleading.  In part, it reads:
> >
> >    communicate only with other local devices, and this allows them to
> >                                                   -------------------
> >    produce cost-effective devices by implementing a degree of security
> >    -------------------------------------------------------------------
> >    appropriate for that expected environment.
> >    -----------------------------------------
> >
> > ERIK:  This text should be replaced with wording that security
> >        cannot be assumed on the link in all situations by the
> >        protocol designers.
>
> It would be better to say "cannot be assumed at all".
> or merely "cannot be assumed".  Let's be as clear about this as possible.

I understand where you want to go with this and I believe it goes
too far.

  A vendor creates a closed box with a single link (a bus) upon which
  v4LL autoconf is performed, and no other device except that supplied
  by the vendor will ever be attached.  Why can't the vendor assume
  security?  This is not a rhetorical argument.  One of the goals of
  the v4LL work is to enable bus behavior without the creation of ever
  more non-IP solutions.

  If a particular link is secured with L2 security, why can't one then
  assume v4LL can be used securely?

---------------------------------------------------------------------------
(I am resorting to dramatic dialog format for easy reading).

Erik:
  Explicitly and clearly state in positive terms that all IP-capable
  devices, including those using only link-local addresses, MUST
  implement security adequate to protect the device's resources
  those resources to which the device has access, and the network.

Bernard:
  Sure, but keep in mind that this is an unfunded mandate.

Keith:
  also keep in mind that secure hosts are cheaper than security 
  holes.

Bernard:
  Not actionable, unless it is described exactly *how* those hosts 
  should be secured on a small home network.

Keith:
  there's no such thing as a one-size-fits-all security solution, 
  because different hosts have different kinds of resources to protect,   
  different threat models, different models for who can use them.  
  that doesn't mean that such hosts can't be secured with a 
  reasonable amount of effort and expense, it just means that it's 
  infeasible to describe exactly how it should be done for all cases.

Erik:
  OK.  Let us delineate enough of a threat and of a use model that
  we can write a security consideration section which will inform
  vendors how to create secure equipment.

  Threat model:

     redirected and disrupted communication through injection of ARP

        ARP is insecure.  A 'classic' ARP attack either redirects 
        traffic to a new L2 address or simply disrupts communication.
        Eventually, the transport layer will require the L3 to L2
        address resolution be repeated.  The attacker can subvert
        this, too.

        Keith pointed out that an ARP attack against v4LL autoconf 
        will do this and in addition require a new round of claim
        and defend.  

        I claim that this is the same kind of attack, though a bit
        more severe (more time and packets involved).  (1) a new
        address must be allocated (if the attacker allows this at
        all), (2) service discovery or multicast based name to
        address resolution must be used to find the new L3 address,
        (3) ARP must be used to find the new L2 address.  Each
        require one or more broadcast (or link-local multicast)
        and one unicast (or broadcast, in the case of v4LL autoconf) 
        reply.  Exactly as in the classic ARP attack, an attacker
        can subvert communication totally through injection of 
        ARP packets.  The only difference is that instead of 
        a repeated cycle of subversion / ARP resolution / subversion, 
        there is a repeated cycle of subversion / claim & defend, 
        discovery, ARP resolution / subversion.

        Conclusion:  
          This protocol does not secure ARP.  The same 
          vulnerabilities exist for it and ARP.

          We do not tell vendors not to use ARP today.  Therefore,
          it is unreasonable for the IETF to tell them not to use
          v4LL autoconfiguration.

  The risk (social, economic) of subverted networks increases
  if networks become more pervasive.  This could occur if we are
  successful with this standard.  I believe this is Keith's real 
  concern.  I agree we need to be very clear to both vendors and 
  users what the risks are and also how they can be countered.

  Countering this threat model:

     Vendors should create products which can secure their use of
     the link layer. For example:

       -  authenticating wireless access and allowing devices
          to operate in a mode where L2 authentication is possible

       -  all networked components are attached in a sealed box
          
     Vendors who produce devices which are used in environments
     where a secured link layer is not necessarily available 
     should:

       -  enable higher layer authentication so that at the
          very least, redirected traffic can be detected and 
          a user warned and communication halted.
           
  Use model:

     shared access media (wireless being an important example)

       -  Users should be aware that use of v4LL autoconf without
          link-layer authentication is dangerous.  Users should 
          demand that wireless appliance products include 
          link-layer authentication capabilities.  Users should 
          enable these features, which will likely require 
          configuration.

          'Be sure to read and follow safety instructions before
           plugging in the device.'

     unshared link (a bus in a sealed box being an important example)

       -  Users should be aware that use of v4LL autoconf in 
          some devices is secure to the extent that the device
          is used as the vendor intended.  For instance, a car 
          may use IP for internal communication, with no 
          authentication.

          If the user connects such a device to a shared access 
          medium, this will expose the device to attack - the 
          most trivial of which disables communication in the
          device.

          'Use only as directed.'

This technology is present in the market place *without* guidance 
(to vendors and users, from the IETF) about how to use it safely.  

Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 May 2002 09:00:48 -0400

>   assume v4LL can be used securely?

Okay, *if* you have a point-to-point link layer (with only two possible
attachment points) which is known to be *inherently* secure (certainly 
not true of any of the wireless technologies in use today) then it *might*
be reasonable for the device to not implement security.  Even then it's
not axiomatically so - because it still leaves the possibliity that the
device can be compromsied by the other host on that point-to-point link
and if the device is then plugged into another network, it can compromise
other hosts.  It's a complicated world, it's very difficult to make
reliable assurances about security, and most vendors/implementors 
(and for that matter most customers/users) don't do good threat analysis.
But we shouldn't imply that that's okay :)

So while "cannot be assumed at all" may be a tad bit too restrictive,
"cannot be assumed in all situations" is really misleading.
"can almost never be assumed" is as close as I know how to say it.

>         more severe (more time and packets involved).  

I agree that the difference is one of degree.   I don't think this is
a showstopper with the link-local protocol - I'm reasonably sure you
can't have zero-knowlege address configuration and security at the 
same time anyway.  But the problem does need to be documented in
the security considerations section, and (for this and other reasons)
there does need to be a way for networks to disable devices' use of
link-local addressing (which itself introduces a security issue
that needs to be documented).

>           it is unreasonable for the IETF to tell them not to use

no, and I didn't propose that we do so.

>           to operate in a mode where L2 authentication is possible

I'd be reluctant to recommend L2 authentication as a possible
remedy, if for no other reason because many L2 authentication 
methods have known flaws (e.g. WEP).   also, authenticating 
the device is not sufficient (even when it can be done reliably)
if the device can be compromised.

It's very difficult to make safe general statements about what
security measures will work.

>           link-layer authentication is dangerous.  

and probably *with* LL authenticaiton as well...

> Users should 

which would largely defeat the purpose of autoconfiguration.

but this might also have implications for the applicability of
address autoconfiguration 

> (to vendors and users, from the IETF) about how to use it safely.  

indeed.  though at least IETF is trying - not that many users
read the security considerations sections of RFCs.

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 May 2002 10:03:01 -0400

I think the entire "security issue" assertion here is quite
overblown and makes unreasonable demands on ZeroConf.

	I'm not sure why folks dander has been raised on that thread
lately, but it seems quite misplaced.

Ran
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 May 2002 11:04:15 -0400

> overblown and makes unreasonable demands on ZeroConf.

I haven't seen anyone claiming that zeroconf needs to be made secure.

I have recommended, and others have agreed, that 

- the security risks presented by zeroconf need to be documented, and 

- zeroconf should not claim that it *provides* any level of security,
  or that it removes any need for a device to provide security.

Keith

---

From: Erik Guttman <[email-masked]>
Date: Wed, 22 May 2002 08:07:26 -0700 (PDT)

Keith,

To help make progress - I mark actions we've agreed on with ACTION
and remaining disagreements with ISSUE.  

---------------------------------------------------------------

On Wed, 22 May 2002, Keith Moore wrote:
> >   A vendor creates a closed box with a single link (a bus) ...
> >
> >   If a particular link is secured with L2 security, why can't one 
> >   then assume v4LL can be used securely?
> 
> be reasonable for the device to not implement security.  

A shared access medium in an unopenable container is secure to the 
extent the container remains unopened.

> Even then it's
> other hosts.  

There is no requirement or expectation of byzantine robustness for 
standards track protocols.  

If a device is multihomed, one interface in a secured (physically or
using L2 authentication), there is the risk that it could become
compromised, and then compromise the network.  If we were to require
that hosts (and routers) be uncompromisable before standardizing 
protocol, we would have to stop most of the work at the IETF.

> It's a complicated world, it's very difficult to make

I agree.  We have to explain the risks.  

> "can almost never be assumed" is as close as I know how to say it.

Let's get concrete.  

  'this allows them to produce cost-effective devices by implementing
   a degree of security appropriate for that expected environment.'

Add:
  'Implementors are advised that unless it is *impossible* to connect
   a device to a shared access medium, it is likely that it will be
   used in environments in which it is exposed to attack.  For example,
   a bus used inside a factory-sealed container might be an appropriate
   environment for attached components to use link-layer 
   autoconfiguration without concern for attack.'

ISSUE: Is this sufficient?  (If not, please suggest an alternative.)

---------------------------------------------------------------

> >         ARP is insecure.  A 'classic' ARP attack either redirects 
[snip]
> the security considerations section, 

ACTION:  Add text to address this point.

---------------------------------------------------------------

> and (for this and other reasons)

If we follow your argument ad absurdum we need a mechanism for
networks to disable ARP :-)  

We need to discuss the 'way to disable' in a separate thread.
For now let's note that we disagree.

ISSUE:  Keith argues for a mechanism to disable device's use of
        link-local addressing.  What are the grounds (*apart from*
        ARP-derived security issues)?

---------------------------------------------------------------

> methods have known flaws (e.g. WEP).   

WEP has a bad rep because it is *actually deployed and used.* 
The same has happened with some cryptography suites used in GSM.
The flaws are being addressed:  They are not architectural problems
with L2 security per se, rather with individual algorithms.

Wouldn't it be great if IETF security protocols were widely 
used enough that had something to be embarrased about and fix 
:-)

> also, authenticating 

We can't prevent devices from being compromised.  Nor are you,
I believe, claiming that v4LL authentication increases this risk.  

ISSUE:  Keith disagrees that L2 authentication is sufficient 
        (enough) to secure v4LL autoconfiguration that it 
        (should) be mentioned as a remedy to ARP related 
        threats.

---------------------------------------------------------------
 
> and probably *with* LL authenticaiton as well...

Bernard?
 
> which would largely defeat the purpose of autoconfiguration.

I believe Aidan Williams and Steve Hanna have initiated work on
easily configured security parameters.  I support efforts in this
direction.

ACTION:  Describe use model in shared and closed-access media.
         Admonish vendors and users.

Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 May 2002 14:22:10 -0400

> extent the container remains unopened.

The medium might be secure in such a case if it's physically protected.
That doesn't imply that the *device* provides adequate security from
whatever threats might be in that environment.

Even assuming a secure medium, there may be threats that still require 
the host to provide security beyond that provided by the medium.

Bottom line is that the responsibility for security cannot, in general,
be expected to be delegated to the transmission medium.  There are 
specific cases where this is probably adequate, but not so in general.  

> standards track protocols.  

Neither is there any exemption for what you term "byzantine".

We know, from long and frequent experience, that general-purpose
hosts are quite often compromised through viruses and the like,
and that a significant percentage of security violations originate
from inside a trusted environment.

We also know that there are severe limitations to using network 
topology as the sole means of providing security.

>    a degree of security appropriate for that expected environment.'

At best, the idea that zeroconf allows vendors to skimp on security
is highly dubious - while it might be true on its face, this statement is 
very likely to be misread.

The cases where a vendor can reasonably expect the environment to be 
secure are so rare in practice that even a nonspecific claim that 
zeroconf "might" help is probably misleading.

> ISSUE: Is this sufficient?  (If not, please suggest an alternative.)

Sigh.  There are threats that exist even when it is impossible to connect 
the device to a shared access medium.  So even though you say "*might* be
an appropriate environment", I think this is too easily misread.

A concrete example: Say you have a device that is supposed to implement
public key cryptography - it's supposed to sign or encrypt things with 
a private key that is stored on the device.  Such a device would be 
quite useful, no?.  And let's further say that the device is designed to 
be used only in physically secure environments - it's recognized (and 
the customer is warned) that if the device is stolen or even removed and
replaced then the key will be compromised, at least to the extent that 
the thief can sign and encrypt things as if he were the intended user.

Now, if the device is supposed to protect that private key, and the device 
has a mechanism that lets that private key be exposed through its network
interface, there's still a security risk with the device even though
the network is assumed to be secure.  The device has a valuable resource
to protect.  The entire reason for putting the private key on a separate 
device is to limit access to that key.  If the key can easily be exposed
to other hosts on the network, it would defeat the purpose of the device, 
and the fact that the network is secure doesn't change that fact.

The point is that any kind of generalization to the effect that network
security is adequate under some conditions is likely to be misleading.  
Even assuming a network that is perfectly secure from intrusion, the 
security of the host is only adequate if there is no partitioning of 
trust - if all hosts/devices in the the network are trusted to exactly 
the same degree.  

Yes, there are sometimes exceptions but it's very difficult to make
reliable general statements about them.

suggested alternative text:

] Implementors are advised that the Internet Protocol archirecture expects 
] every networked device or host must implement security which is adequate 
] to protect the resources to which the device or host has access, including 
] the network itself, against known or credible threats.   Even though use 
] of link-local addresses may reduce the number of threats to which a device 
] is exposed, implementors of devices supporting the Internet Protocol must 
] not assume that a customer's local network is free from security risks.  
] 
] While there may be particular kinds of devices, or particular environments, 
] for which the security provided by the network is adequate to protect 
] the resources that are accessible by the device, it would be misleading to 
] make a general statement to the effect that the requirement to provide
] security is reduced for devices using linklocal addresses as a sole means 
] of access.
]
] IN ALL CASES, whether or not linklocal addresses are used, it is necessary 
] for implementors of devices supporting the Internet Protocol to analyze 
] the known and credible threats to which a specific host or device might be 
] subjected, and to the extent that it is feasible, to provide security 
] mechanisms which ameliorate or reduce the risks associated with such threats.  

> networks to disable ARP :-)  

perhaps, but ARP isn't in scope for this group :)
and of course ARP is an old design.  IPv6 does ND rather than ARP 
in order to avoid some of the problems associated with ARP.

if this were the only problem associated with link local addressing
then I would not argue that we need a mechanism to disable it.
 
>         ARP-derived security issues)?

the other issue that comes to mind is harm to applications that 
expect such addresses to be usable outside the local link.

> The flaws are being addressed:  

WEP has a bad rep because it's *poorly designed* to the point of
being irresponsible.  It's not as if the threats couldn't have
been anticipated - the designers simply failed to do their jobs.

> They are not architectural problems

Agreed, however there are some more fundamental limitations with how 
much protection you can expect a network to provide.  Even a perfectly
secure network cannot prevent its hosts from being compromised and there 
are serious scaling problems associated with trying to make sure that all 
hosts on a network of any reasonable size are secure and trustworthy.  
And for many cases a 'host' is not the right granularity of trust,
yet you don't want to expose finer-grained levels of detail to the network.

In general, expecting the network (whether L2 or L3) to provide security 
from all threats is a dubious architectural choice.    

>         (should) be mentioned as a remedy to ARP related 

I think this is getting somewhat distant from the real issues.  
IMO:

- LL autoconfiguration increases the damage that can be done by
  DoS attacks to the network

- LL autoconfiguration doesn't reliably provide any additional security 
  for the host using LL addresses, even if it uses it as the only means
  of doing IP, and it shouldn't claim that it does.   
  
- regarding the possibility of impersonation, LL is approximately as 
  insecure as ARP.

- L2 authentication can't be relied on to remedy any of the above.
  If you are willing to distribute the information required to make 
  use of L2 authentication, you may as well statically configure
  the IP addresses also.

It's not my intention to insist that devices intended for use in 
sealed boxes - say integrated circuits with wave-solderable packages -
should implement the same degree of security as devices with 
Ethernet or 802.11 or USB interfaces which were clearly meant to
be able to be plugged in to random networks.  Rather, it's my 
intention to avoid giving implementors of the latter kinds of 
devices the impression that they can slack off on security.

I don't know of a good way to draw the line at which "it's okay
to slack off on security" - but I don't think "factory-sealed box"
is adequate.  

I keep coming back to the idea that you can't make general statements
about what kind of security is adequate.  There's no substitute
for doing an analysis of the risks for a specific device and the
environments in which it's going to operate.

Keith

---

From: Aidan Williams <[email-masked]>
Date: Mon, 27 May 2002 11:00:34 +1000

> easily configured security parameters.  I support efforts in this

Yes, we have.  Steve and I spent some time at the last IETF talking
about how to configure and apply shared secrets in zeroconf networks.
As has been pointed out many, many times, the configuration of
the secret isn't "zeroconf".  We're shooting for "simple".

Steve has a draft on secret sharing techniques:
  http://www.ietf.org/internet-drafts/draft-hanna-zeroconf-seccfg-00.txt

I have half a draft on how the secret could be applied, not (yet)
published.  We are hoping to have a document describing a simple
key exchange protocols (over a secure link), and both out by Yokohama.

> environments in which it's going to operate.

Keith, I basically agree with you that security depends critically
on environment.

The zeroconf wg needs to think about the environment in which ZC
protocols will be deployed, understand and document any security
issues, and specify the use of appropriate mechanism to ameliorate
threats.

Consideration of what are believed to be reasonable deployment
scenarios (ie the configuration cable, the home network, and an
adhoc group at a conference) has produced the idea that zeroconf
protocol security mechanisms must at least allow a group of devices
to implent a basic "in/out policy".

I have tried to summarise the approach in the requirements document,
sections:
   http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-reqts-10.txt
   4.    Security Considerations  . . . . . . . . . . . . . . . . . . 15
   4.1   The Basic in/out Security Policy . . . . . . . . . . . . . . 16
   4.2   Security Scenarios . . . . . . . . . . . . . . . . . . . . . 17
   4.2.1 Use on an isolated, secure network link  . . . . . . . . . . 17
   4.2.2 Use on a shared (insecure) link  . . . . . . . . . . . . . . 17
   4.2.3 Use in conjunction with configured protocols . . . . . . . . 17

This is not intended to be a one-size-fits-all approach.
Rather, it is an attempt to discuss appropriate security
measures for what we believe are likely deployment scenarios.

Given that the above is pretty much a re-write of the requirement
document security considerations section, any suggestions as to
how to improve it would be most welcome.

- aidan