1 2DHC Working Group Ken Hornstein 3INTERNET-DRAFT NRL 4Category: Standards Track Ted Lemon 5<draft-hornstein-dhc-kerbauth-02.txt> Internet Engines, Inc. 620 February 2000 Bernard Aboba 7Expires: September 1, 2000 Microsoft 8 Jonathan Trostle 9 Cisco Systems 10 11 DHCP Authentication Via Kerberos V 12 13This document is an Internet-Draft and is in full conformance with all 14provisions of Section 10 of RFC2026. 15 16Internet-Drafts are working documents of the Internet Engineering Task 17Force (IETF), its areas, and its working groups. Note that other groups 18may also distribute working documents as Internet- Drafts. 19 20Internet-Drafts are draft documents valid for a maximum of six months 21and may be updated, replaced, or obsoleted by other documents at any 22time. It is inappropriate to use Internet-Drafts as reference material 23or to cite them other than as "work in progress." 24 25The list of current Internet-Drafts can be accessed at 26http://www.ietf.org/ietf/1id-abstracts.txt 27 28The list of Internet-Draft Shadow Directories can be accessed at 29http://www.ietf.org/shadow.html. 30 31The distribution of this memo is unlimited. 32 331. Copyright Notice 34 35Copyright (C) The Internet Society (2000). All Rights Reserved. 36 372. Abstract 38 39The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for 40host configuration. In some circumstances, it is useful for the DHCP 41client and server to be able to mutually authenticate as well as to 42guarantee the integrity of DHCP packets in transit. This document 43describes how Kerberos V may be used in order to allow a DHCP client and 44server to mutually authenticate as well as to protect the integrity of 45the DHCP exchange. The protocol described in this document is capable of 46handling both intra-realm and inter-realm authentication. 47 48 49 50 51 52 53Hornstein, et al. Standards Track [Page 1] 54 55 56INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 57 58 593. Introduction 60 61The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for 62host configuration. In some circumstances, it is useful for the DHCP 63client and server to be able to mutually authenticate as well as to 64guarantee the integrity of DHCP packets in transit. This document 65describes how Kerberos V may be used in order to allow a DHCP client and 66server to mutually authenticate as well as to protect the integrity of 67the DHCP exchange. The protocol described in this document is capable 68of handling both intra-realm and inter-realm authentication. 69 703.1. Terminology 71 72This document uses the following terms: 73 74DHCP client 75 A DHCP client or "client" is an Internet host using DHCP to 76 obtain configuration parameters such as a network address. 77 78DHCP server 79 A DHCP server or "server" is an Internet host that returns 80 configuration parameters to DHCP clients. 81 82Home KDC The KDC corresponding to the DHCP client's realm. 83 84Local KDC The KDC corresponding to the DHCP server's realm. 85 863.2. Requirements language 87 88In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 89"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 90described in [1]. 91 924. Protocol overview 93 94In DHCP authentication via Kerberos V, DHCP clients and servers utilize 95a Kerberos session key in order to compute a message integrity check 96value included within the DHCP authentication option. The message 97integrity check serves to authenticate as well as integrity protect the 98messages, while remaining compatible with the operation of a DHCP relay. 99Replay protection is also provided by a replay counter within the 100authentication option, as described in [3]. 101 102Each server maintains a list of session keys and identifiers for 103clients, so that the server can retrieve the session key and identifier 104used by a client to which the server has provided previous configuration 105information. Each server MUST save the replay counter from the previous 106authenticated message. To avoid replay attacks, the server MUST discard 107 108 109 110Hornstein, et al. Standards Track [Page 2] 111 112 113INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 114 115 116any incoming message whose replay counter is not strictly greater than 117the replay counter from the previous message. 118 119DHCP authentication, described in [3], must work within the existing 120DHCP state machine described in [4]. For a client in INIT state, this 121means that the client must obtain a valid TGT, as well as a session key, 122within the two round-trips provided by the 123DHCPDISCOVER/OFFER/REQUEST/ACK sequence. 124 125In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP 126server within the DHCPDISCOVER message. The DHCP server then completes 127the AS_REQ using the IP address to be assigned to the client, and 128submits this to the client's home KDC in order to obtain a TGT on the 129client's behalf. Once the home KDC responds with an AS_REP, the DHCP 130server extracts the client TGT and submits this along with its own TGT 131to the home KDC, in order to obtain a user-to-user ticket to the DHCP 132client. The AS_REP as well as the AP_REQ are included by the DHCP server 133in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain 134a home realm TGT and TGT session key, using the latter to decrypt the 135user-to-user ticket to obtain the user-to-user session key. It is the 136user-to-user session key that is used to authenticate and integrity 137protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly, 138this same session key is used to compute the integrity attribute in the 139server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3]. 140 141In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit 142the home realm TGT in the DHCPREQUEST, along with authenticating and 143integrity protecting the message using an integrity attribute within the 144authentication option. The integrity attribute is computed using the 145existing session key. The DHCP server can then return a renewed user- 146to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST 147message from a client in INIT-REBOOT state can only be validated by 148servers that used the same session key to compute the integrity 149attribute in their DHCPOFFER messages. 150 151Other servers will discard the DHCPREQUEST messages. Thus, only servers 152that used the user-to-user session key selected by the client will be 153able to determine that their offered configuration information was not 154selected, returning the offered network address to the server's pool of 155available addresses. The servers that cannot validate the DHCPREQUEST 156message will eventually return their offered network addresses to their 157pool of available addresses as described in section 3.1 of the DHCP 158specification [4]. 159 160When sending a DHCPINFORM, there are two possible procedures. If the 161client knows the DHCP server it will be interacting with, then it can 162obtain a ticket to the DHCP server from the local realm KDC. This will 163require obtaining a TGT to its home realm, as well as possibly a cross- 164 165 166 167Hornstein, et al. Standards Track [Page 3] 168 169 170INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 171 172 173realm TGT to the local realm if the local and home realms differ. Once 174the DHCP client has a local realm TGT, it can then request a DHCP server 175ticket in a TGS_REQ. The DHCP client can then include AP_REQ and 176integrity attributes within the DHCPINFORM. The integrity attribute is 177computed as described in [3], using the session key obtained from the 178TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated 179using the same session key. 180 181If the DHCP client does not know the DHCP server it is interacting with 182then it will not be able to obtain a ticket to it and a different 183procedure is needed. In this case, the client will include in the 184DHCPINFORM an authentication option with a ticket attribute containing 185its home realm TGT. The DHCP server will then use this TGT in order to 186request a user-to-user ticket from the home KDC in a TGS_REQ. The DHCP 187server will return the user-to-user ticket and will authenticate and 188integrity protect the DHCPACK/DHCPNAK message. This is accomplished by 189including AP_REQ and integrity attributes within the authentication 190option included with the DHCPACK/DHCPNAK messages. 191 192In order to support the DHCP client's ability to authenticate the DHCP 193server in the case where the server name is unknown, the Kerberos 194principal name for the DHCP server must be of type KRB_NT_SRV_HST with 195the service name component equal to 'dhcp'. For example, the DHCP server 196principal name for the host srv.foo.org would be of the form 197dhcp/srv.foo.org. The client MUST validate that the DHCP server 198principal name has the above format. This convention requires that the 199administrator ensure that non-DHCP server principals do not have names 200that match the above format. 201 2024.1. Authentication Option Format 203 204A summary of the authentication option format for DHCP authentication 205via Kerberos V is shown below. The fields are transmitted from left to 206right. 207 2080 1 2 3 2090 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 210+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211| Code | Length | Protocol | Algorithm | 212+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213| Global Replay Counter | 214+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215| Global Replay Counter | 216+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217| Attributes... 218+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 220Code 221 222 223 224Hornstein, et al. Standards Track [Page 4] 225 226 227INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 228 229 230 TBD - DHCP Authentication 231 232Length 233 234 The length field is a single octet and indicates the length of the 235 Protocol, Algorith, and Authentication Information fields. Octets 236 outside the range of the length field should be ignored on reception. 237 238Protocol 239 240 TBD - DHCP Kerberos V authentication 241 242Algorithm 243 244 The algorithm field is a single octet and defines the specific 245 algorithm to be used for computation of the authentication option. 246 Values for the field are as follows: 247 248 0 - reserved 249 1 - HMAC-MD5 250 2 - HMAC-SHA 251 3 - 255 reserved 252 253Global Replay Counter 254 255 As described in [3], the global replay counter field is 8 octets in 256 length. It MUST be set to the value of a monotonically increasing 257 counter. Using a counter value such as the current time of day (e.g., 258 an NTP-format timestamp [10]) can reduce the danger of replay 259 attacks. 260 261Attributes 262 263 The attributes field consists of type-length-value attributes of the 264 following format: 265 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Reserved | Payload Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Attribute value... 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 274Type 275 The type field is a single octet and is defined as follows: 276 277 0 - Integrity check 278 279 280 281Hornstein, et al. Standards Track [Page 5] 282 283 284INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 285 286 287 1 - TICKET 288 2 - Authenticator 289 3 - EncTicketPart 290 10 - AS_REQ 291 11 - AS_REP 292 12 - TGS_REQ 293 13 - TGS_REP 294 14 - AP_REQ 295 15 - AP_REP 296 20 - KRB_SAFE 297 21 - KRB_PRIV 298 22 - KRB_CRED 299 25 - EncASRepPart 300 26 - EncTGSRepPart 301 27 - EncAPRepPart 302 28 - EncKrbPrvPart 303 29 - EncKrbCredPart 304 30 - KRB_ERROR 305 306 Note that the values of the Type field are the same as in the 307 Kerberos MSG-TYPE field. As a result, no new number spaces are 308 created for IANA administration. 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338Hornstein, et al. Standards Track [Page 6] 339 340 341INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 342 343 344 The following attribute types are allowed within the following 345 messages: 346 347 DISCOVER OFFER REQUEST DECLINE # Attribute 348 -------------------------------------------------------- 349 0 1 1 1 0 Integrity check 350 0 0 0-1 0 1 Ticket 351 1 0 0 0 10 AS_REQ 352 0 1 0 0 11 AS_REP 353 0 1 0 0 14 AP_REQ 354 0 0-1 0 0 30 KRB_ERROR 355 356 RELEASE ACK NAK INFORM INFORM # Attribute 357 w/known w/unknown 358 server server 359 --------------------------------------------------------------- 360 1 1 1 1 0 0 Integrity check 361 0 0 0 0 1 1 Ticket 362 0 0 0 0 0 10 AS_REQ 363 0 0 0 0 0 11 AS_REP 364 0 0-1 0 1 0 14 AP_REQ 365 0 0 0-1 0 0 30 KRB_ERROR 366 3674.2. Client behavior 368 369The following section, which incorporates material from [3], describes 370client behavior in detail. 371 3724.2.1. INIT state 373 374When in INIT state, the client behaves as follows: 375 376 377[1] As described in [3], the client MUST include the authentication 378 request option in its DHCPDISCOVER message along with option 61 379 [11] to identify itself uniquely to the server. An AS_REQ attribute 380 MUST be included within the authentication request option. This 381 (incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags 382 and MAY include pre-authentication data (PADATA) if the client 383 knows what PADATA its home KDC will require. The ADDRESSES field in 384 the AS_REQ will be ommitted since the client does not yet know its 385 IP address. The ETYPE field will be set to an encryption type that 386 the client can accept. 387 388[2] The client MUST validate DHCPOFFER messages that include an 389 authentication option. Messages including an authentication option 390 with a KRB_ERROR attribute and no integrity attribute are treated 391 as though they are unauthenticated. More typically, authentication 392 393 394 395Hornstein, et al. Standards Track [Page 7] 396 397 398INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 399 400 401 options within the DHCPOFFER message will include AS_REP, AP_REQ, 402 and integrity attributes. To validate the authentication option, 403 the client decrypts the enc-part of the AS_REP in order to obtain 404 the TGT session key. This is used to decrypt the enc-part of the 405 AP_REQ in order to obtain the user-to-user session key. The user- 406 to-user session key is then used to compute the message integrity 407 check as described in [3], and the computed value is compared to 408 the value within the integrity attribute. The client MUST discard 409 any messages which fail to pass validation and MAY log the 410 validation failure. 411 412 As described in [3], the client selects one DHCPOFFER message as 413 its selected configuration. If none of the DHCPOFFER messages 414 received by the client include an authentication option, the client 415 MAY choose an unauthenticated message as its selected 416 configuration. DHCPOFFER messages including an authentication 417 option with a KRB_ERROR attribute and no integrity attribute are 418 treated as though they are unauthenticated. The client SHOULD be 419 configurable to accept or reject unauthenticated DHCPOFFER 420 messages. 421 422[3] The client replies with a DHCPREQUEST message that MUST include an 423 authentication option. The authentication option MUST include an 424 integrity attribute, computed as described in [3], using the user 425 to user session key recovered in step 2. 426 427[4] As noted in [3], the client MUST validate a DHCPACK message from 428 the server that includes an authentication option. DHCPACK or 429 DHCPNAK messages including an authentication option with a 430 KRB_ERROR attribute and no integrity attribute are treated as 431 though they are unauthenticated. The client MUST silently discard 432 the DHCPACK if the message fails to pass validation and MAY log the 433 validation failure. If the DHCPACK fails to pass validation, the 434 client MUST revert to the INIT state and return to step 1. The 435 client MAY choose to remember which server replied with an invalid 436 DHCPACK message and discard subsequent messages from that server. 437 4384.2.2. INIT-REBOOT state 439 440When in INIT-REBOOT state, if the user-to-user ticket is still valid, 441the client MUST re-use the session key from the DHCP server user-to-user 442ticket in its DHCPREQUEST message. This is used to generate the 443integrity attribute contained within the authentication option, as 444described in [3]. In the DHCPREQUEST, the DHCP client also includes its 445home realm TGT in a ticket attribute in the authentication option in 446order to assist the DHCP server in renewing the user-to-user ticket. To 447ensure that the user-to-user ticket remains valid throughout the DHCP 448lease period so that the renewal process can proceed, the Kerberos 449 450 451 452Hornstein, et al. Standards Track [Page 8] 453 454 455INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 456 457 458ticket lifetime SHOULD be set to exceed the DHCP lease time. If the 459user-to-user ticket is expired, then the client MUST return to the INIT 460state. 461 462The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages 463if no authenticated messages were received. DHCPACK/DHCPNAK messages 464with an authentication option containing a KRB_ERROR attribute and no 465integrity attribute are treated as though they are unauthenticated. The 466client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK 467messages as specified in section 3.2 of the DHCP specification [4]. 468 4694.2.3. RENEWING state 470 471When in RENEWING state, the DHCP client can be assumed to have a valid 472IP address, as well as a TGT to the home realm, a user-to-user ticket 473provided by the DHCP server, and a session key with the DHCP server, all 474obtained during the original DHCP conversation. If the user-to-user 475ticket is still valid, the client MUST re-use the session key from the 476user-to-user ticket in its DHCPREQUEST message to generate the integrity 477attribute contained within the authentication option. 478 479Since the DHCP client can renew the TGT to the home realm, it is 480possible for it to continue to hold a valid home realm TGT. However, 481since the DHCP client did not obtain the user-to-user ticket on its own, 482it will need to rely on the DHCP server to renew this ticket. In the 483DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket 484attribute in the authentication option in order to assist the DHCP 485server in renewing the user-to-user ticket. 486 487If the DHCP server user-to-user ticket is expired, then the client MUST 488return to INIT state. To ensure that the user-to-user ticket remains 489valid throughout the DHCP lease period so that the renewal process can 490proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP 491lease time. If client receives no DHCPACK messages or none of the 492DHCPACK messages pass validation, the client behaves as if it had not 493received a DHCPACK message in section 4.4.5 of the DHCP specification 494[4]. 495 4964.2.4. REBINDING state 497 498When in REBINDING state, the DHCP client can be assumed to have a valid 499IP address, as well as a TGT to the home realm, a user-to-user ticket 500and a session key with the DHCP server, all obtained during the original 501DHCP conversation. If the user-to-user ticket is still valid, the 502client MUST re-use the session key from the user-to-user ticket in its 503DHCPREQUEST message to generate the integrity attribute contained within 504the authentication option, as described in [3]. 505 506 507 508 509Hornstein, et al. Standards Track [Page 9] 510 511 512INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 513 514 515Since the DHCP client can renew the TGT to the home realm, it is 516possible for it to continue to hold a valid home realm TGT. However, 517since the DHCP client did not obtain the user-to-user ticket on its own, 518it will need to rely on the DHCP server to renew this ticket. In the 519DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket 520attribute in the authentication option in order to assist the DHCP 521server in renewing the user-to-user ticket. 522 523If the user-to-user ticket is expired, then the client MUST return to 524INIT state. To ensure that the user-to-user ticket remains valid 525throughout the DHCP lease period so that the renewal process can 526proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP 527lease time. If client receives no DHCPACK messages or none of the 528DHCPACK messages pass validation, the client behaves as if it had not 529received a DHCPACK message in section 4.4.5 of the DHCP specification 530[4]. 531 5324.2.5. DHCPRELEASE message 533 534Clients sending a DHCPRELEASE MUST include an authentication option. The 535authentication option MUST include an integrity attribute, computed as 536described in [3], using the user to user session key. 537 5384.2.6. DHCPDECLINE message 539 540Clients sending a DHCPDECLINE MUST include an authentication option. The 541authentication option MUST include an integrity attribute, computed as 542described in [3], using the user to user session key. 543 5444.2.7. DHCPINFORM message 545 546Since the client already has some configuration information, it can be 547assumed that it has the ability to obtain a home or local realm TGT 548prior to sending the DHCPINFORM. 549 550If the DHCP client knows which DHCP server it will be interacting with, 551then it SHOULD include an authentication option containing AP_REQ and 552integrity attributes within the DHCPINFORM. The DHCP client first 553requests a TGT to the local realm via an AS_REQ and then using the TGT 554returned in the AS_REP to request a ticket to the DHCP server from the 555local KDC in a TGS_REQ. The session key obtained from the TGS_REP will 556be used to generate the integrity attribute as described in [3]. 557 558If the DHCP client does not know what DHCP server it will be talking to, 559then it cannot obtain a ticket to the DHCP server. In this case, the 560DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an 561authentication option including a ticket attribute only. The ticket 562attribute includes a TGT for the home realm. The client MUST validate 563 564 565 566Hornstein, et al. Standards Track [Page 10] 567 568 569INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 570 571 572that the DHCP server name in the received Kerberos AP_REQ message is of 573the form dhcp/.... as described in section 4. 574 575The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages 576if no authenticated messages were received. DHCPACK/DHCPNAK messages 577with an authentication option containing a KRB_ERROR attribute and no 578integrity attribute are treated as though they are unauthenticated. The 579client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK 580messages as specified in section 3.2 of the DHCP specification [4]. 581 5824.3. Server behavior 583 584This section, which relies on material from [3], describes the behavior 585of a server in response to client messages. 586 5874.3.1. After receiving a DHCPDISCOVER message 588 589For installations where IP addresses are required within tickets, the 590DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field 591based on the IP address that it will include in the DHCPOFFER. The DHCP 592server sends the AS_REQ to the home KDC with the FORWARDABLE flag set. 593The home KDC then replies to the DHCP server with an AS_REP. The DHCP 594server extracts the client TGT from the AS_REP and forms a TGS_REQ, 595which it sends to the home KDC. 596 597If the DHCP server and client are in different realms, then the DHCP 598server will need to obtain a TGT to the home realm from the KDC of its 599own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the 600DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag 601set and includes the client home realm TGT in the ADDITIONAL-TICKETS 602field, thus requesting a user-to ticket to the DHCP client. The home 603KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user 604ticket is encrypted in the client's home realm TGT session key. 605 606In order to recover the user-to-user session key, the DHCP server 607decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP 608server uses the session key that it shares with the home realm, obtained 609in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to 610the home realm. 611 612The DHCP server then sends a DHCPOFFER to the client, including AS_REP, 613AP_REQ and integrity attributes within the authentication option. The 614AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the 615home KDC. The AP_REQ attribute includes an AP_REQ constructed by the 616DHCP server based on the TGS_REP sent to it by the home KDC. The server 617also includes an integrity attribute generated as specified in [3] from 618the user-to-user session key. The server MUST record the user-to-user 619session key selected for the client and use that session key for 620 621 622 623Hornstein, et al. Standards Track [Page 11] 624 625 626INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 627 628 629validating subsequent messages with the client. 630 6314.3.2. After receiving a DHCPREQUEST message 632 633The DHCP server uses the user-to-user session key in order to validate 634the integrity attribute contained within the authentication option, 635using the method specified in [3]. If the message fails to pass 636validation, it MUST discard the message and MAY choose to log the 637validation failure. 638 639If the message passes the validation procedure, the server responds as 640described in [4], including an integrity attribute computed as specified 641in [3] within the DHCPACK or DHCPNAK message. 642 643If the authentication option included within the DHCPREQUEST message 644contains a ticket attribute then the DHCP server will use the home realm 645TGT included in the ticket attribute in order to renew the user-to-user 646ticket, which it returns in an AP_REQ attribute within the DHCPACK. 647DHCPACK or DHCPNAK messages then include an integrity attribute 648generated as specified in [3], using the new user-to-user session key 649included within the AP_REQ. 650 6514.3.3. After receiving a DHCPINFORM message 652 653The server MAY choose to accept unauthenticated DHCPINFORM messages, or 654only accept authenticated DHCPINFORM messages based on a site policy. 655 656When a client includes an authentication option in a DHCPINFORM message, 657the server MUST respond with an authenticated DHCPACK or DHCPNAK 658message. If the DHCPINFORM message includes an authentication option 659including AP_REQ and integrity attributes, the DHCP server decrypts the 660AP_REQ attribute and then recovers the session key. The DHCP server than 661validates the integrity attribute included in the authentication option 662using the session key. If the integrity attribute is invalid then the 663DHCP server MUST silently discard the DHCPINFORM message. 664 665If the authentication option only includes a ticket attribute and no 666integrity or AP_REQ attributes, then the DHCP server should assume that 667the client needs the server to obtain a user-to-user ticket from the 668home realm KDC. In this case, the DHCP server includes the client home 669realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC. 670It then receives a user-to-user ticket from the home realm KDC in a 671TGS_REP. The DHCP server will then include AP_REQ and integrity 672attributes within the DHCPACK/DHCPNAK. 673 674If the client does not include an authentication option in the 675DHCPINFORM, the server can either respond with an unauthenticated 676DHCPACK message, or a DHCPNAK if the server does not accept 677 678 679 680Hornstein, et al. Standards Track [Page 12] 681 682 683INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 684 685 686unauthenticated clients. 687 6884.3.4. After receiving a DHCPRELEASE message 689 690The DHCP server uses the session key in order to validate the integrity 691attribute contained within the authentication option, using the method 692specified in [3]. If the message fails to pass validation, it MUST 693discard the message and MAY choose to log the validation failure. 694 695If the message passes the validation procedure, the server responds as 696described in [4], marking the client's network address as not allocated. 697 6984.3.5. After receiving a DHCPDECLINE message 699 700The DHCP server uses the session key in order to validate the integrity 701attribute contained within the authentication option, using the method 702specified in [3]. If the message fails to pass validation, it MUST 703discard the message and MAY choose to log the validation failure. 704 705If the message passes the validation procedure, the server proceeds as 706described in [4]. 707 7084.4. Error handling 709 710When an error condition occurs during a Kerberos exchange, Kerberos 711error messages can be returned by either side. These Kerberos error 712messages MAY be logged by the receiving and sending parties. 713 714In some cases, it may be possible for these error messages to be 715included within the authentication option via the KRB_ERROR attribute. 716However, in most cases, errors will result in messages being silently 717discarded and so no response will be returned. 718 719For example, if the home KDC returns a KRB_ERROR in response to the 720AS_REQ submitted by the DHCP server on the client's behalf, then the 721DHCP server will conclude that the DHCPDISCOVER was not authentic, and 722will silently discard it. 723 724However, if the AS_REQ included PADATA and the home KDC responds with an 725AS_REP, then the DHCP server can conclude that the client is authentic. 726If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by 727the home KDC in the TGS_REP, then the fault may lie with the DHCP server 728rather than with the client. In this case, the DHCP server MAY choose to 729return a KRB_ERROR within the authentication option included in the 730DHCPOFFER. The client will then treat this as an unauthenticated 731DHCPOFFER. 732 733 734 735 736 737Hornstein, et al. Standards Track [Page 13] 738 739 740INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 741 742 743Similarly, if the integrity attribute contained in the DHCPOFFER proves 744invalid, the client will silently discard the DHCPOFFER and instead 745accept an offer from another server if one is available. If the 746integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then 747the client behaves as if it did not receive a DHCPACK/DHCPNAK. 748 749When in INIT-REBOOT, REBINDING or RENEWING state, the client will 750include a ticket attribute and integrity attribute within the 751authentication option of the DHCPREQUEST, in order to assist the DHCP 752server in renewing the user-to-user ticket. If the integrity attribute 753is invalid, then the DHCP server MUST silently discard the DHCPREQUEST. 754 755However, if the integrity attribute is successfully validated by the 756DHCP server, but the home realm TGT included in the ticket attribute is 757invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in 758response to its TGS_REQ to the home KDC. In this case, the DHCP server 759MAY respond with a DHCPNAK including a KRB_ERROR attribute and no 760integrity attribute within the authentication option. This will force 761the client back to the INIT state, where it can receive a valid home 762realm TGT. 763 764Where the client included PADATA in the AS_REQ attribute of the 765authentication option within the DHCPDISCOVER and the AS_REQ was 766successfully validated by the KDC, the DHCP server will conclude that 767the DHCP client is authentic. In this case if the client successfully 768validates the integrity attribute in the DHCPOFFER, but the server does 769not validate the integrity attribute in the client's DHCPREQUEST, the 770server MAY choose to respond with an authenticated DHCPNAK containing a 771KRB_ERROR attribute. 772 7734.5. PKINIT issues 774 775When public key authentication is supported with Kerberos as described 776in [8], the client certificate and a signature accompany the initial 777request in the preauthentication fields. As a result, it is conceivable 778that the incomplete AS_REQ included in the DHCPDISCOVER packet may 779exceed the size of a single DHCP option, or even the MTU size. As noted 780in [4], a single option may be as large as 255 octets. If the value to 781be passed is larger than this the client concatenates together the 782values of multiple instances of the same option. 783 7844.6. Examples 785 7864.6.1. INIT state 787 788In the intra-realm case where the DHCP Kerberos mutual authentication is 789successful, the conversation will appear as follows: 790 791 792 793 794Hornstein, et al. Standards Track [Page 14] 795 796 797INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 798 799 800 DHCP DHCP 801 Client Server KDC 802-------------- ------------- --------- 803DHCPDISCOVER 804 (Incomplete 805 AS_REQ) -> 806 AS_REQ -> 807 <- AS_REP 808 TGS_REQ 809 U-2-U -> 810 <- TGS_REP 811 <- DHCPOFFER, 812 (AS_REP, 813 AP_REQ, 814 Integrity) 815DHCPREQUEST 816 (Integrity) -> 817 <- DHCPACK 818 (Integrity) 819 820In the case where the KDC returns a KRB_ERROR in response to the AS_REQ, 821the server will silently discard the DHCPDISCOVER and the conversation 822will appear as follows: 823 824 DHCP DHCP 825 Client Server KDC 826-------------- ------------- --------- 827DHCPDISCOVER 828 (Incomplete 829 AS_REQ) -> 830 AS_REQ -> 831 <- KRB_ERROR 832 833In the inter-realm case where the DHCP Kerberos mutual authentication is 834successful, the conversation will appear as follows: 835 836 DHCP DHCP Home Local 837 Client Server KDC KDC 838-------------- ------------- --------- --------- 839DHCPDISCOVER 840(Incomplete 841 AS_REQ) -> 842 AS_REQ -> 843 <- AS_REP 844 TGS_REQ -> 845 (cross realm, 846 for home 847 KDC) 848 849 850 851Hornstein, et al. Standards Track [Page 15] 852 853 854INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 855 856 857 <- TGS_REP 858 859 TGS_REQ 860 U-2-U -> 861 <- TGS_REP 862 <- DHCPOFFER, 863 (AS_REP, 864 AP_REQ, 865 Integrity) 866DHCPREQUEST 867 (Integrity) -> 868 <- DHCPACK 869 (Integrity) 870 871In the case where the client includes PADATA in the AS_REQ attribute 872within the authentication option of the DHCPDISCOVER and the KDC returns 873an error-free AS_REP indicating successful validation of the PADATA, the 874DHCP server will conclude that the DHCP client is authentic. If the KDC 875then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault 876that lies with the DHCP server, the server MAY choose not to silently 877discard the DHCPDISCOVER. Instead it MAY respond with a DHCPOFFER 878including a KRB_ERROR attribute within the authentication option. The 879client will then treat this as an unauthenticated DHCPOFFER. The 880conversation will appear as follows: 881 882 DHCP DHCP 883 Client Server KDC 884-------------- ------------- --------- 885DHCPDISCOVER 886 (Incomplete 887 AS_REQ 888 w/PADATA) -> 889 AS_REQ -> 890 <- AS_REP 891 TGS_REQ 892 U-2-U -> 893 <- KRB_ERROR 894 <- DHCPOFFER, 895 (KRB_ERROR) 896DHCPREQUEST -> 897 <- DHCPACK 898 899In the intra-realm case where the client included PADATA in the AS_REQ 900attribute of the authentication option and the AS_REQ was successfully 901validated by the KDC, the DHCP server will conclude that the DHCP client 902is authentic. In this case if the client successfully validates the 903integrity attribute in the DHCPOFFER, but the server does not validate 904the integrity attribute in the client's DHCPREQUEST, the server MAY 905 906 907 908Hornstein, et al. Standards Track [Page 16] 909 910 911INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 912 913 914choose to respond with an authenticated DHCPNAK containing a KRB_ERROR 915attribute. The conversation will appear as follows: 916 917 DHCP DHCP 918 Client Server KDC 919-------------- ------------- --------- 920DHCPDISCOVER 921 (Incomplete 922 AS_REQ 923 w/PADATA) -> 924 AS_REQ -> 925 <- AS_REP 926 TGS_REQ 927 U-2-U -> 928 <- TGS_REP 929 <- DHCPOFFER, 930 (AS_REP, 931 AP_REQ, 932 Integrity) 933DHCPREQUEST 934 (Integrity) -> 935 <- DHCNAK 936 (KRB_ERROR, 937 Integrity) 938DHCPDISCOVER 939 (Incomplete 940 AS_REQ) -> 941 942In the intra-realm case where the DHCP client cannot validate the 943integrity attribute in the DHCPOFFER, the client silently discards the 944DHCPOFFER. The conversation will appear as follows: 945 946 DHCP DHCP 947 Client Server KDC 948-------------- ------------- --------- 949DHCPDISCOVER 950 (Incomplete 951 AS_REQ) -> 952 AS_REQ -> 953 <- AS_REP 954 TGS_REQ 955 U-2-U -> 956 <- TGS_REP 957 <- DHCPOFFER, 958 (AS_REP, 959 AP_REQ, 960 Integrity) 961DHCPREQUEST 962 963 964 965Hornstein, et al. Standards Track [Page 17] 966 967 968INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 969 970 971 [To another server] 972 (Integrity) -> 973 974In the intra-realm case where the DHCP client cannot validate the 975integrity attribute in the DHCPACK, the client reverts to INIT state. 976The conversation will appear as follows: 977 978 DHCP DHCP 979 Client Server KDC 980-------------- ------------- --------- 981DHCPDISCOVER 982(Incomplete 983 AS_REQ) -> 984 AS_REQ -> 985 <- AS_REP 986 TGS_REQ 987 U-2-U -> 988 <- TGS_REP 989 <- DHCPOFFER, 990 (AS_REP, 991 AP_REQ, 992 Integrity) 993DHCPREQUEST 994 (Integrity) -> 995 <- DHCPACK 996 (Integrity) 997DHCPDISCOVER 998 (Incomplete 999 AS_REQ) -> 1000 10014.6.2. INIT-REBOOT, RENEWING or REBINDING 1002 1003In the intra-realm or inter-realm case where the original user-to-user 1004ticket is still valid, and the DHCP server still has a valid TGT to the 1005home realm, the conversation will appear as follows: 1006 1007 DHCP DHCP Home 1008 Client Server KDC 1009-------------- ------------- --------- 1010 1011DHCPREQUEST 1012 (TGT, 1013 Integrity) -> 1014 TGS_REQ 1015 U-2-U -> 1016 <- TGS_REP 1017 <- DHCPACK 1018 (AP_REQ, 1019 1020 1021 1022Hornstein, et al. Standards Track [Page 18] 1023 1024 1025INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1026 1027 1028 Integrity) 1029 1030In the intra-realm or inter-realm case where the DHCP server validates 1031the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in 1032response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to 1033silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK 1034to the client instead, using the user-to-user session key previously 1035established with the client. The conversation appears as follows: 1036 1037 DHCP DHCP Home 1038 Client Server KDC 1039-------------- ------------- --------- 1040 1041DHCPREQUEST 1042 (TGT, 1043 Integrity) -> 1044 TGS_REQ 1045 U-2-U -> 1046 <- KRB_ERROR 1047 <- DHCPNAK 1048 (KRB_ERROR, 1049 Integrity) 1050DHCPDISCOVER 1051 (Incomplete 1052 AS_REQ) -> 1053 1054In the intra-realm or inter-realm case where the DHCP server cannot 1055validate the integrity attribute in the DHCPREQUEST, the DHCP server 1056MUST silently discard the DHCPREQUEST and the conversation will appear 1057as follows: 1058 1059 DHCP DHCP 1060 Client Server KDC 1061-------------- ------------- --------- 1062 1063DHCPREQUEST 1064 (TGT, 1065 Integrity) -> 1066 Silent discard 1067[Sequence repeats 1068 until timeout] 1069 1070DHCPDISCOVER 1071 (Incomplete 1072 AS_REQ) -> 1073 1074In the intra-realm or inter-realm case where the original user-to-user 1075ticket is still valid, the server validates the integrity attribute in 1076 1077 1078 1079Hornstein, et al. Standards Track [Page 19] 1080 1081 1082INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1083 1084 1085the DHCPREQUEST, but the client fails to validate the integrity 1086attribute in the DHCPACK, the client will silently discard the DHCPACK. 1087The conversation will appear as follows: 1088 1089 DHCP DHCP 1090 Client Server KDC 1091-------------- ------------- --------- 1092 1093DHCPREQUEST 1094 (TGT, 1095 Integrity) -> 1096 1097 <- DHCPACK 1098 (AP_REQ, 1099 Integrity) 1100DHCPDISCOVER 1101 (Incomplete 1102 AS_REQ) -> 1103 11044.6.3. DHCPINFORM (with known DHCP server) 1105 1106In the case where the DHCP client knows the DHCP server it will be 1107interacting with, the DHCP client will obtain a ticket to the DHCP 1108server and will include AP_REQ and integrity attributes within the 1109DHCPINFORM. 1110 1111Where the DHCP Kerberos mutual authentication is successful, the 1112conversation will appear as follows: 1113 1114 DHCP DHCP 1115 Client Server KDC 1116-------------- ------------- --------- 1117AS_REQ -> 1118 <- AS_REP 1119TGS_REQ -> 1120 <- TGS_REP 1121DHCPINFORM 1122 (AP_REQ, 1123 Integrity) -> 1124 <- DHCPACK 1125 (Integrity) 1126 1127In the inter-realm case where the DHCP Kerberos mutual authentication is 1128successful, the conversation will appear as follows: 1129 1130 DHCP DHCP Home Local 1131 Client Server KDC KDC 1132-------------- ------------- --------- --------- 1133 1134 1135 1136Hornstein, et al. Standards Track [Page 20] 1137 1138 1139INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1140 1141 1142AS_REQ -> 1143 <- AS_REP 1144TGS_REQ -> 1145 <- TGS_REP 1146TGS_REQ -> 1147 <- TGS_REP 1148DHCPINFORM 1149 (AP_REQ, 1150 Integrity) -> 1151 <- DHCPACK 1152 (Integrity) 1153 1154In the inter-realm case where the DHCP server fails to validate the 1155integrity attribute in the DHCPINFORM, the server MUST silently discard 1156the DHCPINFORM. The conversation will appear as follows: 1157 1158 DHCP DHCP Home Local 1159 Client Server KDC KDC 1160-------------- ------------- --------- --------- 1161AS_REQ -> 1162 <- AS_REP 1163TGS_REQ -> 1164 <- TGS_REP 1165TGS_REQ -> 1166 <- TGS_REP 1167DHCPINFORM 1168 (AP_REQ, 1169 Integrity) -> 1170 <- DHCPACK 1171 (Integrity) 1172DHCPINFORM 1173 (AP_REQ, 1174 Integrity) -> 1175 1176In the inter-realm case where the DHCP client fails to validate the 1177integrity attribute in the DHCPACK, the client MUST silently discard the 1178DHCPACK. The conversation will appear as follows: 1179 1180 DHCP DHCP Home Local 1181 Client Server KDC KDC 1182-------------- ------------- --------- --------- 1183AS_REQ -> 1184 <- AS_REP 1185TGS_REQ -> 1186 <- TGS_REP 1187TGS_REQ -> 1188 <- TGS_REP 1189DHCPINFORM 1190 1191 1192 1193Hornstein, et al. Standards Track [Page 21] 1194 1195 1196INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1197 1198 1199 (AP_REQ, 1200 Integrity) -> 1201 12024.6.4. DHCPINFORM (with unknown DHCP server) 1203 1204In the case where the DHCP client does not know the DHCP server it will 1205be interacting with, the DHCP client will only include a ticket 1206attribute within the DHCPINFORM. Thus the DHCP server will not be able 1207to validate the authentication option. 1208 1209Where the DHCP client is able to validate the DHCPACK and no error 1210occur, the onversation will appear as follows: 1211 1212 DHCP DHCP 1213 Client Server KDC 1214-------------- ------------- --------- 1215AS_REQ -> 1216 <- AS_REP 1217DHCPINFORM 1218 (Ticket) -> 1219 TGS_REQ 1220 U-2-U -> 1221 <- TGS_REP 1222 <- DHCPACK 1223 (AP_REQ, 1224 Integrity) 1225 1226In the inter-realm case where the DHCP server needs to obtain a TGT to 1227the home realm, and where the client successfully validates the DHCPACK, 1228the conversation will appear as follows: 1229 1230 DHCP DHCP Home Local 1231 Client Server KDC KDC 1232-------------- ------------- --------- --------- 1233AS_REQ -> 1234 <- AS_REP 1235DHCPINFORM 1236 (Ticket) -> 1237 AS_REQ -> 1238 <- AS_REP 1239 TGS_REQ -> 1240 (cross realm, 1241 for home 1242 KDC) 1243 <- TGS_REP 1244 1245 TGS_REQ 1246 U-2-U -> 1247 1248 1249 1250Hornstein, et al. Standards Track [Page 22] 1251 1252 1253INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1254 1255 1256 <- TGS_REP 1257 <- DHCPACK 1258 (AP_REQ, 1259 Integrity) 1260 1261In the inter-realm case where the local KDC returns a KRB_ERROR in 1262response to the TGS_REQ from the DHCP server, the DHCP server MAY return 1263a KRB_ERROR within the DHCP authentication option included in a DHCPNAK. 1264The conversation will appear as follows: 1265 1266 DHCP DHCP Home Local 1267 Client Server KDC KDC 1268-------------- ------------- --------- --------- 1269AS_REQ -> 1270 <- AS_REP 1271DHCPINFORM 1272 (Ticket) -> 1273 AS_REQ -> 1274 <- AS_REP 1275 TGS_REQ -> 1276 (cross realm, 1277 for home 1278 KDC) 1279 <- KRB_ERROR 1280 <- DHCPNAK 1281 (KRB_ERROR) 1282 1283 1284In the inter-realm case where the DHCP client fails to validate the 1285integrity attribute in the DHCPACK, the client MUST silently discard the 1286DHCPACK. The conversation will appear as follows: 1287 1288 DHCP DHCP Home Local 1289 Client Server KDC KDC 1290-------------- ------------- --------- --------- 1291AS_REQ -> 1292 <- AS_REP 1293DHCPINFORM 1294 (Ticket) -> 1295 AS_REQ -> 1296 <- AS_REP 1297 TGS_REQ -> 1298 (cross realm, 1299 for home 1300 KDC) 1301 <- TGS_REP 1302 1303 TGS_REQ 1304 1305 1306 1307Hornstein, et al. Standards Track [Page 23] 1308 1309 1310INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1311 1312 1313 U-2-U -> 1314 <- TGS_REP 1315 <- DHCPACK 1316 (AP_REQ, 1317 Integrity) 1318DHCPINFORM 1319 (Ticket) -> 1320 13215. References 1322 1323 1324[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1325 Levels", BCP 14, RFC 2119, March 1997. 1326 1327[2] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 1328 (V5)", RFC 1510, September 1993. 1329 1330[3] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 1331 Internet draft (work in progress), draft-ietf-dhc- 1332 authentication-11.txt, June 1999. 1333 1334[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1335 1997. 1336 1337[5] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 1338 Extensions", RFC 2132, March 1997. 1339 1340[6] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 1341 1342[7] Jain, V., Congdon, P., Roese, J., "Network Port Authentication", 1343 IEEE 802.1 PAR submission, June 1999. 1344 1345[8] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 1346 J., Trostle, J., "Public Key Cryptography for Initial 1347 Authentication in Kerberos", Internet draft (work in progress), 1348 draft-ietf-cat-kerberos-pk-init-09.txt, June 1999. 1349 1350[9] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B., 1351 Medvinsky, A., Hur, M., "Public Key Cryptography for Cross-Realm 1352 Authentication in Kerberos", Internet draft (work in progress), 1353 draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999. 1354 1355[10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March 1356 1992. 1357 1358[11] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft 1359 (work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt, 1360 November 1998. 1361 1362 1363 1364Hornstein, et al. Standards Track [Page 24] 1365 1366 1367INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1368 1369 13706. Security Considerations 1371 1372DHCP authentication, described in [3], addresses the following threats: 1373 1374 Modification of messages 1375 Rogue servers 1376 Unauthorized clients 1377 1378This section describes how DHCP authentication via Kerberos V addresses 1379each of these threats. 1380 13816.1. Client security 1382 1383As noted in [3], it may be desirable to ensure that IP addresses are 1384only allocated to authorized clients. This can serve to protect against 1385denial of service attacks. To address this issue it is necessary for 1386DHCP client messages to be authenticated. In order to guard against 1387message modification, it is also necessary for DHCP client messages to 1388be integrity protected. 1389 1390Note that this protocol does not make use of KRB_SAFE, so as to allow 1391modification of mutable fields by the DHCP relay. Replay protection is 1392therefore provided within the DHCP authentication option itself. 1393 1394In DHCP authentication via Kerberos V the DHCP client will authenticate, 1395integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and 1396DHCPRELEASE messages using a user-to-user session key obtained by the 1397DHCP server from the home KDC. If the DHCP client knows the DHCP server 1398it will be interacting with, then the DHCP client MAY also authenticate, 1399integrity and replay-protect the DHCPINFORM message using a session key 1400obtained from the local realm KDC for the DHCP server it expects to 1401converse with. 1402 1403Since the client has not yet obtained a session key, DHCPDISCOVER 1404packets cannot be authenticated using the session key. However, the 1405client MAY include pre-authentication data in the PADATA field included 1406in the DHCPDISCOVER packet. Since the PADATA will then be used by the 1407DHCP server to request a ticket on the client's behalf, the DHCP server 1408will learn from the AS_REP whether the PADATA was acceptable or not. 1409Therefore in this case, the DHCPDISCOVER will be authenticated but not 1410integrity protected. 1411 1412Where the DHCP client does not know the DHCP server it will be 1413interacting with ahead of time, the DHCPINFORM message will not be 1414authenticated, integrity or replay protected. 1415 1416Note that snooping of PADATA and TGTs on the wire may provide an 1417attacker with a means of mounting a dictionary attack, since these items 1418 1419 1420 1421Hornstein, et al. Standards Track [Page 25] 1422 1423 1424INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1425 1426 1427are typically encrypted with a key derived from the user's password. 1428Thus use of strong passwords and/or pre-authentication methods utilizing 1429strong cryptography (see [8]) are recommended. 1430 14316.2. Network access control 1432 1433DHCP authentication has been proposed as a method of limiting access to 1434network media that are not physically secured such as wireless LANs and 1435ports in college residence halls. However, it is not particularly well 1436suited to this purpose since even if address allocation is denied an 1437inauthentic client may use a statically assigned IP address instead, or 1438may attempt to access the network using non-IP protocols. As a result, 1439other methods, described in [6]-[7], have been proposed for controlling 1440access to wireless media and switched LANs. 1441 14426.3. Server security 1443 1444As noted in [3], it may be desirable to protect against rogue DHCP 1445servers put on the network either intentionally or by accident. To 1446address this issue it is necessary for DHCP server messages to be 1447authenticated. In order to guard against message modification, it is 1448also necessary for DHCP server messages to be integrity protected. 1449Replay protection is also provided within the DHCP authentication 1450option. 1451 1452All messages sent by the DHCP server are authenticated and integrity and 1453replaly protected using a session key. This includes the DHCPOFFER, 1454DHCPACK, and DHCPNAK messages. The session key is used to compute the 1455DHCP authentication option, which is verified by the client. 1456 1457In order to provide protection against rogue servers it is necessary to 1458prevent rogue servers from obtaining the credentials necessary to act as 1459a DHCP server. As noted in Section 4, the Kerberos principal name for 1460the DHCP server must be of type KRB_NT_SRV_HST with the service name 1461component equal to 'dhcp'. The client MUST validate that the DHCP server 1462principal name has the above format. This convention requires that the 1463administrator ensure that non-DHCP server principals do not have names 1464that match the above format. 1465 14667. IANA Considerations 1467 1468This draft does not create any new number spaces for IANA 1469administration. 1470 14718. Acknowledgements 1472 1473The authors would like to acknowledge Ralph Droms and William Arbaugh, 1474authors of the DHCP authentication draft [3]. This draft incorporates 1475 1476 1477 1478Hornstein, et al. Standards Track [Page 26] 1479 1480 1481INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1482 1483 1484material from their work; however, any mistakes in this document are 1485solely the responsibility of the authors. 1486 14879. Authors' Addresses 1488 1489Ken Hornstein 1490US Naval Research Laboratory 1491Bldg A-49, Room 2 14924555 Overlook Avenue 1493Washington DC 20375 USA 1494 1495Phone: +1 (202) 404-4765 1496EMail: kenh@cmf.nrl.navy.mil 1497 1498Ted Lemon 1499Internet Engines, Inc. 1500950 Charter Street 1501Redwood City, CA 94063 1502 1503Phone: +1 (650) 779 6031 1504Email: mellon@iengines.net 1505 1506Bernard Aboba 1507Microsoft Corporation 1508One Microsoft Way 1509Redmond, WA 98052 1510 1511Phone: +1 (425) 936-6605 1512EMail: bernarda@microsoft.com 1513 1514Jonathan Trostle 1515170 W. Tasman Dr. 1516San Jose, CA 95134, U.S.A. 1517 1518Email: jtrostle@cisco.com 1519Phone: +1 (408) 527-6201 1520 1521 152210. Intellectual Property Statement 1523 1524The IETF takes no position regarding the validity or scope of any 1525intellectual property or other rights that might be claimed to pertain 1526to the implementation or use of the technology described in this 1527document or the extent to which any license under such rights might or 1528might not be available; neither does it represent that it has made any 1529effort to identify any such rights. Information on the IETF's 1530procedures with respect to rights in standards-track and standards- 1531related documentation can be found in BCP-11. Copies of claims of 1532 1533 1534 1535Hornstein, et al. Standards Track [Page 27] 1536 1537 1538INTERNET-DRAFT DHCP Authentication Via Kerberos V 20 February 2000 1539 1540 1541rights made available for publication and any assurances of licenses to 1542be made available, or the result of an attempt made to obtain a general 1543license or permission for the use of such proprietary rights by 1544implementors or users of this specification can be obtained from the 1545IETF Secretariat. 1546 1547The IETF invites any interested party to bring to its attention any 1548copyrights, patents or patent applications, or other proprietary rights 1549which may cover technology that may be required to practice this 1550standard. Please address the information to the IETF Executive 1551Director. 1552 155311. Full Copyright Statement 1554 1555Copyright (C) The Internet Society (2000). All Rights Reserved. 1556This document and translations of it may be copied and furnished to 1557others, and derivative works that comment on or otherwise explain it or 1558assist in its implmentation may be prepared, copied, published and 1559distributed, in whole or in part, without restriction of any kind, 1560provided that the above copyright notice and this paragraph are included 1561on all such copies and derivative works. However, this document itself 1562may not be modified in any way, such as by removing the copyright notice 1563or references to the Internet Society or other Internet organizations, 1564except as needed for the purpose of developing Internet standards in 1565which case the procedures for copyrights defined in the Internet 1566Standards process must be followed, or as required to translate it into 1567languages other than English. The limited permissions granted above are 1568perpetual and will not be revoked by the Internet Society or its 1569successors or assigns. This document and the information contained 1570herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1571INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1572IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1573INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1574WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1575 157612. Expiration Date 1577 1578This memo is filed as <draft-hornstein-dhc-kerbauth-02.txt>, and 1579expires October 1, 2000. 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592Hornstein, et al. Standards Track [Page 28] 1593 1594 1595