Subject: revised list of zeroconf security requirements

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

The following security requirement summary takes into consideration
the mailing list discussion and hopefully aligns it with the requirements
specification:

 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.

        The goal is to not make IP any less secure, not to 'raise the
        bar.'

   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? 

 1 Conclusions of discussion:
    
   1.1)  Security for non-zeroconf protocols (DHCP, DNS, MADCAP) is out
         of scope.

   1.2)  Security for application level (device control) protocols is out 
         of scope.  

   1.3)  Security defaults 

         + Devices come without security configuration.
         + Devices operating in a network where security configuration
           is required discover this and can be configured.  To the 
           greatest extent possible, this configuration should not
           require manual intervention.

   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, if configured to do so.

          + 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, if configured to do so.

            . Note that in the case of name to address resolution, and
              multicast address allocation this can be used to prevent
              'hoarding attacks.'  A malevolent host could respond to 
              all names to prevent 'nameless' host from picking a
              unique name or claim all multicast group allocations.

          + Antagonistic server attack.  

            . A host MUST be able to determine if a server is posing
              as a 'service discovery registrar' or is legitimate.

              If a host implements DNSSec, DHC autentication, it 
              could use them to identify legitimate servers from
              antagonistic ones, but it is outside of the scope
              of the ZEROCONF WG to require or recommend its deployment.

    2.2) Hosts MAY implement security mechanisms to protect them against
         the following threats:

           + Evesdropping attack.  The host may be able to employ 
             layer 2 or layer 3 security to provide privacy for
             communications.  

    2.3) Hosts MUST be configurable to use that security, as easily
         as possible.
  
 Erik