idnits 2.17.1 draft-ietf-dhc-relay-agent-ipsec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 396. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 (May 26, 2005) is 6910 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 2401 (ref. '2') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. '3') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '4') (Obsoleted by RFC 4306) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC R. Droms 3 Internet-Draft Cisco Systems, Inc. 4 Expires: November 27, 2005 May 26, 2005 6 Authentication of DHCP Relay Agent Options Using IPsec 7 draft-ietf-dhc-relay-agent-ipsec-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 27, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The DHCP Relay Agent Information Option (RFC 3046) conveys 41 information between a DHCP relay agent and a DHCP server. This 42 specification defines a mechanism for securing the messages 43 exchanged between a relay agent and a server using IPsec (RFC 2401). 45 1. DHCP Terminology 47 This document uses the terms "DHCP server" (or "server") and "DHCP 48 client" (or "client") as defined in RFC 2131. The term "DHCP relay 49 agent" refers to a "BOOTP relay agent" as defined in RFC 2131. 51 2. Introduction 53 DHCP (RFC 2131 [5]) provides IP addresses and configuration 54 information for DHCP clients. It includes a relay agent capability 55 (RFC 951 [6], RFC 1542 [7]), in which processes within the network 56 infrastructure receive broadcast messages from clients and forward 57 them to servers as unicast messages. In network environments like 58 DOCSIS data-over-cable and xDSL, for example, it has proven useful 59 for the relay agent to add information to the DHCP message before 60 forwarding it, using the relay agent information option, RFC 3046 61 [1]. The kind of information that a relay agent adds is often used 62 in the server's decision making about the addresses and configuration 63 parameters that the client should receive. The way that the relay 64 agent data is used in server decision-making tends to make that data 65 very important, and highlights the importance of the trust 66 relationship between the relay agent and the server. 68 The existing DHCP Authentication specification (RFC 3118) [8] only 69 secures communication between the DHCP client and server. Because 70 relay agent information is added after the client has signed its 71 message, the DHCP Authentication specification explicitly excludes 72 relay agent data from that authentication. 74 The goals of this specification is to define a method that a relay 75 agent can use to: 76 1. protect the integrity of the data that the relay adds 77 2. provide replay protection for that data 78 3. leverage the existing IPsec mechanism 80 3. Deployment of Relay Agents in a DHCP Service 82 DHCP relay agents forward messages between DHCP clients and DHCP 83 servers, so that the DHCP service can be provided without requiring a 84 DHCP service on each network segment. Usually, there is a DHCP relay 85 agent on the same network segment as the client, and the relay agent 86 forwards messages directly between the client and DHCP server, as 87 illustrated in Figure 1. 89 ______ 90 _____ / \ 91 +------+ / \ +-------+ / \ +------+ 92 | DHCP |--|Network|--| Relay |--| internet |--| DHCP | 93 |client| |Segment| |Agent A| \ / |server| 94 +------+ \_____/ +-------+ \______/ +------+ 95 . 96 Deployment of a DHCP relay agent to forward messages between a DHCP 97 client and a DHCP server 99 Figure 1 101 In some deployments, there may be more than one relay agent between 102 the DHCP client and server. In Figure 2, relay agent A is configured 103 to forward DHCP messages to relay agent B. Relay agent B is 104 configured to forward DHCP messages to relay agent C, which is, in 105 turn, configured to forward DHCP messages to the DHCP server 107 In the case where multiple relay agents are deployed between the DHCP 108 client and server, the responses from the server to the client are 109 sent directly to the relay agent closest to the DHCP client. In 110 Figure 2, the DHCP server will send its responses to the DHCP client 111 directly to relay agent A. 113 ______ 114 _____ / \ 115 +------+ / \ +-------+ / \ 116 | DHCP |--|Network|--| Relay |--| internet | 117 |client| |Segment| |Agent A| \ / 118 +------+ \_____/ +-------+ \______/ 119 | 120 | 121 +-------+ 122 | Relay | 123 |Agent B| 124 +-------+ 125 | 126 ______ 127 / \ 128 / \ 129 | internet | 130 \ / 131 \______/ 132 | 133 +-------+ 134 | Relay | 135 |Agent C| 136 +-------+ 137 | 138 ______ 139 / \ 140 / \ 141 | internet | 142 \ / 143 \______/ 144 | 145 +-------+ 146 | Relay | 147 |Agent D| 148 +-------+ 149 | 150 ______ 151 / \ 152 / \ +------+ 153 | internet |--| DHCP | 154 \ / |server| 155 \______/ +------+ 157 Deployment of multiple relay agents between a DHCP client and server 159 Figure 2 161 4. Relay Agent Message Threat Model 163 DHCP messages are forwarded by DHCP relay agents between DHCP clients 164 and DHCP servers. The messages exchanged between relay agents and 165 servers, in addition to carrying the contents of the messages between 166 the clients and server, may carry additional information in relay 167 agent information options. The information in the relay agent 168 information options may be used by the relay agent, for example to 169 track the physical interface to which a DHCP client is attached, and 170 by the server, for example to affect the selection of an IP address 171 and other configuration information to be assigned to the client. 173 Because the information carried in the relay agent information option 174 may affect the behavior of relay agents and servers, operation of a 175 DHCP service may be disrupted through malicious attacks on DHCP 176 messages carrying relay agent information options. 178 The attacks available to a malicious attacker through the relay 179 information option include inserting new relay information options, 180 modifying the contents of existing relay information options or 181 deleting relay information options. There is no attack available 182 through examining the contents of relay information options so there 183 is no requirement for privacy of the contents of relay information 184 options. 186 A malicious attacker might mount the following denial of service 187 attacks against a DHCP client: 188 o Change the contents of the Agent Circuit ID sub-option or the 189 Agent Remote ID sub-option [1], causing the relay agent to be 190 unable to return DHCP messages from the server to the client 191 o Change the contents of the DOCSIS Device Class sub-option [9], 192 causing the DHCP server to provide incorrect configuration 193 parameters to a DOCSIS device 194 o Change the contents of the Link Selection sub-option [10], causing 195 the DHCP server to assign an IP address from an incorrect subnet 196 to the DHCP client 198 In some networks, hosts are assigned to different VLANs that provide 199 different types of access to the network depending on the identity of 200 the host or the user of that host. For example, a host might be 201 assigned to an internal company VLAN or an isolated VLAN that 202 provides only external Internet access depending on the identity of 203 the host. A malicious attacker might mount the following attacks 204 designed to gain unauthorized network access: 205 o Change the contents of the Link Selection sub-option to cause the 206 DHCP client to be assigned an IP address from an inappropriate 207 VLAN 209 o Change the contents of the RADIUS Attributes sub-option [11] to 210 cause the DHCP client to be authorized to access inappropriate 211 network resources 212 o Replay an earlier DHCP message that contained a valid RADIUS 213 Attributes sub-option to cause the DHCP client to be authorized to 214 access inappropriate network resources 216 5. Use of IPsec to secure DHCP messages 218 Relay agents and servers can use IPsec mechanisms [2] to exchange 219 messages securely as described in this section. If there is a single 220 relay agent between the DHCP client, there is an IPsec trust 221 relationship established between the relay agent and the DHCP server. 222 In Figure 1, relay agent A and the DHCP server must have an IPsec 223 session through which DHCP messages are exchanged. 225 If a client message is relayed through multiple relay agents, there 226 are independent, pairwise IPsec sessions among the relay agents. In 227 a deployment with multiple relay agents, the relay agents are assumed 228 to belong to a single administrative domain or otherwise have the 229 ability to establish IPsec sessions. For example, in Figure 2, there 230 must be an IPsec session between pairs of relay agents A and B, B and 231 C, and C and D. There must also be be a IPsec session between relay 232 agent D and the DHCP server. In addition, there must be an IPsec 233 session between the DHCP server and relay agent A, for messages that 234 will be returned from the server directly to relay agent A. 236 Relay agents and servers that support secure relay agent to server or 237 relay agent to relay agent communication use IPsec under the 238 following conditions: 239 Selectors: Relay agents are manually configured with the addresses 240 of the relay agent or server to which DHCP messages are 241 to be forwarded. Each relay agent and server that will 242 be using IPsec for securing DHCP messages must also be 243 configured with a list of the relay agents to which 244 messages will be returned. The selectors for the relay 245 agents and servers will be the pairs of addresses 246 defining relay agents and servers that exchange DHCP 247 messages on the DHCP UDP ports 67 and 68. 248 Mode: Relay agents and servers use transport mode and ESP [3]. 249 The information in DHCP messages is not generally 250 considered confidential, so encryption need not be used 251 (i.e., NULL encryption can be used). 252 Key management: Because the relay agents and servers are used within 253 an organization, public key schemes are not necessary. 254 Because the relay agents and servers must be manually 255 configured, manually configured key management may 256 suffice, but does not provide defense against replayed 257 messages. Accordingly, if replay protection is required, 258 IKE [4] with preshared secrets must be used. IKE with 259 public keys may be used. 260 Security policy: DHCP messages between relay agents and servers 261 should only be accepted from DHCP peers as identified in 262 the local configuration. 263 Authentication: Shared keys, indexed to the source IP address of the 264 received DHCP message, are adequate in this application. 265 Availability: Appropriate IPsec implementations are likely to be 266 available for servers and for relay agents in more 267 featureful devices used in enterprise and core ISP 268 networks. IPsec is less likely to be available for relay 269 agents in low end devices primarily used in the home or 270 small office markets. 272 6. IANA Considerations 274 There are no IANA considerations for the authentication mechanisms 275 described in this document. 277 7. Security Considerations 279 The threat model for messages exchanged between DHCP relay agents and 280 DHCP servers is described in Section 4. In Section 5, this 281 specification describes a mechanism that can be used to provide 282 authentication and message integrity protection to the messages 283 between DHCP relay agents and DHCP servers. 285 The use of IPsec for securing relay agent options in DHCP messages 286 requires: 287 o the existence of an IPsec implementation available to the relay 288 agents and DHCP servers 289 o that the DHCP relay agents and servers be under appropriate 290 administrative control so that IPsec sessions can be established 291 among the relay agents and servers 292 o manual configuration of the participants, including manual 293 distribution of key 295 The dhc WG has developed two documents describing authentication of 296 DHCP relay agent options to accommodate the requirements of different 297 deployment scenarios: this document and "The Authentication Suboption 298 for the DHCP Relay Agent Option" [12]. In deployments where IPsec is 299 readily available and pairwise keys can be managed efficiently, the 300 use of IPsec as described in this document may be appropriate. If 301 IPsec is not available or there are multiple relay agents for which 302 multiple keys must be managed, the protocol described in "The 303 Authentication Suboption for the DHCP Relay Agent Option" may be 304 appropriate. As is the case whenever two alternatives are available, 305 local network administration can choose whichever is more 306 appropriate. Because the relay agents and the DHCP server are all in 307 the same administrative domain, the appropriate mechanism can be 308 configured on all interoperating DHCP server elements. 310 8. Acknowledgments 312 The need for this specification was made clear by comments made by 313 Thomas Narten and John Schnizlein at IETF 53. 315 9. References 317 9.1 Normative references 319 [1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 320 January 2001. 322 [2] Kent, S. and R. Atkinson, "Security Architecture for the 323 Internet Protocol", RFC 2401, November 1998. 325 [3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 326 (ESP)", RFC 2406, November 1998. 328 [4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 329 RFC 2409, November 1998. 331 9.2 Informative References 333 [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 334 March 1997. 336 [6] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 337 September 1985. 339 [7] Wimer, W., "Clarifications and Extensions for the Bootstrap 340 Protocol", RFC 1542, October 1993. 342 [8] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 343 RFC 3118, June 2001. 345 [9] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable Service 346 Interface Specifications) Device Class DHCP (Dynamic Host 347 Configuration Protocol) Relay Agent Information Sub-option", 348 RFC 3256, April 2002. 350 [10] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, "Link 351 Selection sub-option for the Relay Agent Information Option for 352 DHCPv4", RFC 3527, April 2003. 354 [11] Droms, R. and J. Schnizlein, "RADIUS Attributes Sub-option for 355 the DHCP Relay Agent Information Option", 356 draft-ietf-dhc-agentopt-radius-08 (work in progress), 357 September 2004. 359 [12] Stapp, M. and T. Lemon, "The Authentication Suboption for the 360 DHCP Relay Agent Option", draft-ietf-dhc-auth-suboption-05 361 (work in progress), August 2004. 363 Author's Address 365 Ralph Droms 366 Cisco Systems, Inc. 367 1414 Massachusetts Ave. 368 Boxborough, MA 01719 369 USA 371 Phone: +1 978.936.1674 372 Email: rdroms@cisco.com 374 Intellectual Property Statement 376 The IETF takes no position regarding the validity or scope of any 377 Intellectual Property Rights or other rights that might be claimed to 378 pertain to the implementation or use of the technology described in 379 this document or the extent to which any license under such rights 380 might or might not be available; nor does it represent that it has 381 made any independent effort to identify any such rights. Information 382 on the procedures with respect to rights in RFC documents can be 383 found in BCP 78 and BCP 79. 385 Copies of IPR disclosures made to the IETF Secretariat and any 386 assurances of licenses to be made available, or the result of an 387 attempt made to obtain a general license or permission for the use of 388 such proprietary rights by implementers or users of this 389 specification can be obtained from the IETF on-line IPR repository at 390 http://www.ietf.org/ipr. 392 The IETF invites any interested party to bring to its attention any 393 copyrights, patents or patent applications, or other proprietary 394 rights that may cover technology that may be required to implement 395 this standard. Please address the information to the IETF at 396 ietf-ipr@ietf.org. 398 Disclaimer of Validity 400 This document and the information contained herein are provided on an 401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 403 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 404 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 405 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 408 Copyright Statement 410 Copyright (C) The Internet Society (2005). This document is subject 411 to the rights, licenses and restrictions contained in BCP 78, and 412 except as set forth therein, the authors retain all their rights. 414 Acknowledgment 416 Funding for the RFC Editor function is currently provided by the 417 Internet Society.