idnits 2.17.1 draft-ietf-dhc-auth-suboption-05.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.5 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 639. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 655), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 (August 9, 2004) is 7197 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 3174 (ref. '4') ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '10') (Obsoleted by RFC 8945) -- No information found for draft-ietf-dhc-relay-agent-ipsec- - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group M. Stapp 2 Internet-Draft Cisco Systems, Inc. 3 Expires: February 7, 2005 T. Lemon 4 Nominum, Inc. 5 August 9, 2004 7 The Authentication Suboption for the DHCP Relay Agent Option 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3667. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-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 http:// 27 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 February 7, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 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 an authentication suboption for that option, 43 containing a keyed hash in its payload. The suboption supports data 44 integrity and replay protection for relayed DHCP messages. 46 Table of Contents 48 1. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 49 2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4 52 5. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5 53 6. The Relay Identifier Field . . . . . . . . . . . . . . . . . 5 54 7. Computing Authentication Information . . . . . . . . . . . . 6 55 7.1 The HMAC-SHA1 Algorithm . . . . . . . . . . . . . . . . . 6 56 8. Procedures for Sending Messages . . . . . . . . . . . . . . 7 57 8.1 Replay Detection . . . . . . . . . . . . . . . . . . . . . 7 58 8.2 Packet Preparation . . . . . . . . . . . . . . . . . . . . 8 59 8.3 Checksum Computation . . . . . . . . . . . . . . . . . . . 8 60 8.4 Sending the Message . . . . . . . . . . . . . . . . . . . 8 61 9. Procedures for Processing Incoming Messages . . . . . . . . 8 62 9.1 Initial Examination . . . . . . . . . . . . . . . . . . . 8 63 9.2 Replay Detection Check . . . . . . . . . . . . . . . . . . 9 64 9.3 Testing the Checksum . . . . . . . . . . . . . . . . . . . 9 65 10. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 9 66 10.1 Receiving Messages from Other Relay Agents . . . . . . . 10 67 10.2 Sending Messages to Servers . . . . . . . . . . . . . . 10 68 10.3 Receiving Messages from Servers . . . . . . . . . . . . 10 69 11. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 10 70 11.1 Receiving Messages from Relay Agents . . . . . . . . . . 10 71 11.2 Sending Reply Messages to Relay Agents . . . . . . . . . 10 72 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11 73 13. Security Considerations . . . . . . . . . . . . . . . . . . 11 74 13.1 The Key ID Field . . . . . . . . . . . . . . . . . . . . 12 75 13.2 Protocol Vulnerabilities . . . . . . . . . . . . . . . . 12 76 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 Normative References . . . . . . . . . . . . . . . . . . . . 13 78 Informative References . . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 80 Intellectual Property and Copyright Statements . . . . . . . 15 82 1. Requirements Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [2]. 88 2. DHCP Terminology 90 This document uses the terms "DHCP server" (or "server") and "DHCP 91 client" (or "client") as defined in RFC 2131 [6]. The term "DHCP 92 relay agent" refers to a "BOOTP relay agent" as defined in RFC 2131. 94 3. Introduction 96 DHCP (RFC 2131 [6]) provides IP addresses and configuration 97 information for IPv4 clients. It includes a relay-agent capability 98 (RFC 951 [7], RFC 1542 [8]), in which processes within the network 99 infrastructure receive broadcast messages from clients and forward 100 them to servers as unicast messages. In network environments like 101 DOCSIS data-over-cable and xDSL, for example, it has proven useful 102 for the relay agent to add information to the DHCP message before 103 forwarding it, using the relay-agent information option (RFC 3046 104 [1]). The kind of information that relays add is often used in the 105 server's decision making about the addresses and configuration 106 parameters that the client should receive. The way that the 107 relay-agent data is used in server decision-making tends to make that 108 data very important, and highlights the importance of the trust 109 relationship between the relay agent and the server. 111 The existing DHCP Authentication specification (RFC 3118) [9] only 112 covers communication between the DHCP client and server. Because 113 relay-agent information is added after the client has sent its 114 message, the DHCP Authentication specification explictly excludes 115 relay-agent data from that authentication. 117 The goal of this specification is to define methods that a relay 118 agent can use to: 119 1. protect the integrity of relayed DHCP messages 120 2. provide replay protection for those messages 121 3. leverage existing mechanisms such as DHCP Authentication 123 In order to meet these goals, we specify a new relay-agent suboption, 124 the Authentication suboption. The format of this suboption is very 125 similar to the format of the DHCP Authentication option, and the 126 specification of the cryptographic methods and hash computation for 127 the suboption are also similar to that specification. 129 The Authentication suboption is included by relay agents that wish to 130 ensure the integrity of the data they include in the Relay Agent 131 option. These relay agents are configured with the parameters 132 necessary to generate cryptographic checksums of the data in the DHCP 133 messages which they forward to DHCP servers. A DHCP server configured 134 to process the Authentication suboption uses the information in the 135 suboption to verify the checksum in the suboption, and continues 136 processing the relay agent information option only if the checksum is 137 valid. If the DHCP server sends a response, it includes an 138 Authentication suboption in its response message. Relay agents test 139 the checksums in DHCP server responses to decide whether to forward 140 the responses. 142 4. Suboption Format 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Code | Length | Algorithm | MBZ | RDM | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Replay Detection (64 bits) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Replay Detection cont. | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Relay Identifier | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | | 156 | | 157 | Authentication Information | 158 | | 159 | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 The code for the suboption is TBD. The length field includes the 163 lengths of the algorithm, RDM, and all subsequent suboption fields in 164 octets. 166 The Algorithm field defines the algorithm used to generate the 167 authentication information. 169 Four bits are reserved for future use. These bits SHOULD be set to 170 zero, and MUST be not be used when the suboption is processed. 172 The Replay Detection Method (RDM) field defines the method used to 173 generate the Replay Detection Data. 175 The Replay Detection field contains a value used to detect replayed 176 messages, interpreted according to the RDM. 178 The Relay Identifier field is used by relay agents that do not set 179 giaddr, as described in RFC 3046 [1], Section 2.1. 181 The Authentication Information field contains the data required to 182 communicate algorithm-specific parameters, as well as the checksum. 183 The checksum is usually a digest of the data in the DHCP packet 184 computed using the method specified by the Algorithm field. 186 5. Replay Detection 188 The replay-detection mechanism is based on the notion that a receiver 189 can determine whether or not a message has a valid replay token 190 value. The default RDM, with value 1, specifies that the Replay 191 Detection field contains an increasing counter value. The receiver 192 associates a replay counter with each sender, and rejects any message 193 containing an authentication suboption with a Replay Detection 194 counter value less than or equal to the last valid value. DHCP 195 servers MAY identify relay agents by giaddr value or by other data in 196 the message (e.g. data in other relay agent suboptions). Relay agents 197 identify DHCP servers by source IP address. If the message's replay 198 detection value is valid, and the checksum is also valid, the 199 receiver updates its notion of the last valid replay counter value 200 associated with the sender. 202 All implementations MUST support the default RDM. Additional methods 203 may be defined in the future, following the process described in 204 Section 12. 206 Receivers SHOULD perform the replay-detection check before testing 207 the checksum. The keyed hash calculation is likely to be much more 208 expensive than the replay-detection value check. 210 DISCUSSION: 211 This places a burden on the receiver to maintain some run-time 212 state (the most-recent valid counter value) for each sender, but 213 the number of members in a DHCP agent-server system is unlikely to 214 be unmanageably large. 216 6. The Relay Identifier Field 218 The Relay Agent Information Option [1] specification permits a relay 219 agent to add a relay agent option to relayed messages without setting 220 the giaddr field. In this case, the eventual receiver of the message 221 needs a stable identifier to use in order to associate per-sender 222 state such as Key ID and replay-detection counters. 224 A relay agent that adds a relay agent information option and sets 225 giaddr MUST NOT set the Relay ID field. A relay agent that does not 226 set giaddr MAY be configured to place a value in the Relay ID field. 227 If the relay agent is configured to use the Relay ID field, it MAY be 228 configured with a value to use, or it MAY be configured to generate a 229 value based on some other data, such its MAC or IP addresses. If a 230 relay generates a Relay ID value it SHOULD select a value that it can 231 regenerate reliably, e.g. across reboots. 233 Servers that process an Authentication Suboption SHOULD use the 234 giaddr value to identify the sender if the giaddr field is set. 235 Servers MAY be configured to use some other data in the message to 236 identify the sender. If giaddr is not set, the server SHOULD use the 237 Relay ID field if it is non-zero. If neither the giaddr nor the Relay 238 ID field is set, the server MAY be configured to use some other data 239 in the message, or it MAY increment an error counter. 241 7. Computing Authentication Information 243 The Authentication Information field contains a keyed hash, generated 244 by the sender. All algorithms are defined to process the data in the 245 DHCP messages in the same way. The sender and receiver compute a hash 246 across a buffer containing all of the bytes in the DHCP message, 247 including the fixed DHCP message header, the DHCP options, and the 248 relay agent suboptions, with the following exceptions. The value of 249 the 'hops' field MUST be set to zero for the computation, because its 250 value may be changed in transmission. The value of the 'giaddr' field 251 MUST also be set to zero for the computation because it may be 252 modified in networks where one relay agent adds the relay agent 253 option but another relay agent sets 'giaddr' (see RFC 3046, section 254 2.1). In addition, because the relay agent option itself is included 255 in the computation, the 'authentication information' field in the 256 Authentication suboption is set to all zeroes. The relay agent option 257 length, the Authentication suboption length and other Authentication 258 suboption fields are all included in the computation. 260 All implementations MUST support Algorithm 1, the HMAC-SHA1 261 algorithm. Additional algorithms may be defined in the future, 262 following the process described in Section 12. 264 7.1 The HMAC-SHA1 Algorithm 266 Algorithm 1 is assigned to the HMAC [3] protocol, using the SHA-1 [4] 267 hash function. This algorithm requires that a shared secret key be 268 configured at the relay agent and the DHCP server. A 32-bit Key 269 Identifier is associated with each shared key, and this identifier is 270 carried in the first 4 bytes of the Authentication Information field 271 of the Authentication suboption. The HMAC-SHA1 computation generates 272 a 20-byte hash value, which is placed in the Authentication 273 Information field after the Key ID. 275 The format of the Authentication suboption when Algorithm 1 is used 276 is: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Code | 38 |0 0 0 0 0 0 0 1| MBZ | RDM | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Replay Detection (64 bits) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Replay Detection cont. | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Relay Identifier | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Key ID (32 bits) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 | HMAC-SHA1 (160 bits) | 293 | | 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 The suboption length is 38. The RDM and Replay Detection fields are 298 as specified in Section 5. The Relay ID field is set as specified in 299 Section 6. The Key ID is set by the sender to the ID of the key used 300 in computing the checksum, as an integer value in network byte-order. 301 The HMAC result follows the Key ID. 303 The Key ID exists only to allow the sender and receiver to specify a 304 shared secret in cases where more than one secret is in use among a 305 network's relays and DHCP servers. The Key ID values are entirely a 306 matter of local configuration; they only need to be locally unique. 307 This specification does not define any semantics or impose any 308 requirements on this algorithm's Key ID values. 310 8. Procedures for Sending Messages 312 8.1 Replay Detection 314 The sender obtains a replay-detection counter value to use, based on 315 the RDM it is using. If the sender is using RDM 1, the default RDM, 316 the value MUST be greater than any previously-sent value. 318 8.2 Packet Preparation 320 The sender sets the 'giaddr' field and the 'hops' field to all 321 zeroes. The sender appends the relay agent information option to the 322 client's packet, including the Authentication suboption. The sender 323 selects an appropriate Replay Detection value. The sender places its 324 identifier into the Relay ID field, if necessary, or sets the field 325 to all zeroes. The sender sets the suboption length, places the 326 Replay Detection value into the Replay Detection field of the 327 suboption, and sets the algorithm to the algorithm number that it is 328 using. If the sender is using HMAC-SHA1, it sets the Key ID field to 329 the appropriate value. The sender sets the field which will contain 330 the checksum to all zeroes. Other algorithms may specify additional 331 preparation steps. 333 8.3 Checksum Computation 335 The sender computes the checksum across the entire DHCP message, 336 using the algorithm it has selected. The sender places the result of 337 the computation into the Authentication Information field of the 338 Authentication suboption. 340 8.4 Sending the Message 342 The sender restores the values of the 'hops' and 'giaddr' fields, and 343 sends the message. 345 9. Procedures for Processing Incoming Messages 347 9.1 Initial Examination 349 The receiver examines the message, the value of the giaddr field, and 350 determines whether the packet includes the relay agent information 351 option. The receiver uses its configuration to determine whether it 352 should expect an Authentication suboption. The receiver MUST support 353 configuration that allows it to drop incoming messages that do not 354 contain a valid relay agent information option and Authentication 355 suboption. 357 If the receiver determines that the Authentication suboption is 358 present and that it should process the suboption, it uses the data in 359 the message to determine which algorithm, key, and RDM to use in 360 validating the message. If the receiver cannot determine which 361 algorithm, key, and RDM to use, or if it does not support the value 362 indicated in the message, it SHOULD drop the message. Because this 363 situation could indicate a misconfiguration which could deny service 364 to clients, receivers MAY attempt to notify their administrators or 365 log an error message. 367 9.2 Replay Detection Check 369 The receiver examines the RDM field. Receivers MUST discard messages 370 containing RDM values that they do not support. Because this may 371 indicate a misconfiguration at the sender, an attempt SHOULD be made 372 to indicate this condition to the administrator, by incrementing an 373 error counter or writing a log message. If the receiver supports the 374 RDM, it examines the value in the Replay Detection field using the 375 procedures in the RDM and in Section 5. If the Replay value is not 376 valid, the receiver MUST drop the message. 378 Note that the receiver MUST NOT update its notion of the last valid 379 Replay Detection value for the sender at this point. Until the 380 checksum has been tested, the Replay Detection field cannot be 381 trusted. If the receiver trusts the Replay Detection value without 382 testing the checksum, a malicious host could send a replayed message 383 with a Replay Detection value that was very high, tricking the 384 receiver into rejecting legitimate values from the sender. 386 9.3 Testing the Checksum 388 The receiver prepares the packet in order to test the checksum by 389 setting the 'giaddr' and 'hops' fields to zero, and setting the 390 Authentication Information field of the suboption to all zeroes. 391 Using the algorithm and key associated with the sender, the receiver 392 computes a hash of the message. The receiver compares the result of 393 its computation with the value sent by the sender. If the checksums 394 do not match, the receiver MUST drop the message. Otherwise, the 395 receiver updates its notion of the last valid Replay Detection value 396 associated with the sender, and processes the message. 398 10. Relay Agent Behavior 400 DHCP Relay agents are typically configured with the addresses of one 401 or more DHCP servers. A relay agent that implements this suboption 402 requires an algorithm number for each server, as well as appropriate 403 credentials (i.e. keys) to use. Relay implementations SHOULD support 404 configuration which indicates that all relayed messages should 405 include the authentication suboption. Use of the authentication 406 suboption SHOULD be disabled by default. Relay agents MAY support 407 configuration that indicates that certain destination servers support 408 the authentication suboption, while other servers do not. Relay 409 agents MAY support configuration of a single algorithm number and key 410 to be used with all DHCP servers, or they MAY support configuration 411 of different algorithms and keys for each server. 413 10.1 Receiving Messages from Other Relay Agents 415 There are network configurations in which one relay agent adds the 416 relay agent option, and then forwards the DHCP message to another 417 relay agent. For example, a layer-2 switch might be directly 418 connected to a client, and it might forward messages to an 419 aggregating router, which sets giaddr and then forwards the message 420 to a DHCP server. When a DHCP relay which implements the 421 Authentication suboption receives a message, it MAY use the 422 procedures in Section 9 to verify the source of the message before 423 forwarding it. 425 10.2 Sending Messages to Servers 427 When the relay agent receives a broadcast packet from a client, it 428 determines which DHCP servers (or other relay agents) should receive 429 copies of the message. If the relay agent is configured to include 430 the Authentication suboption, it determines which Algorithm and RDM 431 to use, and then it performs the steps in Section 8. 433 10.3 Receiving Messages from Servers 435 When the relay agent receives a message, it determines from its 436 configuration whether it expects the message to contain a relay agent 437 information option and an Authentication suboption. The relay agent 438 MAY be configured to drop response messages that do not contain the 439 Authentication suboption. The relay agent then follows the procedures 440 in Section 9. 442 11. DHCP Server Behavior 444 DHCP servers may interact with multiple relay agents. Server 445 implementations MAY support configuration that associates the same 446 algorithm and key with all relay agents. Servers MAY support 447 configuration which specifies the algorithm and key to use with each 448 relay agent individually. 450 11.1 Receiving Messages from Relay Agents 452 When a DHCP server which implements the Authentication suboption 453 receives a message, it performs the steps in Section 9. 455 11.2 Sending Reply Messages to Relay Agents 457 When the server has prepared a reply message, it uses the incoming 458 request message and its configuration to determine whether it should 459 include a relay agent information option and an Authentication 460 suboption. If the server is configured to include the Authentication 461 suboption, it determines which Algorithm and RDM to use, and then 462 performs the steps in Section 8. 464 DISCUSSION: 465 This server behavior represents a slight variance from RFC 3046 466 [1], Section 2.2. The Authentication suboption is not echoed back 467 from the server to the relay: the server generates its own 468 suboption. 470 12. IANA Considerations 472 Section 4 defines a new suboption for the DHCP relay agent option, 473 called the Authentication Suboption. IANA is requested to allocate a 474 new suboption code from the relay agent option suboption number 475 space. 477 This specification introduces two new number-spaces for the 478 Authentication suboption's 'Algorithm' and 'Replay Detection Method' 479 fields. These number spaces are to be created and maintained by IANA. 481 The Algorithm identifier is a one-byte value. Algorithm value 0 is 482 reserved. Algorithm value 1 is assigned to the HMAC-SHA1 keyed hash 483 as defined in Section 7.1. Additional algorithm values will be 484 allocated and assigned through IETF consensus, as defined in RFC 2434 485 [5]. 487 The RDM identifier is a four-bit value. RDM value 0 is reserved. RDM 488 value 1 is assigned to the use of a monotonically increasing counter 489 value as defined in Section 5. Additional RDM values will be 490 allocated and assigned through IETF consensus, as defined in RFC 2434 491 [5]. 493 13. Security Considerations 495 This specification describes a protocol to add source authentication 496 and message integrity protection to the messages between DHCP relay 497 agents and DHCP servers. 499 The use of this protocol imposes a new computational burden on relay 500 agents and servers, because they must perform cryptographic hash 501 calculations when they send and receive messages. This burden may add 502 latency to DHCP message exchanges. Because relay agents are involved 503 when clients reboot, periods of very high reboot activity will result 504 in the largest number of messages which have to be processed. During 505 a cable MSO head-end reboot event, for example, the time required for 506 all clients to be served may increase. 508 13.1 The Key ID Field 510 The Authentication suboption contains a four-byte Key ID, following 511 the example of the DHCP Authentication RFC. Other authentication 512 protocols, like DNS TSIG [10], use a key name. A key name is more 513 flexible and potentially more human-readable than a key id. DHCP 514 servers may well be configured to use key names for DNS updates using 515 TSIG, so it might simplify DHCP server configuration if some of the 516 key-management for both protocols could be shared. 518 On the other hand, it is crucial to minimize the size expansion 519 caused by the introduction of the relay agent information option. 520 Named keys would require more physical space, and would entail more 521 complex suboption encoding and parsing implementations. These 522 considerations have led us to specify a fixed-length Key ID instead 523 of a variable-length key name. 525 13.2 Protocol Vulnerabilities 527 Because DHCP is a UDP protocol, messages between relays and servers 528 may be delivered in a different order than the order in which they 529 were generated. The replay-detection mechanism will cause receivers 530 to drop packets which are delivered 'late', leading to client 531 retries. The retry mechanisms which most clients implement should not 532 cause this to be an enormous issue, but it will cause senders to do 533 computational work which will be wasted if their messages are 534 re-ordered. 536 The DHC WG has developed two documents describing authentication of 537 DHCP relay agent options to accommodate the requirements of different 538 deployment scenarios: this document and Authentication of Relay Agent 539 Options Using IPsec [11]. As we note in Section 11, the 540 Authentication suboption can be used without pairwise keys between 541 each relay and each DHCP server. In deployments where IPsec is 542 readily available and pairwise keys can be managed efficiently, the 543 use of IPsec as described in that document may be appropriate. If 544 IPsec is not available or there are multiple relay agents for which 545 multiple keys must be managed, the protocol described in this 546 document may be appropriate. As is the case whenever two 547 alternatives are available, local network administration can choose 548 whichever is more appropriate. Because the relay agents and the DHCP 549 server are all in the same administrative domain, the appropriate 550 mechanism can be configured on all interoperating DHCP server 551 elements. 553 14. Acknowledgements 555 The need for this specification was made clear by comments made by 556 Thomas Narten and John Schnizlein, and the use of the DHCP 557 Authentication option format was suggested by Josh Littlefield, at 558 IETF 53. 560 Normative References 562 [1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 563 January 2001. 565 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 566 Levels", RFC 2119, March 1997. 568 [3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 569 for Message Authentication", RFC 2104, February 1997. 571 [4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 572 RFC 3174, September 2001. 574 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 575 Considerations Section in RFCs", RFC 2434, October 1998. 577 Informative References 579 [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 580 March 1997. 582 [7] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 583 September 1985. 585 [8] Wimer, W., "Clarifications and Extensions for the Bootstrap 586 Protocol", RFC 1542, October 1993. 588 [9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 589 RFC 3118, June 2001. 591 [10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 592 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 593 2845, May 2000. 595 [11] Droms, R., "Authentication of Relay Agent Options Using IPsec 596 (draft-ietf-dhc-relay-agent-ipsec-*.txt)", February 2004. 598 Authors' Addresses 600 Mark Stapp 601 Cisco Systems, Inc. 602 1414 Massachusetts Ave. 603 Boxborough, MA 01719 604 USA 606 Phone: 978.936.0000 607 EMail: mjs@cisco.com 609 Ted Lemon 610 Nominum, Inc. 611 950 Charter St. 612 Redwood City, CA 94063 613 USA 615 EMail: Ted.Lemon@nominum.com 617 Intellectual Property Statement 619 The IETF takes no position regarding the validity or scope of any 620 Intellectual Property Rights or other rights that might be claimed to 621 pertain to the implementation or use of the technology described in 622 this document or the extent to which any license under such rights 623 might or might not be available; nor does it represent that it has 624 made any independent effort to identify any such rights. Information 625 on the IETF's procedures with respect to rights in IETF Documents can 626 be found in BCP 78 and BCP 79. 628 Copies of IPR disclosures made to the IETF Secretariat and any 629 assurances of licenses to be made available, or the result of an 630 attempt made to obtain a general license or permission for the use of 631 such proprietary rights by implementers or users of this 632 specification can be obtained from the IETF on-line IPR repository at 633 http://www.ietf.org/ipr. 635 The IETF invites any interested party to bring to its attention any 636 copyrights, patents or patent applications, or other proprietary 637 rights that may cover technology that may be required to implement 638 this standard. Please address the information to the IETF at 639 ietf-ipr@ietf.org. 641 Disclaimer of Validity 643 This document and the information contained herein are provided on an 644 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 645 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 646 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 647 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 648 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 649 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 651 Copyright Statement 653 Copyright (C) The Internet Society (2004). This document is subject 654 to the rights, licenses and restrictions contained in BCP 78, and 655 except as set forth therein, the authors retain all their rights. 657 Acknowledgment 659 Funding for the RFC Editor function is currently provided by the 660 Internet Society.