idnits 2.17.1 draft-ietf-dhc-security-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Background' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security considerations' ) ** 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.) ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC1035], [RFC1825], [DHCPv6], [DHCP], [DHCAUTH], [DHCPVERSERV], [RFC1825,IPSEC], [IPSEC], [RFC1305], [RFC2065]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 306 has weird spacing: '...h which clien...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In order to protect replay attacks, all communication to servers should contain some variable data that never repeats and both server and client can agree on. A simple approach is to use time of day information that clients and servers check and act upon. Clock synchronization service can be provided by an outside entity[RFC1305] once a client is configured, but bounds must be placed on acceptable skew while a client is off line or migrates between locations. Clients SHOULD not trust time information from servers until after servers have been validated as such. Clients should always assume that the network is insecure. -- 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 (March 1998) is 9533 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1825' on line 454 looks like a reference -- Missing reference section? 'DHCPv6' on line 435 looks like a reference -- Missing reference section? 'RFC2065' on line 457 looks like a reference -- Missing reference section? 'IPSEC' on line 444 looks like a reference -- Missing reference section? 'DHCPVERSERV' on line 439 looks like a reference -- Missing reference section? 'RFC1305' on line 451 looks like a reference -- Missing reference section? 'DHCAUTH' on line 431 looks like a reference -- Missing reference section? 'RFC1035' on line 448 looks like a reference -- Missing reference section? 'DHCP' on line 428 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft O. Gudmundsson, R. Droms 2 DHC Working Group TIS, Bucknell University 3 March 1998 5 Security Requirements for the DHCP protocol 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 26 West Coast). 28 Distribution of this memo is unlimited. 30 Abstract 31 This document addresses the general security requirements of both 32 DHCPv4 and DHCPv6. This document lists security requirements and 33 the the reasons for each requirement. This document does not 34 address how to implement the security requirements. 36 1. Background 38 This section presents some concepts and definitions used throughout 39 this document. 41 1.1. Authentication, confidentiality, data integrity 43 RFC-1825[RFC1825] contains a great description of these terms and 44 their uses. Authentication is the process of establishing the 45 identity of some entity. Once identity has been authenticated, 46 that identity can be used for access control, accounting etc. There 47 are number of authentication technologies available. 49 Public key cryptography is a powerful tool that relies on complex 50 mathematical operations to provide information that only the holder 51 of the private key could have generated. 53 Shared secret authentication is the process of digesting the data 54 transmitted and obfuscating the digest by applying a transformation 55 by a key that is only used by the two entities. This technology can 56 be used to provide both authentication and data integrity. Each 57 pair can share multiple shared secrets, it is important that each 58 secret have an identifier attached to it. 60 Confidentiality can be accomplished by encrypting the data contents 61 of the outgoing packet. Shared secrets can be used as keys for 62 symmetric encryption. 64 1.2. Shared secrets 66 Shared secrets are between two entities; there is NEVER a need to 67 share these secrets with other entities. The hosts storing the 68 secrets MUST protect the secrets as well as possible. 70 1.3 Terminology and DHCP v6 considerations 72 This document uses DHCPv4 terminology as it is more familiar than 73 the new DHCPv6[DHCPv6] terminology. When this document talks about 74 DHCP v4 DISCOVER messages the same will apply to DHCP v6 Solicit 75 Message. Subsequent v6 messages are similar to v4 messages. Both 76 v4 and v6 take advantage of RELAY agents, in some cases these 77 agents can add to the messages from servers, it is important that 78 the added information is treated the same way as data from servers. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 82 this document are to be interpreted as described in RFC 2119. 84 2. Proposed DHCP security requirements 86 The proposed requirements can be summarized in the following rules. 88 - Initial Client/Server Authentication 90 1. Server MUST be able to authenticate client identity. 92 2. Client MUST be able authenticate the server identity as an 93 authorized server. 95 - Initial Relay Agent/Server Authentication 97 3. Server MUST be able to authenticate relay agent identity as an 98 authorized relay agent. 100 4. Relay Agent MUST be able to authenticate server identity as an 101 authorized server. 103 - Successive Client to Server and Relay Agent to Server Communication 105 5. Client and Server MUST agree on security model for 106 protecting future communication. 108 - Server/Relay agent advertisements 110 6. Advertisements MUST be verifiable by all recipients. 112 - Server/Server communication 114 7. All communication MUST be protected for data integrity. 115 Servers MAY request that communication be encrypted. 117 DHCP security cannot be accomplished in a vacuum; as DHCP is not a 118 general purpose communication protocol. Fortunately there are 119 available (or soon will be) protocols that DHCP can take advantage 120 of. First and foremost DNSSEC[RFC2065] or some other key 121 distribution mechanism must be available. IPSEC[RFC1825,IPSEC] will 122 be able to handle requirements 5 and 7. 124 2.1. DHCP Identity 126 In order to secure DHCP all clients MUST have an identity, this 127 identity can possibly be one of the following: host name, user 128 identity, account code. The "prime" identity MUST have a public key 129 stored in the key distribution mechanism. The client MUST know its 130 identity before contacting the server. Each client MUST have 131 access to the correct private key before contacting the DHCP 132 server. 134 If the identity selected for a host is its host name and the key 135 distribution mechanism is DNS, then the public key used to 136 authenticate the host is stored under the host name in its home 137 zone. The private key needs to be stored in the computer at all 138 times. If the identity selected is the user then the key is stored 139 under the user name in DNS (e.g.: ogud.tis.com for me), and the 140 user needs to load the computer with the private key before the 141 host can contact the server. If the identity of the host is just 142 there to uniquely identify the host, the host still needs a private 143 key. 145 Traditional identifiers such as MAC addresses, are not suitable in 146 all cases in identify clients, first there is no database of what 147 MAC goes with what host, secondly some MACs are portable and can 148 easily migrate between hosts such as Ethernet PC CARDS. 150 2.2. DHCP communication protection 152 DHCP is a protocol that carries publicly known information, thus 153 there is limited need for confidentiality. DHCP requires data 154 integrity protection for communication. The option to allow DHCP 155 servers/clients to request confidentiality SHOULD be part of any 156 security architecture. 158 2.3. Policy issues. 160 This document does not address access control issues as that is a 161 policy issue for each site. Effective access control depends on 162 correct authentication, thus this work will make access control 163 simpler. This document does not address the issue of protecting 164 the private key on either server, agent or client. 166 2.4 Security threats to DHCP 168 2.4.1 Attacks against servers 170 There are many possible attacks possible against servers, including 171 denial of service by exhausting the servers allocated address 172 space. Another denial of service attack is to overload the server 173 causing it not to respond to clients. 175 Once servers start updating DNS and other directory services, DHCP 176 servers can be spoofed to register incorrect information in those 177 services. 179 Another possible attack is to gain unauthorized access to some 180 resources, such as network access. 182 2.4.2 Attacks against clients 184 Fake servers[DHCPVERSERV] can provide clients with partially 185 correct information that allows the attacker to route traffic 186 through certain host where critical information can be collected. 187 This becomes important to detect and prevent when encrypted traffic 188 is allowed to pass through firewalls. 190 Clients can be configured with bogus data, so that they will assume 191 that the network is down. In some cases it is hard to get a client 192 to reconfigure itself. Clients can also be configured with 193 addresses of other clients, causing address conflicts. 195 The bright side of this problem is that fake servers are easy to 196 detect by monitoring the network for DHCP traffic. 198 2.5. Complications in implementing the security models 200 A Client that issues DISCOVER message does not have any IP address 201 that works outside the local network, and may not even work on the 202 local network. This prevents the clients from checking with 203 outside information sources. Servers on the other hand are fully 204 configured and can use any information sources accessible. 206 Clients will not wait long for OFFER message, some security checks 207 may take longer than the DHCP retransmission timeout. If DHCP 208 servers had an option to inform clients that DISCOVER messages are 209 being worked on and client should expect an answer in short order, 210 then this problem would be solved. 212 Some DHCP servers do not have CPU cycles to spare to do security 213 checks. Computational load on server in verifying the identity of 214 client can be significant. Different authentication mechanisms have 215 different computational overhead, similarly network delays have to 216 be taken into account if DHC server needs to query remote data 217 source for more data. 219 3. DHCP Security components 221 3.1 Authentication services 223 In order for DHCP servers to be able to determine if a client 224 request should be serviced it is essential for the server to be 225 able to establish the client's identity. There are two kinds of 226 identities that are possible, local mutually agreed upon identities 227 and global identities. 229 Local identity is sufficient if the client will only be configured 230 from a small set of servers, and if there are no expectations that 231 the client will migrate to another location. This is an acceptable 232 solution for a site where all computers are stationary but are 233 configured from DHCP for administrative reasons. Solutions of this 234 kind have certain scaling problems. 236 Global identity on the other hand is needed when a client can 237 connect to multiple servers and it provides some of its identity. 239 An example of local identity is a name or number that is configured 240 in the client and server. This could be the name of the client on 241 the local network. An example of global identity is a DNS name. 243 3.2 Replay prevention 245 In order to protect replay attacks, all communication to servers 246 should contain some variable data that never repeats and both 247 server and client can agree on. A simple approach is to use time of 248 day information that clients and servers check and act upon. Clock 249 synchronization service can be provided by an outside 250 entity[RFC1305] once a client is configured, but bounds must be 251 placed on acceptable skew while a client is off line or migrates 252 between locations. Clients SHOULD not trust time information from 253 servers until after servers have been validated as such. Clients 254 should always assume that the network is insecure. 256 Another approach is to use counters but this requires clients to 257 keep state for each server they talk and has synchronization 258 issues. 260 3.3 Data confidentiality 262 This is not desired service at this point, but it can be added at a 263 later point for all communication except DISCOVER and possibly 264 OFFER and REQUEST. All subsequent communication can be encrypted. 266 3.4 Possible security models for DHCP 268 This section will present a few possible security models and the 269 reasons why each one may be useful. This section IS NOT an 270 advocacy for any of the described models there may be other models 271 possible. It is expected that any security proposal put forward 272 state which model is used as its bases. 274 3.4.1 The ``No security'' model 276 This is the current situation. Below are few arguments that can be 277 made for the status quo. 279 Security is hard. Considering that DHCP for IPv4 is a hack built on 280 an older hack (BOOTP), there is not enough flexibility in the 281 protocol to add security. 283 A smart client attached to a broadcast network can learn everything 284 it needs to know to configure itself by listening to network 285 traffic. The client can either monitor DHCP traffic and/or all 286 network traffic to find gateways, servers and unused addresses. 287 There is no protection against this. 289 DHCPv6 can on the other hand be extended and modified to fit any 290 security model selected. Sites will migrate to IPv6 soon, and the 291 ones that do not deserve what they get. 293 In this model DHCP clients will be able to do harm and be harmed by 294 bogus servers. This model is not acceptable when DHCP servers 295 perform DNS update operations on a client's behalf. Sites MAY 296 select this model but this is strongly discouraged. 298 3.4.2 The ``Simple'' model 300 A DHCP client is configured with a token that allows it to 301 authenticate itself to the servers in the DHCP DISCOVER message. If 302 servers can authenticate the token and the client associated with 303 the token is allowed to communicate with the server the server will 304 reply with OFFER message. 306 In this model servers will know with which client they are 307 dealing, and that should be sufficient protection against most of 308 the attacks against the servers. If a client is able to 309 authenticate the server response, the client might be protected 310 against bad servers. 312 With minor extensions to DHCP, all subsequent communication can be 313 protected. 315 3.4.3 The ``Comprehensive'' Model 317 In this model DHCP servers and clients have the ability to 318 authenticate each other. The requirement here is that clients must 319 be able to authenticate the server without any communication as 320 they can not trust the information from the server. This model also 321 must prevent replay attacks. 323 This model protects all traffic between clients and servers, making 324 it impossible to stage any attacks other than denial of service 325 attacks due to CPU overload of servers. 327 4. Client Authentication 329 Initial authentication is the most important step. Once server and 330 client have established each other's identity the remaining 331 problems can solved. 333 The problem of initial client authentication cannot be solved by 334 IPSEC, as the client does not have an IP identity when it requests 335 service for the first time from the server. Once a client has been 336 configured it can enter IPSEC security associations with other DHCP 337 servers during the lifetime of the IP address lease. 339 4.1 Identification of DHCP clients and scaling issues 341 From a DHCP servers perspective it needs a ''handle'' that can be 342 used to uniquely identify each client, to the server it should not 343 matter what kind of handle is used. From a security point of view, 344 it is important that the ''handle'' be always the same and no 345 possibility of confusion. In DHCP there are at least two types of 346 clients: clients that request some of their net identity from DHCP, 347 and clients that request all of their net identity from DHCP, but 348 from the security requirements standpoint these are identical. 350 MAC addresses are frequently proposed as ''handles'', but in many 351 cases they are not suitable. For example most laptop computers have 352 network connectivity via a PCCARD, these cards are easy to swap and 353 thus are not static. Similarly laptops at different times connect 354 via Ethernet, modem, infrared or wireless all with different MAC 355 addresses but the laptop may ask for the same Identity regardless 356 of connection. 358 Previous DHCP security proposals[DHCAUTH] have suggested the use of 359 shared secrets and passwords to identify clients. It is also 360 possible to use some form of challenge/response system to identify 361 clients. These approaches have limited scaling ability and require 362 a server to server protocol. But in many environments these weaker 363 authentication mechanisms are adequate. 365 The most general case is the identification of a computer that 366 connects to a world wide ISP network and expects the same identity 367 regardless of location. In this case it is unlikely that the same 368 DHCP server serves both India and Iceland. A network of this kind 369 can have a collaborative agreement between a number of different 370 ISPs, with multiple administrative domains. It is not 371 reasonable/scalable that all DHCP servers in this network know 372 shared secrets, or passwords for all computers that are allowed to 373 connect. From a security standpoint it is a bad practice to 374 distribute shared secrets or passwords to many places. 376 4.2. Motivation for single strong authentication schema. 378 DHCP SHOULD require all servers and clients to support at least one 379 mandatory authentication protocol, and allow other ones. This will 380 ensure interoperabilty of all servers and clients. 382 4.3 Motivation for global DNS identities for DHCP clients 384 Once the global identity is registered with an information service, 385 this identity is available within the limits of the information 386 service. DNS is the most common information service used by 387 computers. 389 DNSSEC[RFC2065] strengthens DNS[RFC1035] against information 390 corruption and provides distribution of public keys. If every host 391 that is configured by DHCP has a public key stored in DNS then 392 servers can verify digital signatures generated by that key. Once 393 clients are configured it is possible for client to verify that the 394 server it was configured by is a good DHCP server. In order to do 395 this, DHCP servers for each domain must be listed. 397 IPSEC can be preconfigured with SPI's but there is no definition 398 for the format of the 'destination address'. If it is DNS format, 399 DHCP entities MAY enter IPSEC relationship without a key exchange 400 once client has received DHCP ACK message. 402 5. Sever verification by clients 404 When a client receives an DHCPOFFER message it should try to 405 authenticate the server. For stationary clients this can be as 406 simple as verifying that this is one of the servers it knows about, 407 and trusts. For mobile clients and in adverse networks this is 408 more difficult, there must be a mechanism for identifying the 409 servers that are authorized to allocate addresses in a range. This 410 could be accomplished by adding an RP record at delectation points 411 in the inverse DNS tree or at every node that points the 412 authorities for that address(es), the is the mail 413 address of the responsible party and the is the 414 authorized server. There can be as many RP records as there are 415 servers. If the inverse address map is protected by DNSSEC then 416 this is a convenient mechanism to authenticate this is a good 417 server. For clients that have host name configured they should 418 perform similar lookup to make sure the server is authorized to 419 allocate names in that space. 421 6. Security considerations 423 This document addresses how to add security features to the 424 unsecured DHCP protocol. 426 References 428 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", 429 RFC 2131, Bucknell University, April 1997. 431 [DHCAUTH] R. Droms, "Authentication for DHCP Messages", 432 Internet Draft 433 August 1997 435 [DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration 436 Protocol for IPv6 (DHCPv6)", Internet Draft 437 May 1997 439 [DHCPVERSERV] 440 R. Watson, O. Gudmundsson, "DHCP Server verification 441 by client via DNSSEC", 442 July 1997. 444 [IPSEC] R. Atkinson, "Security Architecture for the 445 Internet Protocol", Internet Draft 446 , February 1998. 448 [RFC1035] P. Mockapetris, "Domain Names - Implementation 449 and Specification," RFC 1034, ISI, November 1987. 451 [RFC1305] Mills, D., "Network Time Protocol (v3)", RFC 452 1305, March 1992. 454 [RFC1825] R. Atkinson, "Security Architecture for the 455 Internet Protocol", RFC 1825, September 1995. 457 [RFC2065] D. Eastlake, C. Kaufman, "Domain Name System 458 Security Extensions", RFC 2065, January 1997. 460 9. Author address 462 Olafur Gudmundsson Ralph Droms 463 Trusted Information System Computer Science Department 464 3060 Washington Road 323 Dana Engineering 465 Bucknell University 466 Glenwood, MD 21738 Lewisburg, PA 17837 467 +1 301 854 6889 +1 717 524 1145 468 ogud@tis.com droms@bucknell.edu