idnits 2.17.1 draft-ietf-dhc-key-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 35 instances of too long lines in the document, the longest one being 27 characters in excess of 72. ** There are 64 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 254: '...transmission key MUST changed to 'A' b...' RFC 2119 keyword, line 267: '...d format". The WEP key MUST sent in an...' RFC 2119 keyword, line 292: '...'. Again here the New WEP key K_n MUST...' RFC 2119 keyword, line 294: '... server MUST use the authentication o...' RFC 2119 keyword, line 364: '...ntication option MUST be set if the w...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 165 has weird spacing: '...k layer key t...' == Line 201 has weird spacing: '... The basic id...' == Line 323 has weird spacing: '...at some absol...' == Line 324 has weird spacing: '...will be insta...' == Line 359 has weird spacing: '...e field is TB...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 452, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2315 (ref. '6') Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Narendar Shankar 2 Univ of Maryland 4 William Arbaugh 5 Univ of Maryland 7 Kan Zhang 8 Hewlett-Packard Labs 10 Wireless Key Management using DHCP 11 draft-ietf-dhc-key-management-00.txt 13 Status of this memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt, and the list of 28 Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines a new DHCP option which is passed from the 34 DHCP Server to the DHCP Client to configure the WEP key on a client's 35 wireless card. 37 In wireless LAN's it is important to encrypt data at the link 38 layer, because of the potential for eavesdropping. This is done in 39 current wireless networks using WEP which has a number of well 40 known flaws- some of which are mitigated through the use of 41 effective key management. For a wireless LAN, DHCP provides an 42 excellent mechanism for implementing wireless key management as it 43 is transparent to the users. 45 1. Introduction. 47 DHCP [1] transports protocol stack configuration parameters from 48 centrally administered servers to TCP/IP hosts. Among those 49 parameters are an IP address. DHCP servers can be configured to 50 dynamically allocate addresses from a pool of addresses, eliminating 51 a manual step in configuration of TCP/IP hosts. 53 A wireless LAN consists of wireless clients(called STA's) which 54 communicate with the wired backbone by means of wireless access 55 points(called AP's). The AP acts a bridge between the wireless and 56 the wired networks. Nodes of a wireless LAN normally use DHCP 57 services to obtain IP addresses, and key management is an easy 59 Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 60 extension. We propose the use of a new DHCP option which supports 61 wireless key management 63 1.1 Threat Model 65 Organizations are rapidly deploying wireless infrastructures based 66 on the IEEE 802.11 standard. Unfortunately, this standard provides 67 only limited and weak support for confidentiality through the 68 wired equivalent privacy (WEP) [2][3]. Furthermore, the 69 standards committee for 802.11 left many of the difficult security 70 issues such as key management and a robust authentication mechanism 71 as open problems. As a result, many of the organizations deploying 72 wireless networks use either a permanent fixed key or no encryption 73 what so ever. 75 1.2 Use of DHCP for wireless key management. 77 Many new schemes which have been proposed to address the 78 authentication, confidentiality and key management for IEEE 79 802.11. The IEEE 802.11 task group on security proposes a change 80 in the 802.11 standard to use the recent 802.1X standard as a 81 means for key managment. However, this cannot solve the problem 82 for the current installed base. We propose the use of a new DHCP 83 option for wireless key management. 85 The advantages of using DHCP as a "transport" for wireless keys are 87 1.2.1 DHCP leases provide an excellent mechanism for implementing 88 cryptographic key periods. When a DHCP client renews its 89 lease with the DHCP server, it also obtains the current 90 wireless key as a part of the lease. The time for renewal 91 of the lease can be appropriately set by the enterprise. 93 1.2.2 The use of DHCP for wireless key management is very 94 inexpensive and more importantly it interoperates with the 95 huge existing installed base. 97 1.3 Design goals 99 These are the goals that were used in the development of the 100 authentication protocol, listed in order of importance: 102 1. Provide a good key management system for wireless LAN's using the 103 DHCP services of the wired LAN's 105 2. Work with the existing infrastructure 107 3. Limit complexity (complexity breeds design and implementation 108 errors). 110 1.4 DHCP Terminology 112 Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 113 This document uses the following terms: 115 o "DHCP client" 117 A DHCP client or "client" is an Internet host using DHCP to obtain 118 configuration parameters such as a network address. 120 o "DHCP server" 122 A DHCP server or "server" is an Internet host that returns 123 configuration parameters to DHCP clients. 125 1.5 Wireless LAN terminology 127 This document uses the following terms 129 o "Wireless Station/Wireless client(STA)" 131 A node/client with a wireless interface . 133 o "Wireless Access Point(AP)" 135 An access point mediates communication between wireless nodes 136 which can't directly communicate with each other. The AP acts like a link layer bridge. 138 o "Wired Equivalent privacy(WEP)" 140 WEP is a the standard for ensuring confidentiality of data 141 (link layer data) specified by the IEEE802.11b standard 143 o "Shared Key and window of keys" 145 WEP uses a shared key for all nodes which wish to communicate 146 with each other. Link layer traffic is encrypted and decrypted 147 with this key. A window of four keys is used as a back up when 148 keys become invalid or unusable. In other words the access 149 point and the clients have a window of keys on their wireless 150 cards and use one of the keys on the card for communication. 152 o Authentication key 154 This is a relatively long lived "WEP" (link layer) key used by the STA for 155 authentication purposes. It is denoted by 'A'. 157 o "Current link layer key" 159 This is the current key being used for link layer communication. It is 160 denoted by 'K' 162 o "Next link layer key" 164 Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 165 This is the next link layer key to be used. It is denoted by 'K_n' 167 2. Basic protocol 169 The wireless network consists of STA's trying to connect to a wired 170 network using the AP. The DHCP server is in the wired part of the 171 network. All link layer traffic is encrypted using the "Current 172 Key"- 'K' ( the current link layer key). Wireless traffic from the 173 STA's is encrypted using 'K'. The AP decrypts the wireless traffic 174 (because it too has 'K') and forwards the traffic to the wired 175 network. 177 The idea to mitigate current WEP flaws is to keep changing the 178 current key 'K'. At the same time valid STA's of the network, who 179 leave the network must be able to obtain the new current key (if it 180 has changed) when they rejoin the network. This is accomplished by 181 a "double door" entry mechanism where the STA authenticates itself 182 into the network using a "link layer authentication key" (another 183 WEP key) called 'A'. The frequency of use of 'A' is small when 184 compared to 'K' and is hence considered to be a key with a longer 185 lifetime. Both the AP and the STA's have a window of four WEP 186 keys. They can listen on any of the four keys but can transmit only 187 on one key. 189 The access point listens on both 'K' and 'A'. The STA's who are a 190 part of the network have 'K' and 'A'. The valid STA's who do not 191 have 'K'(they had left the network and are now rejoining) can 192 authenticate themselves using 'A'. After the STA's have 193 authenticated themselves they obtain the current link layer key 194 'K'. 196 Apart from rejoining the network, regular timed key management 197 takes place for all STA's currently in the network. In other words 198 the current key 'K' keeps changing frequently. We use DHCP as a 199 "transport mechanism" for gettng the new link layer key 'K_n'. 201 The basic idea is as follows: 203 1. When the client/STA joins/rejoins the network, it is 204 assigned an IP address and is given the current link layer 205 key 'K'. The IP address is leased for a particular time 206 period. This time period is set by organizational 207 policy. Apart from this the STA is also given the next link 208 layer WEP key K_n. The reason for doing this is explained 209 in the timing section. 211 2. All the clients in the network who have the current key 212 renew their IP address (NOTE: the address does not need to 213 change) depending on the lease time and in the process also 214 get the new link layer key K_n. 216 Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 217 2.1 Protocol for a client /STA rejoining the network 219 Like it had been mentioned before, the STA does not have the 220 current link layer key 'K' but has the link layer authentication 221 key 'A'. Given below is the protocol for the client to rejoin the 222 network and get the current link layer key 'K'. 224 <---Wireless LAN---------------------><--------Wired LAN-------> 226 DHCPDISCOVER(with Wireless re-key and authentication option set) 227 STA ---------------------------------> AP------------->DHCP SERVER 228 (Listens on 'A','K') 230 DHCPOFFER 231 STA <--------------------AP<-------------------------------DHCP SERVER 232 Authentication Information 233 ASK AP TO CHANGE TO 'A' 235 DHCPREQUEST 236 STA ---------------------------------> AP------------->DHCP SERVER 237 Authentication Information 239 DHCPACK 240 STA <--------------------AP<-------------------------------DHCP SERVER 241 Encrypted (Current Link layer key 'K' + 242 Next Link layer key 'K_n') 244 1. In the initial phase the STA sends a DHCPDISCOVER message with 245 the wireless re-key option set and the DHCP authentication 246 option set. The STA transmits the message encrypted with the 247 link layer Authentication (WEP) Key 'A'. The AP can listen on 248 'A' and 'K' and hence forwards the request to the DHCP server on 249 the wired LAN. 251 2. The DHCP server sends a DHCPOFFER message including the 252 authentication information in accordance with the DHCP 253 authentication protocol[5]. It must also be noted that the AP's 254 transmission key MUST changed to 'A' before transmission and 255 back to K afterwards. The protocol for changing the AP's key is 256 beyond the scope of this document. The duration for the change from 'K' to 257 'A' can be aproximately set to the average period of time for an exchange starting from 258 DHCPDISCOVER to DHCPACK 260 3. Then the STA transmits a DHCPREQUEST message, with the 261 authentication information.The authentication information is 262 again in accordance with [5]. 264 Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 265 4. The DHCP server sends back a DHCPACK message and also its 266 authentication informtion and also the Current Link layer key 267 'K' "in an encrypted format". The WEP key MUST sent in an 268 encrypted format. The encryption can be done with a shared key 269 or any authentication mechanism between the client and server as 270 defined by [5]. Also the DHCP server sends the next link layer 271 key K_n(encrypted). The reason and the details are explained in 272 the timing section. 274 2.2 Phase for renewing allocated IP address when lease expires 276 <---Wireless LAN---------------------><--------Wired LAN-------> 278 DHCPREQUEST 279 STA ---------------------------------> AP------------->DHCP SERVER 280 Authentication Message 282 DHCPACK 283 STA <--------------------AP<-------------------------------DHCP SERVER 284 ENCRYPTED Next current Link Layer key K_n 286 When the lease expires the DHCP client contacts the DHCP server and 287 tries to renew its IP address. When the IP address is renewed, the 288 WEP key is also renewed. 290 This phase is very similar to the initial phase, but for the fact 291 that the AP can transmit in 'K'(current key) because the client 292 already has the current key 'K'. Again here the New WEP key K_n MUST 293 be sent in an encrypted format, and both the client and the DHCP 294 server MUST use the authentication option. 296 3. Delayed key installation for better key management. 298 The straight forward key management protocol has two problems: 300 1. If all the clients renew the keys at the same time then the 301 server becomes overloaded. 303 2. If all the clients renew their keys at different times, 304 then inconsistency problems are introduced and the server 305 might have to listen on multiple keys for prolonged 306 periods. We introduce a new idea of timed key 307 management. All clients contact the server at different 308 times. 310 For the first stage(client joins the network/rejoins the network), 311 assume that the client contacts the server at time t1 (actual time 312 or real world time) and assume the lease period is T seconds. When 313 the client joins the network, it needs the current link layer 314 Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 315 immediately. Also as mentioned before, the client obtains the next 316 link layer session key. The reason for doing so is that during every 317 key renewal the client gets the next link layer key, but initially 318 the client does not even have the current link layer key. Hence it 319 has to be given both the keys. An example is given below. 321 At time t1 K is the current link layer key. The client contacts the 322 server again at time t1+T ( i.e t1+ time of lease). Since the client joins 323 in the middle of a lease period, at some absolut time t2 (t1 < t2< t1+T), 324 a new key K_n will be installed on all cards (t2 325 is termed the "key installation time" and t1+T, t1+2T are all termed 326 as "key renewal times"). This means that from t2 to t1+T this 327 client cannot communicate with the rest of the network. 329 Thus when the client joins the network initially it must be given 330 both the curernt key K and the next link layer key K_n (note that 331 both are link layer keys). Also the client must be given the 332 directive -"Install the key K on the card immediately and use 333 (install on card) the key K_n after t2 - t1 seconds" 335 Now in the next stage, the client 336 already has the current key and it only gets the next link layer key 337 K_n . Assume that the client contacts the server at time t1+T(end of 338 the lease), it obtains the key K_n to be used at time t2+T and the 339 directive "Install key K_n after t2+T-(t1+T) = t2-t1 seconds" 341 Thus the client keeps contacting the server at times(renewal phase) 342 t1 + T, t1 + 2T, t1 + 3T etc., but actual use/installation of the 343 key takes place at times t2, t2 + T, t2 + 2T, t2 + 3T etc. 345 4. Format of wireless authentication option. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Code | Length |Length of encapsulation | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |Time to install next key (t2) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Encrypted current WEP Key (with appropriate encapsulation) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Encrypted next WEP Key (with appropriate encapsulation) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 o Code field is TBD 361 o Length field specifies the length of the option 363 Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 364 o The DHCP authentication option MUST be set if the wireless re-key option 365 is set. 367 o Length of encapsulation filed MUST be set to the size of the encapsulation 368 method used to encapsulate the encrypted current wireless key(explained next). 370 o Encrypted current and next key MAY be of variable length but MUST be 371 encapusulated with the PKCS#7 [6] standard which gives enough 372 information about the algorithm and the encryption parameters 374 o Time to install next key- It is the time in seconds between 375 acquiring the next WEP Key and the time when it is to be installed on 376 the card. The length MUST be set to 32 bits. 378 5. DHCP client behaviour 380 o Client MUST use the DHCP authentication option. 382 o Client MUST set the wireless rekey option in the DHCPDISCOVER message if 383 it wishes to rejoin the network(because it does not have the current link 384 layer key). 386 o Client MUST set the "Time to install next key" field to be all 1's(0xffffffff) 387 if it is joining/ rejoining the network. This is required because the server must be able 388 to distinguish that the client requires the wireless key immediately. 390 o Client MUST set the wireless rekey option in the DHCPREQUEST message 391 if it wishes to renew the current wireless key. Once again it must 392 be remembered that there might be a time difference between getting 393 the key and installing it on the card. 395 o If the Encrypted current WEP key field is set(not all zeroes), the 396 client MUST install current WEP key(after decryption) on the card 397 immediately 399 o Client MUST install the Next WEP key (after decrypting it) on the 400 card only after a time which is equal to "time to install next 401 key". It may be noted that "Time to install next key" MAY be zero. 403 o The protocol for updating the key on the Wireless card on the STA is beyond 404 the scope of this paper. 406 6. DHCP server behaviour 408 o Server MUST use the DHCP authentication option. 410 o Server MUST ignore the wireless re-key option if the DHCP authentication 411 option is not set. 413 o Server MUST set "Encrypted Current WEP key" field if the client is 414 trying to rejoin the network. This can be identified if the client 415 Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 416 sets the "Time to install next key" to be 0xffffffff. If the client 417 hasnt set the "Time to install next key" (client is not rejoinng 418 network but just renewing current key) field, the server MUST set 419 the "Encrypted Current key" to be all 0's 421 o Server MUST set the "Encrypted next WEP key" (with the encrypted next WEP key) 423 o The server MUST set "Time to install next key" to be the difference 424 in time between issuing the next key and the time when the client 425 must install it. 427 o Server MUST encrypt the current WEP key before sending it to the client. 429 o Server MUST encrypt the next WEP key before sending it to the client. 431 o Server MUST send the encrypted WEP key only in the DHCPACK message. 433 o The protocol for updating and changing the key on the Access Point 434 is beyond the scope of this paper as the protocol for the DHCP 435 server to obtain the current and next keys from a key server. It is 436 to be discussed in a separate paper. 438 6. References 440 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, 441 March 1997. 443 [2] J. Walker," Unsafe at any key size: an analysis of the 444 WEP encapsulation," Tech. Rep. 03628E, IEEE 802.11 committee, 445 March 2000. http://grouper.ieee.org/groups/802/11/Documents/ 446 DocumentHolder/0-362.zip. 448 [3] N. Borisov, I. Goldberg, and D. Wagner, "Intercepting Mobile Commu- 449 nications: The Insecurity of 802.11." http://www.isaac.cs.berkeley. 450 edu/isaac/wep-faq.html. 452 [4] W. Arbaugh, N. Shankar, Y.C Justin Wan,"Your 802.11 wireless network 453 has no clothes". http://www.cs.umd.edu/~waa/wireless.pdf 455 [5] R. Droms, W. Arbaugh. "Authentication for DHCP messages", RFC-3118, June 2001 457 [6] B. Kaliski. "PKCS #7: Cryptographic Message Syntax Version 1.5", 458 RFC-2315, March 1998 460 7. Security Considerations 462 This document describes a key management option for use in wireless 463 networks. 465 7.1 Protocol vulnerabilities 467 The fact that the AP is listening on 'A' allows unauthenticated 468 Shankar, Arbaugh, Zhang Wireless Key Management using DHCP July 2001 469 clients to send unauthorized packets onto the 470 network. Organizations are strongly advised to implement layer 2 471 and 3 packet filtering between the wireless and wired networks in 472 conjunction with this option 474 7.2 Protocol limitations 476 This protocol assumes the existence of an authentication server 477 and a key server. 479 8. Acknowledgements 481 The authors would like to thank Y.C.(Justin) Wan for working with us on an 482 initial implementation of this protocol. 484 9. Authors Addresses 486 Narendar Shankar 487 Department of Computer Science 488 University of Maryland 489 A.V. Williams Building 490 College Park, MD 20742 492 Email: narendar@cs.umd.edu 494 William A. Arbaugh 495 Department of Computer Science 496 University of Maryland 497 A.V. Williams Building 498 College Park, MD 20742 500 Email: waa@cs.umd.edu 502 Kan Zhang 503 Hewlett-Packard Labs 504 1501 Page Mill Road 505 Palo Alto, CA 94304 507 Email: kan_zhang@hp.com