idnits 2.17.1 draft-ietf-dhc-authentication-09.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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** 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 5 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 176: '... receiver MUST discard the message....' RFC 2119 keyword, line 246: '...secret ID' field MUST be set to the id...' RFC 2119 keyword, line 248: '... MUST be set to the value of a monot...' RFC 2119 keyword, line 249: '...ntication option MUST be set to all 0s...' RFC 2119 keyword, line 252: '...those two fields MUST also be set to z...' (15 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-authentication-08.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 -- No information found for rfcdraft-ietf-dhc-authentication-08.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 (May 1999) is 9107 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '3') ** Obsolete normative reference: RFC 1305 (ref. '4') (Obsoleted by RFC 5905) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 5 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-08.txt W. Arbaugh, Editor 4 University of Pennsylvania 5 November 1998 6 Expires May 1999 8 Authentication for DHCP Messages 9 11 Status of this memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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 48 DRAFT Authentication for DHCP Messages August 1998 50 a manual step in configuration of TCP/IP hosts. 52 Some network administrators may wish to provide authentication of the 53 source and contents of DHCP messages. For example, clients may be 54 subject to denial of service attacks through the use of bogus DHCP 55 servers, or may simply be misconfigured due to unintentionally 56 instantiated DHCP servers. Network administrators may wish to 57 constrain the allocation of addresses to authorized hosts to avoid 58 denial of service attacks in "hostile" environments where the network 59 medium is not physically secured, such as wireless networks or 60 college residence halls. 62 This document defines a technique that can provide both entity 63 authentication and message authentication. 65 DISCUSSION: 67 This draft combines the original Schiller-Huitema-Droms 68 authentication mechanism () 69 with the "delayed authentication" proposal developed by Bill 70 Arbaugh. This draft has been published as a revision to . 73 1.1 DHCP threat model 75 The threat to DHCP is inherently an insider threat (assuming a 76 properly configured network where BOOTP ports are blocked on the 77 enterprise's perimeter gateways.) Regardless of the gateway 78 configuration, however, the insider and outsider threats are the 79 same. 81 The threat specific to a DHCP client is the possibility of the 82 establishment of a "rogue" server with the intent of providing 83 incorrect configuration information to the client. The motivation for 84 doing so may be to establish a "man in the middle" attack or it may 85 be for a "denial of service" attack. 87 There is another threat to DHCP clients from mistakenly or 88 accidentally configured DHCP servers that answer DHCP client requests 89 with unintentionally incorrect configuration parameters. 91 The threat specific to a DHCP server is an invalid client 92 masquerading as a valid client. The motivation for this may be for 93 "theft of service", or to circumvent auditing for any number of 94 nefarious purposes. 96 The threat common to both the client and the server is the resource 97 "denial of service" attack. These attacks typically involve the 99 DRAFT Authentication for DHCP Messages August 1998 101 exhaustion of valid addresses, or the exhaustion of CPU or network 102 bandwidth. 104 1.2 Design goals 106 These are the goals that were used in the development of the 107 authentication protocol, listed in order of importance: 109 1. Address the threats presented in Section 1.1. 110 2. Avoid changing the current protocol. 111 3. Limit state required by the server. 112 4. Limit complexity (complexity breads design and implementation 113 errors). 115 1.3 Requirements Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [5]. 121 1.4 DHCP Terminology 123 This document uses the following terms: 125 o "DHCP client" 127 A DHCP client or "client" is an Internet host using DHCP to obtain 128 configuration parameters such as a network address. 130 o "DHCP server" 132 A DHCP server of "server"is an Internet host that returns 133 configuration parameters to DHCP clients. 135 2. Format of the authentication option 137 The following diagram defines the format of the DHCP 138 authentication option: 140 DRAFT Authentication for DHCP Messages August 1998 142 +----------+----------+----------+-----------+ 143 | Code | Length | Protocol | Algorithm | 144 +----------+----------+----------+-----------+--- 145 | Authentication information ... 146 +----------+----------+----------+-----------+--- 148 The code for the authentication option is TBD, and the length field 149 contains the length of the protocol, algorithm and authentication 150 information fields in octets. The protocol field defines the 151 particular technique for authentication used in the option. The 152 algorithm field defines the specific algorithm with the technique 153 identified by the protocol field. 155 This document defines two protocols in sections 3 and 4, encoded with 156 protocol field values 0 and 1. Protocol field values 2-254 are 157 reserved for future use. Other protocols may be defined according to 158 the procedure described in section 5. 160 3. Protocol 0 162 If the protocol field is 0, the authentication information field 163 holds a simple authentication token: 165 +----------+----------+----------+----------+ 166 | Code | n+1 | 0 | 0 | 167 +----------+----------+----------+----------+------ 168 | Authentication token (n octets) ... 169 +----------+----------+----------+----------+------ 171 The authentication token is an opaque, unencoded value known to both 172 the sender and receiver. The sender inserts the authentication token 173 in the DHCP message and the receiver matches the token from the 174 message to the shared token. If the authentication option is present 175 and the token from the message does not match the shared token, the 176 receiver MUST discard the message. 178 Protocol 0 may be used to pass a plain-text password and provides 179 only weak entity authentication and no message authentication. This 180 protocol is useful for rudimentary protection against, e.g., 181 inadvertently instantiated DHCP servers. 183 DISCUSSION: 185 The intent here is to pass a constant, non-computed token such as 186 a plain-text password. Other types of entity authentication using 188 DRAFT Authentication for DHCP Messages August 1998 190 computed tokens such as Kerberos tickets or one-time passwords 191 will be defined as separate protocols. 193 4. Protocol 1 195 If the protocol field is 1, the message is using the "delayed 196 authentication" mechanism. In delayed authentication, the client 197 requests authentication in its DHCPDISCOVER message and the server 198 replies with a DHCPOFFER message that includes authentication 199 information information. This authentication information contains an 200 encrypted value generated by the source as a message authentication 201 code (MAC) to provide message authentication and entity 202 authentication. 204 This document defines the use of a particular technique based on the 205 HMAC protocol [3] using the MD5 hash [2]. 207 4.1 Format 209 The format of the authentication request in a DHCPDISCOVER message 210 for protocol 1 is: 212 +----------+----------+----------+----------+ 213 | Code | 2 | 1 | Algorithm| 214 +----------+----------+----------+----------+ 216 The format of the authentication information for protocol 1 is: 218 +----------+----------+----------+----------+ 219 | Code | n | 1 | Algorithm| 220 +----------+----------+----------+----------+ 221 | secret ID | 222 +----------+----------+----------+----------+- 223 | counter (8 octets) ... 224 +----------+----------+----------+----------+- 225 | MAC ... 226 +----------+----------+----------+----------+- 228 This document defines one technique for use with protocol 1, which is 229 identified by setting the algorithm field to 1. Other techniques 230 that use different algorithms may be defined by future 231 specifications. The following definitions will be used in the 232 description of the authentication information for protocol 1, 233 algorithm 1: 235 DRAFT Authentication for DHCP Messages August 1998 237 K - a secret value shared between the source and destination 238 of the message; each secret has a unique identifier 239 Counter - the value of a 64-bit monotonically increasing counter 240 HMAC-MD5 - the MAC generating function [3, 2]. 242 The sender computes the MAC using the HMAC generation algorithm [3] 243 and the MD5 hash function [2]. The entire DHCP message (except as 244 noted below), including the DHCP message header and the options 245 field, is used as input to the HMAC-MD5 computation function. The 246 'secret ID' field MUST be set to the identifier of the secret used to 247 generate the MAC. The 'counter' field of the authentication option 248 MUST be set to the value of a monotonically increasing counter and 249 the 'MAC' field of the authentication option MUST be set to all 0s 250 for the computation of the MAC. Because a DHCP relay agent may alter 251 the values of the 'giaddr' and 'hops' fields in the DHCP message, the 252 contents of those two fields MUST also be set to zero for the 253 computation of the message digest. Using a counter value such as the 254 current time of day (e.g., an NTP-format timestamp [4]) can reduce 255 the danger of replay attacks. 257 DISCUSSION: 259 Algorithm 1 specifies the use of HMAC-MD5. Use of a different 260 technique, such as HMAC-SHA, will be specified as a separate 261 protocol. 263 Protocol 1 requires a shared secret key for each client on each 264 DHCP server with which that client may wish to use the DHCP 265 protocol. Each secret key has a unique identifier that can be 266 used by a receiver to determine which secret was used to generate 267 the MAC in the DHCP message. Therefore, protocol 1 may not scale 268 well in an architecture in which a DHCP client may connect to 269 multiple administrative domains. 271 Note that the meaning of an authentication option can be changed 272 by removing the secret ID, counter and MAC, transforming an 273 authentication option with authentication information into a 274 request for authentication. Therefore, the authentication request 275 form of this option can only appear in a DHCPDISCOVER message. 277 The secret ID has been increased to 32 bits. 279 4.2 Message validation 281 To validate an incoming message, the receiver checks the 'counter' 282 field and computes the MAC as described in [3]. If the 'counter' 283 field does not contain a value larger than the last value of 284 'counter' used by the sender, the receiver MUST discard the incoming 286 DRAFT Authentication for DHCP Messages August 1998 288 message. The receiver MUST set the 'MAC' field of the authentication 289 option to all 0s for computation of the MAC. Because a DHCP relay 290 agent may alter the values of the 'giaddr' and 'hops' fields in the 291 DHCP message, the contents of those two fields MUST also be set to 292 zero for the computation of the MAC. If the MAC computed by the 293 receiver does not match the MAC contained in the authentication 294 option, the receiver MUST discard the DHCP message. 296 4.3 Key utilization 298 Each DHCP client has a key, K. The client uses its key to encode any 299 messages it sends to the server and to authenticate and verify any 300 messages it receives from the server. The client's key must be 301 initially distributed to the client through some out-of-band 302 mechanism, and must be stored locally on the client for use in all 303 authenticated DHCP messages. Once the client has been given its key, 304 it may use that key for all transactions even if the client's 305 configuration changes; e.g., if the client is assigned a new network 306 address. 308 Each DHCP server must know the keys for all authorized clients. If 309 all clients use the same key, clients can perform both entity and 310 message authentication for all messages received from servers. 311 However, sharing of keys is strongly discouraged as it allows for 312 unauthorized clients to masquerade as authorized clients by obtaining 313 a copy of the shared key. Servers will be able to perform message 314 authentication. To authenticate the identity of individual clients, 315 each client must be configured with a unique key. Appendix A 316 describes a technique for key management. 318 4.4 Client considerations 320 This section describes the behavior of a DHCP client using 321 authentication protocol 1. 323 4.4.1 INIT state 325 When in INIT state, the client uses protocol 1 as follows: 327 1. The client includes the authentication request option in its 328 DHCPDISCOVER message. 330 DISCUSSION: 331 Is the 'chaddr' field sufficient to identify the client or 332 should the client be required to include a 'client identifier' 333 option? 335 2. The client validates any DHCPOFFER messages that include 337 DRAFT Authentication for DHCP Messages August 1998 339 authentication information using the mechanism specified in 340 section 4.2. The client MUST discard any messages which fail to 341 pass validation and MAY log the validation failure. The client 342 selects one DHCPOFFER message as its selected configuration. If 343 none of the DHCPOFFER messages received by the client include 344 authentication information, the client MAY choose an 345 unauthenticated message as its selected configuration. The client 346 SHOULD be configurable to accept or reject unauthenticated 347 DHCPOFFER messages. 348 3. The client replies with a DHCPREQUEST message that includes 349 authentication information encoded with the same secret used by 350 the server in the selected DHCPOFFER message. 351 4. The client validates the DHCPACK message from the server. The 352 client MUST discard the DHCPACK if the message fails to pass 353 validation and MAY log the validation failure. The the DHCPACK 354 fails to pass validation, the client reverts to INIT state and 355 returns to step 1. The client MAY choose to remember which server 356 replied with a DHCPACK message that failed to pass validation and 357 discard subsequent messages from that server. 359 4.4.2 INIT-REBOOT state 361 When in INIT-REBOOT state, the client uses the secret it used in its 362 DHCPREQUEST message to obtain its current configuration to generate 363 authentication information for the DHCPREQUEST message. If client 364 receives no DHCPACK messages or none of the DHCPACK messages pass 365 validation, the client reverts to INIT state. 367 4.4.3 RENEWING state 369 When in RENEWING state, the client uses the secret it used in its 370 initial DHCPREQUEST message to obtain its current configuration to 371 generate authentication information for the DHCPREQUEST message. If 372 client receives no DHCPACK messages or none of the DHCPACK messages 373 pass validation, the client behaves as if it had not received a 374 DHCPACK message in section 4.4.5 of the DHCP specification [1]. 376 4.4.4 REBINDING state 378 When in REBINDING state, the client uses the secret it used in its 379 initial DHCPREQUEST message to obtain its current configuration to 380 generate authentication information for the DHCPREQUEST message. If 381 client receives no DHCPACK messages or none of the DHCPACK messages 382 pass validation, the client behaves as if it had not received a 383 DHCPACK message in section 4.4.5 of the DHCP specification [1]. 385 4.5 Server considerations 386 DRAFT Authentication for DHCP Messages August 1998 388 This section describes the behavior of a server in response to client 389 messages using authentication protocol 1. 391 4.5.1 General considerations 393 Each server maintains a list of secrets and identifiers for those 394 secrets that it shares with clients and potential clients. This 395 information must be maintained in such a way that the server can: 397 * Identify an appropriate secret and the identifier for that secret 398 for use with a client that the server may not have previously 399 communicated with 400 * Retrieve the secret and identifier used by a client to which the 401 server has provided previous configuration information 403 Each server MUST save the counter from the previous authenticated 404 message. A server MUST discard any incoming message whose counter is 405 not strictly greater than the counter from the previous message to 406 avoid replay attacks. 408 DISCUSSION: 410 The authenticated DHCPREQUEST message from a client in INIT-REBOOT 411 state can only be validated by servers that used the same secret 412 in their DHCPOFFER messages. Other servers will discard the 413 DHCPREQUEST messages. Thus, only servers that used the secret 414 selected by the client will be able to determine that their 415 offered configuration information was not selected and the offered 416 network address can be returned to the server's pool of available 417 addresses. The servers that cannot validate the DHCPREQUEST 418 message will eventually return their offered network addresses to 419 their pool of available addresses as described in section 3.1 of 420 the DHCP specification [1]. 422 4.5.2 After receiving a DHCPDISCOVER message 424 The server selects a secret for the client and includes 425 authentication information generated by that secret as specified in 426 section 4.1. The server MUST record the secret selected for the 427 client and use that secret for validating subsequent messages with 428 the client. 430 4.5.3 After receiving a DHCPREQUEST message 432 The server uses the secret identified in the message and validates 433 the message as specified in section 4.2. If the message fails to 434 pass validation or the server does not know the secret identified by 435 the to log the validation failure. 437 DRAFT Authentication for DHCP Messages August 1998 439 If the message passes the validation procedure, the server responds 440 as described in the DHCP specification. The server MUST include 441 authentication information generated as specified in section 4.1. 443 5. IANA Considerations 445 The author of a new DHCP option will follow these steps to obtain 446 acceptance of the protocol as a part of the DHCP Internet Standard: 448 1. The author devises the new authentication protocol and/or 449 algorithm. 450 2. The author documents the new technique as an Internet Draft. If 451 this is a new protocol, the protocol code is left as "To Be 452 Determined" (TBD); otherwise, the protocol code is the code from 453 the existing protocol. The algorithm code is left as "TBD". 454 3. The author submits the Internet Draft for review through the IETF 455 standards process as defined in "Internet Official Protocol 456 Standards" (STD 1). 457 4. The new protocol progresses through the IETF standards process; 458 the specification of the new protocol will be reviewed by the 459 Dynamic Host Configuration Working Group (if that group still 460 exists), or as an Internet Draft not submitted by an IETF working 461 group. If the options is accepted as a Standard, the 462 specification for the option is published as a separate RFC. 463 5. At the time of acceptance as an Internet Standard and publication 464 as an RFC, IANA assigns a DHCP authentication protocol number to 465 the new protocol. 467 This procedure for defining new authentication protocols will ensure 468 that: 470 * allocation of new protocol numbers is coordinated from a single 471 authority, 472 * new protocols are reviewed for technical correctness and 473 appropriateness, and 474 * documentation for new protocols is complete and published. 476 DISCUSSION: 477 This procedure is patterned after the procedure for acceptance of 478 new DHCP options. 480 6. References 482 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 483 Bucknell University, March 1997. 485 [2] Rivest, R., "The MD5 Message-Digest Algorithm", 487 DRAFT Authentication for DHCP Messages August 1998 489 RFC-1321, April 1992. 491 [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for 492 Message Authentication," RFC-2104, February 1997. 494 [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March 495 1992. 497 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 498 Levels," RFC-2219, March 1997. 500 7. Acknowledgments 502 Jeff Schiller and Christian Huitema developed this scheme during a 503 terminal room BOF at the Dallas IETF meeting, December 1995. The 504 editor transcribed the notes from that discussion, which form the 505 basis for this document. The editor appreciates Jeff's and 506 Christian's patience in reviewing this document and its earlier 507 drafts. 509 The "delayed authentication" mechanism used in section 4 is due to 510 William Arbaugh. The threat model and requirements in sections 1.1 511 and 1.2 come from Bill's negotiation protocol proposal. The attendees 512 of an interim meeting of the DHC WG held in June, 1998, including 513 Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill Arbaugh, 514 Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan, Munil Shah, 515 Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike Dooley, Greg 516 Rabil and Arun Kapur, developed the threat model and reviewed several 517 alternative proposals. 519 Other input from Bill Sommerfield is gratefully acknowledged. 521 Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas 522 Narten for reviewing earlier drafts of this document. 524 8. Security considerations 526 This document describes authentication and verification mechanisms 527 for DHCP. 529 9. Editors' addresses 531 Ralph Droms 532 Computer Science Department 533 323 Dana Engineering 534 Bucknell University 535 Lewisburg, PA 17837 537 DRAFT Authentication for DHCP Messages August 1998 539 Phone: (717) 524-1145 540 EMail: droms@bucknell.edu 542 William Arbaugh 543 University of Pennsylvania 544 Philadelphia, PA 546 Phone: (410) 465-3432 547 EMail: waa@dsl.cis.upenn.edu 549 10. Expiration 551 This document will expire on May 31, 1999. 553 11. Changes from previous revision 555 * Changed 8 bit protocol number to 16 bit (protocol, algorithm) pair. 557 * Changed 16 bit secret ID to 32 bits. 559 * Clarified that entire DHCP message (with certain field excluded) is 560 used as input to the HMAC-MD5 algorithm. 562 * Added inadvertently instantiated DHCP servers to the threat model. 564 * Clarified Appendix A. 566 DRAFT Authentication for DHCP Messages August 1998 568 Full Copyright Statement 570 Copyright (C) The Internet Society (1998). All Rights Reserved. 572 This document and translations of it may be copied and furnished to 573 others, and derivative works that comment on or otherwise explain it 574 or assist in its implementation may be prepared, copied, published and 575 distributed, in whole or in part, without restriction of any kind, 576 provided that the above copyright notice and this paragraph are 577 included on all such copies and derivative works. However, this 578 document itself may not be modified in any way, such as by removing 579 the copyright notice or references to the Internet Society or other 580 Internet organizations, except as needed for the purpose of developing 581 Internet standards in which case the procedures for copyrights defined 582 in the Internet Standards process must be followed, or as required to 583 translate it into languages other than English. 585 The limited permissions granted above are perpetual and will not be 586 revoked by the Internet Society or its successors or assigns. 588 This document and the information contained herein is provided on an 589 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 590 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 591 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 592 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 593 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 DRAFT Authentication for DHCP Messages August 1998 597 Appendix A - Key Management Technique 599 To avoid centralized management of a list of random keys, suppose K 600 for each client is generated from the pair (client identifier, subnet 601 address), which must be unique to that client. That is, K = MAC(MK, 602 unique-id), where MK is a secret master key and MAC is a keyed one- 603 way function such as HMAC-MD5. 605 Without knowledge of the master key MK, an unauthorized client cannot 606 generate its own key K. The server can quickly validate an incoming 607 message from a new client by regenerating K from the client-id. For 608 known clients, the server can choose to recover the client's K 609 dynamically from the client-id in the DHCP message, or can choose to 610 precompute and cache all of the Ks a priori.