Narendar Shankar Univ of Maryland William Arbaugh Univ of Maryland Kan Zhang Hewlett-Packard Labs Wireless Key Management using DHCP draft-ietf-dhc-key-management-00.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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, and the list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure the WEP key on a client's wireless card. In wireless LAN's it is important to encrypt data at the link layer, because of the potential for eavesdropping. This is done in current wireless networks using WEP which has a number of well known flaws- some of which are mitigated through the use of effective key management. For a wireless LAN, DHCP provides an excellent mechanism for implementing wireless key management as it is transparent to the users. 1. Introduction. DHCP [1] transports protocol stack configuration parameters from centrally administered servers to TCP/IP hosts. Among those parameters are an IP address. DHCP servers can be configured to dynamically allocate addresses from a pool of addresses, eliminating a manual step in configuration of TCP/IP hosts. A wireless LAN consists of wireless clients(called STA's) which communicate with the wired backbone by means of wireless access points(called AP's). The AP acts a bridge between the wireless and the wired networks. Nodes of a wireless LAN normally use DHCP services to obtain IP addresses, and key management is an easy Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 [page 2] extension. We propose the use of a new DHCP option which supports wireless key management 1.1 Threat Model Organizations are rapidly deploying wireless infrastructures based on the IEEE 802.11 standard. Unfortunately, this standard provides only limited and weak support for confidentiality through the wired equivalent privacy (WEP) [2][3]. Furthermore, the standards committee for 802.11 left many of the difficult security issues such as key management and a robust authentication mechanism as open problems. As a result, many of the organizations deploying wireless networks use either a permanent fixed key or no encryption what so ever. 1.2 Use of DHCP for wireless key management. Many new schemes which have been proposed to address the authentication, confidentiality and key management for IEEE 802.11. The IEEE 802.11 task group on security proposes a change in the 802.11 standard to use the recent 802.1X standard as a means for key managment. However, this cannot solve the problem for the current installed base. We propose the use of a new DHCP option for wireless key management. The advantages of using DHCP as a "transport" for wireless keys are 1.2.1 DHCP leases provide an excellent mechanism for implementing cryptographic key periods. When a DHCP client renews its lease with the DHCP server, it also obtains the current wireless key as a part of the lease. The time for renewal of the lease can be appropriately set by the enterprise. 1.2.2 The use of DHCP for wireless key management is very inexpensive and more importantly it interoperates with the huge existing installed base. 1.3 Design goals These are the goals that were used in the development of the authentication protocol, listed in order of importance: 1. Provide a good key management system for wireless LAN's using the DHCP services of the wired LAN's 2. Work with the existing infrastructure 3. Limit complexity (complexity breeds design and implementation errors). 1.4 DHCP Terminology Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 [page 3] This document uses the following terms: o "DHCP client" A DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. o "DHCP server" A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. 1.5 Wireless LAN terminology This document uses the following terms o "Wireless Station/Wireless client(STA)" A node/client with a wireless interface . o "Wireless Access Point(AP)" An access point mediates communication between wireless nodes which can't directly communicate with each other. The AP acts like a link layer bridge. o "Wired Equivalent privacy(WEP)" WEP is a the standard for ensuring confidentiality of data (link layer data) specified by the IEEE802.11b standard o "Shared Key and window of keys" WEP uses a shared key for all nodes which wish to communicate with each other. Link layer traffic is encrypted and decrypted with this key. A window of four keys is used as a back up when keys become invalid or unusable. In other words the access point and the clients have a window of keys on their wireless cards and use one of the keys on the card for communication. o Authentication key This is a relatively long lived "WEP" (link layer) key used by the STA for authentication purposes. It is denoted by 'A'. o "Current link layer key" This is the current key being used for link layer communication. It is denoted by 'K' o "Next link layer key" Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 [page 4] This is the next link layer key to be used. It is denoted by 'K_n' 2. Basic protocol The wireless network consists of STA's trying to connect to a wired network using the AP. The DHCP server is in the wired part of the network. All link layer traffic is encrypted using the "Current Key"- 'K' ( the current link layer key). Wireless traffic from the STA's is encrypted using 'K'. The AP decrypts the wireless traffic (because it too has 'K') and forwards the traffic to the wired network. The idea to mitigate current WEP flaws is to keep changing the current key 'K'. At the same time valid STA's of the network, who leave the network must be able to obtain the new current key (if it has changed) when they rejoin the network. This is accomplished by a "double door" entry mechanism where the STA authenticates itself into the network using a "link layer authentication key" (another WEP key) called 'A'. The frequency of use of 'A' is small when compared to 'K' and is hence considered to be a key with a longer lifetime. Both the AP and the STA's have a window of four WEP keys. They can listen on any of the four keys but can transmit only on one key. The access point listens on both 'K' and 'A'. The STA's who are a part of the network have 'K' and 'A'. The valid STA's who do not have 'K'(they had left the network and are now rejoining) can authenticate themselves using 'A'. After the STA's have authenticated themselves they obtain the current link layer key 'K'. Apart from rejoining the network, regular timed key management takes place for all STA's currently in the network. In other words the current key 'K' keeps changing frequently. We use DHCP as a "transport mechanism" for gettng the new link layer key 'K_n'. The basic idea is as follows: 1. When the client/STA joins/rejoins the network, it is assigned an IP address and is given the current link layer key 'K'. The IP address is leased for a particular time period. This time period is set by organizational policy. Apart from this the STA is also given the next link layer WEP key K_n. The reason for doing this is explained in the timing section. 2. All the clients in the network who have the current key renew their IP address (NOTE: the address does not need to change) depending on the lease time and in the process also get the new link layer key K_n. Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 [page 5] 2.1 Protocol for a client /STA rejoining the network Like it had been mentioned before, the STA does not have the current link layer key 'K' but has the link layer authentication key 'A'. Given below is the protocol for the client to rejoin the network and get the current link layer key 'K'. <---Wireless LAN---------------------><--------Wired LAN-------> DHCPDISCOVER(with Wireless re-key and authentication option set) STA ---------------------------------> AP------------->DHCP SERVER (Listens on 'A','K') DHCPOFFER STA <--------------------AP<-------------------------------DHCP SERVER Authentication Information ASK AP TO CHANGE TO 'A' DHCPREQUEST STA ---------------------------------> AP------------->DHCP SERVER Authentication Information DHCPACK STA <--------------------AP<-------------------------------DHCP SERVER Encrypted (Current Link layer key 'K' + Next Link layer key 'K_n') 1. In the initial phase the STA sends a DHCPDISCOVER message with the wireless re-key option set and the DHCP authentication option set. The STA transmits the message encrypted with the link layer Authentication (WEP) Key 'A'. The AP can listen on 'A' and 'K' and hence forwards the request to the DHCP server on the wired LAN. 2. The DHCP server sends a DHCPOFFER message including the authentication information in accordance with the DHCP authentication protocol[5]. It must also be noted that the AP's transmission key MUST changed to 'A' before transmission and back to K afterwards. The protocol for changing the AP's key is beyond the scope of this document. The duration for the change from 'K' to 'A' can be aproximately set to the average period of time for an exchange starting from DHCPDISCOVER to DHCPACK 3. Then the STA transmits a DHCPREQUEST message, with the authentication information.The authentication information is again in accordance with [5]. Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 [page 6] 4. The DHCP server sends back a DHCPACK message and also its authentication informtion and also the Current Link layer key 'K' "in an encrypted format". The WEP key MUST sent in an encrypted format. The encryption can be done with a shared key or any authentication mechanism between the client and server as defined by [5]. Also the DHCP server sends the next link layer key K_n(encrypted). The reason and the details are explained in the timing section. 2.2 Phase for renewing allocated IP address when lease expires <---Wireless LAN---------------------><--------Wired LAN-------> DHCPREQUEST STA ---------------------------------> AP------------->DHCP SERVER Authentication Message DHCPACK STA <--------------------AP<-------------------------------DHCP SERVER ENCRYPTED Next current Link Layer key K_n When the lease expires the DHCP client contacts the DHCP server and tries to renew its IP address. When the IP address is renewed, the WEP key is also renewed. This phase is very similar to the initial phase, but for the fact that the AP can transmit in 'K'(current key) because the client already has the current key 'K'. Again here the New WEP key K_n MUST be sent in an encrypted format, and both the client and the DHCP server MUST use the authentication option. 3. Delayed key installation for better key management. The straight forward key management protocol has two problems: 1. If all the clients renew the keys at the same time then the server becomes overloaded. 2. If all the clients renew their keys at different times, then inconsistency problems are introduced and the server might have to listen on multiple keys for prolonged periods. We introduce a new idea of timed key management. All clients contact the server at different times. For the first stage(client joins the network/rejoins the network), assume that the client contacts the server at time t1 (actual time or real world time) and assume the lease period is T seconds. When the client joins the network, it needs the current link layer Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 [page 7] immediately. Also as mentioned before, the client obtains the next link layer session key. The reason for doing so is that during every key renewal the client gets the next link layer key, but initially the client does not even have the current link layer key. Hence it has to be given both the keys. An example is given below. At time t1 K is the current link layer key. The client contacts the server again at time t1+T ( i.e t1+ time of lease). Since the client joins in the middle of a lease period, at some absolut time t2 (t1 < t2< t1+T), a new key K_n will be installed on all cards (t2 is termed the "key installation time" and t1+T, t1+2T are all termed as "key renewal times"). This means that from t2 to t1+T this client cannot communicate with the rest of the network. Thus when the client joins the network initially it must be given both the curernt key K and the next link layer key K_n (note that both are link layer keys). Also the client must be given the directive -"Install the key K on the card immediately and use (install on card) the key K_n after t2 - t1 seconds" Now in the next stage, the client already has the current key and it only gets the next link layer key K_n . Assume that the client contacts the server at time t1+T(end of the lease), it obtains the key K_n to be used at time t2+T and the directive "Install key K_n after t2+T-(t1+T) = t2-t1 seconds" Thus the client keeps contacting the server at times(renewal phase) t1 + T, t1 + 2T, t1 + 3T etc., but actual use/installation of the key takes place at times t2, t2 + T, t2 + 2T, t2 + 3T etc. 4. Format of wireless authentication option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |Length of encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Time to install next key (t2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted current WEP Key (with appropriate encapsulation) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted next WEP Key (with appropriate encapsulation) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Code field is TBD o Length field specifies the length of the option Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 [page 8] o The DHCP authentication option MUST be set if the wireless re-key option is set. o Length of encapsulation filed MUST be set to the size of the encapsulation method used to encapsulate the encrypted current wireless key(explained next). o Encrypted current and next key MAY be of variable length but MUST be encapusulated with the PKCS#7 [6] standard which gives enough information about the algorithm and the encryption parameters o Time to install next key- It is the time in seconds between acquiring the next WEP Key and the time when it is to be installed on the card. The length MUST be set to 32 bits. 5. DHCP client behaviour o Client MUST use the DHCP authentication option. o Client MUST set the wireless rekey option in the DHCPDISCOVER message if it wishes to rejoin the network(because it does not have the current link layer key). o Client MUST set the "Time to install next key" field to be all 1's(0xffffffff) if it is joining/ rejoining the network. This is required because the server must be able to distinguish that the client requires the wireless key immediately. o Client MUST set the wireless rekey option in the DHCPREQUEST message if it wishes to renew the current wireless key. Once again it must be remembered that there might be a time difference between getting the key and installing it on the card. o If the Encrypted current WEP key field is set(not all zeroes), the client MUST install current WEP key(after decryption) on the card immediately o Client MUST install the Next WEP key (after decrypting it) on the card only after a time which is equal to "time to install next key". It may be noted that "Time to install next key" MAY be zero. o The protocol for updating the key on the Wireless card on the STA is beyond the scope of this paper. 6. DHCP server behaviour o Server MUST use the DHCP authentication option. o Server MUST ignore the wireless re-key option if the DHCP authentication option is not set. o Server MUST set "Encrypted Current WEP key" field if the client is trying to rejoin the network. This can be identified if the client Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 [page 9 sets the "Time to install next key" to be 0xffffffff. If the client hasnt set the "Time to install next key" (client is not rejoinng network but just renewing current key) field, the server MUST set the "Encrypted Current key" to be all 0's o Server MUST set the "Encrypted next WEP key" (with the encrypted next WEP key) o The server MUST set "Time to install next key" to be the difference in time between issuing the next key and the time when the client must install it. o Server MUST encrypt the current WEP key before sending it to the client. o Server MUST encrypt the next WEP key before sending it to the client. o Server MUST send the encrypted WEP key only in the DHCPACK message. o The protocol for updating and changing the key on the Access Point is beyond the scope of this paper as the protocol for the DHCP server to obtain the current and next keys from a key server. It is to be discussed in a separate paper. 6. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March 1997. [2] J. Walker," Unsafe at any key size: an analysis of the WEP encapsulation," Tech. Rep. 03628E, IEEE 802.11 committee, March 2000. http://grouper.ieee.org/groups/802/11/Documents/ DocumentHolder/0-362.zip. [3] N. Borisov, I. Goldberg, and D. Wagner, "Intercepting Mobile Commu- nications: The Insecurity of 802.11." http://www.isaac.cs.berkeley. edu/isaac/wep-faq.html. [4] W. Arbaugh, N. Shankar, Y.C Justin Wan,"Your 802.11 wireless network has no clothes". http://www.cs.umd.edu/~waa/wireless.pdf [5] R. Droms, W. Arbaugh. "Authentication for DHCP messages", RFC-3118, June 2001 [6] B. Kaliski. "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC-2315, March 1998 7. Security Considerations This document describes a key management option for use in wireless networks. 7.1 Protocol vulnerabilities The fact that the AP is listening on 'A' allows unauthenticated Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 [page 10] clients to send unauthorized packets onto the network. Organizations are strongly advised to implement layer 2 and 3 packet filtering between the wireless and wired networks in conjunction with this option 7.2 Protocol limitations This protocol assumes the existence of an authentication server and a key server. 8. Acknowledgements The authors would like to thank Y.C.(Justin) Wan for working with us on an initial implementation of this protocol. 9. Authors Addresses Narendar Shankar Department of Computer Science University of Maryland A.V. Williams Building College Park, MD 20742 Email: narendar@cs.umd.edu William A. Arbaugh Department of Computer Science University of Maryland A.V. Williams Building College Park, MD 20742 Email: waa@cs.umd.edu Kan Zhang Hewlett-Packard Labs 1501 Page Mill Road Palo Alto, CA 94304 Email: kan_zhang@hp.com