idnits 2.17.1 draft-ietf-dhc-authentication-12.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages 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. ** 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 175: '... detection field MUST be set to the va...' RFC 2119 keyword, line 179: '...cks. This method MUST be supported by ...' RFC 2119 keyword, line 206: '... MUST be set to zero for the computa...' RFC 2119 keyword, line 210: '... the server MUST compute any hash fu...' RFC 2119 keyword, line 213: '...gent, the server MUST not include the ...' (37 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-authentication-11.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: Because a DHCP relay agent may alter the values of the 'giaddr' and 'hops' fields in the DHCP message, the contents of those two fields MUST be set to zero for the computation of any hash function over the message header. Additionally, a relay agent may append the DHCP relay agent information option 82 [7] as the last option in a message to servers. If a server finds option 82 included in a received message, the server MUST compute any hash function as if the option were NOT included in the message without changing the order of options. If the server understands option 82 and will echo the option back to the 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-11.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 (October 1999) is 8960 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: 10 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-11.txt W. Arbaugh, Editor 4 University of Pennsylvania 5 October 1999 6 Expires June 1999 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 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt, and the list of 32 Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The Dynamic Host Configuration Protocol (DHCP) provides a framework 38 for passing configuration information to hosts on a TCP/IP network. 39 In some situations, network administrators may wish to constrain the 40 allocation of addresses to authorized hosts. Additionally, some 41 network administrators may wish to provide for authentication of the 42 source and contents of DHCP messages. This document defines a new 43 DHCP option through which authorization tickets can be easily 44 generated and newly attached hosts with proper authorization can be 45 automatically configured from an authenticated DHCP server. 47 1. Introduction 49 DHCP [1] transports protocol stack configuration parameters from 50 centrally administered servers to TCP/IP hosts. Among those 51 parameters are an IP address. DHCP servers can be configured to 52 dynamically allocate addresses from a pool of addresses, eliminating 54 DRAFT Authentication for DHCP Messages October 1999 56 a manual step in configuration of TCP/IP hosts. 58 Some network administrators may wish to provide authentication of the 59 source and contents of DHCP messages. For example, clients may be 60 subject to denial of service attacks through the use of bogus DHCP 61 servers, or may simply be misconfigured due to unintentionally 62 instantiated DHCP servers. Network administrators may wish to 63 constrain the allocation of addresses to authorized hosts to avoid 64 denial of service attacks in "hostile" environments where the network 65 medium is not physically secured, such as wireless networks or 66 college residence halls. 68 This document defines a technique that can provide both entity 69 authentication and message authentication. 71 DISCUSSION: 73 This draft combines the original Schiller-Huitema-Droms 74 authentication mechanism () 75 with the "delayed authentication" proposal developed by Bill 76 Arbaugh. This draft has been published as a revision to . 79 1.1 DHCP threat model 81 The threat to DHCP is inherently an insider threat (assuming a 82 properly configured network where BOOTP ports are blocked on the 83 enterprise's perimeter gateways.) Regardless of the gateway 84 configuration, however, the potential attacks by insiders and 85 outsiders are the same. 87 The attack specific to a DHCP client is the possibility of the 88 establishment of a "rogue" server with the intent of providing 89 incorrect configuration information to the client. The motivation for 90 doing so may be to establish a "man in the middle" attack or it may 91 be for a "denial of service" attack. 93 There is another threat to DHCP clients from mistakenly or 94 accidentally configured DHCP servers that answer DHCP client requests 95 with unintentionally incorrect configuration parameters. 97 The threat specific to a DHCP server is an invalid client 98 masquerading as a valid client. The motivation for this may be for 99 "theft of service", or to circumvent auditing for any number of 100 nefarious purposes. 102 The threat common to both the client and the server is the resource 103 "denial of service" (DoS) attack. These attacks typically involve the 105 DRAFT Authentication for DHCP Messages October 1999 107 exhaustion of valid addresses, or the exhaustion of CPU or network 108 bandwidth, and are present anytime there is a shared resource. In 109 current practice, redundancy mitigates DoS attacks the best. 111 1.2 Design goals 113 These are the goals that were used in the development of the 114 authentication protocol, listed in order of importance: 116 1. Address the threats presented in Section 1.1. 117 2. Avoid changing the current protocol. 118 3. Limit state required by the server. 119 4. Limit complexity (complexity breads design and implementation 120 errors). 122 1.3 Requirements Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [5]. 128 1.4 DHCP Terminology 130 This document uses the following terms: 132 o "DHCP client" 134 A DHCP client or "client" is an Internet host using DHCP to obtain 135 configuration parameters such as a network address. 137 o "DHCP server" 139 A DHCP server of "server"is an Internet host that returns 140 configuration parameters to DHCP clients. 142 2. Format of the authentication option 144 The following diagram defines the format of the DHCP 145 authentication option: 147 DRAFT Authentication for DHCP Messages October 1999 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Code | Length | Protocol (2) |RDM| Algorithm | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 + Replay Detection (64 bits) + 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | 159 | Authentication Information ... 160 | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 The code for the authentication option is TBD, and the length field 164 contains the length of the protocol, RDM, algorithm, Replay Detection 165 fields and authentication information fields in octets. 167 The protocol field defines the particular technique for 168 authentication used in the option. New protocols are defined as 169 decribed in Section 6. 171 The Replay Detection Method (RDM) bit field determines the type of 172 replay detection used in the Replay Detection Field. The following 173 defines the possible values for the RDM: 175 00 The replay detection field MUST be set to the value 176 of a monotonically increasing counter. Using a 177 counter value such as the current time of day (e.g., 178 an NTP-format timestamp [4]) can reduce the danger of 179 replay attacks. This method MUST be supported by all 180 protocols. 182 01 Reserved to be defined as described in Section 6. 184 10 Reserved to be defined as described in Section 6. 186 11 Reserved to be defined as described in Section 6. 188 The algorithm field defines the specific algorithm within the 189 technique identified by the protocol field. 191 The Replay Detection field is per the RDM, and the authentication 192 information field is per the protocol in use. 194 This document defines two protocols in sections 4 and 5, encoded with 195 protocol field values 0 and 1. Protocol field values 2-254 are 197 DRAFT Authentication for DHCP Messages October 1999 199 reserved for future use. Other protocols may be defined according to 200 the procedure described in section 6. 202 3. Interaction with Relay Agents 204 Because a DHCP relay agent may alter the values of the 'giaddr' and 205 'hops' fields in the DHCP message, the contents of those two fields 206 MUST be set to zero for the computation of any hash function over the 207 message header. Additionally, a relay agent may append the DHCP relay 208 agent information option 82 [7] as the last option in a message to 209 servers. If a server finds option 82 included in a received message, 210 the server MUST compute any hash function as if the option were NOT 211 included in the message without changing the order of options. If the 212 server understands option 82 and will echo the option back to the 213 relay agent, the server MUST not include the option in the 214 computation of any hash function over the message. 216 4. Protocol 0 218 If the protocol field is 0, the authentication information field 219 holds a simple authentication token: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Code | Length |0 0 0 0 0 0 0 0|0 0|0 0 0 0 0 0| 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 + Replay Detection (64 bits) + 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 + Authentication token (n octets) ... + 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 The authentication token is an opaque, unencoded value known to both 236 the sender and receiver. The sender inserts the authentication token 237 in the DHCP message and the receiver matches the token from the 238 message to the shared token. If the authentication option is present 239 and the token from the message does not match the shared token, the 240 receiver MUST discard the message. 242 Protocol 0 may be used to pass a plain-text password and provides 243 only weak entity authentication and no message authentication. This 245 DRAFT Authentication for DHCP Messages October 1999 247 protocol is only useful for rudimentary protection against 248 inadvertently instantiated DHCP servers. 250 DISCUSSION: 252 The intent here is to pass a constant, non-computed token such as 253 a plain-text password. Other types of entity authentication using 254 computed tokens such as Kerberos tickets or one-time passwords 255 will be defined as separate protocols. 257 5. Protocol 1 259 If the protocol field is 1, the message is using the "delayed 260 authentication" mechanism. In delayed authentication, the client 261 requests authentication in its DHCPDISCOVER message and the server 262 replies with a DHCPOFFER message that includes authentication 263 information information. This authentication information contains a 264 nonce value generated by the source as a message authentication code 265 (MAC) to provide message authentication and entity authentication. 267 This document defines the use of a particular technique based on the 268 HMAC protocol [3] using the MD5 hash [2]. 270 5.1 Management Issues 272 This protocol does not attempt to address situations where a client 273 may roam from one administrative domain to another, i.e. interdomain 274 roaming. This protocol is focused solving the intradomain problem 275 where the out-of-band exchange of a shared secret is feasible. 277 5.2 Format 279 The format of the authentication request in a DHCPDISCOVER message 280 for protocol 1 is: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Code | Length |0 0 0 0 0 0 0 1|RDM| Algorithm | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 + Replay Detection (64 bits) + 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 DRAFT Authentication for DHCP Messages October 1999 294 The format of the authentication information for protocol 1 is: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Code | Length |0 0 0 0 0 0 0 1|RDM| Algorithm | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | | 302 + Replay Detection (64 bits) + 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | secret ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | HMAC-MD5 ... 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 This document defines one technique for use with protocol 1, which is 311 identified by setting the algorithm field to 1. Other techniques 312 that use different algorithms may be defined by future 313 specifications, see section 6. The following definitions will be 314 used in the description of the authentication information for 315 protocol 1, algorithm 1: 317 Replay Detection - as defined by the RDM field 318 K - a secret value shared between the source and 319 destination of the message; each secret has a 320 unique identifier (not shown in figures) 321 secret ID - the unique identifier for the secret value 322 used to generate the MAC for this message 323 HMAC-MD5 - the MAC generating function [3, 2]. 325 The sender computes the MAC using the HMAC generation algorithm [3] 326 and the MD5 hash function [2]. The entire DHCP message (except as 327 noted below), including the DHCP message header and the options 328 field, is used as input to the HMAC-MD5 computation function. The 329 'secret ID' field MUST be set to the identifier of the secret used to 330 generate the MAC. 332 DISCUSSION: 334 Algorithm 1 specifies the use of HMAC-MD5. Use of a different 335 technique, such as HMAC-SHA, will be specified as a separate 336 protocol. 338 Protocol 1 requires a shared secret key for each client on each 339 DHCP server with which that client may wish to use the DHCP 341 DRAFT Authentication for DHCP Messages October 1999 343 protocol. Each secret key has a unique identifier that can be 344 used by a receiver to determine which secret was used to generate 345 the MAC in the DHCP message. Therefore, protocol 1 may not scale 346 well in an architecture in which a DHCP client may connect to 347 multiple administrative domains. 349 Note that the meaning of an authentication option can be changed 350 by removing the secret ID, and MAC, transforming an authentication 351 option with authentication information into a request for 352 authentication. Therefore, the authentication request form of 353 this option can only appear in a DHCPDISCOVER message. 355 5.3 Message validation 357 To validate an incoming message, the receiver checks the 'counter' 358 field and computes the MAC as described in [3]. If the 'counter' 359 field does not contain a value larger than the last value of 360 'counter' used by the sender, the receiver MUST discard the 361 incoming message. The receiver MUST set the 'MAC' field of the 362 authentication option to all 0s for computation of the MAC, and 363 because a DHCP relay agent may alter the values of the 'giaddr' 364 and 'hops' fields in the DHCP message, the contents of those two 365 fields MUST also be set to zero for the computation of the MAC. If 366 the MAC computed by the receiver does not match the MAC contained 367 in the authentication option, the receiver MUST discard the DHCP 368 message. 370 5.4 Key utilization 372 Each DHCP client has a key, K. The client uses its key to encode 373 any messages it sends to the server and to authenticate and verify 374 any messages it receives from the server. The client's key SHOULD 375 be initially distributed to the client through some out-of-band 376 mechanism, and SHOULD be stored locally on the client for use in 377 all authenticated DHCP messages. Once the client has been given 378 its key, it SHOULD use that key for all transactions even if the 379 client's configuration changes; e.g., if the client is assigned a 380 new network address. 382 Each DHCP server MUST know, or be able to obtain in a secure 383 manner, the keys for all authorized clients. If all clients use 384 the same key, clients can perform both entity and message 385 authentication for all messages received from servers. However, 386 the sharing of keys is strongly discouraged as it allows for 387 unauthorized clients to masquerade as authorized clients by 388 obtaining a copy of the shared key. To authenticate the identity 389 of individual clients, each client MUST be configured with a 390 unique key. Appendix A describes a technique for key management. 392 DRAFT Authentication for DHCP Messages October 1999 394 5.5 Client considerations 396 This section describes the behavior of a DHCP client using 397 authentication protocol 1. 399 5.5.1 INIT state 401 When in INIT state, the client uses protocol 1 as follows: 403 1. The client MUST include the authentication request option in 404 its DHCPDISCOVER message along with option 61 [6] to identify 405 itself uniquely to the server. 407 2. The client MUST validate any DHCPOFFER messages that include 408 authentication information using the mechanism specified in 409 section 5.2. The client MUST discard any messages which fail 410 to pass validation and MAY log the validation failure. The 411 client selects one DHCPOFFER message as its selected 412 configuration. If none of the DHCPOFFER messages received by 413 the client include authentication information, the client MAY 414 choose an unauthenticated message as its selected 415 configuration. The client SHOULD be configurable to accept or 416 reject unauthenticated DHCPOFFER messages. 417 3. The client replies with a DHCPREQUEST message that MUST include 418 authentication information encoded with the same secret used by 419 the server in the selected DHCPOFFER message. 420 4. The client MUST validate the DHCPACK message from the server. 421 The client MUST discard the DHCPACK if the message fails to 422 pass validation and MAY log the validation failure. If the 423 DHCPACK fails to pass validation, the client MUST revert to 424 INIT state and returns to step 1. The client MAY choose to 425 remember which server replied with a DHCPACK message that 426 failed to pass validation and discard subsequent messages from 427 that server. 429 5.5.2 INIT-REBOOT state 431 When in INIT-REBOOT state, the client MUST use the secret it used 432 in its DHCPREQUEST message to obtain its current configuration to 433 generate authentication information for the DHCPREQUEST message. 434 The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK 435 messages if no authenticated messages were received. The client 436 MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK 437 messages as specified in RFC 2131, section 3.2. 439 5.5.3 RENEWING state 441 When in RENEWING state, the client uses the secret it used in its 443 DRAFT Authentication for DHCP Messages October 1999 445 initial DHCPREQUEST message to obtain its current configuration to 446 generate authentication information for the DHCPREQUEST message. 447 If client receives no DHCPACK messages or none of the DHCPACK 448 messages pass validation, the client behaves as if it had not 449 received a DHCPACK message in section 4.4.5 of the DHCP 450 specification [1]. 452 5.5.4 REBINDING state 454 When in REBINDING state, the client uses the secret it used in its 455 initial DHCPREQUEST message to obtain its current configuration to 456 generate authentication information for the DHCPREQUEST message. 457 If client receives no DHCPACK messages or none of the DHCPACK 458 messages pass validation, the client behaves as if it had not 459 received a DHCPACK message in section 4.4.5 of the DHCP 460 specification [1]. 462 5.5.5 DHCPINFORM message 464 Since the client already has some configuration information, the 465 client may also have established a shared secret value, K, with a 466 server. Therefore, the client SHOULD use the authentication 467 request as in a DHCPDISCOVER message when a shared secret value 468 exists. The client MUST treat any received DHCPACK messages as it 469 does DHCPOFFER messages, see section 5.5.1. 471 5.5.6 DHCPRELEASE message 473 Since the client is already in the BOUND state, the client will 474 have a security association already established with the server. 475 Therefore, the client MUST include authentication information with 476 the DHCPRELEASE message. 478 5.6 Server considerations 480 This section describes the behavior of a server in response to 481 client messages using authentication protocol 1. 483 5.6.1 General considerations 485 Each server maintains a list of secrets and identifiers for those 486 secrets that it shares with clients and potential clients. This 487 information must be maintained in such a way that the server can: 489 * Identify an appropriate secret and the identifier for that 490 secret for use with a client that the server may not have 491 previously communicated with 492 * Retrieve the secret and identifier used by a client to which the 494 DRAFT Authentication for DHCP Messages October 1999 496 server has provided previous configuration information 498 Each server MUST save the counter from the previous authenticated 499 message. A server MUST discard any incoming message whose counter 500 is not strictly greater than the counter from the previous message 501 to avoid replay attacks. 503 DISCUSSION: 505 The authenticated DHCPREQUEST message from a client in INIT- 506 REBOOT state can only be validated by servers that used the 507 same secret in their DHCPOFFER messages. Other servers will 508 discard the DHCPREQUEST messages. Thus, only servers that used 509 the secret selected by the client will be able to determine 510 that their offered configuration information was not selected 511 and the offered network address can be returned to the server's 512 pool of available addresses. The servers that cannot validate 513 the DHCPREQUEST message will eventually return their offered 514 network addresses to their pool of available addresses as 515 described in section 3.1 of the DHCP specification [1]. 517 5.6.2 After receiving a DHCPDISCOVER message 519 The server selects a secret for the client and includes 520 authentication information generated by that secret as specified 521 in section 4.1. The server MUST record the secret selected for 522 the client and use that secret for validating subsequent messages 523 with the client. 525 5.6.3 After receiving a DHCPREQUEST message 527 The server uses the secret identified in the message and validates 528 the message as specified in section 4.2. If the message fails to 529 pass validation or the server does not know the secret identified 530 by the 'secret ID' field, the server MUST discard the message and 531 MAY choose to log the validation failure. 533 If the message passes the validation procedure, the server 534 responds as described in the DHCP specification. The server MUST 535 include authentication information generated as specified in 536 section 4.1. 538 5.6.4 After receiving a DHCPINFORM message 540 The server MAY choose to accept unauthenticated DHCPINFORM 541 messages, or only accept authenticated DHCPINFORM messages based 542 on a site policy. 544 DRAFT Authentication for DHCP Messages October 1999 546 When a client includes the authentication request in a DHCPINFORM 547 message, the server MUST respond with an authenticated DHCPACK 548 message. If the server does not have a shared secret value 549 established with the sender of the DHCPINFORM message, then the 550 server can either respond with an unauthenticated DHCPACK message, 551 or a DHCPNACK if the server does not accept unauthenticated 552 clients. 554 6. IANA Considerations 556 The author of a new DHCP option will follow these steps to obtain 557 acceptance of the protocol as a part of the DHCP Internet 558 Standard: 560 1. The author devises the new authentication protocol and/or 561 algorithm. 562 2. The author documents the new technique as an Internet Draft. 563 If this is a new protocol, the protocol code is left as "To Be 564 Determined" (TBD); otherwise, the protocol code is the code 565 from the existing protocol. The algorithm code is left as 566 "TBD". 567 3. The author submits the Internet Draft for review through the 568 IETF standards process as defined in "Internet Official 569 Protocol Standards" (STD 1). 570 4. The new protocol progresses through the IETF standards process; 571 the specification of the new protocol will be reviewed by the 572 Dynamic Host Configuration Working Group (if that group still 573 exists), or as an Internet Draft not submitted by an IETF 574 working group. If the options is accepted as a Standard, the 575 specification for the option is published as a separate RFC. 576 5. At the time of acceptance as an Internet Standard and 577 publication as an RFC, IANA assigns a DHCP authentication 578 protocol number to the new protocol. 580 This procedure for defining new authentication protocols will 581 ensure that: 583 * allocation of new protocol numbers is coordinated from a single 584 authority, 585 * new protocols are reviewed for technical correctness and 586 appropriateness, and 587 * documentation for new protocols is complete and published. 589 DISCUSSION: 590 This procedure is patterned after the procedure for acceptance 591 of new DHCP options. 593 DRAFT Authentication for DHCP Messages October 1999 595 6. References 597 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 598 Bucknell University, March 1997. 600 [2] Rivest, R., "The MD5 Message-Digest Algorithm", 601 RFC-1321, April 1992. 603 [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for 604 Message Authentication," RFC-2104, February 1997. 606 [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March 607 1992. 609 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 610 Levels," RFC-2219, March 1997. 612 [6] Henry, M., "DHCP Option 61 UUID Type Definition," 613 (work in 614 progress, November 1998. 616 [7] Patrick, M., "DHCP Relay Agent Information Option," 617 (work in progress), 618 November 1998. 620 [8] Gupta, V., "Flexible Authentication for DHCP Messages," 621 (work in progress, June 622 1998. 624 7. Acknowledgments 626 Jeff Schiller and Christian Huitema developed this scheme during a 627 terminal room BOF at the Dallas IETF meeting, December 1995. The 628 editor transcribed the notes from that discussion, which form the 629 basis for this document. The editor appreciates Jeff's and 630 Christian's patience in reviewing this document and its earlier 631 drafts. 633 The "delayed authentication" mechanism used in section 4 is due to 634 William Arbaugh. The threat model and requirements in sections 635 1.1 and 1.2 come from Bill's negotiation protocol proposal. The 636 attendees of an interim meeting of the DHC WG held in June, 1998, 637 including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill 638 Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, 639 Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike 640 Dooley, Greg Rabil and Arun Kapur, developed the threat model and 641 reviewed several alternative proposals. 643 DRAFT Authentication for DHCP Messages October 1999 645 The replay detection method field is due to Vipul Gupta [8]. 647 Other input from Bill Sommerfield is gratefully acknowledged. 649 Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas 650 Narten for reviewing earlier drafts of this document. 652 8. Security considerations 654 This document describes authentication and verification mechanisms 655 for DHCP. 657 9. Editors' addresses 659 Ralph Droms 660 Computer Science Department 661 323 Dana Engineering 662 Bucknell University 663 Lewisburg, PA 17837 665 Phone: (717) 524-1145 666 EMail: droms@bucknell.edu 668 William Arbaugh 669 University of Pennsylvania 670 Philadelphia, PA 672 EMail: waa@dsl.cis.upenn.edu 674 10. Expiration 676 This document will expire on June 30, 2000. 678 DRAFT Authentication for DHCP Messages October 1999 680 Full Copyright Statement 682 Copyright (C) The Internet Society (1999). All Rights Reserved. 684 This document and translations of it may be copied and furnished to 685 others, and derivative works that comment on or otherwise explain it 686 or assist in its implementation may be prepared, copied, published and 687 distributed, in whole or in part, without restriction of any kind, 688 provided that the above copyright notice and this paragraph are 689 included on all such copies and derivative works. However, this 690 document itself may not be modified in any way, such as by removing 691 the copyright notice or references to the Internet Society or other 692 Internet organizations, except as needed for the purpose of developing 693 Internet standards in which case the procedures for copyrights defined 694 in the Internet Standards process must be followed, or as required to 695 translate it into languages other than English. 697 The limited permissions granted above are perpetual and will not be 698 revoked by the Internet Society or its successors or assigns. 700 This document and the information contained herein is provided on an 701 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 702 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 703 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 704 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 705 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 707 DRAFT Authentication for DHCP Messages October 1999 709 Appendix A - Key Management Technique 711 To avoid centralized management of a list of random keys, suppose K 712 for each client is generated from the pair (client identifier, subnet 713 address), which must be unique to that client. That is, K = MAC(MK, 714 unique-id), where MK is a secret master key and MAC is a keyed one- 715 way function such as HMAC-MD5. 717 Without knowledge of the master key MK, an unauthorized client cannot 718 generate its own key K. The server can quickly validate an incoming 719 message from a new client by regenerating K from the client-id. For 720 known clients, the server can choose to recover the client's K 721 dynamically from the client-id in the DHCP message, or can choose to 722 precompute and cache all of the Ks a priori.