idnits 2.17.1 draft-ietf-dhc-authentication-13.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: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 164: '...00, the replay detection field MUST be...' RFC 2119 keyword, line 168: '... method MUST be supported by all ...' RFC 2119 keyword, line 182: '... MUST be set to zero for the computa...' RFC 2119 keyword, line 186: '... the server MUST compute any hash fu...' RFC 2119 keyword, line 190: '... MUST not include the option in the ...' (37 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-authentication-12.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 'MUST not' in this paragraph: Whenever the server sends back option 82 to a relay agent, the server MUST not include the option in the computation of any hash function over the message. -- No information found for rfcdraft-ietf-dhc-authentication-12.txt - is the name correct? -- 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 (December 2000) is 8531 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 1321 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '3') ** Obsolete normative reference: RFC 1305 (ref. '4') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Droms, Editor 2 INTERNET DRAFT Bucknell University 3 Obsoletes: draft-ietf-dhc-authentication-12.txt W. Arbaugh, Editor 4 University of Maryland 5 June 2000 6 Expires December 2000 8 Authentication for DHCP Messages 9 11 Status of this memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt, and the list of 26 Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The Dynamic Host Configuration Protocol (DHCP) provides a framework 32 for passing configuration information to hosts on a TCP/IP network. 33 In some situations, network administrators may wish to constrain the 34 allocation of addresses to authorized hosts. Additionally, some 35 network administrators may wish to provide for authentication of the 36 source and contents of DHCP messages. This document defines a new 37 DHCP option through which authorization tickets can be easily 38 generated and newly attached hosts with proper authorization can be 39 automatically configured from an authenticated DHCP server. 41 1. Introduction 43 DHCP [1] transports protocol stack configuration parameters from 44 centrally administered servers to TCP/IP hosts. Among those 45 parameters are an IP address. DHCP servers can be configured to 46 dynamically allocate addresses from a pool of addresses, eliminating 47 a manual step in configuration of TCP/IP hosts. 49 Some network administrators may wish to provide authentication of the 50 source and contents of DHCP messages. For example, clients may be 51 subject to denial of service attacks through the use of bogus DHCP 52 servers, or may simply be misconfigured due to unintentionally 53 instantiated DHCP servers. Network administrators may wish to 54 constrain the allocation of addresses to authorized hosts to avoid 55 denial of service attacks in "hostile" environments where the network 56 medium is not physically secured, such as wireless networks or 57 college residence halls. 59 This document defines a technique that can provide both entity 60 authentication and message authentication. 62 DISCUSSION: 64 This draft combines the original Schiller-Huitema-Droms 65 authentication mechanism defined in a previous Internet Draft with 66 the "delayed authentication" proposal developed by Bill Arbaugh. 68 1.1 DHCP threat model 70 The threat to DHCP is inherently an insider threat (assuming a 71 properly configured network where BOOTP ports are blocked on the 72 enterprise's perimeter gateways.) Regardless of the gateway 73 configuration, however, the potential attacks by insiders and 74 outsiders are the same. 76 The attack specific to a DHCP client is the possibility of the 77 establishment of a "rogue" server with the intent of providing 78 incorrect configuration information to the client. The motivation for 79 doing so may be to establish a "man in the middle" attack or it may 80 be for a "denial of service" attack. 82 There is another threat to DHCP clients from mistakenly or 83 accidentally configured DHCP servers that answer DHCP client requests 84 with unintentionally incorrect configuration parameters. 86 The threat specific to a DHCP server is an invalid client 87 masquerading as a valid client. The motivation for this may be for 88 "theft of service", or to circumvent auditing for any number of 89 nefarious purposes. 91 The threat common to both the client and the server is the resource 92 "denial of service" (DoS) attack. These attacks typically involve the 93 exhaustion of valid addresses, or the exhaustion of CPU or network 94 bandwidth, and are present anytime there is a shared resource. In 95 current practice, redundancy mitigates DoS attacks the best. 97 1.2 Design goals 99 These are the goals that were used in the development of the 100 authentication protocol, listed in order of importance: 102 1. Address the threats presented in Section 1.1. 103 2. Avoid changing the current protocol. 104 3. Limit state required by the server. 105 4. Limit complexity (complexity breeds design and implementation 106 errors). 108 1.3 Requirements Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [5]. 114 1.4 DHCP Terminology 116 This document uses the following terms: 118 o "DHCP client" 120 A DHCP client or "client" is an Internet host using DHCP to obtain 121 configuration parameters such as a network address. 123 o "DHCP server" 125 A DHCP server or "server" is an Internet host that returns 126 configuration parameters to DHCP clients. 128 2. Format of the authentication option 130 The following diagram defines the format of the DHCP 131 authentication option: 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Code | Length | Protocol | Algorithm | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Algorithm | Replay Detection (64 bits) | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Replay cont. | | 141 +-+-+-+-+-+-+-+-+ | 142 | | 143 | Authentication Information | 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 The code for the authentication option is TBD, and the length field 148 contains the length of the protocol, RDM, algorithm, Replay Detection 149 fields and authentication information fields in octets. 151 The protocol field defines the particular technique for 152 authentication used in the option. New protocols are defined as 153 described in Section 6. 155 The algorithm field defines the specific algorithm within the 156 technique identified by the protocol field. 158 The Replay Detection field is per the RDM, and the authentication 159 information field is per the protocol in use. 161 The Replay Detection Method (RDM) field determines the type of replay 162 detection used in the Replay Detection field. 164 If the RDM field contains 0x00, the replay detection field MUST be 165 set to the value of a monotonically increasing counter. Using a 166 counter value such as the current time of day (e.g., an NTP-format 167 timestamp [4]) can reduce the danger of replay attacks. This 168 method MUST be supported by all protocols. 170 Other values of the RDM field are reserved for future definition 171 according to the procedures described in section 6. 173 This document defines two protocols in sections 4 and 5, encoded with 174 protocol field values 0 and 1. Protocol field values 2-254 are 175 reserved for future use. Other protocols may be defined according to 176 the procedure described in section 6. 178 3. Interaction with Relay Agents 180 Because a DHCP relay agent may alter the values of the 'giaddr' and 181 'hops' fields in the DHCP message, the contents of those two fields 182 MUST be set to zero for the computation of any hash function over the 183 message header. Additionally, a relay agent may append the DHCP relay 184 agent information option 82 [7] as the last option in a message to 185 servers. If a server finds option 82 included in a received message, 186 the server MUST compute any hash function as if the option were NOT 187 included in the message without changing the order of options. 189 Whenever the server sends back option 82 to a relay agent, the server 190 MUST not include the option in the computation of any hash function 191 over the message. 193 4. Protocol 0 195 If the protocol field is 0, the authentication information field 196 holds a simple authentication token: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Code | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |0 0 0 0 0 0 0 0| Replay Detection (64 bits) | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Replay cont. | | 206 +-+-+-+-+-+-+-+-+ | 207 | | 208 | Authentication Information | 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 The authentication token is an opaque, unencoded value known to both 213 the sender and receiver. The sender inserts the authentication token 214 in the DHCP message and the receiver matches the token from the 215 message to the shared token. If the authentication option is present 216 and the token from the message does not match the shared token, the 217 receiver MUST discard the message. 219 Protocol 0 may be used to pass a plain-text password and provides 220 only weak entity authentication and no message authentication. This 221 protocol is only useful for rudimentary protection against 222 inadvertently instantiated DHCP servers. 224 DISCUSSION: 226 The intent here is to pass a constant, non-computed token such as 227 a plain-text password. Other types of entity authentication using 228 computed tokens such as Kerberos tickets or one-time passwords 229 will be defined as separate protocols. 231 5. Protocol 1 232 If the protocol field is 1, the message is using the "delayed 233 authentication" mechanism. In delayed authentication, the client 234 requests authentication in its DHCPDISCOVER message and the server 235 replies with a DHCPOFFER message that includes authentication 236 information information. This authentication information contains a 237 nonce value generated by the source as a message authentication code 238 (MAC) to provide message authentication and entity authentication. 240 This document defines the use of a particular technique based on the 241 HMAC protocol [3] using the MD5 hash [2]. 243 5.1 Management Issues 245 The "delayed authentication" protocol does not attempt to address 246 situations where a client may roam from one administrative domain to 247 another, i.e. interdomain roaming. This protocol is focused on 248 solving the intradomain problem where the out-of-band exchange of a 249 shared secret is feasible. 251 5.2 Format 253 The format of the authentication request in a DHCPDISCOVER message 254 for protocol 1 is: 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Code | Length |0 0 0 0 0 0 0 1| Algorithm | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | RDM | Replay Detection (64 bits) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Replay cont. | 264 +-+-+-+-+-+-+-+-+ 266 The format of the authentication information for protocol 1 is: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Code | Length |0 0 0 0 0 0 0 1| Algorithm | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | RDM | Replay Detection (64 bits) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Replay cont. | Secret ID (32 bits) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | secret id cont| HMAC-MD5 (128 bits) .... 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 This document defines one technique for use with protocol 1, which is 281 identified by setting the algorithm field to 1. Other techniques 282 that use different algorithms may be defined by future 283 specifications, see section 6. The following definitions will be 284 used in the description of the authentication information for 285 protocol 1, algorithm 1: 287 Replay Detection - as defined by the RDM field 288 K - a secret value shared between the source and 289 destination of the message; each secret has a 290 unique identifier (not shown in figures) 291 secret ID - the unique identifier for the secret value 292 used to generate the MAC for this message 293 HMAC-MD5 - the MAC generating function [3, 2]. 295 The sender computes the MAC using the HMAC generation algorithm [3] 296 and the MD5 hash function [2]. The entire DHCP message (except as 297 noted below), including the DHCP message header and the options 298 field, is used as input to the HMAC-MD5 computation function. The 299 'secret ID' field MUST be set to the identifier of the secret used to 300 generate the MAC. 302 DISCUSSION: 304 Algorithm 1 specifies the use of HMAC-MD5. Use of a different 305 technique, such as HMAC-SHA, will be specified as a separate 306 protocol. 308 Protocol 1 requires a shared secret key for each client on each 309 DHCP server with which that client may wish to use the DHCP 310 protocol. Each secret key has a unique identifier that can be 311 used by a receiver to determine which secret was used to generate 312 the MAC in the DHCP message. Therefore, protocol 1 may not scale 313 well in an architecture in which a DHCP client connects to 314 multiple administrative domains. 316 Note that the meaning of an authentication option can be changed 317 by removing the secret ID, and MAC, transforming an authentication 318 option with authentication information into a request for 319 authentication. Therefore, the authentication request form of 320 this option can only appear in a DHCPDISCOVER message. 322 5.3 Message validation 324 To validate an incoming message, the receiver first checks that 325 the value in the replay detection field is acceptable according to 326 the replay detection method specified by the RDM field. Next, the 327 receive computes the MAC as described in [3]. The receiver MUST 328 set the 'MAC' field of the authentication option to all 0s for 329 computation of the MAC, and because a DHCP relay agent may alter 330 the values of the 'giaddr' and 'hops' fields in the DHCP message, 331 the contents of those two fields MUST also be set to zero for the 332 computation of the MAC. If the MAC computed by the receiver does 333 not match the MAC contained in the authentication option, the 334 receiver MUST discard the DHCP message. 336 Section 3 provides additional information on handling messages 337 that include option 82 (Relay Agents). 339 5.4 Key utilization 341 Each DHCP client has a key, K. The client uses its key to encode 342 any messages it sends to the server and to authenticate and verify 343 any messages it receives from the server. The client's key SHOULD 344 be initially distributed to the client through some out-of-band 345 mechanism, and SHOULD be stored locally on the client for use in 346 all authenticated DHCP messages. Once the client has been given 347 its key, it SHOULD use that key for all transactions even if the 348 client's configuration changes; e.g., if the client is assigned a 349 new network address. 351 Each DHCP server MUST know, or be able to obtain in a secure 352 manner, the keys for all authorized clients. If all clients use 353 the same key, clients can perform both entity and message 354 authentication for all messages received from servers. However, 355 the sharing of keys is strongly discouraged as it allows for 356 unauthorized clients to masquerade as authorized clients by 357 obtaining a copy of the shared key. To authenticate the identity 358 of individual clients, each client MUST be configured with a 359 unique key. Appendix A describes a technique for key management. 361 5.5 Client considerations 363 This section describes the behavior of a DHCP client using 364 authentication protocol 1. 366 5.5.1 INIT state 368 When in INIT state, the client uses protocol 1 as follows: 370 1. The client MUST include the authentication request option in 371 its DHCPDISCOVER message along with option 61 [6] to identify 372 itself uniquely to the server. 374 2. The client MUST validate any DHCPOFFER messages that include 375 authentication information using the mechanism specified in 376 section 5.3. The client MUST discard any messages which fail 377 to pass validation and MAY log the validation failure. The 378 client selects one DHCPOFFER message as its selected 379 configuration. If none of the DHCPOFFER messages received by 380 the client include authentication information, the client MAY 381 choose an unauthenticated message as its selected 382 configuration. The client SHOULD be configurable to accept or 383 reject unauthenticated DHCPOFFER messages. 384 3. The client replies with a DHCPREQUEST message that MUST include 385 authentication information encoded with the same secret used by 386 the server in the selected DHCPOFFER message. 387 4. The client MUST validate the DHCPACK message from the server. 388 The client MUST discard the DHCPACK if the message fails to 389 pass validation and MAY log the validation failure. If the 390 DHCPACK fails to pass validation, the client MUST revert to 391 INIT state and returns to step 1. The client MAY choose to 392 remember which server replied with a DHCPACK message that 393 failed to pass validation and discard subsequent messages from 394 that server. 396 5.5.2 INIT-REBOOT state 398 When in INIT-REBOOT state, the client MUST use the secret it used 399 in its DHCPREQUEST message to obtain its current configuration to 400 generate authentication information for the DHCPREQUEST message. 401 The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK 402 messages if no authenticated messages were received. The client 403 MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK 404 messages as specified in section 3.2 of [1]. 406 5.5.3 RENEWING state 408 When in RENEWING state, the client uses the secret it used in its 409 initial DHCPREQUEST message to obtain its current configuration to 410 generate authentication information for the DHCPREQUEST message. 411 If client receives no DHCPACK messages or none of the DHCPACK 412 messages pass validation, the client behaves as if it had not 413 received a DHCPACK message in section 4.4.5 of the DHCP 414 specification [1]. 416 5.5.4 REBINDING state 418 When in REBINDING state, the client uses the secret it used in its 419 initial DHCPREQUEST message to obtain its current configuration to 420 generate authentication information for the DHCPREQUEST message. 421 If client receives no DHCPACK messages or none of the DHCPACK 422 messages pass validation, the client behaves as if it had not 423 received a DHCPACK message in section 4.4.5 of the DHCP 424 specification [1]. 426 5.5.5 DHCPINFORM message 428 Since the client already has some configuration information, the 429 client may also have established a shared secret value, K, with a 430 server. Therefore, the client SHOULD use the authentication 431 request as in a DHCPDISCOVER message when a shared secret value 432 exists. The client MUST treat any received DHCPACK messages as it 433 does DHCPOFFER messages, see section 5.5.1. 435 5.5.6 DHCPRELEASE message 437 Since the client is already in the BOUND state, the client will 438 have a security association already established with the server. 439 Therefore, the client MUST include authentication information with 440 the DHCPRELEASE message. 442 5.6 Server considerations 444 This section describes the behavior of a server in response to 445 client messages using authentication protocol 1. 447 5.6.1 General considerations 449 Each server maintains a list of secrets and identifiers for those 450 secrets that it shares with clients and potential clients. This 451 information must be maintained in such a way that the server can: 453 * Identify an appropriate secret and the identifier for that 454 secret for use with a client that the server may not have 455 previously communicated with 456 * Retrieve the secret and identifier used by a client to which the 457 server has provided previous configuration information 459 Each server MUST save the counter from the previous authenticated 460 message. A server MUST discard any incoming message which fails 461 the replay detection check as defined by the RDM avoid replay 462 attacks. 464 DISCUSSION: 466 The authenticated DHCPREQUEST message from a client in INIT- 467 REBOOT state can only be validated by servers that used the 468 same secret in their DHCPOFFER messages. Other servers will 469 discard the DHCPREQUEST messages. Thus, only servers that used 470 the secret selected by the client will be able to determine 471 that their offered configuration information was not selected 472 and the offered network address can be returned to the server's 473 pool of available addresses. The servers that cannot validate 474 the DHCPREQUEST message will eventually return their offered 475 network addresses to their pool of available addresses as 476 described in section 3.1 of the DHCP specification [1]. 478 5.6.2 After receiving a DHCPDISCOVER message 480 The server selects a secret for the client and includes 481 authentication information in the DHCPOFFER message as specified 482 in section 5, above. The server MUST record the identifier of the 483 secret selected for the client and use that same secret for 484 validating subsequent messages with the client. 486 5.6.3 After receiving a DHCPREQUEST message 488 The server uses the secret identified in the message and validates 489 the message as specified in section 5.3. If the message fails to 490 pass validation or the server does not know the secret identified 491 by the 'secret ID' field, the server MUST discard the message and 492 MAY choose to log the validation failure. 494 If the message passes the validation procedure, the server 495 responds as described in the DHCP specification. The server MUST 496 include authentication information generated as specified in 497 section 5.2. 499 5.6.4 After receiving a DHCPINFORM message 501 The server MAY choose to accept unauthenticated DHCPINFORM 502 messages, or only accept authenticated DHCPINFORM messages based 503 on a site policy. 505 When a client includes the authentication request in a DHCPINFORM 506 message, the server MUST respond with an authenticated DHCPACK 507 message. If the server does not have a shared secret value 508 established with the sender of the DHCPINFORM message, then the 509 server MAY respond with an unauthenticated DHCPACK message, or a 510 DHCPNAK if the server does not accept unauthenticated clients 511 based on the site policy. 513 6. IANA Considerations 515 The author of a new DHCP authentication protocol, algorithm or 516 replay detection method will follow these steps to obtain 517 acceptance of the new procedure as a part of the DHCP Internet 518 Standard: 520 1. The author devises the new authentication protocol, algorithm 521 or replay detection method. 522 2. The author documents the new technique as an Internet Draft. 523 The protocol, algorithm or RDM code for any new procedure is 524 left as "To Be Determined" (TBD). 525 3. The author submits the Internet Draft for review through the 526 IETF standards process as defined in "Internet Official 527 Protocol Standards" (STD 1). 528 4. The new protocol progresses through the IETF standards process; 529 the specification of the new protocol will be reviewed by the 530 Dynamic Host Configuration Working Group (if that group still 531 exists), or as an Internet Draft not submitted by an IETF 532 working group. If the option is accepted as a Standard, the 533 specification for the option is published as a separate RFC. 534 5. At the time of acceptance as a Proposed Internet Standard and 535 publication as an RFC, IANA assigns a DHCP authentication 536 protocol number to the new protocol. 538 This procedure for defining new authentication protocols will 539 ensure that: 541 * allocation of new protocol numbers is coordinated from a single 542 authority, 543 * new protocols are reviewed for technical correctness and 544 appropriateness, and 545 * documentation for new protocols is complete and published. 547 DISCUSSION: 548 This procedure is patterned after the procedure for acceptance 549 of new DHCP options. 551 7. References 553 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 554 Bucknell University, March 1997. 556 [2] Rivest, R., "The MD5 Message-Digest Algorithm", 557 RFC-1321, April 1992. 559 [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for 560 Message Authentication," RFC-2104, February 1997. 562 [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March 563 1992. 565 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 566 Levels," RFC-2219, March 1997. 568 [6] Henry, M., "DHCP Option 61 UUID Type Definition," 569 (work in 570 progress, November 1998. 572 [7] Patrick, M., "DHCP Relay Agent Information Option," 573 (work in progress), 574 November 1998. 576 [8] Gupta, V., "Flexible Authentication for DHCP Messages," 577 (work in progress, June 578 1998. 580 8. Acknowledgments 582 Jeff Schiller and Christian Huitema developed this scheme during a 583 terminal room BOF at the Dallas IETF meeting, December 1995. The 584 editor transcribed the notes from that discussion, which form the 585 basis for this document. The editor appreciates Jeff's and 586 Christian's patience in reviewing this document and its earlier 587 drafts. 589 The "delayed authentication" mechanism used in section 5 is due to 590 Bill Arbaugh. The threat model and requirements in sections 1.1 591 and 1.2 come from Bill's negotiation protocol proposal. The 592 attendees of an interim meeting of the DHC WG held in June, 1998, 593 including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill 594 Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, 595 Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike 596 Dooley, Greg Rabil and Arun Kapur, developed the threat model and 597 reviewed several alternative proposals. 599 The replay detection method field is due to Vipul Gupta [8]. 601 Other input from Bill Sommerfield is gratefully acknowledged. 603 Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas 604 Narten for reviewing earlier drafts of this document. 606 9. Security considerations 608 This document describes authentication and verification mechanisms 609 for DHCP. 611 10. Editors' addresses 613 Ralph Droms 614 Computer Science Department 615 323 Dana Engineering 616 Bucknell University 617 Lewisburg, PA 17837 619 Phone: (717) 524-1145 620 EMail: droms@bucknell.edu 622 Bill Arbaugh 623 Department of Computer Science 624 University of Maryland 625 A.V. Williams Building 626 College Park, MD 20742 628 Phone: (301) 455-2774 629 Email: waa@cs.umd.edu 631 10. Expiration 633 This document will expire on December 31, 2000. 635 Full Copyright Statement 637 Copyright (C) The Internet Society (2000). All Rights Reserved. 639 This document and translations of it may be copied and furnished to 640 others, and derivative works that comment on or otherwise explain it 641 or assist in its implementation may be prepared, copied, published and 642 distributed, in whole or in part, without restriction of any kind, 643 provided that the above copyright notice and this paragraph are 644 included on all such copies and derivative works. However, this 645 document itself may not be modified in any way, such as by removing 646 the copyright notice or references to the Internet Society or other 647 Internet organizations, except as needed for the purpose of developing 648 Internet standards in which case the procedures for copyrights defined 649 in the Internet Standards process must be followed, or as required to 650 translate it into languages other than English. 652 The limited permissions granted above are perpetual and will not be 653 revoked by the Internet Society or its successors or assigns. 655 This document and the information contained herein is provided on an 656 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 657 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 658 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 659 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 660 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 662 Appendix A - Key Management Technique 664 To avoid centralized management of a list of random keys, suppose K 665 for each client is generated from the pair (client identifier [6], 666 subnet address, e.g. 192.168.1.0), which must be unique to that 667 client. That is, K = MAC(MK, unique-id), where MK is a secret master 668 key and MAC is a keyed one-way function such as HMAC-MD5. 670 Without knowledge of the master key MK, an unauthorized client cannot 671 generate its own key K. The server can quickly validate an incoming 672 message from a new client by regenerating K from the client-id. For 673 known clients, the server can choose to recover the client's K 674 dynamically from the client-id in the DHCP message, or can choose to 675 precompute and cache all of the Ks a priori.