idnits 2.17.1 draft-ietf-dhc-security-arch-01.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 5 longer pages, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 50 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 302 has weird spacing: '...h which clien...' == Line 338 has weird spacing: '...dentity from ...' == Line 423 has weird spacing: '...re data binar...' == 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: To prevent replay attacks, DHCP messages must contain time 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 (July 30, 1997) is 9766 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: 'RFC2014' is mentioned on line 432, but not defined == Missing Reference: 'DNSSEC' is mentioned on line 513, but not defined == Missing Reference: 'TSIG' is mentioned on line 609, but not defined == Unused Reference: 'HMAC' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 687, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCAUTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPv6EXT' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPVERSERV' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'Intserver' -- Possible downref: Non-RFC (?) normative reference: ref. 'Server' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSEC' ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) -- Possible downref: Non-RFC (?) normative reference: ref. 'SRV' -- Possible downref: Non-RFC (?) normative reference: ref. 'NETSEC' Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 11 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 July 30, 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 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 documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 22 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This document addresses the general security requirements of both 29 DHCPv4 and DHCPv6. This document lists security requirements and 30 proposes a security model, which meets scaling requirements, 31 security requirements and efficiency requirements. 33 The proposed security model uses public key cryptography and a 34 proposed trusted key distribution mechanism to authenticate clients 35 and servers. Once clients have authenticated themself less expensive 36 mechanishms can be used to protect subsequent communication. The 37 security model also addresses securing relay agents and server to 38 server protocols. 40 1. DHCP security requirements 42 One of the problems of designing a security model for DHCP[DHCP] is 43 the wide variety in use and preconditions that different sites/ 44 clients have. The fact that sites deploy redundant servers and 45 the lack of a server to server protocol further complicates 46 things[Server,Intserver]. 48 1.1. Authentication, confidentiality, data integrity 50 RFC-1825[RFC1825] contains a great description of these terms and 51 their uses. Authentication is the process of establishing the 52 identity of some entity. Once identity has been authenticated, 53 that identity can be used for access control, accounting etc. 55 There are number of authentication technologies available. 57 Public key cryptography is a powerful tool that relies on complex 58 mathematical operations to provide information that only the holder 59 of the private key could have generated. This technology can be 60 used for all the functions named in the title of this section. 62 Shared secret authentication is the process of digesting the data 63 transmitted and obfuscating the digest by applying a transformation 64 by a key that is only used by the two entities. This technology 65 can be used to provide both authentication and data integrity. 66 Each pair can share multiple shared secrets, it is important 67 that each secret have an identifier attached to it. 69 Confidentiality can be accomplished by encrypting the data contents 70 of the outgoing packet. Shared secrets can be used as keys for 71 symmetric encryption. 73 1.2. Shared secrets 75 Shared secrets are between two entities; there is NEVER a need to 76 share these secrets with other entities. The hosts storing the 77 secrets MUST protect the secrets as well as possible. 79 1.3 Terminology and DHCP v6 considerations 81 This document uses DHCPv4 terminology as it is more familiar than 82 the new DHCPv6[DHCPv6] terminology. When this document talks 83 about DISCOVER messages the same will apply to DHCP v6 Solicit 84 Message. No changes are needed in the protocol section 6 to 85 support DHCPv6; some currently proposed DHCPv6[DHCPv6EXT] 86 security options need to be modified. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 89 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in 91 RFC 2119. 93 2. Proposed DHCP security requirements 95 The proposed requirements can be summarized in the following rules. 97 - Initial Client/Server Authentication 99 1. Server MUST authenticate client identity. 101 2. Client SHOULD authenticate the server identity as an 102 authorized server. 104 - Initial Relay Agent/Server Authentication 106 3. Server MUST authenticate relay agent identity as an 107 authorized relay agent. 109 4. Relay Agent MUST authenticate server identity as an 110 authorized server. 112 HAND JUSTIFY 113 - Successive Client to Server and Relay Agent to Server Communication 115 5. Client and Server MUST have agred on security model for 116 protecting future communication. 118 - Server/Relay agent advertisements 120 6. Advertisements MUST be verifiable by all recipients. 122 - Server/Server communication 124 7. All communication MUST be protected for data integrity. 125 Servers MAY request that communication be encrypted. 127 DHCP security cannot be accomplished in a vacuum; as DHCP is not a 128 general purpose communication protocol. Fortunately there are 129 available (or soon will be) protocols that DHCP can take advantage 130 of. First and foremost DNSSEC[RFC2065] or some other key 131 distribution mechanism must be available. IPSEC[RFC1825,IPSEC] 132 will be able to handle requirement 5. It is not clear if IPSEC 133 for IPv6, in some cases using local link addresses, can address 134 requirement 1-4. In the case of IPv4 DHCP MUST perform the 135 initial authentication. 137 2.1. DHCP Identity 139 In order to secure DHCP all clients MUST have an identity, this 140 identity can possibly be one of the following: host name, user 141 identity, account code. The "prime" identity MUST have a public key 142 stored in the key distribution mechanism. The client MUST know its 143 identity before contacting the server. Each client MUST have access 144 to the correct private key before contacting the DHCP server. 146 If the identity selected for a host is its host name and the key 147 distribution mechanism is DNS, then the public key used to 148 authenticate the host is stored under the host name in its home 149 zone. The private key needs to be stored in the computer at all 150 times. If the identity selected is the user then the key is stored 151 under the user name in DNS (e.g.: ogud.tis.com for me), and the user 152 needs to load the computer with the private key before the host 153 can contact the server. If the identity of the host is just 154 there to uniquely identify the host, the host still needs a 155 private key. 157 2.2. DHCP communication protection 158 DHCP is a protocol that carries publicly known information, thus 159 there is limited need for confidentiality. DHCP requires data 160 integrity protection for communication. The option to allow DHCP 161 servers/clients to request confidentiality SHOULD be part of any 162 security architecture. 164 2.3. Policy issues. 166 This document does not address access control issues as that is a 167 policy issue for each site. Effective access control depends on 168 correct authentication, thus this work will make access control 169 simpler. This document does not address the issue of protecting the 170 private key on either server, agent or client. 172 2.4 Security threats to DHCP 174 2.4.1 Attacks against servers 176 There are many possible attacks possible against servers, including 177 denial of service by exhausting the servers allocated address space. 178 Another denial of service attack is to overload the server causing 179 it not to respond to clients. 181 Once servers start updating DNS and other directory services, DHCP 182 servers can be spoofed to register incorrect information in those 183 services. 185 Another possible attack is to gain unauthorized access to some 186 resources, such as network access. 188 2.4.2 Attacks against clients 190 This is a less known problem, but should not be ignored. Fake 191 servers can provide clients with partially correct information 192 that allows the attacker to route traffic through certain host 193 where critical information can be collected. This becomes 194 important to detect and prevent when encrypted traffic is 195 allowed to pass through firewalls. 197 Clients can be configured with bogus data, so that they will assume 198 that the network is down. In some cases it is hard to get a 199 client to reconfigure itself. Clients can also be configured 200 with addresses of other clients, causing address conflicts. 202 The bright side of this problem is that it is not that hard to 203 detect fake servers by monitoring the network for DHCP traffic. 205 2.5. Complications in implementing the security models 207 A Client that issues DISCOVER message does not have any IP address 208 that works outside the local network, and may not even work on 209 the local network. This prevents the clients from checking with 210 outside information sources. Servers on the other hand are fully 211 configured and can use any information sources accessible. 213 Clients will not wait long for OFFER message, some security checks 214 may take longer than the DHCP retransmission timeout. If DHCP 215 servers had an option to inform clients that DISCOVER messages 216 are being worked on and client should expect an answer in short 217 order, then this problem would be solved. 219 Some DHCP servers do not have CPU cycles to spare to do security 220 checks. This is a bogus argument, since inexpensive powerful 221 computers are available and sites should upgrade if security is 222 of concern. 224 3. DHCP Security components 226 3.1 Authentication services 228 In order for DHCP servers to be able to determine if a client 229 request should be serviced it is essential for the server to be 230 able to establish the client's identity. There are two kinds of 231 identities that are possible, local mutually agreed upon 232 identities and global identities. 234 Local identity is sufficient if the client will only be configured 235 from a small set of servers, and if there are no expectations 236 that the client will migrate to another location. This is an 237 acceptable solution for a site where all computers are 238 stationary but are configured from DHCP for administrative 239 reasons. Solutions of this kind have certain scaling problems. 241 Global identity on the other hand is needed when a client can 242 connect to multiple servers and it provides some of its 243 identity. 245 An example of local identity is a name or number that is 246 configured in the client and server. This could be the name of the 247 client on the local network. A good example of global identity 248 is a DNS domain name. 250 3.2 Time service 252 To prevent replay attacks, DHCP messages must contain time 253 information that clients and servers check and act upon. Clock 254 synchronization service can be provided by an outside 255 entity[RFC1305] once a client is configured, but bounds must be 256 placed on acceptable skew while a client is off line or migrates 257 between locations. Clients SHOULD not trust time information 258 from servers until after servers have been validated as such. 259 Clients should always assume that the network is insecure. 261 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 OFFER 264 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 descibed models 272 3.4.1 The "No security" model 274 This is the current situation. The motivation for not changing 275 anything is that security is hard. Considering that DHCP for IPv4 is 276 a hack built on an older hack (BOOTP), there is not enough 277 flexibility in the protocol to add security. 279 A smart client attached to a broadcast network can learn everything 280 it needs to know to configure itself by listening to network 281 traffic. The client can either monitor DHCP traffic and/or all 282 network traffic to find gateways, servers and unused addresses. 283 There is no protection against this. 285 DHCPv6 can on the other hand be extended and modified to fit any 286 security model selected. Sites will migrate to IPv6 soon, and 287 the ones that do not deserve what they get. 289 In this model DHCP clients will be able to do harm and be harmed 290 by bogus servers. This model is not acceptable when DHCP servers 291 perform update operations on a client's behalf. Sites MAY 292 select this model but this is strongly discouraged. 294 3.4.2 The "Simple" model 296 A DHCP client is configured with a token that allows it to 297 authenticate itself to the servers in the DHCP DISCOVER message. 298 If servers can authenticate the token and the client associated 299 with the token is allowed to communicate with the server the 300 server will reply with OFFER message. 302 In this model servers will know with which client they are dealing, 303 and that should be sufficient protection against most of the 304 attacks against the servers. If a client is able to authenticate 305 the server response, the client might be protected against bad 306 servers. 308 With minor extensions to DHCP, all subsequent communication can be 309 protected. 311 3.4.3 The "Comprehensive" Model 312 In this model DHCP servers and clients have the ability to 313 authenticate each other. The requirement here is that clients must 314 be able to authenticate the server without any communication as 315 they can not trust the information from the server. This model 316 also must prevent replay attacks. 318 This model protects all traffic between clients and servers, making 319 it impossible to stage any attacks other than denial of service 320 attacks due to CPU overload of servers. 322 4. Client Authentication: 324 Initial authentication is the most important step. Once server and 325 client have established each other's identity the remaining 326 problems can solved. 328 The problem of initial client authentication cannot be solved by 329 IPSEC, as the client does not have an IP identity when it requests 330 service for the first time from the server. Once the client has 331 been configured it can enter IPSEC security associations with 332 other DHCP servers during the lifetime of the IP address lease. 334 4.1 Types of DHCP clients and their identification needs. 336 In DHCP there are two types of clients: clients that request some of 337 their net identity from DHCP, and clients that request all of their 338 net identity from DHCP. From a security point of view, the 339 second type of client is no different, because these clients 340 must have some identity (for example MAC address) that can be 341 used to uniquely identify them. Previous DHCP security 342 proposals[DHCAUTH] have suggested the use of shared secrets and 343 passwords to identify clients. It is also possible to use some 344 form of challenge/response system to identify clients. These 345 approaches have limited scaling ability and require a server to 346 server protocol. But in many environments these weaker 347 authentication mechanisms are adequate. 349 The most general case is the identification of a computer that 350 connects to a world wide ISP network and expects the same identity 351 regardless of location. In this case it is unlikely that the same 352 DHCP server serves both India and Iceland. A network of this 353 kind can have a collaborative agreement between a number of 354 different ISPs, with multiple administrative domains. It is not 355 reasonable/scalable that all DHCP servers in this network know 356 shared secrets, or passwords for all computers that are allowed 357 to connect. From a security standpoint it is a bad practice to 358 distribute shared secrets or passwords to many places. 360 4.2. Motivation for single strong authentication schema. 362 It is better to mandate ONE strong authentication protocol for all 363 DHCP interaction, rather than allow for multiple ones and allow 364 sites to choose the wrong one. The protocol below uses strong 365 authentication with public key signatures and encryption. The 366 security of the protocol depends on the difficulty in breaking 367 the private keys used. The site security depends on the sites 368 protecting the private keys. By mandating one protocol at this 369 point, we also eliminate the need for negotiating what 370 authentication protocol to use. At this point, the public key 371 algorithm is MUST be RSA. 373 4.3 Motivation for global DNS identities for DHCP clients 375 Once the global identity is registered with an information service, 376 this identity is available within the limits of the information 377 service. DNS is the most common information service used by 378 computers. 380 DNSSEC[RFC2065] strengthens DNS[RFC1035] against information 381 corruption and provides distribution of public keys. If every host 382 that is configured by DHCP has a public key stored in DNS then 383 servers can verify digital signatures generated by that key. 384 Once clients are configured it is possible for client to verify 385 that the server it was configured by is a good DHCP server. In 386 order to do this, either SRV[SRV] records or ALLOC[DHCPVERSERV] 387 DNS record must list the DHCP servers for each domain. 389 IPSEC can be preconfigured with SPI's but there is no definition for 390 the format of the 'destination address'. If it is DNS format, DHCP 391 entities MAY enter IPSEC relationship without a key exchange once 392 client has received DHCP ACK message. 394 5. DHCP security options and their processing 396 5.1 DNS Identity option 398 This option allows the DHCP entities to advertise their own public 399 keys which are stored in DNS and DNSSEC provides secure key rerival 400 mechanism. 402 Field value size in bytes 403 ------------- ------ ----------- 404 option TBD 1 405 length 0-255 1 406 selector 0-64K 2 407 name variable < 250 409 The name specified in this option does not have to be the same name 410 that the client is requesting/using. 412 5.2 Signature option 413 This is an option that carries any type of signature that can be 414 specified. 416 Field value size in bytes 417 ------------- ------ ----------- 418 option TBD 1 419 length 0-255 1 420 algorithm 1-253 1 421 ID 0-2^16 2 422 current time 0-2^32 4 423 signature data binary variable < 246 425 The following algorithms are defined and must be supported by all 426 implementations. 428 0 No signature data 429 1 RSA/MD5 as specified in PKCS1[NETSEC], this is 430 identical to algorithm 1 in DNSSEC. 432 100 HMAC-MD5 as specified in RFC2104[RFC2014] 434 The ID is a 16 bit number that is identical to the key indentifier 435 in the DNSSEC SIG record. This identifier is used to select a 436 key from the key set of the name. If there are multiple keys in 437 the key set that match this ID and can be used for DHCP and are 438 the same size, the verifier must be ready to try all of the keys 439 until verification succeeds. 441 The current time value states at what time the signature is 442 generated, in Universal Time. DHCP entity SHOULD accept signatures 443 that are within 60 seconds of local time. If the signature is not 444 within these bounds the whole packet should be rejected. 446 The size of the signature data field depends on the algorithm used 447 and for some algorithms, the key size. MD5 digests are 16 bytes. 448 RSA signatures are always the same size as the modulus of the 449 key. Signature data can never exceed 246 bytes, this restricts 450 the key sizes used to about 1968 bits. 452 The data covered by signatures is defined in section 5.3.1. The 453 Signature option MUST be the LAST option in the DHCP packet, adding 454 a Signature option MUST NOT result in too large of a packet, 455 other options MUST be removed to make space for the signature 456 option. 458 There are special considerations for Relay agents. A Relay Agent 459 that adds a relay agent option(s) to a signed DHCP packet MUST 460 add a Signature option after its option(s) and its signature 461 MUST cover the whole outgoing packet. If the incoming 462 signature is addressed to this Relay Agent, the Relay Agent MUST 463 remove that signature from the outgoing packet before adding its 464 option(s) to the packet. If the incoming signature is a digital 465 signature (alg=1) it MUST be retained. 467 5.3.1 Data covered by signature option 469 The whole outgoing DHCP packet is covered, including the signature 470 option. 472 For DISCOVER/SOLICIT the signature is calculated over 474 Modified outgoing packet 476 For all other messages the signature is calculated over 478 digest of last valid incoming packet | Modified outgoing packet 480 The modified outgoing packet is the whole DHCP packet with following 481 differences: 483 'giaddr' and 'hops' fields must be set to all zero. 484 All bytes in the signature data must be set 0xa6. 486 The digest of the last incoming packet from the other entity is to 487 associate the outgoing packet to the request or last answer. 489 5.3 Wait option 491 This option allows the server to inform the client that it is 492 currently validating the clients identity and request that the 493 client wait the specified time before retransmitting the query. 495 Field value size in bytes 496 ------------- ------ ----------- 497 option TBD 1 498 length 3 1 499 seconds 1-6 1 501 This option is to throttle back security aware clients while server 502 is authenticating the clients identity. The client MUST ignore 503 this option if it has received 2 previous ones from same server 504 for the same message. 506 6. "Simple" DHCP authentication protocol 508 This protocol is along the lines of the simple model described in 509 section 3.4.2. The foundation that this protocol offers can be used 510 to build a comprehensive protocol. 512 This protocol depends on a reliable certified public key 513 distribution mechanism like DNSSEC[DNSSEC]. Each client supplies 514 its identity in the initial DISCOVER message. This identity 515 indicates where the associated public key is stored. For DNS the 516 identity is the FQDN (Fully Qualified Domain Name), accompanied 517 by the key algorithm number and public key footprint. For other 518 key distribution mechanisms there must be enough information to 520 Expires January 30, 1998 [Page10] 521 retrieve the key from that source. 523 To successfully validate a server public key, clients must be 524 configured with the root key(s) for the key distribution 525 certification tree. 527 The protocols below make use of currently undefined options, these 528 options must be specified before this proposal can be adopted. 530 6.1 DHCP authentication protocol overview 532 In the following discussion, DHCP options not important to the 533 overall schema are not included. 535 6.1.1 Client: DISCOVER message MUST include 537 IDENTITY option (contains identity type, name, unique selector) 538 Signature option (alg=1) signed by public key in IDENTITY option. 540 6.1.2 Server: DHCP-OFFER message 542 If server is able to validate DISCOVER message from a client it 543 shares a secret with it MUST include following options. 545 IDENTITY option 546 Signature option (alg=100) 548 If the client is able to verify this message, it has authenticated 549 the server and the authentication protocol is complete. Future 550 communication can be protected by this secret. 552 If the server is able to validate DISCOVER message from a client 553 that it does not share a secret with, the following options MUST 554 be included. 556 IDENTITY option 557 Signature option (alg=1) 559 If the server needs more time to complete authentication it can send 560 back 562 WAIT option 563 Signature option 0 565 If the server refuses to offer service, as the time in request is 566 out of bounds, the server sends back OFFER which MUST contain 567 only the following options: (EMPTY OFFER). 569 IDENTITY option 570 Signature option 572 If server is unable to authenticate the identity of the client, the 574 Expires January 30, 1998 [Page11] 575 server MUST ignore the client messages. The server SHOULD log the 576 event and CAN ignore requests from the same hardware address for a 577 fixed time. 579 6.1.3 Client DHCP-REQUEST processing 581 If the server has accepted the client's identity, the client can now 582 send the REQUEST message, and this message MUST be signed by its 583 public key in order for other servers to verify that their 584 offers were declined. The following options MUST be present: 586 IDENTITY 587 Security option (alg=1) 589 6.2 Future communication 591 Once a client that does not share a secret with the server selected 592 has been configured, it can optionally authenticate the server as 593 specified in[DHCPVERSERV]. All future communiction between the 594 client and the server MUST contain data protection. It can also 595 attempt to exchange secrets with the server via an optional 596 protocol extension "To Be Determined". If IPSEC is available it 597 CAN be used to protect future communication until the client is 598 renumbered. The client and server can also elect to use RSA 599 signatures on all communication. 601 6.3 Computational complexity of Simple Authentication Protocol 603 This protocol places most of the cost of the expensive public key 604 operations on the client. Servers need to generate signatures on all 605 messages to clients that do not share secrets with them. 607 The cost of verifying the public keys of the client can be to a 608 large extent offloaded to the DNSSEC server if a DNS transaction 609 signature mechanism[RFC2065,TSIG] is used to protect the 610 communication. 612 6.4 Client security requirements 614 Security enabled DHCP clients MUST be able to store their identity 615 and private key between reboots. These same clients SHOULD have 616 a clock that keeps reasonable good time. The client SHOULD be 617 able to store multiple Server Identities and Shared secrets 618 between reboots. Clients MUST be able to perform the following 619 security operations: RSA/MD5 digital signatures and HMAC-MD5. 621 6.5 Server security requirements 623 Security enabled DHCP servers MUST be able to store identities and 624 shared secrets with a large number of clients. Servers MUST be able 625 to perform RSA/MD5 and HMAC-MD5 operations. Servers MUST be 626 configured with either secure DNS resolver, or other form of 627 trusted communication with DNSSEC server. 629 Expires January 30, 1998 [Page12] 631 7. Security considerations 633 This document addresses how to add security features to the 634 unsecured DHCP protocol. 636 7. References 638 [DHCP] R. Droms, "Dynamic Host Configuration Protocol", RFC 639 2131, Bucknell University, April 1997. 641 [DHCAUTH] R. Droms, "Authentication for DHCP Messages", 642 Internet Draft November 643 1996 645 [DHCPv6] J. Bound, C. Perkins, 646 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 648 [DHCPv6EXT] C. Perkins, "Extensions for DHCPv6", Internet Draft 649 May 1997 651 [DHCPVERSERV] R. Watson, O. Gudmundsson, 652 "DHCP Server verification by client via DNSSEC", 653 July 1997. 655 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- 656 Hashing for Message Authentication", RFC 2104, February 1997 658 [Intserver] R. Droms, K. Kinnear, "An Inter-server Protocol for 659 DHCP", Internet Draft , 660 April 1997 662 [Server] R. Droms, R. Cole, "An Inter-server Protocol for 663 DHCP", Internet Draft 664 March 1997. 666 [IPSEC] R. Atkinson, "Security Architecture for the Internet 667 Protocol", Internet Draft , 668 November 1996. 670 [RFC1035] P. Mockapetris, "Domain Names - Implementation and 671 Specification," RFC 1034, ISI, November 1987. 673 [RFC1305] Mills, D., "Network Time Protocol (v3)", RFC 1305, 674 March 1992. 676 [RFC1825] R. Atkinson, "Security Architecture for the Internet 677 Protocol", RFC 1825, September 1995. 679 [RFC2065] D. Eastlake, C. Kaufman, "Domain Name System Security 680 Extensions", RFC 2065, January 1997. 682 [SRV] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the 684 Expires January 30, 1998 [Page13] 685 location of services (DNS SRV)", RFC 2052, October 1996. 687 [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP 688 Vendor Extensions", RFC 2132, March 1997. 690 [NETSEC] C. Kaufman, R. Perlman, M. Speniner, "Network 691 Security: PRIVATE Communications in a PUBLIC World", Prentice 692 Hall 1995. 694 9. Author address 696 Olafur Gudmundsson 697 Trusted Information System 698 3060 Washington Road 699 Glenwood, MD 21738 700 +1 301 854 5794 701 703 Expires January 30, 1998 [Page14]