idnits 2.17.1 draft-ietf-dhc-security-arch-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-25) 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 == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 59 lines 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 63 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC2606-compliant FQDNs 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 108: '... 1. Server MUST authenticate clie...' RFC 2119 keyword, line 109: '... 2. Client SHOULD authenticate th...' RFC 2119 keyword, line 114: '... 3. Server MUST authenticate rela...' RFC 2119 keyword, line 116: '... 4. Relay Agent MUST authenticate ser...' RFC 2119 keyword, line 122: '...lient and Server MUST agree on securit...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 411 has weird spacing: '...l above accom...' -- 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 26, 1997) is 9892 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) ** Obsolete normative reference: RFC 1541 (ref. 'DHCP') (Obsoleted by RFC 2131) -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCAUTH' ** Obsolete normative reference: RFC 2065 (ref. 'DNSSEC') (Obsoleted by RFC 2535) -- Possible downref: Non-RFC (?) normative reference: ref. 'HMAC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSEC' ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. 'Server' ** Obsolete normative reference: RFC 2052 (ref. 'SRV') (Obsoleted by RFC 2782) Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Dynamic Host Configuration WG Olafur Gudmundsson 2 INTERNET DRAFT Trusted Information Systems 3 March 26, 1997 5 Security Architecture for DHCP 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 12 areas, and its working groups. Note that other groups may also 13 distribute 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- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This document addresses the general security requirements of 30 both v4 and v6 versions of DHCP. This document lists security 31 requirements and proposes as security model, which meets scaling 32 requirements, security requirements and efficiency requirements. 34 The proposed security model uses public key cryptography and a 35 proposed trusted key distribution mechanism to authenticate 36 clients and servers. The authentication protocol can also 37 exchange keying material for more efficiently protecting 38 successive communication between client and server. The 39 security model also addresses securing relay agents. 41 1. DHCP security requirements 43 One of the problems of designing a security model for DHCP[DHCP] 44 is the wide variety in use and preconditions that different 45 sites/clients have. The fact that sites deploy redundant servers 46 and the lack of a server to server protocol further complicates 47 things, proposed server to server protocol is an Internet 48 draft[Server]. This document assumes fair knowledge of DHCP. 50 1.1. What is authentication? 52 Authentication is the process of establishing the identity of 53 some entity. Once identity has been authenticated that identity 55 Expires September 26, 1997 [Page 1] 56 can be used for access control, accounting etc.. Public key 57 cryptography is a powerful tool that relies on complex 58 mathematical operations to provide information that only the 59 holder of the private key could have generated. For more 60 background information see RFC-1825[RFC1825]. 62 1.1. Requirements 64 Throughout this document, the words that are used to define the 65 significance of particular requirements are capitalized. These 66 words are: 68 o "MUST" 70 This word or the adjective "REQUIRED" means that the item is an 71 absolute requirement of this specification. 73 o "MUST NOT" 75 This phrase means that the item is an absolute prohibition of 76 this specification. 78 o "SHOULD" 80 This word or the adjective "RECOMMENDED" means that there may 81 exist valid reasons in particular circumstances to ignore this 82 item, but the full implications should be understood and the 83 case carefully weighed before choosing a different course. 85 o "SHOULD NOT" 87 This phrase means that there may exist valid reasons in 88 particular circumstances when the listed behavior is acceptable 89 or even useful, but the full implications should be understood 90 and the case carefully weighed before implementing any behavior 91 described with this label. 93 o "MAY" 95 This word or the adjective "OPTIONAL" means that this item is 96 truly optional. One vendor may choose to include the item 97 because a particular marketplace requires it or because it 98 enhances the product, for example; another vendor may omit the 99 same item. 101 Expires September 26, 1997 [Page 2] 102 2. Proposed DHCP security requirements 104 The proposed requirements can be summarized in the following 105 rules. 106 Initial Client/Server Authentication 108 1. Server MUST authenticate client identity. 109 2. Client SHOULD authenticate the server identity as 110 authorized server 112 Initial Relay Agent/Server Authentication 114 3. Server MUST authenticate relay agent identity as authorized 115 relay agent. 116 4. Relay Agent MUST authenticate server identity as authorized 117 server. 119 Successive Client to Server and Relay Agent to Server 120 Communication 122 5. Client and Server MUST agree on security model for 123 protecting future communication. 125 Server/Relay agent advertisements 127 6. Advertisements MUST be verifiable by all recipients. 129 DHCP security cannot be accomplished in a vacuum; fortunately 130 there are available (or soon will be) protocols that DHCP can 131 take advantage of. First and foremost DNSSEC[DNSSEC] or some 132 other KEY distribution mechanism must be available. 133 IPSEC[RFC1825,IPSEC] will be able to handle requirement 5. It is 134 not clear if IPSEC for IPv6, in some cases using local link 135 addresses, can address requirement 1-4. In the case of IPv4 DHCP 136 MUST perform authentication. 138 2.1. DHCP Identity 140 In order to secure DHCP all clients MUST have an identity, this 141 identity can possibly be one of the following: host name, user 142 identity, account code. The "prime" identity MUST have a public 143 KEY stored in the key distribution mechanism. The client MUST 144 know its identity before contacting the server. Each client 145 MUST have access to the correct private key before contacting 146 the DHCP server. 148 For example if the identity selected for a host is its host name 149 and the key distribution mechanism is DNS, then the public key 150 used to authenticate the host is stored under the host name in 151 its home zone. The private key needs to be stored in the 152 computer at all times. If the identity selected is the user then 153 the key is stored under the user name in DNS (e.g.: ogud.tis.com 154 for me), and user needs to load the computer with the private 155 key before the host can contact the server. If the identity of 157 Expires September 26, 1997 [Page 3] 158 the host is just there to uniquely identify the host, the host 159 still needs a private key. 161 2.2. Policy issues. 163 This document does not address access control issues as that is 164 a policy issue for each site, but effective access control 165 depends on correct authentication, thus this work will make 166 access control simpler. This document does not address the 167 issue of protecting the private key on either server, agent or 168 client. 170 3. Client Authentication: 172 One of the goals of this document is to convince the working 173 group that achieving initial authentication is the most 174 important step. Once server and client have established each 175 other's identity the remaining problems can easily be solved. 177 The problem of initial client authentication cannot be solved by 178 IPSEC, as the client does not have an IP identity when it 179 requests service for the first time from server. Once client 180 has been configured it can enter IPSEC security associations 181 with other DHCP servers during the lifetime of the IP address 182 lease. 184 3.1 Types of DHCP clients and their identification needs. 186 To DHCP there are two kinds of clients. Clients that request 187 some of their net identity, and clients that request ALL of 188 their net identity from DHCP. From a security point of view, the 189 second type of client is no different, because these clients 190 must have some identity (for example MAC address) that can be 191 used to uniquely identify them. Previous DHCP security 192 proposals[DHCAUTH] have suggested the use of shared secrets and 193 passwords to identify clients. It is also possible to use some 194 kind of challenge/response system to identify clients. These 195 approaches have limited scaling ability and require a server to 196 server protocol. But in many environments these weaker 197 authentication mechanisms are adequate. 199 The most general case is the identification of a computer that 200 connects to a world wide ISP network and expects the same 201 identity regardless of location. In this case it is unlikely 202 that the same DHCP server serves both India and Iceland. A 203 network of this kind can have a collaborative agreement between 204 number of different ISPs, with multiple administrative domains. 205 It is not reasonable/scalable that all DHCP servers in this 206 network know shared secrets, or passwords for all computers that 207 are allowed to connect. From a security standpoint it is a bad 208 practice to distribute shared secrets or passwords to many 209 places. 211 3.2. Motivation for single strong authentication schema. 213 Expires September 26, 1997 [Page 4] 214 The author feels that it is better to mandate ONE strong 215 authentication protocol for all DHCP interaction, rather than 216 allow for multiple ones and allow sites to choose the wrong one. 217 The protocol below is a strong authentication using public key 218 signatures and encryption. The security of the protocol depends 219 on the difficulty in breaking the private keys used. The site 220 security depends on the sites protecting the private keys. By 221 mandating one protocol at this point we also eliminate the need 222 for negotiating what authentication protocol to use. At this 223 point the public key algorithm has not been selected. The two 224 leading candidates are RSA and ECC (Elliptical Curve 225 Cryptography). 227 4. General DHCP Client authentication protocol. 229 This protocol depends on a reliable certified public key 230 distribution mechanism like DNSSEC[DNSSEC]. Each host and server 231 supplies it's identity, this identity indicates where the 232 associated public key is stored. For DNS the identity is FQDN 233 (Fully Qualified Domain Name), accompanied by key algorithm 234 number and public key footprint. For other key distribution 235 mechanisms there must be enough information to retrieve the key 236 from that source. To successfully validate a server public key, 237 clients must be configured with root key(s) for the key 238 distribution certification tree. 240 This protocol never transmits public keys as it is easy to forge 241 self signed keys. Instead certified keys are distributed via 242 trusted 3rd party (eg. DNSSEC). One of the preconditions of 243 this protocol is that client and server MUST roughly agree on 244 current time. The role of the current time information below is 245 to prevent replay attacks. If client does not know the current 246 time, it MUST request it before starting the authentication 247 process. Servers and Relay agents MUST provide current time upon 248 request without any security checks. 250 If the client does not know the current time, it must be able to 251 ask the local relay agent/server for the current time without 252 authentication and get an answer. 254 4.1. DHCP authentication protocol overview. 256 In the following discussion, DHCP fields not important to the 257 overall security schema are omitted. Following protocol outline 258 assumes that the key distribution mechanism is DNS. 260 Expires September 26, 1997 [Page 5] 261 1. Client: 262 Sends server discovery packet containing 263 Identity (this can be one of host identity, claimed identity, 264 charging identity) 265 client's own public key identity 266 Optionally its host identity 267 current time 268 security options/transformations supported 269 DHCP requests for at least address, DNS server and gateway 270 address. 271 all preceding data is signed by client private key 272 corresponding to the public key specified above. 274 2. Server: 275 If current time is within accepted range 276 Look up client public key in key distribution mechanism 277 verify signature 278 is this client allowed to connect? 279 If all above checks are passed server sends back 280 server Public KEY identity 281 Security model selected 282 key identifier ( if needed by security Model) 283 current time. 284 information client requested for configuration (Address, DNS 285 server, gateway) 286 all above signed by the Server private KEY. 288 3. Client can now 289 configure itself 290 Look up server Public Key in DNS. 291 if Server key is found, client SHOULD validate packet and 292 Server KEY using DNS 293 client should also verify that DNS server is actually a valid 294 DNS server. 295 Sends server 296 key identifier requesting keying material 297 current time 298 signed by client public key 300 4. Server: 301 Server generates a random key to use and it sends to client 302 key identifier 303 Keying material 304 Lifetime of the security association. 305 Current time 306 This data is encrypted using clients public key 308 The client decrypts the packet with its private key. At this 309 point the client can assume its normal processing and send 310 further requests to server protected by the security model 311 selected. The protocol for a relay agent is similar but is 312 omitted here. 314 Expires September 26, 1997 [Page 6] 315 4.2. Additions to the protocol overview. 317 The protocol outlined above does not spell out all the possible 318 error states that can be entered. This needs to be specified in 319 the full protocol. Some of the possible errors include the 320 following cases: 322 What does the server do if it is unable to retrieve/validate the 323 client key? 324 The Client in its verification phase must be able to determine 325 what are the authorized DHCP servers. This may require a new DNS 326 record, or use the SRV[SRV] record. 327 What does a client do if it is not able to convince itself that 328 it is talking to a good DHCP server? 330 Due to the fact that some of the operations required by this 331 protocol take longer than the time-out values in unsecured DHCP, 332 these need to be changed for Security aware servers and clients. 333 There may be a need for a server to send back an ACK to a client 334 indicating that a request has been received and is being 335 processed to stop client from retransmitting requests. 337 In the case of security aware client trying to talk to security 338 ignorant server the server must return an error code informing 339 the client that it does not understand the request. Security 340 aware servers similarly must treat security ignorant clients 341 differently, but how must be determined. 343 4.3. Justification for the authentication protocol 345 There are number of reasons why the protocol does not attempt to 346 create a security association in the first round. By explicitly 347 requesting the security association, the client is notifying the 348 server that it trusts the server and wants to establish a long 349 term relationship with it. There is no reason to establish a 350 security association with a server the client does not trust. 352 If a server selects a shared secret or encryption as a message 353 protection mechanism then the key selected by the server is for 354 use between one client and one server for a limited time. If 355 there is a group of DHCP servers for this site, then the server 356 to server protocol MAY be used to distribute the secret to all 357 the servers. If redundant servers do not share secrets then a 358 client MUST authenticate itself to each server. If a security 359 association outlives its lease time, it MUST be renewed or 360 deleted. 362 In this protocol, there is no need for shared secrets to leave 363 an administrative domain. This protocol solves the distribution 364 problem of shared secrets and eliminates the need for clients to 365 remember shared secrets. The explicit expiration of shared 366 secrets greatly simplifies server management of shared secrets. 368 The only information that a client needs to know is its own 370 Expires September 26, 1997 [Page 7] 371 identity, its public/private key pair and the root public key 372 for the key distribution mechanism. An added benefit of this 373 protocol is that it does not require the DHCP server to store 374 the authentication information for clients that may connect to 375 it. The public keys used are retrieved from an external source. 376 This means that there will be minimal change in how servers are 377 run. This protocol does not address the access control issue; 378 that is a separate problem. 380 4.4. What does the authentication protocol accomplish? 382 This protocol accomplishes requirements 1 through 4. It carries 383 enough information to enable requirement 5. For server and 384 client to validate each other public keys they may want to walk 385 the DNS tree to the root to create a chain of valid keys. The 386 client cannot trust the DNS server supplied by the server but it 387 can trust the signed verifiable data that the DNS server 388 provides. This requires that the DHCP client be able to do 389 DNSSEC verification locally. 391 To determine that the Server is not an impostor there may be a 392 need to store in DNS the list of authorized DHCP servers and 393 agents in a zone. 395 The "root keys" that client stores, can be the keys for "." or 396 for the outermost domain that the client can talk to servers in. 398 The main reason for having the server select the secret keying 399 material for the security association, has to do with random 400 number entropy. Many computers do not have good sources of 401 randomness available at boot time. A server that has been 402 running for a while, on the other hand, has access to better 403 sources of randomness. The protocol when specified should 404 include guidelines on how to generate good random keys on 405 servers. 407 5. Protecting ongoing client/server communication 409 Rule 5 above states that client (or relay agent) and server must 410 agree on a security model for securing all communication. The 411 authentication protocol above accomplishes the required dynamic 412 setup for this. Once a security aware Server and security aware 413 Client have authenticated each other they have entered a 414 security association. This security association will determine 415 how all successive communication is protected. Below is a list 416 of available mechanisms that accomplish this task. 417 A. None (Current state of affairs) NOT recommended 418 B. Message digest with shared secret. (Protects the contents 419 of the packet). 420 C. Digital signature. (Provides more assurance at higher 421 cost). 422 D. Encrypted communication (Provides confidentiality). 423 E. IPSEC. 425 Expires September 26, 1997 [Page 8] 426 The author feels that mechanisms B and D are the only ones 427 practical for DHCP. Digital signatures are not worth the 428 computational and bandwidth cost for one on one communication. 429 IPSEC will become viable at some point in the future and can/ 430 should be used to protect the communication. The working group 431 needs to decide whether to deploy a message protection mechanism 432 in the DHCP protocol or wait for IPSEC. This document recommends 433 that B be implemented using HMAC[HMAC] technique combined with 434 one of the following message digest algorithms MD5, SHA-1 or 435 RIPEMD-160. 437 Digital signatures provide a stronger authentication mechanism 438 than Message digests but are much more expensive to generate. 439 Some Digital signatures are inexpensive to verify but not all. 440 RSA is inexpensive to verify but DSA is not. Given the expensive 441 computation of digital signatures it is hard to justify their 442 use once identity has been established. 444 6. Impact of Agents on security model. 446 Given that in many cases clients need Agents to connect them to 447 DHCP servers, it is important that agents cannot modify the 448 contents of the DHCP request. It is also important that Agents 449 authenticate server advertisements. Agents should not be allowed 450 to modify client requests in any way, other than that required 451 to route the requests. There is no need for the client to enter 452 a security association with its Relay Agent. 454 6.1. Server/Relay agent advertisements. 456 This is a special case where one entity is talking to many. In 457 order to protect this form of communication from malicious 458 attacks these advertisements MUST be digitally signed using the 459 advertisers public key. It is possible to create a group shared 460 secret or group encryption key. This is not a good arrangement 461 for anything that lasts longer than a short time. Short time can 462 be a few minutes to a few hours; longer than that it is not a 463 secure arrangement. If one party leaks this key information, 464 outsiders can forge traffic. 466 6.2. Security threats from relay agents. 468 Relay agents can potentially conduct "man in the middle" attacks 469 on a system that uses them. In the schema above relay agents can 470 conduct denial of service attacks. This is a simple fact of 471 life and there is no way to overcome that. 473 It is not clear that relay agents can conduct any other kind of 474 attacks as they are not able to forge any of the contents of the 475 packets. 477 In the case where clients do not validate that the server 478 contacted is a valid server, relay agents may conduct attacks as 480 Expires September 26, 1997 [Page 9] 481 fake server. In this attack the relay agent claims to be the 482 server to the client and the client to the server. 483 Careful design of the protocol should be able to prevent this. 485 7. Security considerations 487 This document is about security. 489 8. References 491 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", RFC 492 1541, Bucknell University, October 1993. 494 [DHCAUTH] R. Droms, "Authentication for DHCP Messages", 495 Internet Draft November 496 1996 498 [DNSSEC] D. Eastlake, C. Kaufman, "Domain Name System Security 499 Extensions", RFC 2065, January 1997. 501 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- 502 Hashing for Message Authentication", February 1997 504 [IPSEC] R. Atkinson, "Security Architecture for the Internet 505 Protocol", Internet Draft , 506 November 1996. 508 [RFC1825] R. Atkinson, "Security Architecture for the Internet 509 Protocol", RFC 1825, September 1995. 511 [Server] R. Droms, R. Cole, "An Inter-server Protocol for DHCP" 512 Internet Draft March 1997. 514 [SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the 515 location of services (DNS SRV)", RFC 2052, October 1996. 517 9. Author address 519 Olafur Gudmundsson 520 Trusted Information System 521 3060 Washington Road 522 Glenwood, MD 21738 523 +1 301 854 5794 524