idnits 2.17.1 draft-hornstein-dhc-kerbauth-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 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 174 has weird spacing: '... option forma...' == Line 275 has weird spacing: '...w/known w/unk...' == Line 276 has weird spacing: '... server serv...' == Line 476 has weird spacing: '...ends to the h...' == Line 1205 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 1099, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1102, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1112, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (ref. '2') (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: A later version (-16) exists of draft-ietf-dhc-authentication-11 ** Obsolete normative reference: RFC 2002 (ref. '6') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-09 == Outdated reference: A later version (-08) exists of draft-ietf-cat-kerberos-pk-cross-04 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 1305 (ref. '10') (Obsoleted by RFC 5905) -- Possible downref: Normative reference to a draft: ref. '11' Summary: 8 errors (**), 0 flaws (~~), 17 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group Ken Hornstein 2 INTERNET-DRAFT NRL 3 Category: Standards Track Ted Lemon 4 Internet Engines, Inc. 5 20 February 2000 Bernard Aboba 6 Expires: September 1, 2000 Microsoft 7 Jonathan Trostle 8 Cisco Systems 10 DHCP Authentication Via Kerberos V 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet- Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 The distribution of this memo is unlimited. 32 1. Copyright Notice 34 Copyright (C) The Internet Society (2000). All Rights Reserved. 36 2. Abstract 38 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for 39 host configuration. In some circumstances, it is useful for the DHCP 40 client and server to be able to mutually authenticate as well as to 41 guarantee the integrity of DHCP packets in transit. This document 42 describes how Kerberos V may be used in order to allow a DHCP client and 43 server to mutually authenticate as well as to protect the integrity of 44 the DHCP exchange. The protocol described in this document is capable of 45 handling both intra-realm and inter-realm authentication. 47 3. Introduction 49 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for 50 host configuration. In some circumstances, it is useful for the DHCP 51 client and server to be able to mutually authenticate as well as to 52 guarantee the integrity of DHCP packets in transit. This document 53 describes how Kerberos V may be used in order to allow a DHCP client and 54 server to mutually authenticate as well as to protect the integrity of 55 the DHCP exchange. The protocol described in this document is capable 56 of handling both intra-realm and inter-realm authentication. 58 3.1. Terminology 60 This document uses the following terms: 62 DHCP client 63 A DHCP client or "client" is an Internet host using DHCP to 64 obtain configuration parameters such as a network address. 66 DHCP server 67 A DHCP server or "server" is an Internet host that returns 68 configuration parameters to DHCP clients. 70 Home KDC The KDC corresponding to the DHCP client's realm. 72 Local KDC The KDC corresponding to the DHCP server's realm. 74 3.2. Requirements language 76 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 77 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 78 described in [1]. 80 4. Protocol overview 82 In DHCP authentication via Kerberos V, DHCP clients and servers utilize 83 a Kerberos session key in order to compute a message integrity check 84 value included within the DHCP authentication option. The message 85 integrity check serves to authenticate as well as integrity protect the 86 messages, while remaining compatible with the operation of a DHCP relay. 87 Replay protection is also provided by a replay counter within the 88 authentication option, as described in [3]. 90 Each server maintains a list of session keys and identifiers for 91 clients, so that the server can retrieve the session key and identifier 92 used by a client to which the server has provided previous configuration 93 information. Each server MUST save the replay counter from the previous 94 authenticated message. To avoid replay attacks, the server MUST discard 95 any incoming message whose replay counter is not strictly greater than 96 the replay counter from the previous message. 98 DHCP authentication, described in [3], must work within the existing 99 DHCP state machine described in [4]. For a client in INIT state, this 100 means that the client must obtain a valid TGT, as well as a session key, 101 within the two round-trips provided by the 102 DHCPDISCOVER/OFFER/REQUEST/ACK sequence. 104 In INIT state, the DHCP client submits an incomplete AS_REQ to the DHCP 105 server within the DHCPDISCOVER message. The DHCP server then completes 106 the AS_REQ using the IP address to be assigned to the client, and 107 submits this to the client's home KDC in order to obtain a TGT on the 108 client's behalf. Once the home KDC responds with an AS_REP, the DHCP 109 server extracts the client TGT and submits this along with its own TGT 110 to the home KDC, in order to obtain a user-to-user ticket to the DHCP 111 client. The AS_REP as well as the AP_REQ are included by the DHCP server 112 in the DHCPOFFER. The DHCP client can then decrypt the AS_REP to obtain 113 a home realm TGT and TGT session key, using the latter to decrypt the 114 user-to-user ticket to obtain the user-to-user session key. It is the 115 user-to-user session key that is used to authenticate and integrity 116 protect the client's DHCPREQUEST, and DHCPDECLINE messages. Similarly, 117 this same session key is used to compute the integrity attribute in the 118 server's DHCPOFFER, DHCPACK and DHCPNAK messages, as described in [3]. 120 In the INIT-REBOOT, REBINDING, or RENEWING states, the server can submit 121 the home realm TGT in the DHCPREQUEST, along with authenticating and 122 integrity protecting the message using an integrity attribute within the 123 authentication option. The integrity attribute is computed using the 124 existing session key. The DHCP server can then return a renewed user- 125 to-user ticket within the DHCPACK message. The authenticated DHCPREQUEST 126 message from a client in INIT-REBOOT state can only be validated by 127 servers that used the same session key to compute the integrity 128 attribute in their DHCPOFFER messages. 130 Other servers will discard the DHCPREQUEST messages. Thus, only servers 131 that used the user-to-user session key selected by the client will be 132 able to determine that their offered configuration information was not 133 selected, returning the offered network address to the server's pool of 134 available addresses. The servers that cannot validate the DHCPREQUEST 135 message will eventually return their offered network addresses to their 136 pool of available addresses as described in section 3.1 of the DHCP 137 specification [4]. 139 When sending a DHCPINFORM, there are two possible procedures. If the 140 client knows the DHCP server it will be interacting with, then it can 141 obtain a ticket to the DHCP server from the local realm KDC. This will 142 require obtaining a TGT to its home realm, as well as possibly a cross- 143 realm TGT to the local realm if the local and home realms differ. Once 144 the DHCP client has a local realm TGT, it can then request a DHCP server 145 ticket in a TGS_REQ. The DHCP client can then include AP_REQ and 146 integrity attributes within the DHCPINFORM. The integrity attribute is 147 computed as described in [3], using the session key obtained from the 148 TGS_REP. The DHCP server replies with a DHCPACK/DHCPNAK, authenticated 149 using the same session key. 151 If the DHCP client does not know the DHCP server it is interacting with 152 then it will not be able to obtain a ticket to it and a different 153 procedure is needed. In this case, the client will include in the 154 DHCPINFORM an authentication option with a ticket attribute containing 155 its home realm TGT. The DHCP server will then use this TGT in order to 156 request a user-to-user ticket from the home KDC in a TGS_REQ. The DHCP 157 server will return the user-to-user ticket and will authenticate and 158 integrity protect the DHCPACK/DHCPNAK message. This is accomplished by 159 including AP_REQ and integrity attributes within the authentication 160 option included with the DHCPACK/DHCPNAK messages. 162 In order to support the DHCP client's ability to authenticate the DHCP 163 server in the case where the server name is unknown, the Kerberos 164 principal name for the DHCP server must be of type KRB_NT_SRV_HST with 165 the service name component equal to 'dhcp'. For example, the DHCP server 166 principal name for the host srv.foo.org would be of the form 167 dhcp/srv.foo.org. The client MUST validate that the DHCP server 168 principal name has the above format. This convention requires that the 169 administrator ensure that non-DHCP server principals do not have names 170 that match the above format. 172 4.1. Authentication Option Format 174 A summary of the authentication option format for DHCP authentication 175 via Kerberos V is shown below. The fields are transmitted from left to 176 right. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Code | Length | Protocol | Algorithm | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Global Replay Counter | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Global Replay Counter | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Attributes... 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Code 191 TBD - DHCP Authentication 193 Length 195 The length field is a single octet and indicates the length of the 196 Protocol, Algorith, and Authentication Information fields. Octets 197 outside the range of the length field should be ignored on reception. 199 Protocol 201 TBD - DHCP Kerberos V authentication 203 Algorithm 205 The algorithm field is a single octet and defines the specific 206 algorithm to be used for computation of the authentication option. 207 Values for the field are as follows: 209 0 - reserved 210 1 - HMAC-MD5 211 2 - HMAC-SHA 212 3 - 255 reserved 214 Global Replay Counter 216 As described in [3], the global replay counter field is 8 octets in 217 length. It MUST be set to the value of a monotonically increasing 218 counter. Using a counter value such as the current time of day (e.g., 219 an NTP-format timestamp [10]) can reduce the danger of replay 220 attacks. 222 Attributes 224 The attributes field consists of type-length-value attributes of the 225 following format: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type | Reserved | Payload Length | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Attribute value... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Type 236 The type field is a single octet and is defined as follows: 238 0 - Integrity check 239 1 - TICKET 240 2 - Authenticator 241 3 - EncTicketPart 242 10 - AS_REQ 243 11 - AS_REP 244 12 - TGS_REQ 245 13 - TGS_REP 246 14 - AP_REQ 247 15 - AP_REP 248 20 - KRB_SAFE 249 21 - KRB_PRIV 250 22 - KRB_CRED 251 25 - EncASRepPart 252 26 - EncTGSRepPart 253 27 - EncAPRepPart 254 28 - EncKrbPrvPart 255 29 - EncKrbCredPart 256 30 - KRB_ERROR 258 Note that the values of the Type field are the same as in the 259 Kerberos MSG-TYPE field. As a result, no new number spaces are 260 created for IANA administration. 262 The following attribute types are allowed within the following 263 messages: 265 DISCOVER OFFER REQUEST DECLINE # Attribute 266 -------------------------------------------------------- 267 0 1 1 1 0 Integrity check 268 0 0 0-1 0 1 Ticket 269 1 0 0 0 10 AS_REQ 270 0 1 0 0 11 AS_REP 271 0 1 0 0 14 AP_REQ 272 0 0-1 0 0 30 KRB_ERROR 274 RELEASE ACK NAK INFORM INFORM # Attribute 275 w/known w/unknown 276 server server 277 --------------------------------------------------------------- 278 1 1 1 1 0 0 Integrity check 279 0 0 0 0 1 1 Ticket 280 0 0 0 0 0 10 AS_REQ 281 0 0 0 0 0 11 AS_REP 282 0 0-1 0 1 0 14 AP_REQ 283 0 0 0-1 0 0 30 KRB_ERROR 285 4.2. Client behavior 287 The following section, which incorporates material from [3], describes 288 client behavior in detail. 290 4.2.1. INIT state 292 When in INIT state, the client behaves as follows: 294 [1] As described in [3], the client MUST include the authentication 295 request option in its DHCPDISCOVER message along with option 61 296 [11] to identify itself uniquely to the server. An AS_REQ attribute 297 MUST be included within the authentication request option. This 298 (incomplete) AS_REQ will set the FORWARDABLE and RENEWABLE flags 299 and MAY include pre-authentication data (PADATA) if the client 300 knows what PADATA its home KDC will require. The ADDRESSES field in 301 the AS_REQ will be ommitted since the client does not yet know its 302 IP address. The ETYPE field will be set to an encryption type that 303 the client can accept. 305 [2] The client MUST validate DHCPOFFER messages that include an 306 authentication option. Messages including an authentication option 307 with a KRB_ERROR attribute and no integrity attribute are treated 308 as though they are unauthenticated. More typically, authentication 309 options within the DHCPOFFER message will include AS_REP, AP_REQ, 310 and integrity attributes. To validate the authentication option, 311 the client decrypts the enc-part of the AS_REP in order to obtain 312 the TGT session key. This is used to decrypt the enc-part of the 313 AP_REQ in order to obtain the user-to-user session key. The user- 314 to-user session key is then used to compute the message integrity 315 check as described in [3], and the computed value is compared to 316 the value within the integrity attribute. The client MUST discard 317 any messages which fail to pass validation and MAY log the 318 validation failure. 320 As described in [3], the client selects one DHCPOFFER message as 321 its selected configuration. If none of the DHCPOFFER messages 322 received by the client include an authentication option, the client 323 MAY choose an unauthenticated message as its selected 324 configuration. DHCPOFFER messages including an authentication 325 option with a KRB_ERROR attribute and no integrity attribute are 326 treated as though they are unauthenticated. The client SHOULD be 327 configurable to accept or reject unauthenticated DHCPOFFER 328 messages. 330 [3] The client replies with a DHCPREQUEST message that MUST include an 331 authentication option. The authentication option MUST include an 332 integrity attribute, computed as described in [3], using the user 333 to user session key recovered in step 2. 335 [4] As noted in [3], the client MUST validate a DHCPACK message from 336 the server that includes an authentication option. DHCPACK or 337 DHCPNAK messages including an authentication option with a 338 KRB_ERROR attribute and no integrity attribute are treated as 339 though they are unauthenticated. The client MUST silently discard 340 the DHCPACK if the message fails to pass validation and MAY log the 341 validation failure. If the DHCPACK fails to pass validation, the 342 client MUST revert to the INIT state and return to step 1. The 343 client MAY choose to remember which server replied with an invalid 344 DHCPACK message and discard subsequent messages from that server. 346 4.2.2. INIT-REBOOT state 348 When in INIT-REBOOT state, if the user-to-user ticket is still valid, 349 the client MUST re-use the session key from the DHCP server user-to-user 350 ticket in its DHCPREQUEST message. This is used to generate the 351 integrity attribute contained within the authentication option, as 352 described in [3]. In the DHCPREQUEST, the DHCP client also includes its 353 home realm TGT in a ticket attribute in the authentication option in 354 order to assist the DHCP server in renewing the user-to-user ticket. To 355 ensure that the user-to-user ticket remains valid throughout the DHCP 356 lease period so that the renewal process can proceed, the Kerberos 357 ticket lifetime SHOULD be set to exceed the DHCP lease time. If the 358 user-to-user ticket is expired, then the client MUST return to the INIT 359 state. 361 The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages 362 if no authenticated messages were received. DHCPACK/DHCPNAK messages 363 with an authentication option containing a KRB_ERROR attribute and no 364 integrity attribute are treated as though they are unauthenticated. The 365 client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK 366 messages as specified in section 3.2 of the DHCP specification [4]. 368 4.2.3. RENEWING state 370 When in RENEWING state, the DHCP client can be assumed to have a valid 371 IP address, as well as a TGT to the home realm, a user-to-user ticket 372 provided by the DHCP server, and a session key with the DHCP server, all 373 obtained during the original DHCP conversation. If the user-to-user 374 ticket is still valid, the client MUST re-use the session key from the 375 user-to-user ticket in its DHCPREQUEST message to generate the integrity 376 attribute contained within the authentication option. 378 Since the DHCP client can renew the TGT to the home realm, it is 379 possible for it to continue to hold a valid home realm TGT. However, 380 since the DHCP client did not obtain the user-to-user ticket on its own, 381 it will need to rely on the DHCP server to renew this ticket. In the 382 DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket 383 attribute in the authentication option in order to assist the DHCP 384 server in renewing the user-to-user ticket. 386 If the DHCP server user-to-user ticket is expired, then the client MUST 387 return to INIT state. To ensure that the user-to-user ticket remains 388 valid throughout the DHCP lease period so that the renewal process can 389 proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP 390 lease time. If client receives no DHCPACK messages or none of the 391 DHCPACK messages pass validation, the client behaves as if it had not 392 received a DHCPACK message in section 4.4.5 of the DHCP specification 393 [4]. 395 4.2.4. REBINDING state 397 When in REBINDING state, the DHCP client can be assumed to have a valid 398 IP address, as well as a TGT to the home realm, a user-to-user ticket 399 and a session key with the DHCP server, all obtained during the original 400 DHCP conversation. If the user-to-user ticket is still valid, the 401 client MUST re-use the session key from the user-to-user ticket in its 402 DHCPREQUEST message to generate the integrity attribute contained within 403 the authentication option, as described in [3]. 405 Since the DHCP client can renew the TGT to the home realm, it is 406 possible for it to continue to hold a valid home realm TGT. However, 407 since the DHCP client did not obtain the user-to-user ticket on its own, 408 it will need to rely on the DHCP server to renew this ticket. In the 409 DHCPREQUEST, the DHCP client includes its home realm TGT in a ticket 410 attribute in the authentication option in order to assist the DHCP 411 server in renewing the user-to-user ticket. 413 If the user-to-user ticket is expired, then the client MUST return to 414 INIT state. To ensure that the user-to-user ticket remains valid 415 throughout the DHCP lease period so that the renewal process can 416 proceed, the Kerberos ticket lifetime SHOULD be set to exceed the DHCP 417 lease time. If client receives no DHCPACK messages or none of the 418 DHCPACK messages pass validation, the client behaves as if it had not 419 received a DHCPACK message in section 4.4.5 of the DHCP specification 420 [4]. 422 4.2.5. DHCPRELEASE message 424 Clients sending a DHCPRELEASE MUST include an authentication option. The 425 authentication option MUST include an integrity attribute, computed as 426 described in [3], using the user to user session key. 428 4.2.6. DHCPDECLINE message 430 Clients sending a DHCPDECLINE MUST include an authentication option. The 431 authentication option MUST include an integrity attribute, computed as 432 described in [3], using the user to user session key. 434 4.2.7. DHCPINFORM message 436 Since the client already has some configuration information, it can be 437 assumed that it has the ability to obtain a home or local realm TGT 438 prior to sending the DHCPINFORM. 440 If the DHCP client knows which DHCP server it will be interacting with, 441 then it SHOULD include an authentication option containing AP_REQ and 442 integrity attributes within the DHCPINFORM. The DHCP client first 443 requests a TGT to the local realm via an AS_REQ and then using the TGT 444 returned in the AS_REP to request a ticket to the DHCP server from the 445 local KDC in a TGS_REQ. The session key obtained from the TGS_REP will 446 be used to generate the integrity attribute as described in [3]. 448 If the DHCP client does not know what DHCP server it will be talking to, 449 then it cannot obtain a ticket to the DHCP server. In this case, the 450 DHCP client MAY send an unauthenticated DHCPINFORM or it MAY include an 451 authentication option including a ticket attribute only. The ticket 452 attribute includes a TGT for the home realm. The client MUST validate 453 that the DHCP server name in the received Kerberos AP_REQ message is of 454 the form dhcp/.... as described in section 4. 456 The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK messages 457 if no authenticated messages were received. DHCPACK/DHCPNAK messages 458 with an authentication option containing a KRB_ERROR attribute and no 459 integrity attribute are treated as though they are unauthenticated. The 460 client MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK 461 messages as specified in section 3.2 of the DHCP specification [4]. 463 4.3. Server behavior 465 This section, which relies on material from [3], describes the behavior 466 of a server in response to client messages. 468 4.3.1. After receiving a DHCPDISCOVER message 470 For installations where IP addresses are required within tickets, the 471 DHCP server MAY complete the AS_REQ by filling in the ADDRESSES field 472 based on the IP address that it will include in the DHCPOFFER. The DHCP 473 server sends the AS_REQ to the home KDC with the FORWARDABLE flag set. 474 The home KDC then replies to the DHCP server with an AS_REP. The DHCP 475 server extracts the client TGT from the AS_REP and forms a TGS_REQ, 476 which it sends to the home KDC. 478 If the DHCP server and client are in different realms, then the DHCP 479 server will need to obtain a TGT to the home realm from the KDC of its 480 own (local) realm prior to sending the TGS_REQ. The TGS_REQ includes the 481 DHCP server's TGT within the home realm, has the ENC-TKT-IN-SKEY flag 482 set and includes the client home realm TGT in the ADDITIONAL-TICKETS 483 field, thus requesting a user-to ticket to the DHCP client. The home 484 KDC then returns a user-to-user ticket in a TGS_REP. The user-to-user 485 ticket is encrypted in the client's home realm TGT session key. 487 In order to recover the user-to-user session key, the DHCP server 488 decrypts the enc-part of the TGS_REP. To accomplish this, the DHCP 489 server uses the session key that it shares with the home realm, obtained 490 in the AS_REQ/AS_REP conversation that it used to obtain its own TGT to 491 the home realm. 493 The DHCP server then sends a DHCPOFFER to the client, including AS_REP, 494 AP_REQ and integrity attributes within the authentication option. The 495 AS_REP attribute encapsulates the AS_REP sent to the DHCP server by the 496 home KDC. The AP_REQ attribute includes an AP_REQ constructed by the 497 DHCP server based on the TGS_REP sent to it by the home KDC. The server 498 also includes an integrity attribute generated as specified in [3] from 499 the user-to-user session key. The server MUST record the user-to-user 500 session key selected for the client and use that session key for 501 validating subsequent messages with the client. 503 4.3.2. After receiving a DHCPREQUEST message 505 The DHCP server uses the user-to-user session key in order to validate 506 the integrity attribute contained within the authentication option, 507 using the method specified in [3]. If the message fails to pass 508 validation, it MUST discard the message and MAY choose to log the 509 validation failure. 511 If the message passes the validation procedure, the server responds as 512 described in [4], including an integrity attribute computed as specified 513 in [3] within the DHCPACK or DHCPNAK message. 515 If the authentication option included within the DHCPREQUEST message 516 contains a ticket attribute then the DHCP server will use the home realm 517 TGT included in the ticket attribute in order to renew the user-to-user 518 ticket, which it returns in an AP_REQ attribute within the DHCPACK. 519 DHCPACK or DHCPNAK messages then include an integrity attribute 520 generated as specified in [3], using the new user-to-user session key 521 included within the AP_REQ. 523 4.3.3. After receiving a DHCPINFORM message 525 The server MAY choose to accept unauthenticated DHCPINFORM messages, or 526 only accept authenticated DHCPINFORM messages based on a site policy. 528 When a client includes an authentication option in a DHCPINFORM message, 529 the server MUST respond with an authenticated DHCPACK or DHCPNAK 530 message. If the DHCPINFORM message includes an authentication option 531 including AP_REQ and integrity attributes, the DHCP server decrypts the 532 AP_REQ attribute and then recovers the session key. The DHCP server than 533 validates the integrity attribute included in the authentication option 534 using the session key. If the integrity attribute is invalid then the 535 DHCP server MUST silently discard the DHCPINFORM message. 537 If the authentication option only includes a ticket attribute and no 538 integrity or AP_REQ attributes, then the DHCP server should assume that 539 the client needs the server to obtain a user-to-user ticket from the 540 home realm KDC. In this case, the DHCP server includes the client home 541 realm TGT and its own home realm TGT in a TGS_REQ to the home realm KDC. 542 It then receives a user-to-user ticket from the home realm KDC in a 543 TGS_REP. The DHCP server will then include AP_REQ and integrity 544 attributes within the DHCPACK/DHCPNAK. 546 If the client does not include an authentication option in the 547 DHCPINFORM, the server can either respond with an unauthenticated 548 DHCPACK message, or a DHCPNAK if the server does not accept 549 unauthenticated clients. 551 4.3.4. After receiving a DHCPRELEASE message 553 The DHCP server uses the session key in order to validate the integrity 554 attribute contained within the authentication option, using the method 555 specified in [3]. If the message fails to pass validation, it MUST 556 discard the message and MAY choose to log the validation failure. 558 If the message passes the validation procedure, the server responds as 559 described in [4], marking the client's network address as not allocated. 561 4.3.5. After receiving a DHCPDECLINE message 563 The DHCP server uses the session key in order to validate the integrity 564 attribute contained within the authentication option, using the method 565 specified in [3]. If the message fails to pass validation, it MUST 566 discard the message and MAY choose to log the validation failure. 568 If the message passes the validation procedure, the server proceeds as 569 described in [4]. 571 4.4. Error handling 573 When an error condition occurs during a Kerberos exchange, Kerberos 574 error messages can be returned by either side. These Kerberos error 575 messages MAY be logged by the receiving and sending parties. 577 In some cases, it may be possible for these error messages to be 578 included within the authentication option via the KRB_ERROR attribute. 579 However, in most cases, errors will result in messages being silently 580 discarded and so no response will be returned. 582 For example, if the home KDC returns a KRB_ERROR in response to the 583 AS_REQ submitted by the DHCP server on the client's behalf, then the 584 DHCP server will conclude that the DHCPDISCOVER was not authentic, and 585 will silently discard it. 587 However, if the AS_REQ included PADATA and the home KDC responds with an 588 AS_REP, then the DHCP server can conclude that the client is authentic. 589 If the subsequent TGS_REQ is unsuccessful, with a KRB_ERROR returned by 590 the home KDC in the TGS_REP, then the fault may lie with the DHCP server 591 rather than with the client. In this case, the DHCP server MAY choose to 592 return a KRB_ERROR within the authentication option included in the 593 DHCPOFFER. The client will then treat this as an unauthenticated 594 DHCPOFFER. 596 Similarly, if the integrity attribute contained in the DHCPOFFER proves 597 invalid, the client will silently discard the DHCPOFFER and instead 598 accept an offer from another server if one is available. If the 599 integrity attribute included in the DHCPACK/DHCPNAK proves invalid, then 600 the client behaves as if it did not receive a DHCPACK/DHCPNAK. 602 When in INIT-REBOOT, REBINDING or RENEWING state, the client will 603 include a ticket attribute and integrity attribute within the 604 authentication option of the DHCPREQUEST, in order to assist the DHCP 605 server in renewing the user-to-user ticket. If the integrity attribute 606 is invalid, then the DHCP server MUST silently discard the DHCPREQUEST. 608 However, if the integrity attribute is successfully validated by the 609 DHCP server, but the home realm TGT included in the ticket attribute is 610 invalid (e.g. expired), then the DHCP server will receive a KRB_ERROR in 611 response to its TGS_REQ to the home KDC. In this case, the DHCP server 612 MAY respond with a DHCPNAK including a KRB_ERROR attribute and no 613 integrity attribute within the authentication option. This will force 614 the client back to the INIT state, where it can receive a valid home 615 realm TGT. 617 Where the client included PADATA in the AS_REQ attribute of the 618 authentication option within the DHCPDISCOVER and the AS_REQ was 619 successfully validated by the KDC, the DHCP server will conclude that 620 the DHCP client is authentic. In this case if the client successfully 621 validates the integrity attribute in the DHCPOFFER, but the server does 622 not validate the integrity attribute in the client's DHCPREQUEST, the 623 server MAY choose to respond with an authenticated DHCPNAK containing a 624 KRB_ERROR attribute. 626 4.5. PKINIT issues 628 When public key authentication is supported with Kerberos as described 629 in [8], the client certificate and a signature accompany the initial 630 request in the preauthentication fields. As a result, it is conceivable 631 that the incomplete AS_REQ included in the DHCPDISCOVER packet may 632 exceed the size of a single DHCP option, or even the MTU size. As noted 633 in [4], a single option may be as large as 255 octets. If the value to 634 be passed is larger than this the client concatenates together the 635 values of multiple instances of the same option. 637 4.6. Examples 639 4.6.1. INIT state 641 In the intra-realm case where the DHCP Kerberos mutual authentication is 642 successful, the conversation will appear as follows: 644 DHCP DHCP 645 Client Server KDC 646 -------------- ------------- --------- 647 DHCPDISCOVER 648 (Incomplete 649 AS_REQ) -> 650 AS_REQ -> 651 <- AS_REP 652 TGS_REQ 653 U-2-U -> 654 <- TGS_REP 655 <- DHCPOFFER, 656 (AS_REP, 657 AP_REQ, 658 Integrity) 659 DHCPREQUEST 660 (Integrity) -> 661 <- DHCPACK 662 (Integrity) 664 In the case where the KDC returns a KRB_ERROR in response to the AS_REQ, 665 the server will silently discard the DHCPDISCOVER and the conversation 666 will appear as follows: 668 DHCP DHCP 669 Client Server KDC 670 -------------- ------------- --------- 671 DHCPDISCOVER 672 (Incomplete 673 AS_REQ) -> 674 AS_REQ -> 675 <- KRB_ERROR 677 In the inter-realm case where the DHCP Kerberos mutual authentication is 678 successful, the conversation will appear as follows: 680 DHCP DHCP Home Local 681 Client Server KDC KDC 682 -------------- ------------- --------- --------- 683 DHCPDISCOVER 684 (Incomplete 685 AS_REQ) -> 686 AS_REQ -> 687 <- AS_REP 688 TGS_REQ -> 689 (cross realm, 690 for home 691 KDC) 692 <- TGS_REP 694 TGS_REQ 695 U-2-U -> 696 <- TGS_REP 697 <- DHCPOFFER, 698 (AS_REP, 699 AP_REQ, 700 Integrity) 701 DHCPREQUEST 702 (Integrity) -> 703 <- DHCPACK 704 (Integrity) 706 In the case where the client includes PADATA in the AS_REQ attribute 707 within the authentication option of the DHCPDISCOVER and the KDC returns 708 an error-free AS_REP indicating successful validation of the PADATA, the 709 DHCP server will conclude that the DHCP client is authentic. If the KDC 710 then returns a KRB_ERROR in response to the TGS_REQ, indicating a fault 711 that lies with the DHCP server, the server MAY choose not to silently 712 discard the DHCPDISCOVER. Instead it MAY respond with a DHCPOFFER 713 including a KRB_ERROR attribute within the authentication option. The 714 client will then treat this as an unauthenticated DHCPOFFER. The 715 conversation will appear as follows: 717 DHCP DHCP 718 Client Server KDC 719 -------------- ------------- --------- 720 DHCPDISCOVER 721 (Incomplete 722 AS_REQ 723 w/PADATA) -> 724 AS_REQ -> 725 <- AS_REP 726 TGS_REQ 727 U-2-U -> 728 <- KRB_ERROR 729 <- DHCPOFFER, 730 (KRB_ERROR) 731 DHCPREQUEST -> 732 <- DHCPACK 734 In the intra-realm case where the client included PADATA in the AS_REQ 735 attribute of the authentication option and the AS_REQ was successfully 736 validated by the KDC, the DHCP server will conclude that the DHCP client 737 is authentic. In this case if the client successfully validates the 738 integrity attribute in the DHCPOFFER, but the server does not validate 739 the integrity attribute in the client's DHCPREQUEST, the server MAY 740 choose to respond with an authenticated DHCPNAK containing a KRB_ERROR 741 attribute. The conversation will appear as follows: 743 DHCP DHCP 744 Client Server KDC 745 -------------- ------------- --------- 746 DHCPDISCOVER 747 (Incomplete 748 AS_REQ 749 w/PADATA) -> 750 AS_REQ -> 751 <- AS_REP 752 TGS_REQ 753 U-2-U -> 754 <- TGS_REP 755 <- DHCPOFFER, 756 (AS_REP, 757 AP_REQ, 758 Integrity) 759 DHCPREQUEST 760 (Integrity) -> 761 <- DHCNAK 762 (KRB_ERROR, 763 Integrity) 764 DHCPDISCOVER 765 (Incomplete 766 AS_REQ) -> 768 In the intra-realm case where the DHCP client cannot validate the 769 integrity attribute in the DHCPOFFER, the client silently discards the 770 DHCPOFFER. The conversation will appear as follows: 772 DHCP DHCP 773 Client Server KDC 774 -------------- ------------- --------- 775 DHCPDISCOVER 776 (Incomplete 777 AS_REQ) -> 778 AS_REQ -> 779 <- AS_REP 780 TGS_REQ 781 U-2-U -> 782 <- TGS_REP 783 <- DHCPOFFER, 784 (AS_REP, 785 AP_REQ, 786 Integrity) 787 DHCPREQUEST 789 [To another server] 790 (Integrity) -> 792 In the intra-realm case where the DHCP client cannot validate the 793 integrity attribute in the DHCPACK, the client reverts to INIT state. 794 The conversation will appear as follows: 796 DHCP DHCP 797 Client Server KDC 798 -------------- ------------- --------- 799 DHCPDISCOVER 800 (Incomplete 801 AS_REQ) -> 802 AS_REQ -> 803 <- AS_REP 804 TGS_REQ 805 U-2-U -> 806 <- TGS_REP 807 <- DHCPOFFER, 808 (AS_REP, 809 AP_REQ, 810 Integrity) 811 DHCPREQUEST 812 (Integrity) -> 813 <- DHCPACK 814 (Integrity) 815 DHCPDISCOVER 816 (Incomplete 817 AS_REQ) -> 819 4.6.2. INIT-REBOOT, RENEWING or REBINDING 821 In the intra-realm or inter-realm case where the original user-to-user 822 ticket is still valid, and the DHCP server still has a valid TGT to the 823 home realm, the conversation will appear as follows: 825 DHCP DHCP Home 826 Client Server KDC 827 -------------- ------------- --------- 829 DHCPREQUEST 830 (TGT, 831 Integrity) -> 832 TGS_REQ 833 U-2-U -> 834 <- TGS_REP 835 <- DHCPACK 836 (AP_REQ, 837 Integrity) 839 In the intra-realm or inter-realm case where the DHCP server validates 840 the integrity attribute in the DHCPREQUEST, but receives a KRB_ERROR in 841 response to the TGS_REQ to the KDC, the DHCP sever MAY choose not to 842 silently discard the DHCPREQUEST and MAY return an authenticated DHCPNAK 843 to the client instead, using the user-to-user session key previously 844 established with the client. The conversation appears 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 <- KRB_ERROR 856 <- DHCPNAK 857 (KRB_ERROR, 858 Integrity) 859 DHCPDISCOVER 860 (Incomplete 861 AS_REQ) -> 863 In the intra-realm or inter-realm case where the DHCP server cannot 864 validate the integrity attribute in the DHCPREQUEST, the DHCP server 865 MUST silently discard the DHCPREQUEST and the conversation will appear 866 as follows: 868 DHCP DHCP 869 Client Server KDC 870 -------------- ------------- --------- 872 DHCPREQUEST 873 (TGT, 874 Integrity) -> 875 Silent discard 876 [Sequence repeats 877 until timeout] 879 DHCPDISCOVER 880 (Incomplete 881 AS_REQ) -> 883 In the intra-realm or inter-realm case where the original user-to-user 884 ticket is still valid, the server validates the integrity attribute in 885 the DHCPREQUEST, but the client fails to validate the integrity 886 attribute in the DHCPACK, the client will silently discard the DHCPACK. 887 The conversation will appear as follows: 889 DHCP DHCP 890 Client Server KDC 891 -------------- ------------- --------- 893 DHCPREQUEST 894 (TGT, 895 Integrity) -> 897 <- DHCPACK 898 (AP_REQ, 899 Integrity) 900 DHCPDISCOVER 901 (Incomplete 902 AS_REQ) -> 904 4.6.3. DHCPINFORM (with known DHCP server) 906 In the case where the DHCP client knows the DHCP server it will be 907 interacting with, the DHCP client will obtain a ticket to the DHCP 908 server and will include AP_REQ and integrity attributes within the 909 DHCPINFORM. 911 Where the DHCP Kerberos mutual authentication is successful, the 912 conversation will appear as follows: 914 DHCP DHCP 915 Client Server KDC 916 -------------- ------------- --------- 917 AS_REQ -> 918 <- AS_REP 919 TGS_REQ -> 920 <- TGS_REP 921 DHCPINFORM 922 (AP_REQ, 923 Integrity) -> 924 <- DHCPACK 925 (Integrity) 927 In the inter-realm case where the DHCP Kerberos mutual authentication is 928 successful, the conversation will appear as follows: 930 DHCP DHCP Home Local 931 Client Server KDC KDC 932 -------------- ------------- --------- --------- 933 AS_REQ -> 934 <- AS_REP 935 TGS_REQ -> 936 <- TGS_REP 937 TGS_REQ -> 938 <- TGS_REP 939 DHCPINFORM 940 (AP_REQ, 941 Integrity) -> 942 <- DHCPACK 943 (Integrity) 945 In the inter-realm case where the DHCP server fails to validate the 946 integrity attribute in the DHCPINFORM, the server MUST silently discard 947 the DHCPINFORM. The conversation will appear as follows: 949 DHCP DHCP Home Local 950 Client Server KDC KDC 951 -------------- ------------- --------- --------- 952 AS_REQ -> 953 <- AS_REP 954 TGS_REQ -> 955 <- TGS_REP 956 TGS_REQ -> 957 <- TGS_REP 958 DHCPINFORM 959 (AP_REQ, 960 Integrity) -> 961 <- DHCPACK 962 (Integrity) 963 DHCPINFORM 964 (AP_REQ, 965 Integrity) -> 967 In the inter-realm case where the DHCP client fails to validate the 968 integrity attribute in the DHCPACK, the client MUST silently discard the 969 DHCPACK. The conversation will appear as follows: 971 DHCP DHCP Home Local 972 Client Server KDC KDC 973 -------------- ------------- --------- --------- 974 AS_REQ -> 975 <- AS_REP 976 TGS_REQ -> 977 <- TGS_REP 978 TGS_REQ -> 979 <- TGS_REP 980 DHCPINFORM 981 (AP_REQ, 982 Integrity) -> 984 4.6.4. DHCPINFORM (with unknown DHCP server) 986 In the case where the DHCP client does not know the DHCP server it will 987 be interacting with, the DHCP client will only include a ticket 988 attribute within the DHCPINFORM. Thus the DHCP server will not be able 989 to validate the authentication option. 991 Where the DHCP client is able to validate the DHCPACK and no error 992 occur, the onversation will appear as follows: 994 DHCP DHCP 995 Client Server KDC 996 -------------- ------------- --------- 997 AS_REQ -> 998 <- AS_REP 999 DHCPINFORM 1000 (Ticket) -> 1001 TGS_REQ 1002 U-2-U -> 1003 <- TGS_REP 1004 <- DHCPACK 1005 (AP_REQ, 1006 Integrity) 1008 In the inter-realm case where the DHCP server needs to obtain a TGT to 1009 the home realm, and where the client successfully validates the DHCPACK, 1010 the conversation will appear as follows: 1012 DHCP DHCP Home Local 1013 Client Server KDC KDC 1014 -------------- ------------- --------- --------- 1015 AS_REQ -> 1016 <- AS_REP 1017 DHCPINFORM 1018 (Ticket) -> 1019 AS_REQ -> 1020 <- AS_REP 1021 TGS_REQ -> 1022 (cross realm, 1023 for home 1024 KDC) 1025 <- TGS_REP 1027 TGS_REQ 1028 U-2-U -> 1029 <- TGS_REP 1030 <- DHCPACK 1031 (AP_REQ, 1032 Integrity) 1034 In the inter-realm case where the local KDC returns a KRB_ERROR in 1035 response to the TGS_REQ from the DHCP server, the DHCP server MAY return 1036 a KRB_ERROR within the DHCP authentication option included in a DHCPNAK. 1037 The conversation will appear as follows: 1039 DHCP DHCP Home Local 1040 Client Server KDC KDC 1041 -------------- ------------- --------- --------- 1042 AS_REQ -> 1043 <- AS_REP 1044 DHCPINFORM 1045 (Ticket) -> 1046 AS_REQ -> 1047 <- AS_REP 1048 TGS_REQ -> 1049 (cross realm, 1050 for home 1051 KDC) 1052 <- KRB_ERROR 1053 <- DHCPNAK 1054 (KRB_ERROR) 1056 In the inter-realm case where the DHCP client fails to validate the 1057 integrity attribute in the DHCPACK, the client MUST silently discard the 1058 DHCPACK. The conversation will appear as follows: 1060 DHCP DHCP Home Local 1061 Client Server KDC KDC 1062 -------------- ------------- --------- --------- 1063 AS_REQ -> 1064 <- AS_REP 1065 DHCPINFORM 1066 (Ticket) -> 1067 AS_REQ -> 1068 <- AS_REP 1069 TGS_REQ -> 1070 (cross realm, 1071 for home 1072 KDC) 1073 <- TGS_REP 1075 TGS_REQ 1076 U-2-U -> 1077 <- TGS_REP 1078 <- DHCPACK 1079 (AP_REQ, 1080 Integrity) 1081 DHCPINFORM 1082 (Ticket) -> 1084 5. References 1086 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1087 Levels", BCP 14, RFC 2119, March 1997. 1089 [2] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 1090 (V5)", RFC 1510, September 1993. 1092 [3] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 1093 Internet draft (work in progress), draft-ietf-dhc- 1094 authentication-11.txt, June 1999. 1096 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1097 1997. 1099 [5] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor 1100 Extensions", RFC 2132, March 1997. 1102 [6] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 1104 [7] Jain, V., Congdon, P., Roese, J., "Network Port Authentication", 1105 IEEE 802.1 PAR submission, June 1999. 1107 [8] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, 1108 J., Trostle, J., "Public Key Cryptography for Initial 1109 Authentication in Kerberos", Internet draft (work in progress), 1110 draft-ietf-cat-kerberos-pk-init-09.txt, June 1999. 1112 [9] Tung, B., Ryutov, T., Neuman, C., Tsudik, G., Sommerfeld, B., 1113 Medvinsky, A., Hur, M., "Public Key Cryptography for Cross-Realm 1114 Authentication in Kerberos", Internet draft (work in progress), 1115 draft-ietf-cat-kerberos-pk-cross-04.txt, June 1999. 1117 [10] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March 1118 1992. 1120 [11] Henry, M., "DHCP Option 61 UUID Type Definition", Internet draft 1121 (work in progress), draft-henry-DHCP-opt61-UUID-type-00.txt, 1122 November 1998. 1124 6. Security Considerations 1126 DHCP authentication, described in [3], addresses the following threats: 1128 Modification of messages 1129 Rogue servers 1130 Unauthorized clients 1132 This section describes how DHCP authentication via Kerberos V addresses 1133 each of these threats. 1135 6.1. Client security 1137 As noted in [3], it may be desirable to ensure that IP addresses are 1138 only allocated to authorized clients. This can serve to protect against 1139 denial of service attacks. To address this issue it is necessary for 1140 DHCP client messages to be authenticated. In order to guard against 1141 message modification, it is also necessary for DHCP client messages to 1142 be integrity protected. 1144 Note that this protocol does not make use of KRB_SAFE, so as to allow 1145 modification of mutable fields by the DHCP relay. Replay protection is 1146 therefore provided within the DHCP authentication option itself. 1148 In DHCP authentication via Kerberos V the DHCP client will authenticate, 1149 integrity and replay-protect the DHCPREQUEST, DHCPDECLINE and 1150 DHCPRELEASE messages using a user-to-user session key obtained by the 1151 DHCP server from the home KDC. If the DHCP client knows the DHCP server 1152 it will be interacting with, then the DHCP client MAY also authenticate, 1153 integrity and replay-protect the DHCPINFORM message using a session key 1154 obtained from the local realm KDC for the DHCP server it expects to 1155 converse with. 1157 Since the client has not yet obtained a session key, DHCPDISCOVER 1158 packets cannot be authenticated using the session key. However, the 1159 client MAY include pre-authentication data in the PADATA field included 1160 in the DHCPDISCOVER packet. Since the PADATA will then be used by the 1161 DHCP server to request a ticket on the client's behalf, the DHCP server 1162 will learn from the AS_REP whether the PADATA was acceptable or not. 1163 Therefore in this case, the DHCPDISCOVER will be authenticated but not 1164 integrity protected. 1166 Where the DHCP client does not know the DHCP server it will be 1167 interacting with ahead of time, the DHCPINFORM message will not be 1168 authenticated, integrity or replay protected. 1170 Note that snooping of PADATA and TGTs on the wire may provide an 1171 attacker with a means of mounting a dictionary attack, since these items 1172 are typically encrypted with a key derived from the user's password. 1173 Thus use of strong passwords and/or pre-authentication methods utilizing 1174 strong cryptography (see [8]) are recommended. 1176 6.2. Network access control 1178 DHCP authentication has been proposed as a method of limiting access to 1179 network media that are not physically secured such as wireless LANs and 1180 ports in college residence halls. However, it is not particularly well 1181 suited to this purpose since even if address allocation is denied an 1182 inauthentic client may use a statically assigned IP address instead, or 1183 may attempt to access the network using non-IP protocols. As a result, 1184 other methods, described in [6]-[7], have been proposed for controlling 1185 access to wireless media and switched LANs. 1187 6.3. Server security 1189 As noted in [3], it may be desirable to protect against rogue DHCP 1190 servers put on the network either intentionally or by accident. To 1191 address this issue it is necessary for DHCP server messages to be 1192 authenticated. In order to guard against message modification, it is 1193 also necessary for DHCP server messages to be integrity protected. 1194 Replay protection is also provided within the DHCP authentication 1195 option. 1197 All messages sent by the DHCP server are authenticated and integrity and 1198 replaly protected using a session key. This includes the DHCPOFFER, 1199 DHCPACK, and DHCPNAK messages. The session key is used to compute the 1200 DHCP authentication option, which is verified by the client. 1202 In order to provide protection against rogue servers it is necessary to 1203 prevent rogue servers from obtaining the credentials necessary to act as 1204 a DHCP server. As noted in Section 4, the Kerberos principal name for 1205 the DHCP server must be of type KRB_NT_SRV_HST with the service name 1206 component equal to 'dhcp'. The client MUST validate that the DHCP server 1207 principal name has the above format. This convention requires that the 1208 administrator ensure that non-DHCP server principals do not have names 1209 that match the above format. 1211 7. IANA Considerations 1213 This draft does not create any new number spaces for IANA 1214 administration. 1216 8. Acknowledgements 1218 The authors would like to acknowledge Ralph Droms and William Arbaugh, 1219 authors of the DHCP authentication draft [3]. This draft incorporates 1220 material from their work; however, any mistakes in this document are 1221 solely the responsibility of the authors. 1223 9. Authors' Addresses 1225 Ken Hornstein 1226 US Naval Research Laboratory 1227 Bldg A-49, Room 2 1228 4555 Overlook Avenue 1229 Washington DC 20375 USA 1231 Phone: +1 (202) 404-4765 1232 EMail: kenh@cmf.nrl.navy.mil 1234 Ted Lemon 1235 Internet Engines, Inc. 1236 950 Charter Street 1237 Redwood City, CA 94063 1239 Phone: +1 (650) 779 6031 1240 Email: mellon@iengines.net 1242 Bernard Aboba 1243 Microsoft Corporation 1244 One Microsoft Way 1245 Redmond, WA 98052 1247 Phone: +1 (425) 936-6605 1248 EMail: bernarda@microsoft.com 1250 Jonathan Trostle 1251 170 W. Tasman Dr. 1252 San Jose, CA 95134, U.S.A. 1254 Email: jtrostle@cisco.com 1255 Phone: +1 (408) 527-6201 1257 10. Intellectual Property Statement 1259 The IETF takes no position regarding the validity or scope of any 1260 intellectual property or other rights that might be claimed to pertain 1261 to the implementation or use of the technology described in this 1262 document or the extent to which any license under such rights might or 1263 might not be available; neither does it represent that it has made any 1264 effort to identify any such rights. Information on the IETF's 1265 procedures with respect to rights in standards-track and standards- 1266 related documentation can be found in BCP-11. Copies of claims of 1267 rights made available for publication and any assurances of licenses to 1268 be made available, or the result of an attempt made to obtain a general 1269 license or permission for the use of such proprietary rights by 1270 implementors or users of this specification can be obtained from the 1271 IETF Secretariat. 1273 The IETF invites any interested party to bring to its attention any 1274 copyrights, patents or patent applications, or other proprietary rights 1275 which may cover technology that may be required to practice this 1276 standard. Please address the information to the IETF Executive 1277 Director. 1279 11. Full Copyright Statement 1281 Copyright (C) The Internet Society (2000). All Rights Reserved. 1282 This document and translations of it may be copied and furnished to 1283 others, and derivative works that comment on or otherwise explain it or 1284 assist in its implmentation may be prepared, copied, published and 1285 distributed, in whole or in part, without restriction of any kind, 1286 provided that the above copyright notice and this paragraph are included 1287 on all such copies and derivative works. However, this document itself 1288 may not be modified in any way, such as by removing the copyright notice 1289 or references to the Internet Society or other Internet organizations, 1290 except as needed for the purpose of developing Internet standards in 1291 which case the procedures for copyrights defined in the Internet 1292 Standards process must be followed, or as required to translate it into 1293 languages other than English. The limited permissions granted above are 1294 perpetual and will not be revoked by the Internet Society or its 1295 successors or assigns. This document and the information contained 1296 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1297 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1298 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1299 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1300 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1302 12. Expiration Date 1304 This memo is filed as , and 1305 expires October 1, 2000.