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 $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]