idnits 2.17.1 draft-ietf-dhc-v4-threat-analysis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 860. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 884. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 137 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (June 13, 2006) is 6526 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2026' is defined on line 738, but no explicit reference was found in the text == Unused Reference: 'RFC3594' is defined on line 755, but no explicit reference was found in the text == Unused Reference: 'RFC3978' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'RFC3979' is defined on line 762, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1541 (Obsoleted by RFC 2131) ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-auth-suboption-03 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hibbs 3 INTERNET-DRAFT Richard Barr Hibbs, P.E. 4 Category: Informational C. Smith 5 Expires: December 15, 2006 C & C Catering 6 B. Volz 7 Cisco Systems, Inc. 8 M. Zohar 9 IBM T. J. Watson Research Center 10 June 13, 2006 12 Dynamic Host Configuration Protocol for IPv4 (DHCPv4) 13 Threat Analysis 15 16 Saved: Tuesday, June 13, 2006, 12:56:25 18 Intellectual Property Rights 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Status of this Memo 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Comments are solicited and should be addressed to the working 44 group's mailing list at dhcwg@ietf.org and/or the author(s). 46 Copyright Notice 48 Copyright (C) The Internet Society (2006). 50 Abstract 52 DHCPv4 (RFC 2131) is a stable, widely used protocol for 53 configuration of host systems in a TCP/IPv4 network. It did not 54 provide for authentication of clients and servers, nor did it 55 provide for data confidentiality. This is reflected in the original 56 "Security Considerations" section of RFC 2131, which identifies a 57 few threats and leaves development of any defenses against those 58 threats to future work. In about 1995, DHCP security began to 59 attract attention from the Internet community, eventually resulting 60 in the publication of RFC 3118 in 2001. Although RFC 3118 was a 61 mandatory prerequisite for the DHCPv4 Reconfigure Extension, RFC 62 3203, it has had no known usage by any commercial or private 63 implementation since its adoption. The DHC Working Group adopted a 64 work item for 2003 to review and modify or replace RFC 3118 to 65 afford a workable, easily deployed security mechanism for DHCPv4. 66 This memo provides a threat analysis of the Dynamic Host 67 Configuration Protocol for Ipv4 (DHCPv4) for use both as RFC 2131 68 advances from Draft Standard to Full Standard and to support our 69 chartered work improving the acceptance and deployment of RFC 3118. 71 Table of Contents 73 1 Introduction................................................4 74 1.1 Issues for Consideration...............................4 75 1.2 Exclusions.............................................4 76 2 Use of Key Words............................................5 77 3 Applicability...............................................5 78 3.1 Assumptions............................................5 79 3.2 Scope of this Memo.....................................5 80 4 General threats to DHCPv4...................................5 81 4.1 Denial-of-Service Attacks..............................5 82 4.1.1 Refusal to Configure Clients.....,...............5 83 4.1.2 Impersonating Clients.............,..............5 84 4.1.3 Flooding...........................,.............6 85 4.2 Client Misconfiguration................................6 86 4.3 Theft of Network Service...............................6 87 4.4 Packet Insertion, Deletion, or Modification............7 88 5 Weaknesses of RFC 3118......................................7 89 5.1 Key Exposure...........................................7 90 5.2 Key Distribution.......................................7 91 5.3 Replay attacks.........................................8 92 5.4 Protocol Agreement Difficulties........................8 93 5.5 DHCPv4 Relay Agents Excluded...........................8 94 5.6 Unanticipated Infrastructure Changes...................8 95 6 DHCPv4 Security Requirements................................9 96 6.1 Environments...........................................9 97 6.2 Capabilities..........................................10 98 6.3 Musings on the Key Distribution Problem...............10 99 6.4 Data Confidentiality..................................11 100 6.4.1 "Public" Data in DHCP Packets...................12 101 6.4.2 Protecting Data in DHCP Options.................12 102 6.5 Host versus User Authentication.......................12 103 6.5.1 Why do we make this distinction?................13 104 6.5.2 Is one mechanism sufficient?....................13 105 7 IANA Considerations........................................14 106 8 Security Considerations....................................14 107 9 Acknowledgements...........................................14 108 10 References................................................14 109 10.1 Normative References.................................14 110 10.2 Informative References...............................15 111 1 Introduction 113 DHCPv4 as defined in [RFC1541] and [RFC2131] does not provide any 114 form of communication security, confidentiality, data integrity, or 115 peer entity authentication. 117 A design team was formed at IETF-55 in Atlanta in November 2002 to 118 look at DHCPv4 and [RFC3118] to document security requirements for 119 DHCPv4. [RFC3118] defines the current security mechanisms for 120 DHCPv4. 122 Unfortunately, RFC 3118 has neither been implemented nor deployed to 123 date. There is widespread feeling that its current restriction to 124 manual keying of clients limits its deployment. The DHC Working 125 Group seeks to rectify this situation by defining security 126 mechanisms for DHCPv4 that have better deployment properties. 128 1.1 Issues for Consideration 130 Specific issues to be considered include: 132 O Improved key management and scalability. 134 O Security for messages passed between relay agents and servers. 136 O The increased usage of DHCPv4 on insecure (e.g., wireless) and 137 public LANs. 139 O The need for clients to be able to authenticate servers, without 140 simultaneously requiring client authentication by the server. 142 O Does use of the Relay Agent Information Option imply the need 143 for authenticated messages between DHCP servers and relay 144 agents? 146 1.2 Exclusions 148 Excluded from our analysis are: 150 O Securing messages between relay agents and servers: work is 151 already underway on this, see [RFC4030] and [relay-ipsec]. 153 O DHCP Reconfigure Extension (FORCERENEW) [RFC3203]: the authors 154 believe it is appropriate to put the onus to provide the 155 analysis on those who are interested in moving that work forward. 156 [Editor's note: despite repeated calls on the DHC Working Group 157 mailing list to identify even a single implementation of 158 FORCERENEW, we are unable to put forward an example of its use.] 160 O DHCP Failover Protocol, as defined in [failover]: the server- 161 to-server protocol used differs significantly from DHCP, and 162 there has been no recent work on the [failover] draft. 164 O DHCP-DNS Interaction, as defined in [fqdn]: securing 165 communication between DHCP servers and DNS servers is a DNS 166 update security issue and therefore out of scope for the DHC 167 working group. 169 O DHCPv6, as defined in [RFC3315]: while we believe that 170 authentication techniques developed for DHCPv4 would generally 171 be applicable to DHCPv6, there are fundamental differences 172 between the two protocols and RFC 3118 specifies DHCPv4-style 173 message and options formats, so we have chosen to concentrate on 174 DHCPv4. 176 O DHCP Lease Query, as defined in [RFC4388]: because of lack of 177 maturity. 179 2 Use of Key Words 181 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 182 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 3 Applicability 187 3.1 Assumptions 189 This document assumes that the reader is familiar with both the base 190 DHCPv4 protocol as defined in [RFC2131] and the DHCPv4 191 authentication extension as defined in [RFC3118], and does not 192 attempt to provide a tutorial on either. 194 3.2 Scope of this Memo 196 This document confines its analysis to DHCPv4, as defined in 197 [RFC2131] and [RFC2132] and DHCP Authentication, as defined in 198 [RFC3118]. 200 4 General threats to DHCPv4 202 These are the classes of threats to the base DHCPv4 protocol. Not 203 all of these are DHCP-specific, nor can all the concerns listed be 204 addressed by DHCP authentication. 206 4.1 Denial-of-Service Attacks 208 4.1.1 Refusal to Configure Clients 210 A rogue DHCP server can refuse to configure clients by responding 211 with either partial information (i.e., missing the IP address, yet 212 containing other information), or a non-routable (or otherwise bad) 213 IP address, or the server may respond to DHCPDISCOVER messages (with 214 DHCPOFFER messages) but then ignore the subsequent client 215 DHCPREQUEST messages. This may cause a client to repeatedly fail to 216 be configured, though clients could take steps to ensure that they 217 subsequently ignore such servers for some time. 219 4.1.2 Impersonating Clients 221 A rogue client can impersonate a client or many clients, by using 222 another client's client identifier (client identifier option) and/or 223 hardware address (chaddr) or by generating these identifiers. This 224 may be done to: 226 O Obtain addresses when hardware address or client identifier 227 restrictions (lists) are configured into the site's server 228 through some mechanism not described in RFC 2131. Some sites 229 may use such a mechanism to restrict the clients that are 230 allowed addresses. A rogue client listens to DHCPv4 traffic and 231 captures a few chaddrs or client identifiers and starts using 232 them. 234 O Simulate many clients to consume all available addresses. The 235 rogue client may either hold on to these addresses (until the 236 leases expire) or decline the addresses (by sending a 237 DHCPDECLINE) in the hopes that the server will remove the 238 declined address from use for a longer period. 240 O Create havoc on the subnet by injecting fake messages on behalf 241 of other clients, prematurely releasing (DHCPRELEASE) or 242 declining (DHCPDECLINE) their addresses. A rogue client listens 243 to DHCPv4 traffic and gleams client identity and address 244 information and uses this information to inject fake messages. 246 4.1.3 Flooding 248 A rogue client can flood the network with (near-) continuous DHCPv4 249 request messages thereby consuming processing resources and network 250 bandwidth. 252 We mention this attack only for completeness, as there is little or 253 nothing that a DHCP server can do to prevent such an attack and the 254 client could just as well send messages of other protocols, so we 255 will not discuss it further. 257 4.2 Client Misconfiguration 259 Rogue servers may give out bad configuration information (such as 260 fake gateways or DNS servers), or relay agents or other network 261 elements may alter packets between a client and server, to cause the 262 client to be misconfigured, or potentially worse cause future man- 263 in-the-middle attacks. This category is usually part of another 264 attack, be it theft of service, business espionage, or business 265 interruption including denial of service. 267 4.3 Theft of Network Service 269 By "theft of network service", we mean the taking of an unused 270 address for network access or the use of an assigned address not 271 belonging to the client, in contrast with "client masquerading" 272 (Section 2.1.2) which refers specifically to the use of a legitimate 273 client's chaddr or client identifier. 275 Instantiation of an unauthorized client for purposes of using 276 network resources or services is only partially preventable using 277 client-server authentication techniques. We mention this attack 278 only for completeness, as there is little or nothing a DHCP server 279 itself can do to prevent such an attack. Additional host and 280 application security is required to prevent theft of service, and 281 such layer 5 and higher functions are declared out of scope for this 282 analysis. 284 4.4 Packet Insertion, Deletion, or Modification 286 If a client (or server or relay agent) is known to crash or shut 287 down when invalid packets of some type are sent, this could be 288 simply another type of denial of service attack. Likewise, simply 289 deleting certain packet types (DHCPREQUEST to renew or rebind a 290 lease) would eventually result in client lease expiration, a denial 291 of service attack. A rogue relay agent or other host would 292 typically use packet insertion and deletion to interrupt service. 293 In a different vein, the modification of packets in the DHCP 294 exchange may be used to facilitate many different types of attacks 295 on either client or server. For example, a DHCPACK could be 296 modified to a DHCPNAK, thereby denying the client a lease. 298 5 Weaknesses of RFC 3118 300 An authentication mechanism for DHCPv4 protocol messages was 301 developed in RFC 3118, proposing two basic authentication mechanisms 302 and the means for extending the repertoire of methods as needed. 303 The configuration token method (protocol 0) relies on exchanging 304 clear-text authentication tokens between unconfigured DHCPv4 clients 305 and DHCPv4 servers. It is also vulnerable to message interception. 306 Delayed authentication (protocol 1) focuses on solving the 307 intradomain authentication problem where the out-of-band exchange of 308 a shared secret is feasible. 310 5.1 Key Exposure 312 The configuration token protocol, protocol 0, utilizes clear-text 313 authentication tokens (i.e., passwords), providing only weak entity 314 authentication and no message authentication. This protocol is 315 vulnerable to interception and provides only the most rudimentary 316 protection against inadvertently instantiated DHCP servers. It also 317 leaks the key before knowing whether the server supports protocol 0. 319 5.2 Key Distribution 321 Both protocols 0 and 1 suffer from the lack of a means to easily, 322 quickly, and reliably distribute authentication tokens used in the 323 protocols. In many environments, some existing key distribution 324 mechanism is presumed to be trusted and reliable, with strong 325 administrative procedures and a security-conscious user population 326 in place, leaving only the selection and specification of an 327 appropriate cryptographic algorithm as a concern of the protocol 328 designer. 330 Relying on such out-of-band methods to distribute and manage tens or 331 hundreds of thousands of tokens is a significant barrier to the 332 widespread implementation of either protocol 0 or 1. 334 Key distribution presents a significant system management challenge 335 that is in marked contrast with DHCP itself, a protocol that has 336 been successfully deployed in environments that make few demands or 337 assumptions. If we are to hope for similarly successful deployment 338 of authentication for DHCP, a means for mitigating (if not 339 eliminating) these difficulties must be offered. 341 5.3 Replay attacks 343 Since the configuration token protocol, protocol 0, passes a clear- 344 text authentication token, the token would be visible to any host on 345 the same subnet. Delayed authentication, protocol 1, is not 346 susceptible to replay attacks since it contains a nonce value 347 generated by the source and a message authentication code (MAC) 348 which provides both message and entity authentication. 350 5.4 Protocol Agreement Difficulties 352 An a priori agreement is presumed to have taken place between client 353 and server on the authentication protocol to use. No mechanism is 354 provided to allow for the discovery of supported protocols, nor is 355 there a facility for negotiation. The only way to express non- 356 support of a protocol is by failing to respond. 358 5.5 DHCPv4 Relay Agents Excluded 360 [RFC3118] is defined exclusively for client-server communication. 361 The role of relay agents has expanded somewhat from their earliest 362 definition to include a DHCP option carrying relay agent information 363 via sub-options [RFC3046]. An authentication sub-option for the 364 relay agent information option has been defined by [RFC4030], though 365 it only defines a single protocol, symmetrical shared-secret keys, 366 to protect the contents of the messages between DHCP relay agents 367 and servers. Work-in-progress to protect the interaction between 368 relay agents and servers using IPSEC [relay-ipsec] seems to have 369 halted, with no recent work. 371 5.6 Unanticipated Infrastructure Changes 373 Rapid commit, defined by [RFC4039], specifies how a two-message 374 exchange between client and server can dramatically decrease the 375 elapsed time for address assignment, a feature becoming significant 376 as more and more highly mobile devices desire an abbreviated address 377 assignment phase for short duration communications. 379 While a two-message exchange by itself does not affect the overall 380 security of the communications, it has two side effects. First, the 381 delayed authentication protocol simply cannot be used as the 382 DHCPOFFER message required to return a nonce value to the client is 383 not present. Second, as noted by the authors of [RFC4039], without 384 authentication it is considerably more likely to consume addresses, 385 increasing the risk of one type of denial of service attack. 387 CableLabs client configuration [RFC3495] adds another two-tier 388 option to the DHCPv4 options list, defining an initial set of sub- 389 options for passing configuration information specific to CableLabs 390 VoIP and possible future services. Although several of the sub- 391 options contain potentially sensitive information regarding Kerberos 392 tickets to be used by cable modems and media terminal adapters. The 393 option specification does not require used of DHCP authentication, 394 although it would seem to be necessary. The authors of this memo do 395 not wish to go so far as to recommend that DHCP authentication be a 396 requirement for any or all DHCP options, but the CableLabs client 397 configuration option will likely not be the last option that could 398 benefit from a robust, workable authentication implementation. 400 Passive duplicate address detection [p-dad] is a relatively new 401 proposal to replace the use of ICMPECHO and ARP messages by DHCP 402 clients and servers to improve the duplicate address detection 403 process by passively listening to message traffic and developing a 404 table of matches between chaddr, DHCP client identifier, and IP 405 address that would be periodically transmitted to interested DHCP 406 servers. The presence of an entry for a particular IP address would 407 signify that it is known to be in use, so a DHCP server could 408 exclude the address from its pool of addresses available for 409 assignment. 411 The address usage collector (AUC) defined by [p-dad] does not use 412 the DHCP client-server protocol, nor does it function by actively 413 handling DHCP messages, so its implementation would not affect 414 authenticated DHCP messages. However, DHC Working Group discussion 415 of the [p-dad] draft raised the point that the AUC must capture the 416 client identifiers used in DHCP message exchanges. If DHCP 417 authentication were enabled, an AUC of necessity would be required 418 to have the same authentication configuration data (protocol, 419 algorithm, and key) as the clients and servers, certainly a 420 consideration for scalability and risk assessment. 422 6 DHCPv4 Security Requirements 424 DHCPv4 was developed in an era when computers were primarily used in 425 business and university environments. Security was either not a 426 concern or was addressed by controlling physical access stemming 427 from the belief that intrusion into critical systems was most likely 428 to come from an external source. Now, with wireless access points 429 and ubiquitous networking, physical access control mechanisms are no 430 longer sufficient, and security and privacy issues are a major 431 concern. 433 6.1 Environments 435 The following environments can be expected for DHCPv4 436 implementations: 438 O Network size, from a few hosts to hundreds of thousands of hosts. 440 O Network topology, from a single subnet to Class-A networks. 442 O Network location, from a single room to international dispersion. 444 O Wired, broadcast wireless, and directional wireless media. 446 O Movement between different media and networks. 448 6.2 Capabilities 450 The following are essential elements of DHCPv4 security: 452 1. Clients MUST be able to authenticate servers (to prevent 453 misconfigured clients and assure that the correct servers are 454 being contacted). 456 2. Servers MUST be able to authenticate clients (use of hardware 457 addresses and client-IDs provides no real security but is all 458 that is easily possible today). Better mechanisms are needed 459 for servers to identify clients to whom they will offer service 460 (to prevent IP address pool depletion, for example). 462 3. Administrators MUST be able to choose between four 463 authentication paradigms: 465 a. No authentication required. 467 b. Mutual authentication required. 469 c. Client authenticates server. 471 d. Server authenticates client. 473 4. Integrity of DHCP packet exchanges MUST be assured. 475 Not all capabilities may be needed or desired in all situations. 477 6.3 Musings on the Key Distribution Problem 479 The authors believe that only by addressing scalability issues with 480 key distribution can RFC 3118 achieve wide deployment. While it is 481 not our intention to describe solutions in this document, we admit 482 that we find several models used today by browsers and secure web 483 servers as well as token-based user authentication schemes such as 484 the RSA SecureID token to be attractive. Trusted root certificates 485 are distributed with the client implementation (web browser); users 486 have the ability to extend the certificates that they will accept, 487 install their own certificates (should client identification be 488 required), and choose which certificate to present to servers 489 requesting the client's identity. Security tokens that combine a 490 secure seed value with the current time of day using a cryptographic 491 algorithm to produce effectively a random one-time pad are 492 relatively inexpensive and widely available. 494 Analogously, DHCPv4 servers could make use of certificates just as 495 web servers do, while DHCPv4 clients could be distributed with 496 appropriate certificate authority certificates (trust anchors). 497 Self-signed certificates are, of course, a possibility should an 498 organization wish full control over its domain of trust. 500 Should this path be pursued, we believe that certificate revocation 501 will be a major problem to confront, just as it is in the 502 browser/web server environment today. Revocation of client 503 certificates (which we believe would occur, on the whole, much more 504 frequently than revocation of server certificates) would require 505 only ordinary care in certificate validation by the DHCP server. 507 Revocation of server certificates is more complex because of the 508 difficulty updating client configurations, as well as the inability 509 of clients to rely on certificate revocation lists while in the 510 process of performing IP address and configuration management. 512 Using a security token device today is mostly to identify a person 513 requesting access to a private resource. Key fobs, USB dongles, or 514 wallet cards are in the possession of a user, and in conjunction 515 with a user name, password, and possibly other information confirms 516 two of the three classic dimensions of provable identity (something 517 you know--user name and password, something you have--the security 518 token, and something you are--biometrics typically satisfy this 519 dimension.) 521 We envision a security token becoming part of the host system's 522 hardware complement in the near future, such that the token then 523 becomes not a user identity validator, but a host system validator. 524 It is common today to have a system service tag or serial number 525 that is machine-readable. Some hardware configurations include 526 processors with readable serial numbers as well. What we lack is a 527 secure means to generate a cryptographically random key that cannot 528 be easily defeated by software or component swapping. 530 Either of these approaches offers a simple way to avoid the classic 531 key distribution problem, though neither is totally without cost. 532 Somehow, somewhere, a token's identifiers (seed and algorithm) must 533 be recorded by the DHCP and other interested servers, or the 534 certificate infrastructure must be in place. We see no way to 535 eliminate administrative issues associated with security, but we can 536 see an end to passwords written on a sticky note. 538 An interesting Internet-Draft by Alper Yegin et al. [eap-auth] 539 proposed the use of EAP for DHCP authentication using the delayed 540 method. Their draft required modifications to several components of 541 an AAA solution, but illustrated how delayed authentication could be 542 "bootstrapped" using tools at our disposal. 544 That idea is also suggested by [RFC4014] Ralph Droms and John 545 Schnizlein, who define a DHCP option code for RADIUS information 546 provided by an NAS, similar to the mechanism in [eap-auth]. These 547 two documents taken together may provide a third solution to the key 548 distribution problem. 550 6.4 Data Confidentiality 552 Data Confidentiality was not provided for in the original DHCP 553 protocol as defined in RFC 2131 or any of the subsequent RFCs. 554 Historically, DHCP was mainly used to assign IP addresses and return 555 configuration options such as the local gateway and DNS information. 557 Over time the DHCP protocol has evolved, deployments are extending 558 beyond physically secure intranets to public networks in hotspots, 559 cafes, airports, and at home over broadband. We are seeing an 560 accompanying proliferation of new configuration options. 562 DHCP has, in fact, become so successful that it is now used to 563 transport a great deal of configuration data that could be obtained 564 in a variety of other ways. It is certainly possible that a client 565 or server will wish to reveal some of these data only to a properly 566 authenticated peer. 568 6.4.1 "Public" Data in DHCP Packets 570 We assume that any information that may be gleaned directly from the 571 network using, for example, Ethernet promiscuous mode is not 572 confidential. It could be argued that over time more and more 573 communication will be switched, encrypted, or secured at the 574 physical layer, so that less information could easily be gleaned 575 from the network traffic. 577 Taking encryption into consideration, the IP packet payload might be 578 encrypted, but not the IP header itself since it is required for 579 packet routing. As a result, none of the IP header fields are 580 confidential. IP addresses included in the header are therefore not 581 confidential. Similarly, the hardware addresses are also not 582 confidential. 584 Although the IP packet payload (which would include the UDP or TCP 585 header) might normally be encrypted, some protocols have made 586 explicit decisions not to encrypt their exchanges, declaring their 587 data public. DNS is such a protocol [dns-threats]. Thus, we may 588 also treat DNS domain and server information as public. 590 Commonly used routing protocols such as BGP [RFC1771], RIP [RFC1721], 591 and router discovery [RFC1256] also normally send advertisements in 592 the clear and we therefore extend our treatment of public DHCP data 593 to routing information. 595 6.4.2 Protecting Data in DHCP Options 597 Some DHCP options (e.g., relay agent options, [RFC3046]) or option 598 families (site or vendor options) admit no analysis because the data 599 carried by them may be of unknown sensitivity. Users must do their 600 own analysis of confidentiality. 602 Should some data require confidentiality, it may be possible to 603 exploit the "public" data above to allow a two-step configuration 604 process in which sufficient client configuration is first obtained 605 by the normal DHCPDISCOVER/OFFER/REQUEST/ACK exchange, and private 606 data subsequently transmitted over a secure communications channel 607 (such as IPsec) using DHCPINFORM. 609 6.5 Host versus User Authentication 611 [RFC3118] is concerned specifically with DHCP clients and servers 612 authenticating themselves to each other if required by an 613 administrative domain. This is not the same thing as authenticating 614 users for establishing their Identity, access rights, permissions, 615 or other matters relating to what they can view or do once connected 616 to the network. 618 6.5.1 Why do we make this distinction? 620 Host authentication provides only assurance that the hosts 621 connecting to a network are recognized. This may be for several 622 reasons, including: 624 O Requirement to restrict network access from "foreign" hosts to 625 ensure consistent technical support or meet other regulatory 626 requirements such as double-insulation or non-sparking. 628 O Requirement to restrict network access from "unsecured" (for 629 instance, non-TEMPEST compliant) hosts in a high security 630 network. 632 O Requirement to restrict network access from unknown hosts whose 633 identity has not been recorded by existing administrative 634 procedures, saving troubleshooting and administrative effort. 636 User authentication focuses on the individual users of a host system, 637 seeking to uniquely identify someone to establish their rights to 638 view, print, add, alter, delete, edit, modify, copy, or manipulate 639 any data maintained by an organization, run software programs, or 640 affect changes in the environment. This may be for such reasons as: 642 O Requirement to be compliant with regulations such as HIPAA, SOX, 643 and GLBA designed to safeguard and protect confidentiality and 644 various reporting requirements. 646 O Requirement to maintain reasonable controls over access to 647 certain critical systems such as utility power grids, water and 648 sewage treatment plants, the network infrastructure itself, and 649 life safety systems of all sorts. 651 O Requirement to maintain administrative controls over certain 652 sensitive information such as trade secrets and personnel data 654 6.5.2 Is one mechanism sufficient? 656 Full discussion of this question is beyond the scope of this memo, 657 but the simple answer is, "probably not." This has a significant 658 implication for the claims of certain techniques such as 659 "sandboxing" of unverified users, restricting their network access 660 to a user registration web site until their identity has been 661 established. Simply put, limiting network access is not DHCP 662 authentication, although it does represent a very workable approach 663 to user authentication in many cases. 665 Recall that a user can be identified by "something they know," 666 "something they have," and "something they are." While the same 667 could be said to be true of host systems, the authors point out that 668 while we do not pretend to understand all of the ways that future 669 developers might imbue hosts with the tools to independently create 670 attacks on our infrastructure, we will assert that users will be the 671 greatest risk for some time still. 673 DHCP Authentication addresses only host authentication from the 674 belief that other, existing mechanisms such as IPSEC, SSL, and VPN 675 can protect the content of communications, with Identity Management 676 and other technologies can protect applications and data. 678 A properly authenticated host could still launch a denial of service 679 attack, corrupt sensitive data, or wreak other havoc, which 680 underscores our point that host and user authentication are 681 different. 683 A well-secured network needs both. 685 7 IANA Considerations 687 None known. 689 8 Security Considerations 691 This entire memo presents a threat analysis of the DHCPv4 protocol. 693 9 Acknowledgements 695 This document is the result of work undertaken the by DHCP working 696 group, beginning at the 55th IETF meeting in Atlanta. The authors 697 would also like to acknowledge contributions from others not 698 directly involved in writing this memo, including John Beatty and 699 Vipul Gupta of Sun Microsystems, Ralph Droms of Cisco Systems, 700 Bernard Aboba of Microsoft, and Mark Stapp of Cisco Systems for 701 their careful reviews and helpful suggestions. 703 10 References 705 10.1 Normative References 707 [RFC1256] Deering, S., "ICMP Router Discovery Messages," RFC 1256, 708 September 1991. 710 [RFC1541] Droms, R., "Dynamic Host Configuration Protocol," RFC 1541, 711 October 1993. 713 [RFC1721] Malkin, G., "RIP Version 2 Protocol Analysis," RFC 1721, 714 November 1994. 716 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 717 4)," RFC 1771, March 1995. 719 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol," RFC 2131, 720 March 1997. 722 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 723 Extensions", RFC 2132, March 1997. 725 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option," RFC 726 3046, January 2001. 728 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 729 Messages," RFC 3118, June 2001. 731 [RFC4014] Droms, R. and J. Schnizlein, " Remote Authentication Dial- 732 In User Service (RADIUS) Attributes Suboption for the Dynamic 733 Host Configuration Protocol (DHCP) Relay Agent Information 734 Option," RFC 4014, February 2005. 736 10.2 Informative References 738 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 739 3," RFC 2026, BCP 9, October 1996. 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, March 1997. 744 [RFC3203] T'Joens, Y., C. Hublet and P. De Schrijver, "DHCP 745 Reconfigure Extension," RFC 3203, December 2001. 747 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 748 M. Carney, "Dynamic Host Configuration Protocol for IPv6 749 (DHCPv6)," RFC 3315, July 2003. 751 [RFC3495] Beser, B. and P. Duffy, "Dynamic Host Configuration 752 Protocol (DHCP) Option for CableLabs Client Configuration," RFC 753 3495, March 2003. 755 [RFC3594] Duffy, P., PacketCable Security Ticket Control Sub-Option 756 for the DHCP CableLabs Client Configuration (CCC) Option"," RFC 757 3594, September 2003. 759 [RFC3978] Bradner, S., "IETF Rights in Contributions," RFC 3978, BCP 760 78, March 2005. 762 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 763 Technology," RFC 3979, BCP 79, March 2005. 765 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 766 the DHCP Relay Agent Option," draft-ietf-dhc-auth-suboption-03), 767 RFC 4030, March 2005. 769 [RFC4039] Park, S., P. Kim and B. Volz, "Rapid Commit Option for the 770 Dynamic Host Configuration Protocol version 4 (DHCPv4)," RFC 771 4039, March 2005. 773 [RFC4388] Woundy, R., and Kinnear, K., "Dynamic Host Configuration 774 Protocol (DHCP) Leasequery," February 2006. 776 [dns-threats] Atkins, D. and R. Austein, "Threat Analysis Of The 777 Domain Name System," draft-ietf-dnsext-dns-threats-07 (work in 778 progress), April 2004. 780 [draft2223bis] Reynolds, J. and R. Braden, "Instructions to Request 781 for Comments (RFC) Authors," draft-rfc-editor-rfc2223bis-08.txt 782 (work in progress), August 2004. 784 [eap-auth] Yegin, A., H. Tschofenig and D. Forsberg, "Bootstrapping 785 RFC3118 Delayed DHCP Authentication Using EAP-based Network 786 Access Authentication," draft-yegin-eap-boot-rfc3118-02, (work 787 in progress), March 2006. 789 [failover] Droms, R. and K. Kinnear, "DHCP Failover Protocol," 790 draft-ietf-dhc-failover-12 (work in progress), December 2003. 791 [Editor's note: at the time of publication of this memo, the 792 Failover Internet-Draft has expired.] 794 [fqdn] Stapp, M., Volz, B., and Y. Rekhter, "The DHCP Client FQDN 795 Option," draft-ietf-dhc-fqdn-option-13 (work in progress), March 796 2006. 798 [p-dad] Forte, A., S. Shin and H. Schulzrinne, "Passive Duplicate 799 Address Detection for Dynamic Host Configuration Protocol 800 (DHCP)," draft-forte-dhc-passive-dad-02 (work-in-progress), June 801 2006. 803 [relay-ipsec] Droms, R., "Authentication of DHCP Relay Agent Options 804 Using Ipsec," draft-ietf-dhc-relay-agent-ipsec-02 (work in 805 progress), May 2005. [Editor's note: at the time of 806 publication of this memo, the Relay IPSEC Internet-Draft has 807 expired.] 808 Authors' Addresses 810 Richard Barr Hibbs 811 Richard Barr Hibbs, P.E. 812 952 Sanchez Street 813 San Francisco, California 94114-3362 814 USA 816 Phone: +1 415 648 3920 817 Fax: +1 415 648 9017 818 E-Mail: rbhibbs@pacbell.net 820 Carl Smith 821 C & C Catering 822 1121 Holly Street 823 Alameda, California 94502 824 USA 826 E-Mail: islandia@alumni.ucsd.edu 828 Bernard Volz 829 Cisco Systems, Inc. 830 1414 Massachusetts Avenue 831 Boxborough, Massachusetts 01719 832 USA 834 Phone: +1 978 936 0382 835 E-Mail: volz@cisco.com 837 Mimi Zohar 838 IBM T. J. Watson Research Center 839 19 Skyline Drive 840 Hawthorne, New York 10532-2134 841 USA 843 Phone: +1 914 784 7606 844 E-Mail: zohar@us.ibm.com 846 Full Copyright Statement 848 Copyright (C) The Internet Society (2006). All rights reserved. 850 This document is subject to the rights, licenses and restrictions 851 contained in BCP 78, and except as set forth therein, the authors 852 retain all their rights. 854 This document and the information contained herein are provided on 855 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 856 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 857 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 858 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 859 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 860 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 862 Intellectual Property 864 The IETF takes no position regarding the validity or scope of any 865 Intellectual Property Rights or other rights that might be claimed 866 to pertain to the implementation or use of the technology described 867 in this document or the extent to which any license under such 868 rights might or might not be available; nor does it represent that 869 it has made any independent effort to identify any such rights. 870 Information on the procedures with respect to rights in RFC 871 documents can be found in BCP 78 and BCP 79. 873 Copies of IPR disclosures made to the IETF Secretariat and any 874 assurances of licenses to be made available, or the result of an 875 attempt made to obtain a general license or permission for the use 876 of such proprietary rights by implementers or users of this 877 specification can be obtained from the IETF on-line IPR repository 878 at http://www.ietf.org/ipr. 880 The IETF invites any interested party to bring to its attention any 881 copyrights, patents or patent applications, or other proprietary 882 rights that may cover technology that may be required to implement 883 this standard. Please address the information to the IETF at ietf- 884 ipr@ietf.org. 886 Acknowledgement 888 Funding for the RFC Editor function is provided by the IETF 889 Administrative Support Activity (IASA). 891 APPENDIX: NOTES 893 This appendix will be removed in its entirety before the memo goes 894 to Working Group Last Call. 896 ISSUES LIST 898 This section summarizes issues raised in this memo that require 899 resolution by the DHC Working Group. 901 1. Because of the specific exception for inclusion of the Relay 902 Agent Information Option [RFC3046] in cases where it does not 903 fit in the main payload portion of a DHCP response packet, 904 should the use of DHCP Authentication be mandated in place of 905 the Relay Agent Authentication suboption? 907 2. Does the CableLabs Client Configuration option [RFC3495] require 908 the use of DHCP Authentication to protect sensitive information 909 about Kerberos domains and keys? 911 3. Should the DHC Working Group promote the development of a new 912 authentication protocol based on the use of certificates? 914 4. Should the DHC Working Group solicit an update from the authors 915 of the EAP-based authentication protocol [eap-auth] and develop 916 it as a new authentication protocol? 918 5. Should the DHC Working Group promote the development of a new 919 authentication protocol based on hardware security tokens? 921 CHANGE LOG 923 This section summarizes the changes made to this memo as it has 924 evolved. 926 "-01" Draft 928 No significant changes were made from initial ("-0") version: 930 O Updated author information. 932 O Removed unused references. 934 O Added the Change Log section. 936 "-02" Draft 938 The following changes were made: 940 O Updated author information. 942 O Added text to 1.3 to exclude security for messages passed 943 between relay agents and servers, as there are two Internet- 944 Drafts on this subject. 946 O Reworded several sections in section 2. 948 O Revised and renamed section 2.1.2. Now includes more attacks. 950 O Revised section 2.1.3. 952 O Minor revisions to section 3, 3.2, and 3.2. 954 O Other minor insertions, deletions, and modifications based on 955 comments from Bernard Aboba and Mark Stapp and to otherwise 956 improve the document. 958 "-03" Draft 960 The draft was updated, correcting minor spelling, grammatical, and 961 typographical errors, and modified in the following ways: 963 O Removed Section 8, "Change Log," to APPENDIX and added an issues 964 list section. 966 O Replaced all Internet-Draft boilerplate with the most current 967 versions. 969 O Renumbered document sections. 971 O Updated author information. 973 O Updated references for I-Ds advanced to RFCs. 975 O Added normative and informative references. 977 O Added discussion of Relay Agents (section 3.5.) 979 O Added section 3.6, discussing the side effects of infrastruture 980 changes from the Rapid Commit and CableLabs configuration 981 options, and the newly proposed Address Usage Collector (AUC) 982 for passive duplicate address detection. 984 O Expanded section 4.3, "Musings on the Key Distribution Problem" 985 to include description of hardware-based key generation tokens. 987 O Added section 4.5, "Host versus User Authentication," to help 988 clarify the problem [RFC3118] is intended to address. 990 O Added discussion of the RADIUS-based authentication proposal 991 described in [RFC4014]. 993 O Added discussion of the EAP-based authentication protocol 994 proposed by A. Yegin et al. 996 O Inserted Intellectual Property Rights statement on first page. 998 O Performed general spelling, grammar, and typography update of 999 entire memo text. 1001 O Reviewed all drafts used as references, updated as necessary.