[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Draft                  Securing Zeroconf Networks          November 2000


Zeroconf Working Group                                    Aidan Williams
Internet Engineering Task Force                                 Motorola
INTERNET-DRAFT
November 2000
Expires May 2001

                       Securing Zeroconf Networks
               <draft-williams-zeroconf-security-00.txt>

             $Revision: 1.7 $ $Date: 2000/11/09 04:53:35 $


                         Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   Devices using zeroconf networking protocols can communicate using IP
   without requiring user configuration or infrastructure services like
   DHCP and DNS.

   The options available to secure zeroconf networks are canvassed.  A
   comparison is made between bootstrapping IPSec and securing sample
   protocols from each area listed in the zeroconf working group
   charter.  This shows IPSec to be the most promising approach for
   securing zeroconf protocols.





Expires May 2001                                                [Page 1]


Draft                  Securing Zeroconf Networks          November 2000


Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.


1.  Background

   Zeroconfiguration networking protocols allow devices using IP to
   communicate without requiring user configuration or infrastructure
   services like DHCP and DNS.  The motivation for zeroconf is to make
   IP networking as easy to use as possible.  Ensuring that these
   protocols can operate in a secure fashion without onerous
   configuration presents a challenge.

   Meaningful security typically requires some configuration, something
   which can be construed as counter to the spirit of the zeroconf
   working group.  On the other hand, zeroconf protocols are expected to
   operate in environments requiring security, and so we need to answer
   the question:

     How can meaningful security be supported without compromising the
     goals of zeroconf?

   The purpose of this document is not to define a complete protocol
   specification or a comprehensive set of requirements, but to
   highlight some of the issues and sketch out how the problem might be
   approached.

   This document is structured as follows.  Firstly, some motivating
   scenarios highlighting the need for zeroconf security are presented.
   Then some general characteristics of the problem space are noted.
   The next section looks at how security techniques might be applied to
   zeroconf network protocols, and is divided into two sub-sections: (1)
   bootstrapping IPSec on zeroconf networks, and (2) how individual
   protocols may be secured (e.g. mDNS, SLPv2).  The final sections of
   the document are a conclusion and reference section.

   Please note that familiarity with a variety of protocols is assumed.
   Discussion of these protocols is limited to describing the
   characteristics of the protocol which have a bearing on secure
   operation.  For a detailed description of these protocols, please
   refer to the references provided.








Expires May 2001                                                [Page 2]


Draft                  Securing Zeroconf Networks          November 2000


2.  Motivating Scenarios for Zeroconf Security

   There has been considerable discussion on the zeroconf mailing list
   about whether security is required or even possible in zeroconf
   networks.  The following two sections present scenarios where
   zeroconf networks require security mechanisms.


   2.1.  Adhoc, Shared Networks

      An example of a zeroconf network requiring security is a
      collection of devices in a personal area network.  It is likely
      that two or more personal area networks will come into
      communication range with each other.  A mechanism is therefore
      required to control access to such a network (e.g. to prevent
      someone from using your phone with their wireless headset).  At
      the same time, addition and removal of devices from such a network
      should be as simple as possible.

      Another example is people on a train, or at a conference, who want
      to establish private communications using a shared network.  Such
      a network may be wireless, or even wired.  Even in an environment
      with infrastructure, a lightweight way of creating groups of
      devices which can securely communicate would be beneficial.


   2.2.  Home Networking

      An obvious application domain for zeroconf protocols is in the
      home.  People have a natural expectation that the physical items
      in their home are secure, this same expectation is extended to
      networked devices.  A house installed with a private wired network
      can employ insecure zeroconf protocols without great risk, however
      home networks are increasingly employing wireless and powerline
      networking.

      As wireless and powerline networking become more popular, a
      network installed in one house or apartment will almost certainly
      overlap with one or more networks in adjacent dwellings.  The
      range of an 802.11 network (like an Airport basestation) will
      easily extend next door and to adjacent floors of an apartment
      block.  Should the basestation be plugged into a cable or DSL
      modem, anyone within range can use it as a connection to the
      internet unless steps are taken to secure it.  Also, an inventory
      of the devices in the home could be taken without the owner being





Expires May 2001                                                [Page 3]


Draft                  Securing Zeroconf Networks          November 2000


      aware as a prelude to a theft.

      The usual approach taken to secure radio and powerline networks is
      to rely on some form of Layer-2 encryption.  Unfortunately, this
      approach would prevent new devices from using zeroconf protocols
      at all until they are configured with some kind of key which
      allows them to access the network medium.  Zeroconf protocols in
      the home are attractive because they don't require the users to be
      network engineers in order to plug devices in and have them work
      properly.  If however the responsibility for security is
      transferred onto Layer-2 encryption, the opposite situation is
      created.  Consider an environment with a bridged network of some
      802.3-style wireless LAN, powerline and phoneline networking (e.g.
      [WLAN], [HomePlug], [HomePNA]).  In order for the network to
      operate, each device on a shared link must have been configured
      properly in a link specific way.  This is in opposition to the
      goals of the zeroconf working group.

      The myriad of approaches taken to Layer-2 security, each with
      their own configuration method, is not friendly to the user.
      Standards in this area have the potential to improve the
      situation.

      Note also that there is scope for people to create secure networks
      using link technologies that usually don't have Layer-2
      encryption, or where the network is by nature shared.  Examples
      are: a workplace ethernet, or at an IETF meeting using the 802.11
      network where everybody has the same shared key.


3.  Security Characteristics of Zeroconf Networks

   3.1.  What Needs to be Supported?

      Fundamentally, the securing of zeroconf networks requires support
      for the easy formation of device groups which can then communicate
      securely amongst themselves.  Devices in the group need to share
      credentials/keys/policy/etc.

      The formation of such groups needs to be lightweight, both in the
      complexity presented to the user and in the demands placed on the
      devices in terms of processing power and storage requirements.

      A device group could use a shared symmetric key, or a shared
      public key pair as the basis for authenticating group membership.





Expires May 2001                                                [Page 4]


Draft                  Securing Zeroconf Networks          November 2000


      Public key cryptography has the disadvantage that it is
      computationally intensive.  An additional key for each device
      would facilitate rekeying of all devices in the group during
      device removal, or as part of normal operation.


   3.2.  Sharing Secrets

      One significant problem in secure zeroconf networks is secret
      sharing, or key distribution.  Lightweight techniques allowing a
      secret to be shared between devices in a group need to be easy to
      use and secure.

      The goal of this draft is not to evaluate secret sharing
      techniques in detail, however possible approaches include:

       o using an out-of-band mechanism to transfer security
         information: barcodes, special power socket in a home
         controller, swipe card, etc

       o Diffie-Hellman key agreement [DH], with some form of external
         authentication to prevent man-in-the-middle attacks

       o A "leap of faith" (e.g. SSH host keys, Section 3.1, [SSH]),
         "The Resurrecting Duckling" [QUACK], or similar protocols.

       o A public key certification approach (which seems unwieldy for
         the problem space).


      Readers are advised to refer to Steve Hanna's draft [SECCFG]
      comparing various secret sharing schemes for a more in-depth
      treatment.


   3.3.  Vulnerabilities in Checking for Configuration Servers

      Various proposed zeroconf protocols attempt to locate a
      configuration server before operating in a zeroconf mode.
      Examples are:


       o IPv4 link-local address configuration [IPv4LL],
         which attempts to locate a DHCP server






Expires May 2001                                                [Page 5]


Draft                  Securing Zeroconf Networks          November 2000


       o multicast address allocation [AutoAAP],
         which attempts to locate a MADCAP server

       o Service Location Protocol, Version 2 [SLPv2],
         which attempts to locate directory agents.


      In order for zeroconf protocols to be secure, the mechanism used
      to locate a configuration server must also be secured.  Failing to
      do so allows an unauthenticated user to disable or disrupt the
      operation of the zeroconf protocol.  Securing the server location
      mechanism for each protocol is (currently) outside the scope of
      this document.


4.  Options for Zeroconf Security

   Assuming a shared key or key pair common to all devices in a group,
   one of the following options may be taken:

    (1)   Use IPSec to provide network layer security

    (2)   Secure individual protocols

   Securing all network traffic with IPSec looks to be the simpler, and
   more comprehensive option.  Securing individual protocols has the
   potential to be lighter-weight, but requires different approaches
   depending on what security techniques the application protocol has
   employed.

   Another consideration is that a group key, as described, above works
   well for authenticating group membership, but may not be suitable for
   confidentiality.  An automatic keying protocol such as [IKE] derives
   additional ephemeral keying material to support confidentiality and
   authentication of content/data.  This limits the usage of the group
   key, thus reducing the requirement to frequently change it and also
   provides desirable characteristics like perfect forward secrecy.

   Many application protocols focus on the authentication of requests
   and responses.  This may not be adequate in a home network where
   passive sniffing could allow an inventory of a home to be collected
   remotely.  Retrofitting confidentiality mechanisms to many of these
   protocols would require significant work.







Expires May 2001                                                [Page 6]


Draft                  Securing Zeroconf Networks          November 2000


   4.1.  Using IPSec to Provide Network Layer Security

      A shared group key can be viewed as providing a mechanism to
      bootstrap the Internet Key Exchange protocol [IKE] along the lines
      of the techniques being discussed in the ipsra working group.  The
      pre-shared secret (either a key or key pair) can be used to
      authenticate IKE Phase 1 (Section 5.4, [IKE]).  Security
      associations can then be negotiated for services in the normal
      way.

      IKE makes use of Diffie-Hellman, which could be an expensive
      operation for low end devices.

      The current IKE specification only caters for Security Association
      (SA) negotiation between two entities with unicast addresses.
      This means that although broadcast and multicast traffic can be
      secured with IPSec, there is no standard mechanism for automatic
      negotiating of an SA.  Work in SMuG (and the subsequent IETF
      working group msec) will provide mechanisms to address this
      problem [SMUG].

      Another possible solution is to manually configure a "shared SA"
      on all the devices at the same time the group key is configured.
      All senders to the multicast group or broadcast address would use
      the same Security Parameter Index (SPI) (Section 4.7,
      [IPSecARCH]).


   4.2.  Securing Individual Zeroconf Protocols

      The zeroconf working group charter refers to four groups of
      protocols.  The following section takes a sample protocol from
      each category and discusses how it might be secured.
      Additionally, protocols beyond these four may need to be secured.

      The four categories listed in the zeroconf working group charter
      and their example protocols are:

       o Interface Configuration
         (IP address, network prefix, gateway router)
         Examples:
         Dynamic Configuration of IPv4 Link Local Addresses [IPv4LL],
         IPv6 Stateless Address Autoconfiguration [IPv6AddrConf]







Expires May 2001                                                [Page 7]


Draft                  Securing Zeroconf Networks          November 2000


       o Name-to-Address Translation
         Example: Multicast DNS [mDNS] with Domain Name System Security
         Extensions [DNSSEC]

       o Service Discovery
         Example: Service Location Protocol [SLPv2]

       o Automatic allocation of Multicast Addresses
         Example: Multicast Address Allocation Protocol [AutoAAP]


      4.2.1.  Interface Configuration

         4.2.1.1.  Dynamic Configuration of IPv4 Link-Local Addresses

            The [IPv4LL] draft describes a claim/collide mechanism using
            ARP to select an IPv4 address.  Since ARP as currently
            defined cannot be secured, neither can the address
            allocation mechanism.

            [IPv4LL] does not address network prefix configuration
            (other than the link local IPv4 prefix) or router discovery.


         4.2.1.2.  IPv6 Stateless Address Autoconfiguration

            IPv6 autoconfiguration [IPv6AddrConf] also makes use of
            neighbour discovery in a claim/collide mechanism to select
            IPv6 link local address.  IPv6 uses multicast for neighbour
            discovery rather than ARP.  If link-local multicast can be
            secured with IPSec as described earlier, then so can IPv6
            neighbour discovery.  IPSec supports both authentication and
            confidentiality.

            Available network prefixes can be acquired via router
            advertisements which can be secured in a similar way.  Note
            also that IPv6 mandates IPSec as a security mechanism.


      4.2.2.  Name-to-Address Translation

         Multicast DNS [mDNS] has been proposed as one mechanism for
         doing name to address translation in zeroconf networks.

         The DNS Security Extensions [DNSSEC] provide data integrity and





Expires May 2001                                                [Page 8]


Draft                  Securing Zeroconf Networks          November 2000


         authentication for DNS by storing authenticated public keys and
         Resource Record (RR) signatures in the DNS.  A resolver starts
         with one or more trusted public keys associated with a zone,
         and builds paths from that zone to other zones by retrieving
         keys and verifying signatures from the DNS.  DNSSEC does not
         specify a symmetric key mechanism for authentication.

         In a zeroconf network, a public key pair associated with a
         group of devices could be used to create digital signatures for
         RRs in a zone such as .lcl.arpa.  Since the public key used to
         sign RRs in this zone would already be shared, it may not be
         necessary to include KEY RRs in responses.

         Note that DNSSEC was not designed to support confidentiality or
         access control.  Thus it cannot be used to authenticate the
         sender of a DNS request, or prevent passive discovery of device
         information.


      4.2.3.  Service Discovery

         Discussion is ongoing in the zeroconf working group as to
         whether SLP or mDNS with SRV RRs will be used for service
         discovery.  Since mDNS has been covered in the previous
         section, SLPv2 will be used here as the example service
         discovery protocol.

         Although [SLPv2] defines a mechanism for authenticating various
         messages, implementation is optional.  There are no
         confidentiality mechanisms defined in the current
         specification.

         If message authentication is implemented a DSA with SHA-1
         authentication block must be included as one of the message
         authenticators.  Authentication blocks using other techniques
         are allowed, but not specified.

         This implies one of the following things:

          o a shared DSA key pair must be distributed amongst the
            devices,

          o a mechanism must be devised which allows devices to securely
            obtain the public key needed to verify a particular
            signature,





Expires May 2001                                                [Page 9]


Draft                  Securing Zeroconf Networks          November 2000


          o the DSS signature is computed, but ignored in favour of some
            other scheme which is included as an additional
            authentication block (e.g. an HMAC computed with a shared
            symmetric key).


         Work would need to be done on SLPv2 to support confidentiality,
         and thus prevent passive sniffing of available
         services/devices.


      4.2.4.  Automatic allocation of Multicast Addresses

         A claim/collide multicast address allocation mechanism is
         described in [AutoAAP], which adapts the Multicast Address
         Allocation Protocol [AAP] to zeroconf networks.

         The AAP specification recommends the use of IPSec when security
         is required.  Since AAP messages are multicast, the same issues
         discussed earlier with IPSec and security associations for
         multicast and broadcast apply here.


5.  Conclusion

   Bootstrapping IPSec to secure zeroconf networks seems by far the most
   promising approach to zeroconf security.  Although there are a
   security mechanisms present in the candidate protocols, they
   typically provide authentication and not confidentiality.  Each
   protocol uses a different approach to security, and to secure each
   adds additional complexity to the security problem.  In contrast,
   IPSec is a single mechanism providing both authentication and
   confidentiality and covers all the candidate protocols.


6.  Security Considerations

   This draft addresses security considerations in various protocols
   proposed for zeroconf networks.


7.  Acknowledgements

   Steve Hanna has provided much helpful input to this draft.






Expires May 2001                                               [Page 10]


Draft                  Securing Zeroconf Networks          November 2000


8.  References


   [AAP]
        Mark Handley, Stephen R. Hanna, "Multicast Address Allocation
        Protocol (AAP)" draft-ietf-malloc-aap-04.txt, work-in-progress.


   [AutoAAP]
        Dave Thaler, Bernard Aboba, "Multicast Address Allocation in
        Auto-Configured Networks", draft-thaler-zeroconf-
        multicast-02.txt, work-in-progress.


   [DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631,
        June 1999.
        Note that certificates aren't necessary for the application of
        Diffie-Hellman to zeroconf networks.  Any technique that would
        prevent a man-in-the-middle attack could be employed.


   [DNSSEC]
        D. Eastlake., "Domain Name System Security Extensions", RFC
        2535, March 1999.


   [HomePNA]
        Home Phoneline Networking: http://www.homepna.org/


   [HomePlug]
        Powerline networking: http://www.homeplug.org/


   [IKE]
        D. Harkins, D. Carrel., "The Internet Key Exchange (IKE)", RFC
        2409, November 1998.


   [IPSecArch]
        S. Kent, R. Atkinson., "Security Architecture for the Internet
        Protocol", RFC 2401, November 1998.








Expires May 2001                                               [Page 11]


Draft                  Securing Zeroconf Networks          November 2000


   [IPv4LL]
        Stuart Cheshire, "Dynamic Configuration of IPv4 link-local
        addresses", draft-ietf-zeroconf-ipv4-linklocal-00.txt, work-in-
        progress.


   [IPv6AddrConf]
        S. Thomson, T. Narten., "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.


   [mDNS]
        Levon Esibov, Bernard Aboba, Dave Thaler, "Multicast DNS",
        draft-aboba-dnsext-mdns-01.txt, work-in-progress.


   [QUACK]
        Frank Stajano, Ross Anderson, "The Resurrecting Duckling:
        Security Issues for Ad-hoc Wireless Networks"
        http://www.cl.cam.ac.uk/~fms27/duckling/, April 1999


   [SECCFG]
        Steve Hanna, Aidan Williams, "Lightweight Security
        Configuration", draft-hanna-zeroconf-seccfg-00.txt, work-in-
        progress.


   [SLPv2]
        E. Guttman, C. Perkins, J. Veizades, M. Day., "Service Location
        Protocol, Version 2", RFC 2165, June 1999.


   [SMUG]
        This is an IRTF working group.
        http://www.securemulticast.org/


   [SSH]
        T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. Lehtinen,
        "SSH Protocol Architecture", draft-ietf-secsh-
        architecture-05.txt, work-in-progress.








Expires May 2001                                               [Page 12]


Draft                  Securing Zeroconf Networks          November 2000


   [WLAN]
        Two common flavours of wireless LANs are:
        802.11 based -- http://www.wirelessethernet.com/
        HomeRF based -- http://www.homerf.org/


9.  Author's Addresses

   Aidan Williams
   Motorola Australian Research Centre
   Locked Bag 5028
   Botany, NSW, 1455,
   Australia
   Aidan.Williams@motorola.com


10.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."









Expires May 2001                                               [Page 13]


Draft                  Securing Zeroconf Networks          November 2000


   Table of Contents


    Status of this Memo ...........................................    1
    Abstract ......................................................    1
    Copyright Notice ..............................................    2
   1 Background ...................................................    2
   2 Motivating Scenarios for Zeroconf Security ...................    3
   2.1 Adhoc, Shared Networks .....................................    3
   2.2 Home Networking ............................................    3
   3 Security Characteristics of Zeroconf Networks ................    4
   3.1 What Needs to be Supported?  ...............................    4
   3.2 Sharing Secrets ............................................    5
   3.3 Vulnerabilities in Checking for Configuration Servers ......    5
   4 Options for Zeroconf Security ................................    6
   4.1 Using IPSec to Provide Network Layer Security ..............    7
   4.2 Securing Individual Zeroconf Protocols .....................    7
   4.2.1 Interface Configuration ..................................    8
   4.2.1.1 Dynamic Configuration of IPv4 Link-Local Addresses
             ......................................................    8
   4.2.1.2 IPv6 Stateless Address Autoconfiguration ...............    8
   4.2.2 Name-to-Address Translation ..............................    8
   4.2.3 Service Discovery ........................................    9
   4.2.4 Automatic allocation of Multicast Addresses ..............   10
   5 Conclusion ...................................................   10
   6 Security Considerations ......................................   10
   7 Acknowledgements .............................................   10
   8 References ...................................................   11
   9 Author's Addresses ...........................................   13
   10 Full Copyright Statement ....................................   13




















Expires May 2001                                               [Page 14]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/