Subject: security input for ZeroConf requirements

From: Erik Guttman <[email-masked]>
Date: Fri, 7 Jan 2000 13:08:28 +0100 (MET)

Myron,

Please consider this as a contribution to section 4 of the ZeroConf
Requirements draft.  

A very important decision has to be made:  Are we going to require
that security be configurable for zeroconf protocols?  It is clear
that security is required for the 'big brother' configured protocols
(ie. DHCP, DNS, MADCAP).  It is also clear that in a true ZeroConf
setting (ie. NO configuration) security is not possible. What I am
asking is if you are using ZeroConf protocols (ie. IP address
autoconfiguration) should you allow for the possibility that you
also have security configuration.  In that case IP address autoconf
could be done in such a way that hosts without proper configuration
would not be able to claim addresses.

I sent a more detailed note on this topic to the mailing list.  Please
review the requirements below as they include options 1 and 2.

Note that for service discovery I did not include the option for 
insecure operation.  Service discovery is not fundamentally different
on zeroconf or configured networks - the (decentralized set of) servers
themselves provide service location information whether they are in 
unconfigured or configured networks.  Thus, secure operation is 
equally important in either case.

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

The current section is set up as:

4  Security Requirements
4.1 IP Host Configuration
4.2 Domain name to IP address resolution
4.3 Multicast Address allocation
4.4 Service Discovery

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

I suggest that this section be restructured as:

4  Security Requirements

   The principal goal of security requirements for ZeroConf
   networking is to not make IP networking less secure than it is
   without the use of ZeroConf protocols.  This is challenging since
   ZeroConf provides the ability for any host to obtain host
   configuration, to discover and to use network resources.  In the
   case where ZeroConf access media is physically accessible (e.g.
   wireless, powerline) or routed to additional network segments,
   there is no longer any physical security.

   The following sections are security considerations for the four
   Areas which this document addresses. 

4.1 ZeroConf Security Threat Analysis

   The threats fall into three broad categories:

   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.

4.1.1 IP Host Configuration 

   Potential threats include:
   - A host could hoard IP addresses, denying others access to the
     network.
   - A host could pose as an antagonistic DHCP server and misconfigure 
     other hosts on the network.

4.1.2 Domain name to IP address resolution

   Potential threats include:
   - A host could masquerade, responding to names requests
     illegitimately.
   - A host could hoard names, responding to all 'claim' requests.
   - A host could pose as an antagonistic DNS server and fail to
     resolve names correctly, or intentionally resolve them
     incorrectly.

4.1.3 Multicast Address Allocation 

   Potential threats include:
   - A host could hoard multicast addresses, denying others the
     ability to obtain them.

4.1.4 Service Discovery

   Potential threats include:
   - Servers could masquerade by responding to service discovery
     requests which they shouldn't respond to.
   - A host could pose as an antagonistic service discovery
     'infrastructure element.' Some service discovery protocols
     offer a 'registry', 'directory', 'proxy' or other
     infrastructure element for scalability.

-----------------------------------------------------------------------
New text should be added for the actual security requirements.

4.2 Security Requirements

   Protocols designed for host configuration, name resolution, service
   discovery and multicast address allocation include security mechanisms.
   These protocols have been designed for use in configured networks.
   The same security mechanisms appropriate in a configured network is
   not useful in a ZeroConf network.

   ZeroConf requirements will not specify that all security threats
   be addressed by ZeroConf protocols since it would be inappropriate 
   to do so.

   Security always requires configuration.  For that reason, no
   secure operation will be possible on a network which has absolutely
   no configuration.  

   That is not the same as saying that ZeroConf requirements are silent 
   with respect to security.  When configuration is added to a host using 
   ZeroConf protocols, the host transitions to another mode of operation. 
   In this case, the host which is appropriately configured may be able to 
   counter threats posed to systems using ZeroConf protocols.

   The ZeroConf requirements specify the transition from insecure to
   secure operation.  A host fulfilling ZeroConf requirements will be
   capable of secure operation in each protocol area, if it is supplied 
   with appropriate security configuration (such as cryptographic keys.)

4.2.1  IP Host Configuration

   Hosts MUST be able to be configured to use DHCP authentication.

   Option 1:

      No provision is made for securing IP Host Configuration using
      the ZeroConf protocol for IP Host Configuration.

   Option 2:

      Hosts MUST be able to be configured to use a ZeroConf protocol
      for host configuration securely.  For example, a claim and defend
      protocol used for host configuration would have to include security 
      data with all messages.  A host in the ZeroConf network could verify
      that another host's claim was legitimate or not. 

4.2.2  Domain name to IP address resolution

   Hosts MUST be able to be configured to use DNS Security.

   Option 1:

      No provision is made for securing the ZeroConf Domain Name 
      to IP address resolution protocol.

   Option 2:

      Hosts MUST be able to be configured to use a ZeroConf protocol
      for Domain name to IP address resolution securely.  For example, 
      a 'reply' from the resolution protocol could be accompanied by
      a 'signature' which could be verified before being accepted.
      The security configuration would have to provide the server
      portion of the protocol with the data needed to produce a 
      'signature' which could only be produced if in possession of 
      the configuration data.

4.2.3  Multicast Address Allocation

   Hosts MUST be able to be configured to use MADCAP security.

   Option 1:

      No provision is made for securing the ZeroConf protocol for
      multicast address allocation.

   Option 2:

      Hosts MUST be able to be configured to use a ZeroConf protocol
      for multicast address allocation securely.  For example, a claim 
      and defend protocol used for multicast address allocation would 
      have to include security data with all messages.  A host in the 
      ZeroConf network could verify that another host's claim was 
      legitimate or not. 

4.2.4  Service Discovery

   Both clients and servers MUST be able to be configured to use 
   security mechanisms offered by the Service Discovery Protocol.  

   These mechanisms allow a client to determine if both the service it 
   discovers and the service discovery protocol infrastructure it uses
   to discover services are 'legitimate.'

   The service discovery protocol MUST provide mechanisms so that
   a server can use security configuration to advertise service 
   information in a way that clients can verify.  

   The service discovery protocol MUST provide mechanisms so that
   a client can use security configuration to verify service 
   information it obtains.  The client is essentially verifying
   that the server had possession of certain secrets.  The client
   trusts that only 'legitimate' servers would possess these secrets.