idnits 2.17.1 draft-ietf-dhc-authentication-14.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 ...' (40 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-authentication-13.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-13.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 8532 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-13.txt W. Arbaugh, Editor 4 University of Maryland 5 July 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 | RDM | 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. This authentication information contains a nonce value 237 generated by the source as a message authentication code (MAC) to 238 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 or a 321 DHCPINFORM message. 323 5.3 Message validation 325 To validate an incoming message, the receiver first checks that 326 the value in the replay detection field is acceptable according to 327 the replay detection method specified by the RDM field. Next, the 328 receiver computes the MAC as described in [3]. The receiver MUST 329 set the 'MAC' field of the authentication option to all 0s for 330 computation of the MAC, and because a DHCP relay agent may alter 331 the values of the 'giaddr' and 'hops' fields in the DHCP message, 332 the contents of those two fields MUST also be set to zero for the 333 computation of the MAC. If the MAC computed by the receiver does 334 not match the MAC contained in the authentication option, the 335 receiver MUST discard the DHCP message. 337 Section 3 provides additional information on handling messages 338 that include option 82 (Relay Agents). 340 5.4 Key utilization 342 Each DHCP client has a key, K. The client uses its key to encode 343 any messages it sends to the server and to authenticate and verify 344 any messages it receives from the server. The client's key SHOULD 345 be initially distributed to the client through some out-of-band 346 mechanism, and SHOULD be stored locally on the client for use in 347 all authenticated DHCP messages. Once the client has been given 348 its key, it SHOULD use that key for all transactions even if the 349 client's configuration changes; e.g., if the client is assigned a 350 new network address. 352 Each DHCP server MUST know, or be able to obtain in a secure 353 manner, the keys for all authorized clients. If all clients use 354 the same key, clients can perform both entity and message 355 authentication for all messages received from servers. However, 356 the sharing of keys is strongly discouraged as it allows for 357 unauthorized clients to masquerade as authorized clients by 358 obtaining a copy of the shared key. To authenticate the identity 359 of individual clients, each client MUST be configured with a 360 unique key. Appendix A describes a technique for key management. 362 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. 412 If client receives no DHCPACK messages or none of the DHCPACK 413 messages pass validation, the client behaves as if it had not 414 received a DHCPACK message in section 4.4.5 of the DHCP 415 specification [1]. 417 5.5.4 REBINDING state 419 When in REBINDING state, the client uses the secret it used in its 420 initial DHCPREQUEST message to obtain its current configuration to 421 generate authentication information for the DHCPREQUEST message. 422 If client receives no DHCPACK messages or none of the DHCPACK 423 messages pass validation, the client behaves as if it had not 424 received a DHCPACK message in section 4.4.5 of the DHCP 425 specification [1]. 427 5.5.5 DHCPINFORM message 429 Since the client already has some configuration information, the 430 client may also have established a shared secret value, K, with a 431 server. Therefore, the client SHOULD use the authentication 432 request as in a DHCPDISCOVER message when a shared secret value 433 exists. The client MUST treat any received DHCPACK messages as it 434 does DHCPOFFER messages, see section 5.5.1. 436 5.5.6 DHCPRELEASE message 438 Since the client is already in the BOUND state, the client will 439 have a security association already established with the server. 440 Therefore, the client MUST include authentication information with 441 the DHCPRELEASE message. 443 5.6 Server considerations 445 This section describes the behavior of a server in response to 446 client messages using authentication protocol 1. 448 5.6.1 General considerations 450 Each server maintains a list of secrets and identifiers for those 451 secrets that it shares with clients and potential clients. This 452 information must be maintained in such a way that the server can: 454 * Identify an appropriate secret and the identifier for that 455 secret for use with a client that the server may not have 456 previously communicated with 457 * Retrieve the secret and identifier used by a client to which the 458 server has provided previous configuration information 460 Each server MUST save the counter from the previous authenticated 461 message. A server MUST discard any incoming message which fails 462 the replay detection check as defined by the RDM avoid replay 463 attacks. 465 DISCUSSION: 467 The authenticated DHCPREQUEST message from a client in INIT- 468 REBOOT state can only be validated by servers that used the 469 same secret in their DHCPOFFER messages. Other servers will 470 discard the DHCPREQUEST messages. Thus, only servers that used 471 the secret selected by the client will be able to determine 472 that their offered configuration information was not selected 473 and the offered network address can be returned to the server's 474 pool of available addresses. The servers that cannot validate 475 the DHCPREQUEST message will eventually return their offered 476 network addresses to their pool of available addresses as 477 described in section 3.1 of the DHCP specification [1]. 479 5.6.2 After receiving a DHCPDISCOVER message 481 The server selects a secret for the client and includes 482 authentication information in the DHCPOFFER message as specified 483 in section 5, above. The server MUST record the identifier of the 484 secret selected for the client and use that same secret for 485 validating subsequent messages with the client. 487 5.6.3 After receiving a DHCPREQUEST message 489 The server uses the secret identified in the message and validates 490 the message as specified in section 5.3. If the message fails to 491 pass validation or the server does not know the secret identified 492 by the 'secret ID' field, the server MUST discard the message and 493 MAY choose to log the validation failure. 495 If the message passes the validation procedure, the server 496 responds as described in the DHCP specification. The server MUST 497 include authentication information generated as specified in 498 section 5.2. 500 5.6.4 After receiving a DHCPINFORM message 502 The server MAY choose to accept unauthenticated DHCPINFORM 503 messages, or only accept authenticated DHCPINFORM messages based 504 on a site policy. 506 When a client includes the authentication request in a DHCPINFORM 507 message, the server MUST respond with an authenticated DHCPACK 508 message. If the server does not have a shared secret value 509 established with the sender of the DHCPINFORM message, then the 510 server MAY respond with an unauthenticated DHCPACK message, or a 511 DHCPNAK if the server does not accept unauthenticated clients 512 based on the site policy, or the server MAY choose not to respond 513 to the DHCPINFORM message. 515 6. IANA Considerations 517 The author of a new DHCP authentication protocol, algorithm or 518 replay detection method will follow these steps to obtain 519 acceptance of the new procedure as a part of the DHCP Internet 520 Standard: 522 1. The author devises the new authentication protocol, algorithm 523 or replay detection method. 524 2. The author documents the new technique as an Internet Draft. 525 The protocol, algorithm or RDM code for any new procedure is 526 left as "To Be Determined" (TBD). 527 3. The author submits the Internet Draft for review through the 528 IETF standards process as defined in "Internet Official 529 Protocol Standards" (STD 1). 530 4. The new protocol progresses through the IETF standards process; 531 the specification of the new protocol will be reviewed by the 532 Dynamic Host Configuration Working Group (if that group still 533 exists), or as an Internet Draft not submitted by an IETF 534 working group. If the option is accepted as a Standard, the 535 specification for the option is published as a separate RFC. 536 5. At the time of acceptance as a Proposed Internet Standard and 537 publication as an RFC, IANA assigns a DHCP authentication 538 protocol number to the new protocol. 540 This procedure for defining new authentication protocols will 541 ensure that: 543 * allocation of new protocol numbers is coordinated from a single 544 authority, 545 * new protocols are reviewed for technical correctness and 546 appropriateness, and 547 * documentation for new protocols is complete and published. 549 DISCUSSION: 550 This procedure is patterned after the procedure for acceptance 551 of new DHCP options. 553 7. References 555 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 556 Bucknell University, March 1997. 558 [2] Rivest, R., "The MD5 Message-Digest Algorithm", 559 RFC-1321, April 1992. 561 [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for 562 Message Authentication," RFC-2104, February 1997. 564 [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March 565 1992. 567 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 568 Levels," RFC-2219, March 1997. 570 [6] Henry, M., "DHCP Option 61 UUID Type Definition," 571 (work in 572 progress, November 1998. 574 [7] Patrick, M., "DHCP Relay Agent Information Option," 575 (work in progress), 576 November 1998. 578 [8] Gupta, V., "Flexible Authentication for DHCP Messages," 579 (work in progress, June 580 1998. 582 8. Acknowledgments 584 Jeff Schiller and Christian Huitema developed this scheme during a 585 terminal room BOF at the Dallas IETF meeting, December 1995. The 586 editor transcribed the notes from that discussion, which form the 587 basis for this document. The editor appreciates Jeff's and 588 Christian's patience in reviewing this document and its earlier 589 drafts. 591 The "delayed authentication" mechanism used in section 5 is due to 592 Bill Arbaugh. The threat model and requirements in sections 1.1 593 and 1.2 come from Bill's negotiation protocol proposal. The 594 attendees of an interim meeting of the DHC WG held in June, 1998, 595 including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill 596 Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, 597 Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike 598 Dooley, Greg Rabil and Arun Kapur, developed the threat model and 599 reviewed several alternative proposals. 601 The replay detection method field is due to Vipul Gupta [8]. 603 Other input from Bill Sommerfield is gratefully acknowledged. 605 Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas 606 Narten for reviewing earlier drafts of this document. 608 9. Security considerations 610 This document describes authentication and verification mechanisms 611 for DHCP. 613 10. Editors' addresses 615 Ralph Droms 616 Computer Science Department 617 323 Dana Engineering 618 Bucknell University 619 Lewisburg, PA 17837 621 Phone: (717) 524-1145 622 EMail: droms@bucknell.edu 624 Bill Arbaugh 625 Department of Computer Science 626 University of Maryland 627 A.V. Williams Building 628 College Park, MD 20742 630 Phone: (301) 455-2774 631 Email: waa@cs.umd.edu 633 10. Expiration 635 This document will expire on December 31, 2000. 637 Full Copyright Statement 639 Copyright (C) The Internet Society (2000). All Rights Reserved. 641 This document and translations of it may be copied and furnished to 642 others, and derivative works that comment on or otherwise explain it 643 or assist in its implementation may be prepared, copied, published and 644 distributed, in whole or in part, without restriction of any kind, 645 provided that the above copyright notice and this paragraph are 646 included on all such copies and derivative works. However, this 647 document itself may not be modified in any way, such as by removing 648 the copyright notice or references to the Internet Society or other 649 Internet organizations, except as needed for the purpose of developing 650 Internet standards in which case the procedures for copyrights defined 651 in the Internet Standards process must be followed, or as required to 652 translate it into languages other than English. 654 The limited permissions granted above are perpetual and will not be 655 revoked by the Internet Society or its successors or assigns. 657 This document and the information contained herein is provided on an 658 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 659 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 660 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 661 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 662 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 664 Appendix A - Key Management Technique 666 To avoid centralized management of a list of random keys, suppose K 667 for each client is generated from the pair (client identifier [6], 668 subnet address, e.g. 192.168.1.0), which must be unique to that 669 client. That is, K = MAC(MK, unique-id), where MK is a secret master 670 key and MAC is a keyed one-way function such as HMAC-MD5. 672 Without knowledge of the master key MK, an unauthorized client cannot 673 generate its own key K. The server can quickly validate an incoming 674 message from a new client by regenerating K from the client-id. For 675 known clients, the server can choose to recover the client's K 676 dynamically from the client-id in the DHCP message, or can choose to 677 precompute and cache all of the Ks a priori. 679 To avoid compromis of this key management system, the master key, MK, 680 MUST NOT be stored by any clients. The client SHOULD only be given 681 its key, K. If MK is compromised, a new MK SHOULD be chosen and all 682 clients given new individual keys.