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

Versions: 00

                                                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


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