idnits 2.17.1 draft-ietf-dhc-securing-dhc-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-26) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** 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 4 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages 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. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 69 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [3,4,5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 86: '...he protocol. The server MUST supply an...' RFC 2119 keyword, line 89: '..., the default gateway information MUST...' RFC 2119 keyword, line 125: '...e DHCPSEC fails and MUST be terminated...' RFC 2119 keyword, line 130: '... renew phase MUST be based on the ...' RFC 2119 keyword, line 145: '... client, the DHCPSEC server SHOULD not...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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: Note: As suggested earlier, if the temporary address is not same as the address assigned in the trusted configuration phase, then the DHCP protocol may have to be modified so that instead of sending a NACK for the renew message, the server can ACK with an alternate address. The other approach is to modify the protocol so that instead of issuing a DHCP renew, the client can do a DHCP discover and, instead of sending a discover message as a broadcast, it is sent as a unicast message over the trusted communication channel. If the new trusted address is not identical to the un-trusted address assigned to a client, the DHCPSEC server SHOULD not automatically reclaim address before the duration of the temporary lease (it could lead to some race conditions). The client may issue an un-trusted release for the temporary address is no longer needed. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 203 looks like a reference -- Missing reference section? '2' on line 206 looks like a reference -- Missing reference section? '3' on line 208 looks like a reference -- Missing reference section? '4' on line 212 looks like a reference -- Missing reference section? '5' on line 215 looks like a reference -- Missing reference section? '6' on line 218 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHCP working Group Baiju V. Patel 2 INTERNET DRAFT Intel Corporation 3 July 11, 1997 Expires in 6 months 5 Securing DHCP 7 9 Status of this Memo 11 This document is a submission to the IETF Dynamic Host 12 Configuration Protocol (dhc) Working Group. Comments are 13 solicited and should be addressed to the working group 14 mailing list (dhcp-v4@bucknell.edu) or to the editor. 16 This document is an Internet-Draft. Internet-Drafts are 17 working documents of the Internet Engineering Task Force 18 (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please 29 check the 1id-abstracts.txt listing contained in the 30 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 31 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 32 ds.internic.net (US East Coast), or ftp.isi.edu (US West 33 Coast). 35 Abstract 37 This proposal describes methods of securing DHCP based on 38 IETF DHCP and IPSEC protocols. This protocol achieves 39 security goals for DHCP client and servers without having to 40 define a new security protocol. Instead, it first bootstraps 41 the DHCP client in un-trusted mode using existing DHCP 42 protocol and then proceeds to secure configuration of the 43 client using existing DHCP and IP protocol features. 45 1. Introduction 47 In this draft, we present a method of securing DHCP protocol 48 and use notation DHCPSEC for the proposed method. The 49 servers and clients that implement the proposed method are 50 denoted by DHCPSEC servers and clients, respactively. 52 The objective behind securing DHCP is to securely configure 53 a DHCP client with an IP address(es) and configuration 54 parameters. The DHCPSEC does not protect against an 55 unauthorized client from arbitrarily selecting an address 56 and using it. Instead, if a client obtains IP address(es) 57 and configuration parameters using DHCPSEC protocol, it is 58 assured that the IP address and configurations obtained 59 using DHCPSEC are the ones provided by an authenticated 60 DHCPSEC server and the integrity of the parameters is not 61 compromised by an adversary in the network. The subsequent 62 renewal of the lease, and acquiring of the additional 63 configuration parameters, as well as release of the lease of 64 an address(es) is authenticated as well. Thus, the protocol 65 protects the client from an adversary who may release the 66 lease of its IP address. The DHCPSEC server also 67 authenticates the DHCPSEC clients. This allows an DHCPSEC 68 server to determine if a client should be allocated an 69 address at all, and to help determine configuration 70 parameters for the client. Moreover, it prevents an 71 adversary from renewing or releasing an address assigned to 72 an authorized client. 74 2. Securing DHCP Protocol 76 The DHCPSEC is comprised of several phases: 1) start-up 77 phase, 2) trusted configuration phase, 3) trusted renew, and 78 4) trusted release phase. 80 2.1. Start-up phase 82 In start-up phase, the DHCPSEC client brings up an un- 83 trusted configuration using the DHCP protocol defined in 84 [1]. The configuration supplied by the DHCP server in this 85 phase is the minimal configuration required to execute 86 subsequent phases of the protocol. The server MUST supply an 87 IP address, and optionally, provide default gateway and DNS 88 server information. If the DHCP server is not on the same 89 subnet as the client, the default gateway information MUST 90 be provided. The lease time (configurable) for the IP 91 address should be relatively small for the efficient use of 92 the addresses. The recommended duration of the lease is 93 hundreds of milliseconds. 95 In many environments, there may be a concern that an 96 adversary may be able to launch a denial of service attack 97 by quickly requesting too many addresses (short lease in 98 this case) and thus denying a legitimate client an IP 99 address. There are several alternatives that may be deployed 100 to protect against some forms of such denial of attacks. For 101 example, if the DHCPSEC server is on the same subnet as the 102 client, it may allocate a non-routable temporary address to 103 a DHCP client. Since the non-routable address space is 104 large, an authorized client is likely to get an address even 105 when this type of attack is in progress (it may result in a 106 fairly large short lived state in the server). Broadband 107 cable network environment may use such configuration by 108 deploying DHCPSEC server at the head-end. In a switch based 109 network, the monitors may be deployed in the hubs to detect 110 both unauthorized use of IP addresses and denial of service 111 attacks. If the attack in progress is detected, the ports 112 may be deactivated. This is by no means a complete list of 113 protection mechanisms against denial of service attack and 114 the implementers must take appropriate actions to protect 115 against such attacks. Note that the proposed method does not 116 attempt to protect against denial of service attack. 118 2.2. Trusted configuration phase 120 In this phase, the DHCPSEC client proceeds with establishing 121 a secure communication channel (as defined in section 2.4) 122 between itself and a known DHCPSEC server (the address of 123 the server is known after the start-up phase). If the 124 DHCPSEC client fails to establish a secure channel with the 125 DHCPSEC server, the DHCPSEC fails and MUST be terminated 126 with appropriate messages. Naturally, the process may be 127 repeated again as often as desired. Once the trusted channel 128 is established, the DHCPSEC client proceeds to renew the IP 129 address using DHCP renew message. The communication for DHCP 130 renew phase MUST be based on the unicast messages over the 131 secured communication channel between the DHCPSEC client and 132 server. If the renew completes successfully, the IP address 133 allocated to the DHCPSEC client is authenticated. 135 Note: As suggested earlier, if the temporary address is not 136 same as the address assigned in the trusted configuration 137 phase, then the DHCP protocol may have to be modified so 138 that instead of sending a NACK for the renew message, the 139 server can ACK with an alternate address. The other approach 140 is to modify the protocol so that instead of issuing a DHCP 141 renew, the client can do a DHCP discover and, instead of 142 sending a discover message as a broadcast, it is sent as a 143 unicast message over the trusted communication channel. If 144 the new trusted address is not identical to the un-trusted 145 address assigned to a client, the DHCPSEC server SHOULD not 146 automatically reclaim address before the duration of the 147 temporary lease (it could lead to some race conditions). The 148 client may issue an un-trusted release for the temporary 149 address is no longer needed. 151 2.3. Trusted Renew and Release 153 The DHCPSEC server MUST ignore any renew or release request 154 over clear channel for securely allocated IP address. Lease 155 of a securely allocated IP address may be renewed or 156 released only over a secure channel between the DHCPSEC 157 server and client to whom the address was allocated in the 158 trusted configuration phase of the DHCPSEC protocol. The 159 identity of the client is verified by the secure channel 160 protocol. In summary, the trusted release phase is 161 essentially same as the trusted configuration phase. 163 2.4. Authenticated Secure Channel 165 The DHCPSEC compliant servers and clients MUST implement the 166 secure channel based on IPSEC AH [2] and ISAKMP/OAKLEY 167 [3,4,5]. IPSEC ESP [6] MAY be used when the situation 168 warrants. DHCPSEC clients and servers must conform to the 169 interoperability requirements of IPSEC protocol suit 170 (including ISAKMP/OAKLEY, IPSEC AH, and IPSEC ESP). In 171 future other secure communication channels may be defined. 173 The IPSEC security association is used by the DHCPSEC 174 protocol during the trusted configuration phase. Therefore, 175 at the end of this phase, the security association SHOULD be 176 discarded by both the DHCPSEC client and servers. In some 177 cases (e.g., when the temporary address is same as the 178 securely assigned address), the same security association 179 MAY be used for further communication between the two 180 systems. 182 3. Security Considerations 184 The proposed protocol does not address security requirements 185 for tftp function that is part of the bootp protocol. It is 186 assumed that the integrity of the files tftp'd will be 187 verified using means external to this protocol. An example 188 of such means would be to use signed files for software 189 download using tftp so that the client would be able to 190 authenticate and verify integrity of the copied software. 191 The server may enforce licensing requirements on the 192 software by external means such as a license servers. 194 4. Acknowledgments 196 The author would like to thank Thomas Narten, Ralph Droms, 197 Peter Ford, Eric Dittert, Dave Chouinard, Charlie Perkins, 198 and Throop Wilder, Munil Shah and many others for helping 199 improve this draft. 201 5. References 203 [1] Droms, R, "Dynamic Host Configuration Protocol", RFC 204 1531. Bucknell University, 1993. 206 [2] Atkinson, R., "IP Authentication Header", RFC 1826. 208 [3] Maughan, D., Schrtler, M. Schneider, M., and Truner, J., 209 "Internet Security Association and Key Management Protocol 210 (ISAKMP)". 212 [4] Piper, D., The Internet IP Security Domain of 213 Interpretations, Internet Draft. 215 [5] Carel, D., Harkins, D., "The Resolution of ISAKMP with 216 Oakley". 218 [6] Atkinson, R., "IP Encapsulating Security Payload (ESP)", 219 RFC 1827. 221 6. Authors' Address 223 Baiju V. Patel 224 Intel Corporation 225 MS JF3-206 226 2111 NE 25th Ave. 227 Hillsboro, OR, USA 97124 228 +1(503)264-2422 229 baiju@mailbox.jf.intel.com