idnits 2.17.1 draft-ietf-dhc-relay-agent-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 (June 7, 2003) is 7627 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '4') ** Obsolete normative reference: RFC 2401 (ref. '5') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. '6') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2434 (ref. '7') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '12') (Obsoleted by RFC 8945) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Stapp 3 Internet-Draft Cisco Systems, Inc. 4 Expires: December 6, 2003 T. Lemon 5 Nominum, Inc. 6 R. Droms 7 Cisco Systems, Inc. 8 June 7, 2003 10 The Authentication Suboption for the DHCP Relay Agent Option 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 6, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 The DHCP Relay Agent Information Option (RFC 3046) conveys 43 information between a DHCP relay agent and a DHCP server. This 44 specification defines two mechanisms for securing the messages 45 exchanged between a relay agent and a server. The first mechanism 46 defines a new authentication suboption for the Relay Agent 47 Information Option that supports source entity authentication and 48 data integrity for relayed DHCP messages. The authentication 49 suboption contains a cryptographic signature in a payload derived 50 from the option used in DHCP Authentication (RFC 3118). The second 51 mechanism uses IPsec (RFC 2401) to protect messages exchanged between 52 relay agents and servers. 54 Table of Contents 56 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 57 2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Relay Agent Option Authentication Sub-option . . . . . . . . 4 60 4.1 Suboption Format . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 6 62 4.3 The Relay Identifier Field . . . . . . . . . . . . . . . . . 6 63 4.4 Computing Authentication Information . . . . . . . . . . . . 7 64 4.4.1 The HMAC-MD5 Algorithm . . . . . . . . . . . . . . . . . . . 7 65 4.5 Procedures for Sending Messages . . . . . . . . . . . . . . 9 66 4.5.1 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 9 67 4.5.2 Packet Preparation . . . . . . . . . . . . . . . . . . . . . 9 68 4.5.3 Signature Computation . . . . . . . . . . . . . . . . . . . 9 69 4.5.4 Sending the Message . . . . . . . . . . . . . . . . . . . . 9 70 4.6 Procedures for Processing Incoming Messages . . . . . . . . 9 71 4.6.1 Initial Examination . . . . . . . . . . . . . . . . . . . . 9 72 4.6.2 Replay Detection Check . . . . . . . . . . . . . . . . . . . 10 73 4.6.3 Signature Check . . . . . . . . . . . . . . . . . . . . . . 10 74 4.7 Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 10 75 4.7.1 Receiving Messages from Other Relay Agents . . . . . . . . . 11 76 4.7.2 Sending Messages to Servers . . . . . . . . . . . . . . . . 11 77 4.7.3 Receiving Messages from Servers . . . . . . . . . . . . . . 11 78 4.8 DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 11 79 4.8.1 Receiving Messages from Relay Agents . . . . . . . . . . . . 12 80 4.8.2 Sending Reply Messages to Relay Agents . . . . . . . . . . . 12 81 5. Use of IPsec to secure DHCP messages . . . . . . . . . . . . 12 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 83 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 84 7.1 Authentication sub-option Protocol Considerations . . . . . 13 85 7.2 IPsec Considerations . . . . . . . . . . . . . . . . . . . . 14 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 87 References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 90 Full Copyright Statement . . . . . . . . . . . . . . . . . . 16 92 1. Requirements Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [1]. 98 2. DHCP Terminology 100 This document uses the terms "DHCP server" (or "server") and "DHCP 101 client" (or "client") as defined in RFC 2131. The term "DHCP relay 102 agent" refers to a "BOOTP relay agent" as defined in RFC 2131. 104 3. Introduction 106 DHCP (RFC 2131 [8]) provides IP addresses and configuration 107 information for DHCP clients. It includes a relay agent capability 108 (RFC 951 [9], RFC 1542 [10]), in which processes within the network 109 infrastructure receive broadcast messages from clients and forward 110 them to servers as unicast messages. In network environments like 111 DOCSIS data-over-cable and xDSL, for example, it has proven useful 112 for the relay agent to add information to the DHCP message before 113 forwarding it, using the relay agent information option, RFC 3046 114 [2]. The kind of information that a relay agent adds is often used 115 in the server's decision making about the addresses and configuration 116 parameters that the client should receive. The way that the relay 117 agent data is used in server decision-making tends to make that data 118 very important, and highlights the importance of the trust 119 relationship between the relay agent and the server. 121 The existing DHCP Authentication specification (RFC 3118) [11] only 122 secures communication between the DHCP client and server. Because 123 relay agent information is added after the client has signed its 124 message, the DHCP Authentication specification explictly excludes 125 relay agent data from that authentication. 127 The goals of this specification is to define methods that a relay 128 agent can use to: 130 1. protect the integrity of the data that the relay adds 132 2. provide replay protection for that data 134 3. leverage existing mechanisms such as DHCP Authentication and 135 IPsec 137 The first mechanism defined to meet these goals specifies a new relay 138 agent suboption, the Authentication suboption. The format of this 139 suboption is very similar to the format of the DHCP Authentication 140 option, and the specification of the cryptographic methods and 141 signature computation for the suboption are also similar to that 142 option's specification. 144 The Authentication suboption is included by relay agents that wish to 145 ensure the integrity of the data they include in the Relay Agent 146 option. These relay agents are configured with the parameters 147 necessary to generate cryptographically strong signatures of the data 148 in the DHCP messages which they forward to DHCP servers. A DHCP 149 server configured to process the Authentication suboption uses the 150 information in the suboption to validate the signature in the 151 suboption, and continues processing the relay agent information 152 option only if the signature is valid. If the DHCP server sends a 153 response, it includes an Authentication suboption in its response 154 message, signing the data in its message. Relay agents check the 155 signatures in DHCP server responses and decide whether to forward the 156 responses based on the signatures' validity. 158 The second mechanism specifies the use of IPsec between relay agents 159 and servers to autenticate the identity of the source and contents of 160 messages carrying relay agent options. 162 4. Relay Agent Option Authentication Sub-option 164 The Relay Agent Option Authentication Sub-option, described in this 165 section of the document, provides identity authentication, detection 166 of modification of message contents and protection against message 167 replay. 169 4.1 Suboption Format 171 0 1 2 3 172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Code | Length | Algorithm | MBZ | RDM | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Replay Detection (64 bits) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Replay Detection cont. | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Relay Identifier | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 | | 184 | Authentication Information | 185 | | 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 The code for the suboption is TBD. The length field includes the 190 lengths of the algorithm, RDM, and all subsequent suboption fields in 191 octets. 193 The Algorithm field defines the algorithm used to generate the 194 authentication information. 196 Four bits are reserved for future use. These bits SHOULD be set to 197 zero, and MUST be ignored when the suboption is processed. 199 The Replay Detection Method (RDM) field defines the method used to 200 generate the Replay Detection Data. 202 The Replay Detection field contains a value used to detect replayed 203 messages, interpreted according to the RDM. 205 The Relay Identifier field is used by relay agents that do not set 206 giaddr, as described in RFC 3046 [2], Section 2.1. 208 The Authentication Information field contains the data required to 209 communicate algorithm-specific parameters, as well as the signature. 210 The signature is usually a digest of the data in the DHCP packet 211 computed using the method specified by the Algorithm field. 213 4.2 Replay Detection 215 The replay-detection mechanism is based on the notion that a receiver 216 can determine whether or not a message has a valid replay token 217 value. The default RDM, with value 1, specifies that the Replay 218 Detection field contains an increasing counter value. The receiver 219 associates a replay counter with each sender, and rejects any message 220 containing an authentication suboption with a Replay Detection 221 counter value less than the last valid value. DHCP servers MAY 222 identify relay agents by giaddr value or by other data in the message 223 (e.g. data in other relay agent suboptions). Relay agents identify 224 DHCP servers by source IP address. If the message's replay detection 225 value is valid, and the signature is also valid, the receiver updates 226 the its notion of the last valid replay counter value associated with 227 the sender. 229 All implementations MUST support the default RDM. Additional methods 230 may be defined in the future, following the process described in 231 Section 6. 233 Receivers SHOULD perform the replay-detection check before validating 234 the signature. The authentication hash calculation is likely to be 235 much more expensive than the replay-detection value check. 237 DISCUSSION: 239 This places a burden on the receiver to maintain some run-time 240 state (the most-recent valid counter value) for each sender, but 241 the number of members in a DHCP agent-server system is unlikely to 242 be unmanageably large. 244 4.3 The Relay Identifier Field 246 The Relay Agent Information Option [2] specification permits a relay 247 agent to add a relay agent option to relayed messages without setting 248 the giaddr field. In this case, the eventual receiver of the message 249 needs a stable identifier to use in order to associate per-sender 250 state such as Key ID and replay-detection counters. 252 A relay agent that adds a relay agent information option and sets 253 giaddr MUST NOT set the Relay ID field. A relay agent that does not 254 set giaddr MAY be configured to place a value in the Relay ID field. 255 If the relay agent is configured to use the Relay ID field, it MAY be 256 configured with a value to use, or it MAY be configured to generate a 257 value based on some other data, such its MAC or IP addresses. If a 258 relay agent generates a Relay ID value it SHOULD select a value that 259 it can regenerate reliably, e.g. across reboots. 261 Servers that process an Authentication Suboption SHOULD use the 262 giaddr value to identify the sender if the giaddr field is set. 263 Servers MAY be configured to use some other data in the message to 264 identify the signer. If giaddr is not set, the server SHOULD use the 265 Relay ID field if it is non-zero. If neither the giaddr nor the 266 Relay ID field is set, the server MAY be configured to use some other 267 data in the message, or it MAY increment an error counter. 269 4.4 Computing Authentication Information 271 The Authentication Information field contains a computed signature, 272 generated by the sender. All algorithms are defined to process the 273 data in the DHCP messages in the same way. The sender and receiver 274 compute the signature across a buffer containing all of the bytes in 275 the DHCP message, including the fixed DHCP message header, the DHCP 276 options, and the relay agent suboptions, with the following 277 exceptions. The value of the 'hops' field MUST be set to zero for 278 the computation, because its value may be changed in transmission. 279 The value of the 'giaddr' field MUST also be set to sero for the 280 computation because it may be modified in networks where one relay 281 agent adds the relay agent option but another relay agent sets 282 'giaddr' (see RFC 3046, section 2.1). In addition, because the relay 283 agent option itself is included in the computation, the 'signature' 284 part of the 'authentication information' field in the Authentication 285 suboption is set to all zeroes. The relay agent option length, the 286 Authentication suboption length and other Authentication suboption 287 fields are all included in the computation. 289 All implementations MUST support Algorithm 1, the HMAC-MD5 algorithm. 290 Additional algorithms may be defined in the future, following the 291 process described in Section 6. 293 4.4.1 The HMAC-MD5 Algorithm 295 Algorithm 1 is assigned to the HMAC [3] protocol, using the MD5 [4] 296 hash function. This algorithm requires that a shared secret key be 297 configured at the relay agent and the DHCP server. A 32-bit Key 298 Identifier is associated with each shared key, and this identifier is 299 carried in the first 4 bytes of the Authentication Information field 300 of the Authentication suboption. The HMAC-MD5 computation generates 301 a 16-byte signature, which is placed in the Authentication 302 Information field after the Key ID. 304 The format of the Authentication suboption when Algorithm 1 is used 305 is: 307 0 1 2 3 308 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Code | 34 |0 0 0 0 0 0 0 1| MBZ | RDM | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Replay Detection (64 bits) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Replay Detection cont. | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Relay Identifier | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Key ID (32 bits) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | | 321 | HMAC-MD5 (128 bits) | 322 | | 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 The suboption length is 34. The RDM and Replay Detection fields are 327 as specified in Section 4.2. The Relay ID field is set as specified 328 in Section 4.3. The Key ID is set by the sender to the ID of the key 329 used in computing the signature, as an integer value in network byte- 330 order. The HMAC signature follows the Key ID. 332 The Key ID exists only to allow the sender and receiver to specify a 333 shared secret in cases where more than one secret is in use among a 334 network's relays and DHCP servers. The Key ID values are entirely a 335 matter of local configuration; they only need to be locally unique. 336 This specification does not define any semantics or impose any 337 requirements on this algorithm's Key ID values. 339 DISCUSSION: 341 We specify a four-byte Key ID, following the example of the DHCP 342 Authentication RFC. Other authentication protocols, like DNS TSIG 343 [12], use a key name. A key name is more flexible and potentially 344 more human-readable than a key id. DHCP servers may well be 345 configured to use key names for DNS updates using TSIG, so it 346 might simplify DHCP server configuration if some of the key- 347 management for both protocols could be shared. 349 On the other hand, it is crucial to minimize the size expansion 350 caused by the introduction of the relay agent information option. 351 Named keys would require more physical space, and would entail 352 more complex suboption encoding and parsing implementations. 354 These considerations have led us to specify a fixed-length Key ID 355 instead of a variable-length key name. 357 4.5 Procedures for Sending Messages 359 4.5.1 Replay Detection 361 The sender obtains a replay-detection counter value to use, based on 362 the RDM it is using. If the sender is using RDM 1, the default RDM, 363 the value MUST be greater than any previously-sent value. 365 4.5.2 Packet Preparation 367 The sender sets the 'giaddr' field and the 'hops' field to all 368 zeroes. The sender appends the relay agent information option to the 369 client's packet, including the Authentication suboption. The sender 370 selects an appropriate Replay Detection value. The sender places its 371 identifier into the Relay ID field, if necessary, or sets the field 372 to all zeroes. The sender sets the suboption length, places the 373 Replay Detection value into the Replay Detection field of the 374 suboption, and sets the algorithm to the algorithm number that it is 375 using. If the sender is using HMAC-MD5, it sets the Key ID field to 376 the appropriate value. The sender sets the field which will contain 377 the signature to all zeroes. Other algorithms may specify additional 378 preparation steps. 380 4.5.3 Signature Computation 382 The sender computes the signature across the entire DHCP message, 383 using the algorithm it has selected. The sender places the result of 384 the computation into the signature field of the Authentication 385 suboption. 387 4.5.4 Sending the Message 389 The sender restores the values of the 'hops' and 'giaddr' fields, and 390 sends the message. 392 4.6 Procedures for Processing Incoming Messages 394 4.6.1 Initial Examination 396 The receiver examines the message, the value of the giaddr field, and 397 determines whether the packet includes the relay agent information 398 option. The receiver uses its configuration to determine whether it 399 should expect an Authentication suboption. The receiver MAY be 400 configured to drop incoming messages that do not contain a valid 401 relay agent information option and Authentication suboption. 403 If the receiver determines that the Authentication suboption is 404 present and that it should process the suboption, it uses the data in 405 the message to determine which algorithm, key, and RDM to use in 406 validating the message. If the receiver cannot determine which 407 algorithm, key, and RDM to use, or if it does not support the value 408 indicated in the message, it SHOULD drop the message. Because this 409 situation could indicate a misconfiguration which could deny service 410 to clients, receivers MAY attempt to notify their administrators or 411 log an error message. 413 4.6.2 Replay Detection Check 415 The receiver examines the RDM field. Receivers MUST discard messages 416 containing RDM values that they do not support. Because this may 417 indicate a misconfiguration at the sender, an attempt SHOULD be made 418 to indicate this condition to the administrator, by incrementing an 419 error counter or writing a log message. If the receiver supports the 420 RDM, it examines the value in the Replay Detection field using the 421 procedures in the RDM and in Section 4.2. If the Replay value is not 422 valid, the receiver MUST drop the message. 424 Note that the receiver MUST NOT update its notion of the last valid 425 Replay Detection value for the sender at this point. Until the 426 signature has been checked, the Replay Detection field cannot be 427 trusted. If the receiver trusts the Replay Detection value without 428 checking the signature, a malicious host could send a replayed 429 message with a Replay Detection value that was very high, tricking 430 the receiver into rejecting legitimate values from the sender. 432 4.6.3 Signature Check 434 The receiver prepares the packet in order to check the signature. 435 The receiver sets the 'giaddr' and 'hops' fields to zero, and sets 436 the signature field of the Authentication suboption to all zeroes. 437 Using the algorithm and key associated with the sender, the receiver 438 computes a hash of the message. The receiver compares the result of 439 its computation with the value sent by the sender. If the signatures 440 do not match, the receiver MUST drop the message. Otherwise, the 441 receiver updates its notion of the last valid Replay Detection value 442 associated with the sender, and processes the message. 444 4.7 Relay Agent Behavior 446 DHCP Relay agents are typically configured with the addresses of one 447 or more DHCP servers. A relay agent that implements this suboption 448 requires an algorithm number for each server, as well as appropriate 449 credentials (i.e. keys) to use. Relay implementations SHOULD 450 support configuration which indicates that all relayed messages 451 should include the authentication suboption. Use of the 452 authentication suboption SHOULD be disabled by default. Relay agents 453 MAY support configuration that indicates that certain destination 454 servers support the authentication suboption, while other servers do 455 not. Relays MAY support configuration of a single algorithm number 456 and key to be used with all DHCP servers, or they MAY support 457 configuration of different algorithms and keys for each server. 459 4.7.1 Receiving Messages from Other Relay Agents 461 There are network configurations in which one relay agent adds the 462 relay agent option, and then forwards the DHCP message to another 463 relay. For example, a layer-2 switch might be directly connected to 464 a client, and it might forward messages to an aggregating router, 465 which sets giaddr and then forwards the message to a DHCP server. 466 When a DHCP relay which implements the Authentication suboption 467 receives a message, it MAY use the procedures in Section 4.6 to 468 verify the source of the message before forwarding it. 470 4.7.2 Sending Messages to Servers 472 When the relay agent receives a broadcast packet from a client, it 473 determines which DHCP servers (or other relay agents) should receive 474 copies of the message. If the relay agent is configured to include 475 the Authentication suboption, it determines which Algorithm and RDM 476 to use, and then it performs the steps in Section 4.5. 478 4.7.3 Receiving Messages from Servers 480 When the relay agent receives a message, it determines from its 481 configuration whether it expects the message to contain a relay agent 482 information option and an Authentication suboption. The relay agent 483 MAY be configured to drop response messages that do not contain the 484 Authentication suboption. The relay agent then follows the 485 procedures in Section 4.6. 487 4.8 DHCP Server Behavior 489 DHCP servers may interact with multiple relay agents. Server 490 implementations MAY support configuration that associates the same 491 algorithm and key with all relay agents. Servers MAY support 492 configuration which specifies the algorithm and key to use with each 493 relay agent individually. 495 4.8.1 Receiving Messages from Relay Agents 497 When a DHCP server which implements the Authentication suboption 498 receives a message, it performs the steps in Section 4.6. 500 4.8.2 Sending Reply Messages to Relay Agents 502 When the server has prepared a reply message, it uses the incoming 503 request message and its configuration to determine whether it should 504 include a relay agent information option and an Authentication 505 suboption. If the server is configured to include the Authentication 506 suboption, it determines which Algorithm and RDM to use, and then 507 performs the steps in Section 4.5. 509 DISCUSSION: 511 This server behavior represents a slight variance from RFC 3046 512 [2], Section 2.2. The Authentication suboption is not echoed back 513 from the server to the relay: the server generates its own 514 suboption. 516 5. Use of IPsec to secure DHCP messages 518 Relay agents and servers that exchange messages securely can use 519 IPsec mechanisms [5] as described in this section. Relay agents and 520 servers MUST support manual configuration and installation of static 521 keys. If a client message is relayed through multiple relay agents, 522 each of the relay agents must have established independent, pairwise 523 trust relationships. That is, if messages from client C will be 524 relayed by relay agent A to relay agent B and then to the server, 525 relay agents A and B must be configured to use IPSec for the messages 526 they exchange, and relay agent B and the server must be configured to 527 use IPSec for the messages they exchange. 529 Relay agents and servers that support secure relay agent to server or 530 relay agent to relay agent communication, MUST include an IPsec 531 implementation with the following restrictions: 533 o The IPsec implementation MUST use ESP [6] 535 o Packet authentication MUST be applied 537 o Encryption MAY be applied (i.e., NULL encryption can be used) 539 6. IANA Considerations 541 Section 4.1 defines a new suboption for the DHCP relay agent option, 542 called the Authentication Suboption. IANA is requested to allocate a 543 new suboption code from the relay agent option suboption number 544 space. 546 This specification introduces two new number-spaces for the 547 Authentication suboption's 'Algorithm' and 'Replay Detection Method' 548 fields. These number spaces are to be created and maintained by 549 IANA. 551 The Algorithm identifier is a one-byte value. Algorithm value 0 is 552 reserved. Algorithm value 1 is assigned to the HMAC-MD5 signature as 553 defined in Section 4.4.1. Additional algorithm values will be 554 allocated and assigned through IETF consensus, as defined in RFC 2434 555 [7]. 557 The RDM identifier is a four-bit value. RDM value 0 is reserved. 558 RDM value 1 is assigned to the use of a monotonically increasing 559 counter value as defined in Section 4.2. Additional RDM values will 560 be allocated and assigned through IETF consensus, as defined in RFC 561 2434 [7]. 563 7. Security Considerations 565 This specification describes two mechanisms that can be used to 566 provide authentication and message integrity protection to the 567 messages between DHCP relay agents and DHCP servers. 569 The use of the authentication sub-option protocol imposes a new 570 computational burden on relay agents and servers, because they must 571 perform cryptographic hash calculations when they send and receive 572 messages. This burden may add latency to DHCP messages exchanges. 573 Because relay agents are involved when clients reboot, periods of 574 very high reboot activity will result in the largest number of 575 messages which have to be signed and verified. During a cable MSO 576 head-end reboot event, for example, the time required for all clients 577 to be served may increase. 579 7.1 Authentication sub-option Protocol Considerations 581 Because DHCP is a UDP protocol, messages between relays and servers 582 may be delivered in a different order than the order in which they 583 were generated. The replay-detection mechanism will cause receivers 584 to drop packets which are delivered 'late', leading to client 585 retries. The retry mechanisms which most clients implement should 586 not cause this to be an enormous issue, but it will cause senders to 587 do computational work which will be wasted if their messages are re- 588 ordered. 590 The authentication sub-option protocol requires configuration of 591 relay agents and servers with shared secret keys. 593 7.2 IPsec Considerations 595 The use of IPsec for securing relay agent options in DHCP messages 596 requires the existence of an IPsec implementation available to the 597 relay agents and DHCP servers. It also requires manual configuration 598 of the participants, including manual distribution of keys. 600 8. Acknowledgements 602 The need for this specification was made clear by comments made by 603 Thomas Narten and John Schnizlein, and the use of the DHCP 604 Authentication option format was suggested by Josh Littlefield, at 605 IETF 53. 607 Normative references 609 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 610 Levels", RFC 2119, March 1997. 612 [2] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 613 January 2001. 615 [3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 616 for Message Authentication", RFC 2104, February 1997. 618 [4] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 619 1992. 621 [5] Kent, S. and R. Atkinson, "Security Architecture for the 622 Internet Protocol", RFC 2401, November 1998. 624 [6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 625 (ESP)", RFC 2406, November 1998. 627 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 628 Considerations Section in RFCs", RFC 2434, October 1998. 630 Informative References 632 [8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 633 March 1997. 635 [9] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 636 September 1985. 638 [10] Wimer, W., "Clarifications and Extensions for the Bootstrap 639 Protocol", RFC 1542, October 1993. 641 [11] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 642 RFC 3118, June 2001. 644 [12] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 645 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 646 2845, May 2000. 648 Authors' Addresses 650 Mark Stapp 651 Cisco Systems, Inc. 652 1414 Massachusetts Ave. 653 Boxborough, MA 01719 654 USA 656 Phone: 978.936.1535 657 EMail: mjs@cisco.com 659 Ted Lemon 660 Nominum, Inc. 661 950 Charter St. 662 Redwood City, CA 94063 663 USA 665 EMail: mellon@nominum.com 667 Ralph Droms 668 Cisco Systems, Inc. 669 1414 Massachusetts Ave. 670 Boxborough, MA 01719 671 USA 673 Phone: +1 978.936.1674 674 EMail: rdroms@cisco.com 676 Full Copyright Statement 678 Copyright (C) The Internet Society (2003). All Rights Reserved. 680 This document and translations of it may be copied and furnished to 681 others, and derivative works that comment on or otherwise explain it 682 or assist in its implementation may be prepared, copied, published 683 and distributed, in whole or in part, without restriction of any 684 kind, provided that the above copyright notice and this paragraph are 685 included on all such copies and derivative works. However, this 686 document itself may not be modified in any way, such as by removing 687 the copyright notice or references to the Internet Society or other 688 Internet organizations, except as needed for the purpose of 689 developing Internet standards in which case the procedures for 690 copyrights defined in the Internet Standards process must be 691 followed, or as required to translate it into languages other than 692 English. 694 The limited permissions granted above are perpetual and will not be 695 revoked by the Internet Society or its successors or assigns. 697 This document and the information contained herein is provided on an 698 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 699 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 700 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 701 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 702 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 704 Acknowledgement 706 Funding for the RFC Editor function is currently provided by the 707 Internet Society.