idnits 2.17.00 (12 Aug 2021) /tmp/idnits52590/draft-hornstein-dhc-kerbauth-06.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 194 has weird spacing: '... option forma...' == Line 296 has weird spacing: '...w/known w/unk...' == Line 297 has weird spacing: '... server serv...' == Line 497 has weird spacing: '...ends to the h...' == Line 1226 has weird spacing: '... server must ...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1137, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (ref. '2') (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 == Outdated reference: A later version (-08) exists of draft-ietf-cat-kerberos-pk-cross-07 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 1305 (ref. '10') (Obsoleted by RFC 5905) Summary: 6 errors (**), 0 flaws (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Ken Hornstein 3 INTERNET-DRAFT NRL 4 Category: Standards Track Ted Lemon 5 Internet Engines, Inc. 6 11 October 2001 Bernard Aboba 7 Microsoft 8 Jonathan Trostle 9 Cisco Systems 11 DHCP Authentication Via Kerberos V 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet- Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 The distribution of this memo is unlimited. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This document describes how Kerberos V may be used in order to allow a 40 DHCP client and server to mutually authenticate as well as to protect 41 the integrity of the DHCP exchange. The protocol described in this 42 document is capable of handling both intra-realm and inter-realm 43 authentication. 45 Table of Contents 47 1. Introduction .......................................... 3 48 1.1 Terminology ..................................... 3 49 1.2 Requirements language ........................... 3 50 2. Protocol overview ..................................... 3 51 2.1 Authentication option format ................... 6 52 2.2 Client behavior ................................. 8 53 2.3 Server behavior ................................. 12 54 2.4 Error handling .................................. 14 55 2.5 PKINIT issues ................................... 15 56 2.6 Examples ........................................ 17 57 3. References ............................................ 26 58 4. Security considerations ............................... 27 59 4.1 Client security ................................. 27 60 4.2 Network access control .......................... 28 61 4.2 Server security ................................. 28 62 5. IANA considerations ................................... 28 63 Acknowledgments .............................................. 29 64 Author's addresses ........................................... 29 65 Intellectual Property Statement .............................. 30 66 Full Copyright Statement ..................................... 30 67 1. Introduction 69 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for 70 host configuration. In some circumstances, it is useful for the DHCP 71 client and server to be able to mutually authenticate as well as to 72 guarantee the integrity of DHCP packets in transit. This document 73 describes how Kerberos V may be used in order to allow a DHCP client and 74 server to mutually authenticate as well as to protect the integrity of 75 the DHCP exchange. The protocol described in this document is capable 76 of handling both intra-realm and inter-realm authentication. 78 1.1. Terminology 80 This document uses the following terms: 82 DHCP client 83 A DHCP client or "client" is an Internet host using DHCP to 84 obtain configuration parameters such as a network address. 86 DHCP server 87 A DHCP server or "server" is an Internet host that returns 88 configuration parameters to DHCP clients. 90 Home KDC The KDC corresponding to the DHCP client's realm. 92 Local KDC The KDC corresponding to the DHCP server's realm. 94 1.2. Requirements language 96 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 97 "RECOMMENDED "SHOULD", and "SHOULD NOT", are to be interpreted as 98 described in [1]. 100 2. Protocol overview 102 In DHCP authentication via Kerberos V, DHCP clients and servers utilize 103 a Kerberos session key in order to compute a message integrity check 104 value included within the DHCP authentication option. The message 105 integrity check serves to authenticate as well as integrity protect the 106 messages, while remaining compatible with the operation of a DHCP relay. 107 Replay protection is also provided by a replay counter within the 108 authentication option, as described in [3]. 110 Each server maintains a list of session keys and identifiers for 111 clients, so that the server can retrieve the session key and identifier 112 used by a client to which the server has provided previous configuration 113 information. Each server MUST save the replay counter from the previous 114 authenticated message. To avoid replay attacks, the server MUST discard 115 any incoming message whose replay counter is not strictly greater than 116 the replay counter from the previous message. 118 DHCP authentication, described in [3], must work within the existing 119 DHCP state machine described in [4]. For a client in INIT state, this 120 means that the client must obtain a valid TGT, as well as a session key, 121 within the two round-trips provided by the 122 DHCPDISCOVER/OFFER/REQUEST/ACK sequence. 124 In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP 125 server within the DHCPDISCOVER message. The DHCP server then completes 126 the AS_REQ using the IP address to be assigned to the client, and 127 submits this to the client's home KDC in order to obtain a TGT on the 128 client's behalf. Once the home KDC responds with an AS_REP, the DHCP 129 server extracts the client TGT and submits this along with its own TGT 130 to the home KDC, in order to obtain a user-to-user ticket to the DHCP 131 client. The AS_REP as well as the AP_REQ are included by the DHCP server 132 in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain 133 a home realm TGT and TGT session key, using the latter to decrypt the 134 user-to-user ticket to obtain the user-to-user session key. It is the 135 user-to-user session key that is used to authenticate and integrity 136 protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly, 137 this same session key is used to compute the integrity attribute in the 138 server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3]. 140 In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit 141 the home realm TGT in the DHCPREQUEST, along with authenticating and 142 integrity protecting the message using an integrity attribute within the 143 authentication option. The integrity attribute is computed using the 144 existing session key. The DHCP server can then return a renewed user- 145 to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST 146 message from a client in INIT-REBOOT state can only be validated by 147 servers that used the same session key to compute the integrity 148 attribute in their DHCPOFFER messages. 150 Other servers will discard the DHCPREQUEST messages. Thus, only servers 151 that used the user-to-user session key selected by the client will be 152 able to determine that their offered configuration information was not 153 selected, returning the offered network address to the server's pool of 154 available addresses. The servers that cannot validate the DHCPREQUEST 155 message will eventually return their offered network addresses to their 156 pool of available addresses as described in section 3.1 of the DHCP 157 specification [4]. 159 When sending a DHCPINFORM, there are two possible procedures. If the 160 client knows the DHCP server it will be interacting with, then it can 161 obtain a ticket to the DHCP server from the local realm KDC. This will 162 require obtaining a TGT to its home realm, as well as possibly a cross- 163 realm TGT to the local realm if the local and home realms differ. Once 164 the DHCP client has a local realm TGT, it can then request a DHCP server 165 ticket in a TGS_REQ. The DHCP client can then include AP_REQ and 166 integrity attributes within the DHCPINFORM. The integrity attribute is 167 computed as described in [3], using the session key obtained from the 168 TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated 169 using the same session key. 171 If the DHCP client does not know the DHCP server it is interacting with 172 then it will not be able to obtain a ticket to it and a different 173 procedure is needed. In this case, the client will include in the 174 DHCPINFORM an authentication option with a ticket attribute containing 175 its home realm TGT. The DHCP server will then use this TGT in order to 176 request a user-to-user ticket from the home KDC in a TGS_REQ. The DHCP 177 server will return the user-to-user ticket and will authenticate and 178 integrity protect the DHCPACK/DHCPNAK message. This is accomplished by 179 including AP_REQ and integrity attributes within the authentication 180 option included with the DHCPACK/DHCPNAK messages. 182 In order to support the DHCP client's ability to authenticate the DHCP 183 server in the case where the server name is unknown, the Kerberos 184 principal name for the DHCP server must be of type KRB_NT_SRV_HST with 185 the service name component equal to 'dhcp'. For example, the DHCP server 186 principal name for the host srv.foo.org would be of the form 187 dhcp/srv.foo.org. The client MUST validate that the DHCP server 188 principal name has the above format. This convention requires that the 189 administrator ensure that non-DHCP server principals do not have names 190 that match the above format. 192 2.1. Authentication Option Format 194 A summary of the authentication option format for DHCP authentication 195 via Kerberos V is shown below. The fields are transmitted from left to 196 right. 198 0 1 2 3 199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Code | Length | Protocol | Algorithm | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Global Replay Counter | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Global Replay Counter | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Attributes... 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Code 212 TBD - DHCP Authentication 214 Length 216 The length field is a single octet and indicates the length of the 217 Protocol, Algorithm, and Authentication Information fields. Octets 218 outside the range of the length field should be ignored on reception. 220 Protocol 222 TBD - DHCP Kerberos V authentication 224 Algorithm 226 The algorithm field is a single octet and defines the specific 227 algorithm to be used for computation of the authentication option. 228 Values for the field are as follows: 230 0 - reserved 231 1 - HMAC-MD5 232 2 - HMAC-SHA 233 3 - 255 reserved 235 Global Replay Counter 237 As described in [3], the global replay counter field is 8 octets in 238 length. It MUST be set to the value of a monotonically increasing 239 counter. Using a counter value such as the current time of day (e.g., 240 an NTP-format timestamp [10]) can reduce the danger of replay 241 attacks. 243 Attributes 245 The attributes field consists of type-length-value attributes of the 246 following format: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Reserved | Payload Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Attribute value... 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Type 257 The type field is a single octet and is defined as follows: 259 0 - Integrity check 260 1 - TICKET 261 2 - Authenticator 262 3 - EncTicketPart 263 10 - AS_REQ 264 11 - AS_REP 265 12 - TGS_REQ 266 13 - TGS_REP 267 14 - AP_REQ 268 15 - AP_REP 269 20 - KRB_SAFE 270 21 - KRB_PRIV 271 22 - KRB_CRED 272 25 - EncASRepPart 273 26 - EncTGSRepPart 274 27 - EncAPRepPart 275 28 - EncKrbPrvPart 276 29 - EncKrbCredPart 277 30 - KRB_ERROR 279 Note that the values of the Type field are the same as in the 280 Kerberos MSG-TYPE field. As a result, no new number spaces are 281 created for IANA administration. 283 The following attribute types are allowed within the following 284 messages: 286 DISCOVER OFFER REQUEST DECLINE # Attribute 287 -------------------------------------------------------- 288 0 1 1 1 0 Integrity check 289 0 0 0-1 0 1 Ticket 290 1 0 0 0 10 AS_REQ 291 0 1 0 0 11 AS_REP 292 0 1 0 0 14 AP_REQ 293 0 0-1 0 0 30 KRB_ERROR 295 RELEASE ACK NAK INFORM INFORM # Attribute 296 w/known w/unknown 297 server server 298 --------------------------------------------------------------- 299 1 1 1 1 0 0 Integrity check 300 0 0 0 0 1 1 Ticket 301 0 0 0 0 0 10 AS_REQ 302 0 0 0 0 0 11 AS_REP 303 0 0-1 0 1 0 14 AP_REQ 304 0 0 0-1 0 0 30 KRB_ERROR 306 2.2. Client behavior 308 The following section, which incorporates material from [3], describes 309 client behavior in detail. 311 2.2.1. INIT state 313 When in INIT state, the client behaves as follows: 315 [1] As described in [3], the client MUST include the authentication 316 request option in its DHCPDISCOVER message along with option 61 [6] 317 to identify itself uniquely to the server. An AS_REQ attribute MUST 318 be included within the authentication request option. This 319 (incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags 320 and MAY include pre-authentication data (PADATA) if the client 321 knows what PADATA its home KDC will require. The ADDRESSES field in 322 the AS_REQ will be omitted since the client does not yet know its 323 IP address. The ETYPE field will be set to an encryption type that 324 the client can accept. 326 [2] The client MUST validate DHCPOFFER messages that include an 327 authentication option. Messages including an authentication option 328 with a KRB_ERROR attribute and no integrity attribute are treated 329 as though they are unauthenticated. More typically, authentication 330 options within the DHCPOFFER message will include AS_REP, AP_REQ, 331 and integrity attributes. To validate the authentication option, 332 the client decrypts the enc-part of the AS_REP in order to obtain 333 the TGT session key. This is used to decrypt the enc-part of the 334 AP_REQ in order to obtain the user-to-user session key. The user- 335 to-user session key is then used to compute the message integrity 336 check as described in [3], and the computed value is compared to 337 the value within the integrity attribute. The client MUST discard 338 any messages which fail to pass validation and MAY log the 339 validation failure. 341 As described in [3], the client selects one DHCPOFFER message as 342 its selected configuration. If none of the DHCPOFFER messages 343 received by the client include an authentication option, the client 344 MAY choose an unauthenticated message as its selected 345 configuration. DHCPOFFER messages including an authentication 346 option with a KRB_ERROR attribute and no integrity attribute are 347 treated as though they are unauthenticated. The client SHOULD be 348 configurable to accept or reject unauthenticated DHCPOFFER 349 messages. 351 [3] The client replies with a DHCPREQUEST message that MUST include an 352 authentication option. The authentication option MUST include an 353 integrity attribute, computed as described in [3], using the user 354 to user session key recovered in step 2. 356 [4] As noted in [3], the client MUST validate a DHCPACK message from 357 the server that includes an authentication option. DHCPACK or 358 DHCPNAK messages including an authentication option with a 359 KRB_ERROR attribute and no integrity attribute are treated as 360 though they are unauthenticated. The client MUST silently discard 361 the DHCPACK if the message fails to pass validation and MAY log the 362 validation failure. If the DHCPACK fails to pass validation, the 363 client MUST revert to the INIT state and return to step 1. The 364 client MAY choose to remember which server replied with an invalid 365 DHCPACK message and discard subsequent messages from that server. 367 2.2.2. INIT-REBOOT state 369 When in INIT-REBOOT state, if the user-to-user ticket is still valid, 370 the client MUST re-use the session key from the DHCP server user-to-user 371 ticket in its DHCPREQUEST message. This is used to generate the 372 integrity attribute contained within the authentication option, as 373 described in [3]. In the DHCPREQUEST, the DHCP client also includes its 374 home realm TGT in a ticket attribute in the authentication option in 375 order to assist the DHCP server in renewing the user-to-user ticket. To 376 ensure that the user-to-user ticket remains valid throughout the DHCP 377 lease period so that the renewal process can proceed, the Kerberos 378 ticket lifetime SHOULD be set to exceed the DHCP lease time. If the 379 user-to-user ticket is expired, then the client MUST return to the INIT 380 state. 382 The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages 383 if no authenticated messages were received. DHCPACK/DHCPNAK messages 384 with an authentication option containing a KRB_ERROR attribute and no 385 integrity attribute are treated as though they are unauthenticated. The 386 client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK 387 messages as specified in section 3.2 of the DHCP specification [4]. 389 2.2.3. RENEWING state 391 When in RENEWING state, the DHCP client can be assumed to have a valid 392 IP address, as well as a TGT to the home realm, a user-to-user ticket 393 provided by the DHCP server, and a session key with the DHCP server, all 394 obtained during the original DHCP conversation. If the user-to-user 395 ticket is still valid, the client MUST re-use the session key from the 396 user-to-user ticket in its DHCPREQUEST message to generate the integrity 397 attribute contained within the authentication option. 399 Since the DHCP client can renew the TGT to the home realm, it is 400 possible for it to continue to hold a valid home realm TGT. However, 401 since the DHCP client did not obtain the user-to-user ticket on its own, 402 it will need to rely on the DHCP server to renew this ticket. In the 403 DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket 404 attribute in the authentication option in order to assist the DHCP 405 server in renewing the user-to-user ticket. 407 If the DHCP server user-to-user ticket is expired, then the client MUST 408 return to INIT state. To ensure that the user-to-user ticket remains 409 valid throughout the DHCP lease period so that the renewal process can 410 proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP 411 lease time. If client receives no DHCPACK messages or none of the 412 DHCPACK messages pass validation, the client behaves as if it had not 413 received a DHCPACK message in section 4.4.5 of the DHCP specification 414 [4]. 416 2.2.4. REBINDING state 418 When in REBINDING state, the DHCP client can be assumed to have a valid 419 IP address, as well as a TGT to the home realm, a user-to-user ticket 420 and a session key with the DHCP server, all obtained during the original 421 DHCP conversation. If the user-to-user ticket is still valid, the 422 client MUST re-use the session key from the user-to-user ticket in its 423 DHCPREQUEST message to generate the integrity attribute contained within 424 the authentication option, as described in [3]. 426 Since the DHCP client can renew the TGT to the home realm, it is 427 possible for it to continue to hold a valid home realm TGT. However, 428 since the DHCP client did not obtain the user-to-user ticket on its own, 429 it will need to rely on the DHCP server to renew this ticket. In the 430 DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket 431 attribute in the authentication option in order to assist the DHCP 432 server in renewing the user-to-user ticket. 434 If the user-to-user ticket is expired, then the client MUST return to 435 INIT state. To ensure that the user-to-user ticket remains valid 436 throughout the DHCP lease period so that the renewal process can 437 proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP 438 lease time. If client receives no DHCPACK messages or none of the 439 DHCPACK messages pass validation, the client behaves as if it had not 440 received a DHCPACK message in section 4.4.5 of the DHCP specification 441 [4]. 443 2.2.5. DHCPRELEASE message 445 Clients sending a DHCPRELEASE MUST include an authentication option. The 446 authentication option MUST include an integrity attribute, computed as 447 described in [3], using the user to user session key. 449 2.2.6. DHCPDECLINE message 451 Clients sending a DHCPDECLINE MUST include an authentication option. The 452 authentication option MUST include an integrity attribute, computed as 453 described in [3], using the user to user session key. 455 2.2.7. DHCPINFORM message 457 Since the client already has some configuration information, it can be 458 assumed that it has the ability to obtain a home or local realm TGT 459 prior to sending the DHCPINFORM. 461 If the DHCP client knows which DHCP server it will be interacting with, 462 then it SHOULD include an authentication option containing AP_REQ and 463 integrity attributes within the DHCPINFORM. The DHCP client first 464 requests a TGT to the local realm via an AS_REQ and then using the TGT 465 returned in the AS_REP to request a ticket to the DHCP server from the 466 local KDC in a TGS_REQ. The session key obtained from the TGS_REP will 467 be used to generate the integrity attribute as described in [3]. 469 If the DHCP client does not know what DHCP server it will be talking to, 470 then it cannot obtain a ticket to the DHCP server. In this case, the 471 DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an 472 authentication option including a ticket attribute only. The ticket 473 attribute includes a TGT for the home realm. The client MUST validate 474 that the DHCP server name in the received Kerberos AP_REQ message is of 475 the form dhcp/.... as described in section 4. 477 The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages 478 if no authenticated messages were received. DHCPACK/DHCPNAK messages 479 with an authentication option containing a KRB_ERROR attribute and no 480 integrity attribute are treated as though they are unauthenticated. The 481 client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK 482 messages as specified in section 3.2 of the DHCP specification [4]. 484 2.3. Server behavior 486 This section, which relies on material from [3], describes the behavior 487 of a server in response to client messages. 489 2.3.1. After receiving a DHCPDISCOVER message 491 For installations where IP addresses are required within tickets, the 492 DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field 493 based on the IP address that it will include in the DHCPOFFER. The DHCP 494 server sends the AS_REQ to the home KDC with the FORWARDABLE flag set. 495 The home KDC then replies to the DHCP server with an AS_REP. The DHCP 496 server extracts the client TGT from the AS_REP and forms a TGS_REQ, 497 which it sends to the home KDC. 499 If the DHCP server and client are in different realms, then the DHCP 500 server will need to obtain a TGT to the home realm from the KDC of its 501 own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the 502 DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag 503 set and includes the client home realm TGT in the ADDITIONAL-TICKETS 504 field, thus requesting a user-to ticket to the DHCP client. The home 505 KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user 506 ticket is encrypted in the client's home realm TGT session key. 508 In order to recover the user-to-user session key, the DHCP server 509 decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP 510 server uses the session key that it shares with the home realm, obtained 511 in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to 512 the home realm. 514 The DHCP server then sends a DHCPOFFER to the client, including AS_REP, 515 AP_REQ and integrity attributes within the authentication option. The 516 AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the 517 home KDC. The AP_REQ attribute includes an AP_REQ constructed by the 518 DHCP server based on the TGS_REP sent to it by the home KDC. The server 519 also includes an integrity attribute generated as specified in [3] from 520 the user-to-user session key. The server MUST record the user-to-user 521 session key selected for the client and use that session key for 522 validating subsequent messages with the client. 524 2.3.2. After receiving a DHCPREQUEST message 526 The DHCP server uses the user-to-user session key in order to validate 527 the integrity attribute contained within the authentication option, 528 using the method specified in [3]. If the message fails to pass 529 validation, it MUST discard the message and MAY choose to log the 530 validation failure. 532 If the message passes the validation procedure, the server responds as 533 described in [4], including an integrity attribute computed as specified 534 in [3] within the DHCPACK or DHCPNAK message. 536 If the authentication option included within the DHCPREQUEST message 537 contains a ticket attribute then the DHCP server will use the home realm 538 TGT included in the ticket attribute in order to renew the user-to-user 539 ticket, which it returns in an AP_REQ attribute within the DHCPACK. 540 DHCPACK or DHCPNAK messages then include an integrity attribute 541 generated as specified in [3], using the new user-to-user session key 542 included within the AP_REQ. 544 2.3.3. After receiving a DHCPINFORM message 546 The server MAY choose to accept unauthenticated DHCPINFORM messages, or 547 only accept authenticated DHCPINFORM messages based on a site policy. 549 When a client includes an authentication option in a DHCPINFORM message, 550 the server MUST respond with an authenticated DHCPACK or DHCPNAK 551 message. If the DHCPINFORM message includes an authentication option 552 including AP_REQ and integrity attributes, the DHCP server decrypts the 553 AP_REQ attribute and then recovers the session key. The DHCP server than 554 validates the integrity attribute included in the authentication option 555 using the session key. If the integrity attribute is invalid then the 556 DHCP server MUST silently discard the DHCPINFORM message. 558 If the authentication option only includes a ticket attribute and no 559 integrity or AP_REQ attributes, then the DHCP server should assume that 560 the client needs the server to obtain a user-to-user ticket from the 561 home realm KDC. In this case, the DHCP server includes the client home 562 realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC. 563 It then receives a user-to-user ticket from the home realm KDC in a 564 TGS_REP. The DHCP server will then include AP_REQ and integrity 565 attributes within the DHCPACK/DHCPNAK. 567 If the client does not include an authentication option in the 568 DHCPINFORM, the server can either respond with an unauthenticated 569 DHCPACK message, or a DHCPNAK if the server does not accept 570 unauthenticated clients. 572 2.3.4. After receiving a DHCPRELEASE message 574 The DHCP server uses the session key in order to validate the integrity 575 attribute contained within the authentication option, using the method 576 specified in [3]. If the message fails to pass validation, it MUST 577 discard the message and MAY choose to log the validation failure. 579 If the message passes the validation procedure, the server responds as 580 described in [4], marking the client's network address as not allocated. 582 2.3.5. After receiving a DHCPDECLINE message 584 The DHCP server uses the session key in order to validate the integrity 585 attribute contained within the authentication option, using the method 586 specified in [3]. If the message fails to pass validation, it MUST 587 discard the message and MAY choose to log the validation failure. 589 If the message passes the validation procedure, the server proceeds as 590 described in [4]. 592 2.4. Error handling 594 When an error condition occurs during a Kerberos exchange, Kerberos 595 error messages can be returned by either side. These Kerberos error 596 messages MAY be logged by the receiving and sending parties. 598 In some cases, it may be possible for these error messages to be 599 included within the authentication option via the KRB_ERROR attribute. 600 However, in most cases, errors will result in messages being silently 601 discarded and so no response will be returned. 603 For example, if the home KDC returns a KRB_ERROR in response to the 604 AS_REQ submitted by the DHCP server on the client's behalf, then the 605 DHCP server will conclude that the DHCPDISCOVER was not authentic, and 606 will silently discard it. 608 However, if the AS_REQ included PADATA and the home KDC responds with an 609 AS_REP, then the DHCP server can conclude that the client is authentic. 610 If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by 611 the home KDC in the TGS_REP, then the fault may lie with the DHCP server 612 rather than with the client. In this case, the DHCP server MAY choose to 613 return a KRB_ERROR within the authentication option included in the 614 DHCPOFFER. The client will then treat this as an unauthenticated 615 DHCPOFFER. 617 Similarly, if the integrity attribute contained in the DHCPOFFER proves 618 invalid, the client will silently discard the DHCPOFFER and instead 619 accept an offer from another server if one is available. If the 620 integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then 621 the client behaves as if it did not receive a DHCPACK/DHCPNAK. 623 When in INIT-REBOOT, REBINDING or RENEWING state, the client will 624 include a ticket attribute and integrity attribute within the 625 authentication option of the DHCPREQUEST, in order to assist the DHCP 626 server in renewing the user-to-user ticket. If the integrity attribute 627 is invalid, then the DHCP server MUST silently discard the DHCPREQUEST. 629 However, if the integrity attribute is successfully validated by the 630 DHCP server, but the home realm TGT included in the ticket attribute is 631 invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in 632 response to its TGS_REQ to the home KDC. In this case, the DHCP server 633 MAY respond with a DHCPNAK including a KRB_ERROR attribute and no 634 integrity attribute within the authentication option. This will force 635 the client back to the INIT state, where it can receive a valid home 636 realm TGT. 638 Where the client included PADATA in the AS_REQ attribute of the 639 authentication option within the DHCPDISCOVER and the AS_REQ was 640 successfully validated by the KDC, the DHCP server will conclude that 641 the DHCP client is authentic. In this case if the client successfully 642 validates the integrity attribute in the DHCPOFFER, but the server does 643 not validate the integrity attribute in the client's DHCPREQUEST, the 644 server MAY choose to respond with an authenticated DHCPNAK containing a 645 KRB_ERROR attribute. 647 2.5. PKINIT issues 649 When public key authentication is supported with Kerberos as described 650 in [8], the client certificate and a signature accompany the initial 651 request in the pre-authentication fields. As a result, it is 652 conceivable that the incomplete AS_REQ included in the DHCPDISCOVER 653 packet may exceed the size of a single DHCP option, or even the MTU 654 size. As noted in [4], a single option may be as large as 255 octets. 655 If the value to be passed is larger than this the client concatenates 656 together the values of multiple instances of the same option. 658 2.6. Examples 660 2.6.1. INIT state 662 In the intra-realm case where the DHCP Kerberos mutual authentication is 663 successful, the conversation will appear as follows: 665 DHCP DHCP 666 Client Server KDC 667 -------------- ------------- --------- 668 DHCPDISCOVER 669 (Incomplete 670 AS_REQ) -> 671 AS_REQ -> 672 <- AS_REP 673 TGS_REQ 674 U-2-U -> 675 <- TGS_REP 676 <- DHCPOFFER, 677 (AS_REP, 678 AP_REQ, 679 Integrity) 680 DHCPREQUEST 681 (Integrity) -> 682 <- DHCPACK 683 (Integrity) 685 In the case where the KDC returns a KRB_ERROR in response to the AS_REQ, 686 the server will silently discard the DHCPDISCOVER and the conversation 687 will appear as follows: 689 DHCP DHCP 690 Client Server KDC 691 -------------- ------------- --------- 692 DHCPDISCOVER 693 (Incomplete 694 AS_REQ) -> 695 AS_REQ -> 696 <- KRB_ERROR 698 In the inter-realm case where the DHCP Kerberos mutual authentication is 699 successful, the conversation will appear as follows: 701 DHCP DHCP Home Local 702 Client Server KDC KDC 703 -------------- ------------- --------- --------- 704 DHCPDISCOVER 705 (Incomplete 706 AS_REQ) -> 707 AS_REQ -> 708 <- AS_REP 709 TGS_REQ -> 710 (cross realm, 711 for home 712 KDC) 713 <- TGS_REP 715 TGS_REQ 716 U-2-U -> 717 <- TGS_REP 718 <- DHCPOFFER, 719 (AS_REP, 720 AP_REQ, 721 Integrity) 722 DHCPREQUEST 723 (Integrity) -> 724 <- DHCPACK 725 (Integrity) 727 In the case where the client includes PADATA in the AS_REQ attribute 728 within the authentication option of the DHCPDISCOVER and the KDC returns 729 an error-free AS_REP indicating successful validation of the PADATA, the 730 DHCP server will conclude that the DHCP client is authentic. If the KDC 731 then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault 732 that lies with the DHCP server, the server MAY choose not to silently 733 discard the DHCPDISCOVER. Instead it MAY respond with a DHCPOFFER 734 including a KRB_ERROR attribute within the authentication option. The 735 client will then treat this as an unauthenticated DHCPOFFER. 737 The conversation will appear as follows: 739 DHCP DHCP 740 Client Server KDC 741 -------------- ------------- --------- 742 DHCPDISCOVER 743 (Incomplete 744 AS_REQ 745 w/PADATA) -> 746 AS_REQ -> 747 <- AS_REP 748 TGS_REQ 749 U-2-U -> 750 <- KRB_ERROR 751 <- DHCPOFFER, 752 (KRB_ERROR) 753 DHCPREQUEST -> 754 <- DHCPACK 756 In the intra-realm case where the client included PADATA in the AS_REQ 757 attribute of the authentication option and the AS_REQ was successfully 758 validated by the KDC, the DHCP server will conclude that the DHCP client 759 is authentic. In this case if the client successfully validates the 760 integrity attribute in the DHCPOFFER, but the server does not validate 761 the integrity attribute in the client's DHCPREQUEST, the server MAY 762 choose to respond with an authenticated DHCPNAK containing a KRB_ERROR 763 attribute. The conversation will appear as follows: 765 DHCP DHCP 766 Client Server KDC 767 -------------- ------------- --------- 768 DHCPDISCOVER 769 (Incomplete 770 AS_REQ 771 w/PADATA) -> 772 AS_REQ -> 773 <- AS_REP 774 TGS_REQ 775 U-2-U -> 776 <- TGS_REP 777 <- DHCPOFFER, 778 (AS_REP, 779 AP_REQ, 780 Integrity) 781 DHCPREQUEST 782 (Integrity) -> 783 <- DHCNAK 784 (KRB_ERROR, 785 Integrity) 786 DHCPDISCOVER 787 (Incomplete 788 AS_REQ) -> 790 In the intra-realm case where the DHCP client cannot validate the 791 integrity attribute in the DHCPOFFER, the client silently discards the 792 DHCPOFFER. The conversation will appear as follows: 794 DHCP DHCP 795 Client Server KDC 796 -------------- ------------- --------- 797 DHCPDISCOVER 798 (Incomplete 799 AS_REQ) -> 800 AS_REQ -> 801 <- AS_REP 802 TGS_REQ 803 U-2-U -> 804 <- TGS_REP 805 <- DHCPOFFER, 806 (AS_REP, 807 AP_REQ, 808 Integrity) 809 DHCPREQUEST 810 [To another server] 811 (Integrity) -> 813 In the intra-realm case where the DHCP client cannot validate the 814 integrity attribute in the DHCPACK, the client reverts to INIT state. 815 The conversation will appear as follows: 817 DHCP DHCP 818 Client Server KDC 819 -------------- ------------- --------- 820 DHCPDISCOVER 821 (Incomplete 822 AS_REQ) -> 823 AS_REQ -> 824 <- AS_REP 825 TGS_REQ 826 U-2-U -> 827 <- TGS_REP 828 <- DHCPOFFER, 829 (AS_REP, 830 AP_REQ, 831 Integrity) 832 DHCPREQUEST 833 (Integrity) -> 834 <- DHCPACK 835 (Integrity) 836 DHCPDISCOVER 837 (Incomplete 838 AS_REQ) -> 840 2.6.2. INIT-REBOOT, RENEWING or REBINDING 842 In the intra-realm or inter-realm case where the original user-to-user 843 ticket is still valid, and the DHCP server still has a valid TGT to the 844 home realm, the conversation will appear as follows: 846 DHCP DHCP Home 847 Client Server KDC 848 -------------- ------------- --------- 850 DHCPREQUEST 851 (TGT, 852 Integrity) -> 853 TGS_REQ 854 U-2-U -> 855 <- TGS_REP 856 <- DHCPACK 857 (AP_REQ, 858 Integrity) 860 In the intra-realm or inter-realm case where the DHCP server validates 861 the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in 862 response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to 863 silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK 864 to the client instead, using the user-to-user session key previously 865 established with the client. The conversation appears as follows: 867 DHCP DHCP Home 868 Client Server KDC 869 -------------- ------------- --------- 871 DHCPREQUEST 872 (TGT, 873 Integrity) -> 874 TGS_REQ 875 U-2-U -> 876 <- KRB_ERROR 877 <- DHCPNAK 878 (KRB_ERROR, 879 Integrity) 880 DHCPDISCOVER 881 (Incomplete 882 AS_REQ) -> 884 In the intra-realm or inter-realm case where the DHCP server cannot 885 validate the integrity attribute in the DHCPREQUEST, the DHCP server 886 MUST silently discard the DHCPREQUEST and the conversation will appear 887 as follows: 889 DHCP DHCP 890 Client Server KDC 891 -------------- ------------- --------- 893 DHCPREQUEST 894 (TGT, 895 Integrity) -> 896 Silent discard 897 [Sequence repeats 898 until timeout] 900 DHCPDISCOVER 901 (Incomplete 902 AS_REQ) -> 904 In the intra-realm or inter-realm case where the original user-to-user 905 ticket is still valid, the server validates the integrity attribute in 906 the DHCPREQUEST, but the client fails to validate the integrity 907 attribute in the DHCPACK, the client will silently discard the DHCPACK. 908 The conversation will appear as follows: 910 DHCP DHCP 911 Client Server KDC 912 -------------- ------------- --------- 914 DHCPREQUEST 915 (TGT, 916 Integrity) -> 918 <- DHCPACK 919 (AP_REQ, 920 Integrity) 921 DHCPDISCOVER 922 (Incomplete 923 AS_REQ) -> 925 2.6.3. DHCPINFORM (with known DHCP server) 927 In the case where the DHCP client knows the DHCP server it will be 928 interacting with, the DHCP client will obtain a ticket to the DHCP 929 server and will include AP_REQ and integrity attributes within the 930 DHCPINFORM. 932 Where the DHCP Kerberos mutual authentication is successful, the 933 conversation will appear as follows: 935 DHCP DHCP 936 Client Server KDC 937 -------------- ------------- --------- 938 AS_REQ -> 939 <- AS_REP 940 TGS_REQ -> 941 <- TGS_REP 942 DHCPINFORM 943 (AP_REQ, 944 Integrity) -> 945 <- DHCPACK 946 (Integrity) 948 In the inter-realm case where the DHCP Kerberos mutual authentication is 949 successful, the conversation will appear as follows: 951 DHCP DHCP Home Local 952 Client Server KDC KDC 953 -------------- ------------- --------- --------- 954 AS_REQ -> 955 <- AS_REP 956 TGS_REQ -> 957 <- TGS_REP 958 TGS_REQ -> 959 <- TGS_REP 960 DHCPINFORM 961 (AP_REQ, 962 Integrity) -> 963 <- DHCPACK 964 (Integrity) 966 In the inter-realm case where the DHCP server fails to validate the 967 integrity attribute in the DHCPINFORM, the server MUST silently discard 968 the DHCPINFORM. 970 The conversation will appear as follows: 972 DHCP DHCP Home Local 973 Client Server KDC KDC 974 -------------- ------------- --------- --------- 975 AS_REQ -> 976 <- AS_REP 977 TGS_REQ -> 978 <- TGS_REP 979 TGS_REQ -> 980 <- TGS_REP 981 DHCPINFORM 982 (AP_REQ, 983 Integrity) -> 984 <- DHCPACK 985 (Integrity) 986 DHCPINFORM 987 (AP_REQ, 988 Integrity) -> 990 In the inter-realm case where the DHCP client fails to validate the 991 integrity attribute in the DHCPACK, the client MUST silently discard the 992 DHCPACK. The conversation will appear as follows: 994 DHCP DHCP Home Local 995 Client Server KDC KDC 996 -------------- ------------- --------- --------- 997 AS_REQ -> 998 <- AS_REP 999 TGS_REQ -> 1000 <- TGS_REP 1001 TGS_REQ -> 1002 <- TGS_REP 1003 DHCPINFORM 1004 (AP_REQ, 1005 Integrity) -> 1007 2.6.4. DHCPINFORM (with unknown DHCP server) 1009 In the case where the DHCP client does not know the DHCP server it will 1010 be interacting with, the DHCP client will only include a ticket 1011 attribute within the DHCPINFORM. Thus the DHCP server will not be able 1012 to validate the authentication option. 1014 Where the DHCP client is able to validate the DHCPACK and no error 1015 occurs, the conversation will appear as follows: 1017 DHCP DHCP 1018 Client Server KDC 1019 -------------- ------------- --------- 1020 AS_REQ -> 1021 <- AS_REP 1022 DHCPINFORM 1023 (Ticket) -> 1024 TGS_REQ 1025 U-2-U -> 1026 <- TGS_REP 1027 <- DHCPACK 1028 (AP_REQ, 1029 Integrity) 1031 In the inter-realm case where the DHCP server needs to obtain a TGT to 1032 the home realm, and where the client successfully validates the DHCPACK, 1033 the conversation will appear as follows: 1035 DHCP DHCP Home Local 1036 Client Server KDC KDC 1037 -------------- ------------- --------- --------- 1038 AS_REQ -> 1039 <- AS_REP 1040 DHCPINFORM 1041 (Ticket) -> 1042 AS_REQ -> 1043 <- AS_REP 1044 TGS_REQ -> 1045 (cross realm, 1046 for home 1047 KDC) 1048 <- TGS_REP 1050 TGS_REQ 1051 U-2-U -> 1052 <- TGS_REP 1053 <- DHCPACK 1054 (AP_REQ, 1055 Integrity) 1057 In the inter-realm case where the local KDC returns a KRB_ERROR in 1058 response to the TGS_REQ from the DHCP server, the DHCP server MAY return 1059 a KRB_ERROR within the DHCP authentication option included in a DHCPNAK. 1061 The conversation will appear as follows: 1063 DHCP DHCP Home Local 1064 Client Server KDC KDC 1065 -------------- ------------- --------- --------- 1066 AS_REQ -> 1067 <- AS_REP 1068 DHCPINFORM 1069 (Ticket) -> 1070 AS_REQ -> 1071 <- AS_REP 1072 TGS_REQ -> 1073 (cross realm, 1074 for home 1075 KDC) 1076 <- KRB_ERROR 1077 <- DHCPNAK 1078 (KRB_ERROR) 1080 In the inter-realm case where the DHCP client fails to validate the 1081 integrity attribute in the DHCPACK, the client MUST silently discard the 1082 DHCPACK. The conversation will appear as follows: 1084 DHCP DHCP Home Local 1085 Client Server KDC KDC 1086 -------------- ------------- --------- --------- 1087 AS_REQ -> 1088 <- AS_REP 1089 DHCPINFORM 1090 (Ticket) -> 1091 AS_REQ -> 1092 <- AS_REP 1093 TGS_REQ -> 1094 (cross realm, 1095 for home 1096 KDC) 1097 <- TGS_REP 1099 TGS_REQ 1100 U-2-U -> 1101 <- TGS_REP 1102 <- DHCPACK 1103 (AP_REQ, 1104 Integrity) 1105 DHCPINFORM 1106 (Ticket) -> 1108 3. References 1110 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1111 Levels", BCP 14, RFC 2119, March 1997. 1113 [2] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 1114 (V5)", RFC 1510, September 1993. 1116 [3] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", RFC 1117 3118, June 2001. 1119 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1120 1997. 1122 [5] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 1123 Extensions", RFC 2132, March 1997. 1125 [6] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft 1126 (work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt, 1127 November 1998. 1129 [7] IEEE Standards for Local and Metropolitan Area Networks: Port based 1130 Network Access Control, IEEE Std 802.1X-2001, June 2001. 1132 [8] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 1133 J., Trostle, J., "Public Key Cryptography for Initial 1134 Authentication in Kerberos", Internet draft (work in progress), 1135 draft-ietf-cat-kerberos-pk-init-14.txt, July 2001. 1137 [9] Hur, M., Tung, B., Ryutov, T., Neuman, C., Medvinsky, A., Tsudik 1138 G., Sommerfeld, B., "Public Key Cryptography for Cross-Realm 1139 Authentication in Kerberos", Internet draft (work in progress), 1140 draft-ietf-cat-kerberos-pk-cross-07.txt, December 2001. 1142 [10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March 1143 1992. 1145 4. Security Considerations 1147 DHCP authentication, described in [3], addresses the following threats: 1149 Modification of messages 1150 Rogue servers 1151 Unauthorized clients 1153 This section describes how DHCP authentication via Kerberos V addresses 1154 each of these threats. 1156 4.1. Client security 1158 As noted in [3], it may be desirable to ensure that IP addresses are 1159 only allocated to authorized clients. This can serve to protect against 1160 denial of service attacks. To address this issue it is necessary for 1161 DHCP client messages to be authenticated. In order to guard against 1162 message modification, it is also necessary for DHCP client messages to 1163 be integrity protected. 1165 Note that this protocol does not make use of KRB_SAFE, so as to allow 1166 modification of mutable fields by the DHCP relay. Replay protection is 1167 therefore provided within the DHCP authentication option itself. 1169 In DHCP authentication via Kerberos V the DHCP client will authenticate, 1170 integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and 1171 DHCPRELEASE messages using a user-to-user session key obtained by the 1172 DHCP server from the home KDC. If the DHCP client knows the DHCP server 1173 it will be interacting with, then the DHCP client MAY also authenticate, 1174 integrity and replay-protect the DHCPINFORM message using a session key 1175 obtained from the local realm KDC for the DHCP server it expects to 1176 converse with. 1178 Since the client has not yet obtained a session key, DHCPDISCOVER 1179 packets cannot be authenticated using the session key. However, the 1180 client MAY include pre-authentication data in the PADATA field included 1181 in the DHCPDISCOVER packet. Since the PADATA will then be used by the 1182 DHCP server to request a ticket on the client's behalf, the DHCP server 1183 will learn from the AS_REP whether the PADATA was acceptable or not. 1184 Therefore in this case, the DHCPDISCOVER will be authenticated but not 1185 integrity protected. 1187 Where the DHCP client does not know the DHCP server it will be 1188 interacting with ahead of time, the DHCPINFORM message will not be 1189 authenticated, integrity or replay protected. 1191 Note that snooping of PADATA and TGTs on the wire may provide an 1192 attacker with a means of mounting a dictionary attack, since these items 1193 are typically encrypted with a key derived from the user's password. 1194 Thus use of strong passwords and/or pre-authentication methods utilizing 1195 strong cryptography (see [8]) are recommended. 1197 4.2. Network access control 1199 DHCP authentication has been proposed as a method of limiting access to 1200 network media that are not physically secured such as wireless LANs and 1201 ports in college residence halls. However, DHCP is not well suited to 1202 this purpose since even if address allocation is denied an unauthentic 1203 client may use a statically assigned IP address instead, or may attempt 1204 to access the network using non-IP protocols. As a result, other 1205 methods, such as IEEE 802.1X Network Port access control [7], have been 1206 proposed for controlling access to wireless media and switched LANs. 1208 4.3. Server security 1210 As noted in [3], it may be desirable to protect against rogue DHCP 1211 servers put on the network either intentionally or by accident. To 1212 address this issue it is necessary for DHCP server messages to be 1213 authenticated. In order to guard against message modification, it is 1214 also necessary for DHCP server messages to be integrity protected. 1215 Replay protection is also provided within the DHCP authentication 1216 option. 1218 All messages sent by the DHCP server are authenticated and integrity and 1219 replay protected using a session key. This includes the DHCPOFFER, 1220 DHCPACK, and DHCPNAK messages. The session key is used to compute the 1221 DHCP authentication option, which is verified by the client. 1223 In order to provide protection against rogue servers it is necessary to 1224 prevent rogue servers from obtaining the credentials necessary to act as 1225 a DHCP server. As noted in Section 4, the Kerberos principal name for 1226 the DHCP server must be of type KRB_NT_SRV_HST with the service name 1227 component equal to 'dhcp'. The client MUST validate that the DHCP server 1228 principal name has the above format. This convention requires that the 1229 administrator ensure that non-DHCP server principals do not have names 1230 that match the above format. 1232 5. IANA Considerations 1234 This draft does not create any new number spaces for IANA 1235 administration. 1237 Acknowledgments 1239 The authors would like to acknowledge Ralph Droms and William Arbaugh, 1240 authors of the DHCP authentication draft [3]. This draft incorporates 1241 material from their work; however, any mistakes in this document are 1242 solely the responsibility of the authors. 1244 Authors' Addresses 1246 Ken Hornstein 1247 US Naval Research Laboratory 1248 Bldg A-49, Room 2 1249 4555 Overlook Avenue 1250 Washington DC 20375 USA 1252 Phone: +1 (202) 404-4765 1253 EMail: kenh@cmf.nrl.navy.mil 1255 Ted Lemon 1256 Internet Engines, Inc. 1257 950 Charter Street 1258 Redwood City, CA 94063 1260 Phone: +1 (650) 779 6031 1261 Email: mellon@iengines.net 1263 Bernard Aboba 1264 Microsoft Corporation 1265 One Microsoft Way 1266 Redmond, WA 98052 1268 Phone: +1 (425) 936-6605 1269 EMail: bernarda@microsoft.com 1271 Jonathan Trostle 1272 170 W. Tasman Dr. 1273 San Jose, CA 95134, U.S.A. 1275 Email: jtrostle@cisco.com 1276 Phone: +1 (408) 527-6201 1277 Intellectual Property Statement 1279 The IETF takes no position regarding the validity or scope of any 1280 intellectual property or other rights that might be claimed to pertain 1281 to the implementation or use of the technology described in this 1282 document or the extent to which any license under such rights might or 1283 might not be available; neither does it represent that it has made any 1284 effort to identify any such rights. Information on the IETF's 1285 procedures with respect to rights in standards-track and standards- 1286 related documentation can be found in BCP-11. Copies of claims of 1287 rights made available for publication and any assurances of licenses to 1288 be made available, or the result of an attempt made to obtain a general 1289 license or permission for the use of such proprietary rights by 1290 implementors or users of this specification can be obtained from the 1291 IETF Secretariat. 1293 The IETF invites any interested party to bring to its attention any 1294 copyrights, patents or patent applications, or other proprietary rights 1295 which may cover technology that may be required to practice this 1296 standard. Please address the information to the IETF Executive 1297 Director. 1299 Full Copyright Statement 1301 Copyright (C) The Internet Society (2001). All Rights Reserved. 1302 This document and translations of it may be copied and furnished to 1303 others, and derivative works that comment on or otherwise explain it or 1304 assist in its implementation may be prepared, copied, published and 1305 distributed, in whole or in part, without restriction of any kind, 1306 provided that the above copyright notice and this paragraph are included 1307 on all such copies and derivative works. However, this document itself 1308 may not be modified in any way, such as by removing the copyright notice 1309 or references to the Internet Society or other Internet organizations, 1310 except as needed for the purpose of developing Internet standards in 1311 which case the procedures for copyrights defined in the Internet 1312 Standards process must be followed, or as required to translate it into 1313 languages other than English. The limited permissions granted above are 1314 perpetual and will not be revoked by the Internet Society or its 1315 successors or assigns. This document and the information contained 1316 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1317 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1318 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1319 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1321 Expiration Date 1323 This memo is filed as , and 1324 expires May 1, 2002.