1 2 3DHC Working Group S. Medvinsky 4Internet Draft Motorola 5Document: <draft-smedvinsky-dhc-kerbauth-01.txt> 6Category: Standards Track P.Lalwaney 7Expires: January 2001 Nokia 8 9 July 2000 10 11 12 Kerberos V Authentication Mode for Uninitialized Clients 13 14 15Status of this Memo 16 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 28 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 34 35 The distribution of this memo is unlimited. It is filed as <draft- 36 smedvinsky-dhc-kerbauth-01.txt>, and expires January 2001. Please 37 send comments to the authors. 38 39 40 411. Abstract 42 43 The Dynamic Host Configuration Protocol (DHCP) [1] includes an 44 option that allows authentication of all DHCP messages, as specified 45 in [2]. This document specifies a DHCP authentication mode based on 46 Kerberos V tickets. This provides mutual authentication between a 47 DHCP client and server, as well as authentication of all DHCP 48 messages. 49 50 This document specifies Kerberos message exchanges between an 51 uninitialized client and the KDC (Key Distribution Center) using an 52 IAKERB proxy [7] so that the Kerberos key management phase is 53 decoupled from, and precedes the address allocation and network 54 configuration phase that uses the DHCP authentication option. In 55 order to make use of the IAKERB proxy, this document specifies a 56 transport mechanism that works with an uninitialized client (i.e. a 57 58Kerberos V Authentication Mode for Uninitialized Clients July 2000 59 60 61 client without an assigned IP address). In addition, the document 62 specifies the format of the Kerberos authenticator to be used with 63 the DHCP authentication option. 64 652. Conventions used in this document 66 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 69 this document are to be interpreted as described in RFC-2119. 70 713. Introduction 72 73 3.1 Terminology 74 75 o "DHCP client" 76 77 A DHCP client is an Internet host using DHCP to obtain configuration 78 parameters such as a network address. 79 80 o "DHCP server" 81 82 A DHCP server is an Internet host that returns configuration 83 parameters to DHCP clients. 84 85 O "Ticket" 86 87 A Kerberos term for a record that helps a client authenticate itself 88 to a server; it contains the client's identity, a session key, a 89 timestamp, and other information, all sealed using the server's 90 secret key. It only serves to authenticate a client when presented 91 along with a fresh Authenticator. 92 93 o "Key Distribution Center" 94 95 Key Distribution Center, a network service that supplies tickets and 96 temporary session keys; or an instance of that service or the host 97 on which it runs. The KDC services both initial ticket and Ticket- 98 Granting Ticket (TGT) requests. The initial ticket portion is 99 sometimes referred to as the Authentication Server (or service. The 100 Ticket-Granting Ticket portion is sometimes referred to as the 101 Ticket-Granting Server (or service). 102 103 o "Realm" 104 105 A Kerberos administrative domain that represents a group of 106 principals registered at a KDC. A single KDC may be responsible for 107 one or more realms. A fully qualified principal name includes a 108 realm name along with a principal name unique within that realm. 109 1103.2 Protocol Overview 111 112 113 114S. Medvinsky, P. Lalwaney -2- 115 116Kerberos V Authentication Mode for Uninitialized Clients July 2000 117 118 119 DHCP as defined in [1] defines the protocol exchanges for a client 120 to obtain its IP address and network configuration information from 121 a DHCP Server. Kerberos V5 as described in [6] defines the protocol 122 and message exchanges to mutually authenticate two parties. It is 123 our goal to provide authentication support for DHCP using Kerberos. 124 This implies that the Kerberos key management exchange has to take 125 place before a client gets its IP address from the DHCP Server. 126 Kerberos assumes that the client has a network address and can 127 contact the Key Distribution Center to obtain its credentials for 128 authenticated communication with an application server. 129 130 In this specification we utilize the key exchange using an IAKERB 131 proxy described in [7]. This does not require any changes to either 132 the IAKERB or the Kerberos V5 specification. This document also 133 specifies a particular transport that allows an uninitialized client 134 to contact an IAKERB proxy. 135 136 The Kerberos ticket returned from the key management exchange 137 discussed in Section 5 of this document is passed to the DHCP Server 138 inside the DHCP authentication option with the new Kerberos 139 authenticator type. This is described in Section 6 of this draft. 140 141 1423.3 Related Work 143 144 A prior Internet Draft [3] outlined the use of Kerberos-based 145 authentication for DHCP. The proposal tightly coupled the Kerberos 146 client state machines and the DHCP client state machines. As a 147 result, the Kerberos key management messages were carried in DHCP 148 messages, along with the Kerberos authenticators. In addition, the 149 first DHCP message exchange (request, offer) is not authenticated. 150 151 We propose a protocol exchange where Kerberos key management is 152 decoupled from and precedes authenticated DHCP exchanges. This 153 implies that the Kerberos ticket returned in the initial key 154 management exchange could be used to authenticate servers assigning 155 addresses by non-DHCP address assignment mechanisms like RSIP [4] 156 and for service specific parameter provisioning mechanisms using SLP 157 [5]. 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172S. Medvinsky, P. Lalwaney -3- 173 174Kerberos V Authentication Mode for Uninitialized Clients July 2000 175 176 177 1784. System Architecture 179 180 181 Client 182 -------- -------- 183 | | 5.Authenticated DHCP | | 184 | DHCP |<------------------------>| DHCP | 185 | client | | server | 186 | | | | 187 | | | | 188 |Kerberos| | | 189 | Client | | | 190 -------- -------- 191 ^ 192 | 193 | 194 | 195 | ------- 196 ------------------------------>| | 197 Kerberos Key Mgmt | Proxy | 198 messages: | | 199 1. AS Request / 2.AS Reply ------- 200 3. TGS Request / 4.TGS Reply ^ 201 | Kerberos 202 | Key Mgmt messages 203 v (1, 2, 3, 4) 204 -------- 205 | | 206 | KDC | 207 | | 208 -------- 209 210 Figure 1: System blocks and message interactions between them 211 212 213 In this architecture, the DHCP client obtains a Kerberos ticket from 214 the Key Distribution Center (KDC) using standard Kerberos messages, 215 as specified in [6]. The client, however, contacts the KDC via a 216 proxy server, according to the IAKERB mechanism, described in [7]. 217 The are several reasons why a client has to go through this proxy in 218 order to contact the KDC: 219 220 a)The client may not know the host address of the KDC and may be 221 sending its first request message as a broadcast on a local 222 network. The KDC may not be located on the local network, and 223 even if it were - it will be unable to communicate with a client 224 without an IP address. This document describes a specific 225 mechanism that may be used by a client to communicate with the 226 Kerberos proxy. 227 228 229 230S. Medvinsky, P. Lalwaney -4- 231 232Kerberos V Authentication Mode for Uninitialized Clients July 2000 233 234 235 b)The client may not know its Kerberos realm name. The proxy is 236 able to fill in the missing client realm name in an AS Request 237 message, as specified in IAKERB. Note that in the case that 238 PKINIT pre-authenticator is used [8], the realm name in the AS 239 Request may be the KDC realm name and not the client�s realm name. 240 241 c) The client does not know the realm name of the DHCP server. 242 243 According to IAKERB, when the client sends a TGS Request with a 244 missing server realm name, the proxy will return to the client an 245 error message containing the missing realm name. 246 247 Note that in this case the proxy could return the client a wrong 248 realm name and the client could be fooled into obtaining a ticket 249 for the wrong DHCP server (on the same local network). However, 250 the wrong DHCP server must still be a registered principal in a 251 KDC database. In some circumstances this may be an acceptable 252 compromise. Also, see the security considerations section. 253 254 IAKERB describes the proxy as part of an application server - the 255 DHCP server in this case. However, in this document we are not 256 requiring the proxy to be integrated with the DHCP server. The 257 same IAKERB mechanisms apply in the more general case, where the 258 proxy is an independent application. This proxy, however, MUST be 259 reachable by a client via a local network broadcast. 260 261 After a client has obtained a Kerberos ticket for the DHCP server, 262 it will use it as part of an authentication option in the DHCP 263 messages. The only extension to the DHCP protocol is the addition 264 of a new authenticator type based on Kerberos tickets. 265 2664.1 Cross-Realm Authentication 267 268 Figure 1 shows a client communicating with a single KDC via a proxy. 269 However, the DHCP client�s realm may be different from the DHCP 270 server�s realm. In that case, the client may need to first contact 271 the KDC in its local realm to obtain a cross-realm TGT. Then, the 272 client would use the cross-realm TGT to contact the KDC in the DHCP 273 server�s realm, as specified in [6]. 274 275 In the following example a client doesn�t know its realm or the DHCP 276 server�s realm, which happens to be different from the client�s 277 realm. Here are the steps in obtaining the ticket for the DHCP 278 server (based on [6] and [7]): 279 280 1) The client sends AS Request with NULL realm to the proxy. 281 2) The proxy fills in the realm and forwards the AS Request to 282 the KDC in the client�s realm. 283 3) The KDC issues a TGT and sends back an AS Reply to the 284 proxy. 285 4) The proxy forwards AS Reply to the client. 286 287 288S. Medvinsky, P. Lalwaney -5- 289 290Kerberos V Authentication Mode for Uninitialized Clients July 2000 291 292 293 5) The client sends TGS Request for a principal name "dhcpsrvr" 294 with NULL realm to the proxy. 295 6) The proxy returns KRB_AP_ERR_REALM_REQUIRED error with the 296 DHCP server�s realm to the client. 297 7) The client sends another TGS Request for a cross-realm TGT 298 to the proxy. 299 8) The proxy forwards the TGS Request to the KDC in the 300 client�s realm. 301 9) The KDC issues a cross-realm TGT and sends back a TGS Reply 302 to the proxy. 303 10) The proxy forwards TGS Reply to the client. 304 11) The client sends a TGS Request to the proxy for a principal 305 "dhcpsrvr" with the realm name filled in, using a cross-realm 306 TGT. 307 12) The proxy forwards TGS Request to the KDC in the DHCP 308 server's realm. 309 13) The KDC issues a ticket for the DHCP server and sends TGS 310 Reply back to the proxy. 311 14) The proxy forwards TGS Reply to the client. 312 313 In a most general case, the client may need to contact any number of 314 KDCs in different realms before it can get a ticket for the DHCP 315 server. In each case, the client would contact a KDC via the proxy 316 server, as specified in Section 5 of this document. 317 3184.2 Public Key Authentication 319 320 This specification also allows clients to perform public key 321 authentication to the KDC, based on the PKINIT specification [8]. 322 In this case, the size of an AS Request and AS Reply messages is 323 likely to exceed the size of typical link MTU's. 324 325 Here is an example, where PKINIT is used by a DHCP client that is 326 not a registered principal in the KDC principal database: 327 328 1) The client sends AS Request with a PKINIT Request pre- 329 authenticator to the proxy. This includes the client�s 330 signature and X.509 certificate. The KDC realm field is 331 left as NULL. 332 2) The proxy fills in the realm and forwards the AS Request to 333 the KDC in the filled in realm. This is the realm of the 334 DHCP server. Here, the client�s realm is the name of a 335 Certification Authority - not the same as the KDC realm. 336 3) The KDC issues a TGT and sends back an AS Reply with a 337 PKINIT Reply pre-authenticator to the proxy. 338 4) The proxy forwards the AS Reply to the client. 339 5) The client sends TGS Request for a principal name "dhcpsrvr" 340 with the realm found in the TGT to the proxy. 341 6) The proxy forwards TGS Request to the KDC in the DHCP 342 server�s realm. 343 7) The KDC issues a ticket for the DHCP server and sends TGS 344 Reply back to the proxy. 345 346S. Medvinsky, P. Lalwaney -6- 347 348Kerberos V Authentication Mode for Uninitialized Clients July 2000 349 350 351 8) The proxy forwards TGS Reply to the client. 352 353 354 5. Key Management Exchange that Precedes Network Address Allocation 355 356 An uninitialized host (e.g. on power-on and reset) does not have a 357 network address. It does have a link layer address or hardware 358 address. At this time, the client may not have any information on 359 its realm or the realm of the address allocation server (DHCP 360 Server). 361 362 In the Kerberos key management exchange, a client gets its ticket 363 granting ticket (TGT) by contacting the Authentication Server in the 364 KDC using the AS_Request / Reply messages (shown as messages 1 and 2 365 in Figure 1). The client then contacts the Ticket Granting Server in 366 the KDC to get the DHCP server ticket (to be used for mutual 367 authentication with the DHCP server) using the TGS_REQ / TGS_REP 368 messages (shown as messages 3 and 4 in the above figure). It is 369 also possible for the client to obtain a DHCP server ticket directly 370 with the AS Request / Reply exchange, without the use of the TGT. 371 372 In the use of Kerberos for DHCP authentication, the client (a) does 373 not have an IP/network address (b) does not know he KDC�s IP address 374 (c) the KDC may not be on the local network and (d) the client may 375 not know the DHCP Server�s IP address and realm. We therefore 376 require a Kerberos proxy on the local network to accept broadcast 377 Kerberos request messages (AS_REQ and TGS_REQ) from uninitialized 378 clients and relay them to the appropriate KDC. 379 380 The uninitialized client formulates a broadcast AS_REQ or TGS_REQ as 381 follows: 382 383 The request payload contains the client hardware address in 384 addresses field with a negative value for the address type. Kerberos 385 v5 [6] allows for the usage of negative address types for "local" 386 use. Note that IAKERB [7] discourages the use of the addresses field 387 as network addresses may not be known or may change in situation 388 where proxies are used. In this draft we incorporate the negative 389 values permitted in the Kerberos transport in the address type field 390 of both the AS_REQ and TGS_REQ messages. The negative value SHOULD 391 be the negative number of the hardware address type "htype" value 392 (from assigned numbers RFC) used in RFC 2131. The address field of 393 the message contains the clients hardware address. 394 395 The request payload is UDP encapsulated and addressed to port 88 on 396 the server/proxy. The UDP source port is selected by the client. The 397 source and destination network addresses are the all-zero�s address 398 and the broadcast address, respectively. For IPv4, the source IP 399 address is set to 0.0.0.0 and the destination IP address is set to 400 255.255.255.255. The data link layer header source address 401 corresponds to the link layer/hardware address of the client. The 402 403 404S. Medvinsky, P. Lalwaney -7- 405 406Kerberos V Authentication Mode for Uninitialized Clients July 2000 407 408 409 destination link layer address is the broadcast address at the link 410 layer (e.g. for Ethernet the address is ffffffff). 411 412 In the case where AS_REQ message contains a PKINIT pre-authenticator 413 for public key-based client authentication (based on [8]), the 414 message will probably not fit into a single UDP packet given typical 415 link MTU's. 416 417 It is assumed that the proxy server on a network is configured with 418 a list of KDC�s, their realms and their IP addresses. The proxy 419 server will act as a client to the KDC and forward standard Kerberos 420 messages to/from the KDC using unicast UDP or TCP transport 421 mechanisms, according to [6]. 422 423 Upon receiving a broadcast request from a client, the proxy MUST 424 record the client�s hardware address that appears as the source 425 address on the frame as well as in the addresses field of the 426 request message. Based on the realm of the KDC specified in the 427 request, the proxy determines the KDC to which this message is 428 relayed as a unicast message from the proxy to the KDC. In the case 429 that the client left the KDC realm name as NULL, it is up to the 430 proxy to first determine the correct realm name and fill it in the 431 request (according to [7]). 432 433 On receiving a request, the KDC formulates a response (AS_REP or 434 TGS_REP). It includes the client�s addresses field in the encrypted 435 part of the ticket (according to [6]). This response is unicast to 436 the proxy. 437 438 Upon receiving the reply, the proxy MUST first determine the 439 previously saved hardware address of the client. The proxy 440 broadcasts the reply on its local network. This is a network layer 441 broadcast. At the link level, it uses the hardware address obtained 442 from the addresses field of the request. 443 444 The client on receiving the response (link layer destination address 445 as its hardware address, network layer address is the broadcast 446 address) must verify that the hardware address in the ticket 447 corresponds to its link layer address. 448 449 Upon receiving a TGS_REP (or an AS_REP with the application server 450 ticket) from the proxy, the client will have enough information to 451 securely communicate with the application server (the DHCP Server in 452 this case), as specified in the following section. 453 454 455 456 457 458 459 460 461 462S. Medvinsky, P. Lalwaney -8- 463 464Kerberos V Authentication Mode for Uninitialized Clients July 2000 465 466 467 6. Authenticated Message Exchange Between the DHCP Client and the 468 DHCP Server 469 470 The ticket returned in the TGS response is used by the DHCP client 471 in the construction of the Kerberos authenticator. The Kerberos 472 ticket serves two purposes: to establish a shared session key with 473 the DHCP server, and is also included as part of a Kerberos 474 authenticator in the DHCP request. 475 476 If the size of the authenticator is greater than 255 bytes, the DHCP 477 authentication option is repeated multiple times. When the values 478 of all the authentication options are concatenated together, they 479 will make up the complete authenticator. 480 481 Once the session key is established, the Kerberos structure 482 containing the ticket (AP REQ) can be omitted from the authenticator 483 for subsequent messages sent by both the DHCP client and the DHCP 484 server. 485 486 The Kerberos authenticator for a DHCP request message is specified 487 below: 488 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Code | Length | Protocol | Algorithm | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | | 495 + Replay Detection (64 bits) + 496 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | | 499 + Authentication token (n octets) ... + 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 503 The format of this authenticator is in accordance with [2]. The code 504 for the authentication option is TBD, and the length field contains 505 the length of the remainder of the option, starting with the 506 protocol field. 507 508 The value of the protocol field for this authenticator MUST be set 509 to 2. 510 511 The algorithm field MUST take one of the following values: 512 1 - HMAC-MD5 513 2 - HMAC-SHA-1 514 515 Replay protection field is a monotonically increasing counter field. 516 When the Kerberos AP REQ structure is present in the authenticator 517 the counter may be set to any value. The AP REQ contains its own 518 replay protection mechanism in the form of a timestamp. 519 520S. Medvinsky, P. Lalwaney -9- 521 522Kerberos V Authentication Mode for Uninitialized Clients July 2000 523 524 525 526 Once the session key has been established and the AP REQ is not 527 included in the authenticator, this field MUST be monotonically 528 increasing in the messages sent by the client. 529 530 Kerberos authenticator token consists of type-length-value 531 attributes: 532 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type | Reserved | Payload Length | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | attribute value... 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 541 The following attributes are included in the Kerberos authenticator 542 token: 543 544 Type Attribute Name Value 545 -------------------------------------------------------------------- 546 0 Message Integrity Code Depends on the value of the 547 algorithm field. Its length is 548 16 bytes for HMAC-MD5 [9, 10] 549 and 20 bytes for HMAC-SHA-1 550 [11, 10]. The HMAC key must be 551 derived from Kerberos session 552 key found in the Kerberos 553 ticket according to the key 554 derivation rules in [6]: 555 556 HMAC Key = DK(sess key, 557 key usage | 0x99) 558 559 Here, DK is defined in [12] and 560 the key usage value for DHCP is 561 TBD. 562 563 The HMAC is calculated over the 564 entire DHCP message. The 565 Message Integrity Code 566 attribute MUST be set to all 0s 567 for the computation of the 568 HMAC. Because a DHCP relay 569 agent may alter the values of 570 the 'giaddr' and 'hops' fields 571 in the DHCP message, the 572 contents of those two fields 573 MUST also be set to zero for 574 the computation of the HMAC. 575 Rules specified in Section 3 of 576 [2] for the exclusion and 577 578S. Medvinsky, P. Lalwaney -10- 579 580Kerberos V Authentication Mode for Uninitialized Clients July 2000 581 582 583 processing of the relay agent 584 information are applicable here 585 too. 586 587 This field MUST always be 588 present in the Kerberos 589 authenticator. 590 591 1 AP_REQ ASN.1 encoding of a Kerberos 592 AP_REQ message, as specified 593 in [6]. This MUST be included 594 by the client when establishing 595 a new session key. In all 596 other cases, this attribute 597 MUST be omitted. 598 599 AP_REQ contains the Kerberos ticket for the DHCP server and also 600 contains information needed by the DHCP server to authenticate the 601 client. After verifying the AP_REQ and decrypting the Kerberos 602 ticket, the DHCP server is able to extract a session key which it 603 now shares with the DHCP client. 604 605 The Kerberos authenticator token contains its own replay protection 606 mechanism inside the AP_REQ structure. The AP_REQ contains a 607 timestamp that must be within an agreed upon time window at the DHCP 608 server. However, this does not require the DHCP clients to maintain 609 an accurate clock between reboots. Kerberos allows clients to 610 synchronize their clock with the KDC with the help of Kerberos 611 KRB_AP_ERR_SKEW error message, as specified in [6]. 612 613 The DHCP server MUST save both the session key and its associated 614 expiration time found in the Kerberos ticket. Up until the 615 expiration time, the server must accept client requests with the 616 Kerberos authenticator that does not include the AP REQ, using the 617 saved session key in calculating HMAC values. 618 619 The Kerberos authenticator inside all DHCP server responses MUST NOT 620 contain the AP REQ and MUST use the saved Kerberos session key in 621 calculating HMAC values. 622 623 When the session key expires, it is the client's responsibility to 624 obtain a new ticket from the KDC and to include an AP REQ inside the 625 Kerberos authenticator for the next DHCP request message. 626 627 628 629 630 631 632 633 634 635 636S. Medvinsky, P. Lalwaney -11- 637 638Kerberos V Authentication Mode for Uninitialized Clients July 2000 639 640 6417. Detailed message flows for Kerberos and DHCP message Exchanges 642 643 The following flow depicts the Kerberos exchange in which a AS REQ 644 message is used to directly request the DHCP Server ticket. There 645 are no changes to transport mechanisms below when the additional 646 phase of using TGS requests/responses with TGT�s is used. 647 648 Client IAKERB Proxy KDC 649 650 KB-client-------- AS_REQ ------> 651 652 AS REQ Address type = - (htype) 653 AS REQ Address= hw address 654 655 src UDP port = senders port 656 destination UDP port = 88 657 658 src IP = 0.0.0.0 659 destination IP = 255.255.255.255 660 661 src link layer address = 662 client�s HW/link address [e.g Ethernet address] 663 664 destination link layer address = 665 link broadcast address [e.g. ffffffff for Ethernet] 666 667 668 ---------------------------> 669 (unicast to UDP port 88) 670 671 672 673 <-------------------------- 674 (unicast AS REP) 675 Encrypted portion of ticket 676 Includes clients HW address 677 678 679 <---------------AS_REP ----------- 680 681 682 Ticket includes client�s hardware address 683 684 src UDP port = 88 685 destination UDP port = copied from src port in AS_REQ 686 687 src IP = Proxy�s IP address 688 destination IP = 255.255.255.255 689 690 src link layer address = Proxy�s HW/link address 691 destination link layer address = 692 Client�s link layer address from AS_REQ 693 694 695S. Medvinsky, P. Lalwaney -12- 696 697Kerberos V Authentication Mode for Uninitialized Clients July 2000 698 699 700 701 702 703 The client uses the ticket received from the KDC in the DHCP 704Authentication option as described in Section 6. 705 706 707 Client 708 DHCP-client DHCP Server 709 710 ------DHCPDISCOVER ----> 711 (Auth Protocol = 2, includes Kerberos 712 authenticator with AP REQ ) 713 ----------------------------------- 714 | HMAC | AP REQ | 715 ---------------------------------- 716 | Ticket| Client Authent | 717 -------------------------- 718 719 1. Server decrypts ticket 720 (inside AP REQ) with service 721 key 722 2. Server decrypts client 723 authenticator (inside AP REQ) 724 and checks content and 725 checksum to validate the 726 client. 727 3. Recompute HMAC with session 728 key and compare. 729 730 731 <-------DHCPOFFER---------- 732 (Auth Protocol = 2, no AP REQ ) 733 734 735 736 ---------DHCPREQUEST-------> 737 (Auth Protocol = 2, no AP REQ) 738 739 740 <--------DHCPACK------------- 741 (Auth Protocol = 2, no AP REQ ) 742 743 744 745 7468. Security Considerations 747 748 DHCP clients that do not know the DHCP server�s realm name will get 749 it from the proxy, as specified in IAKERB [7]. Since the proxy is 750 not authenticated, a DHCP client can be fooled into obtaining a 751 ticket for the wrong DHCP server in the wrong realm. 752 753S. Medvinsky, P. Lalwaney -13- 754 755Kerberos V Authentication Mode for Uninitialized Clients July 2000 756 757 758 759 This could happen when the client leaves out the server realm name 760 in a TGS Request message to the proxy. It is also possible, 761 however, for a client to directly request a DHCP server ticket with 762 an AS Request message. In those cases, the same situation occurs 763 when the client leaves out the realm name in an AS Request. 764 765 This wrong DHCP server is still registered as a valid principal in a 766 database of a KDC that can be trusted by the client. In some 767 circumstances a client may assume that a DHCP server that is a 768 Kerberos principal registered with a trusted KDC will not attempt to 769 deliberately misconfigure a client. 770 771 This specification provides a tradeoff between: 772 773 1) The DHCP clients knowing DHCP server�s realm ahead of time, 774 which provides for full 2-way authentication at the cost of 775 an additional configuration parameter. 776 2) The DHCP clients not requiring any additional configuration 777 information, besides a password or a key (and a public key 778 certificate if PKINIT is used). This is at the cost of not 779 being able to fully authenticate the identity of the DHCP 780 server. 781 782 783 7849. References 785 786 787 [1]Droms, R., Arbaugh, W., "Dynamic Host Configuration Protocol", 788 RFC 2131, Bucknell University, March 1997. 789 790 [2]Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 791 draft-ietf-dhc-authentication-13.txt, June 2000. 792 793 [3]Hornstein, K., Lemon, T., "DHCP Authentication Via Kerberos V", 794 draft-hornstein-dhc-kerbauth-02.txt, February 2000. 795 796 [4]Borella, M., Grabelsky, D., Lo, J., Tuniguchi, K., "Realm 797 Specific IP: Protocol Specification ", draft-ietf-nat-rsip- 798 protocol-06.txt, March 2000. 799 800 [5]Guttman, E., Perkins, C., Veizades, J., Day, M., "Service 801 Location Protocol, Version 2", RFC 2608, June 1999. 802 803 [6]Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 804 Authentication Service (V5)", draft-ietf-cat-kerberos-revisions- 805 05.txt, March 2000. 806 807 808 809 810 811S. Medvinsky, P. Lalwaney -14- 812 813Kerberos V Authentication Mode for Uninitialized Clients July 2000 814 815 816 817 [7]Swift, M., Trostle, J., "Initial Authentication and Pass Through 818 Authentication Using Kerberos V5 and the GSS-API (IAKERB)", 819 draft-ietf-cat-iakerb-03.txt, September 1999. 820 821 [8]Tung, B., C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, 822 J. Trostle, "Public Key Cryptography for Initial Authentication 823 in Kerberos", draft-ietf-cat-pk-init-11.txt, March 2000. 824 825 [9]Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 826 1992. 827 828 [10]Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for 829 Message Authentication," RFC 2104, February 1997. 830 831 [11]NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995. 832 833 [12]Horowitz, M., "Key Derivation for Authentication, Integrity, and 834 Privacy", draft-horowitz-key-derivation-02.txt, August 1998. 835 836 [13]Bradner, S. "The Internet Standards Process -- Revision 3", RFC 837 2026. 838 839 840 841 10. Author's Addresses 842 843 Sasha Medvinsky 844 Motorola 845 6450 Sequence Drive 846 San Diego, CA 92121 847 Email: smedvinsky@gi.com 848 849 Poornima Lalwaney 850 Nokia 851 12278 Scripps Summit Drive 852 San Diego, CA 92131 853 Email: poornima.lalwaney@nokia.com 854 855 85611. Expiration 857 858 This memo is filed as <draft-smedvinsky-dhc-kerbauth-01.txt>, and 859 expires January 1, 2001. 860 861 862 86312. Intellectual Property Notices 864 865 866 867 868 869 870S. Medvinsky, P. Lalwaney -15- 871 872Kerberos V Authentication Mode for Uninitialized Clients March 2000 873 874 875 This section contains two notices as required by [13] for 876 standards track documents. Per [13], section 10.4(A): 877 878 The IETF takes no position regarding the validity or scope of any 879 intellectual property or other rights that might be claimed to 880 pertain to the implementation or use of the technology described in 881 this document or the extent to which any license under such rights 882 might or might not be available; neither does it represent that it 883 has made any effort to identify any such rights. Information on the 884 IETF's procedures with respect to rights in standards-track and 885 standards-related documentation can be found in BCP-11. Copies of 886 claims of rights made available for publication and any assurances 887 of licenses to be made available, or the result of an attempt made 888 to obtain a general license or permission for the use of such 889 proprietary rights by implementers or users of this specification 890 can be obtained from the IETF Secretariat. 891 892 Per [13] section 10.4(D): 893 894 The IETF has been notified of intellectual property rights 895 claimed in regard to some or all of the specification contained in 896 this document. For more information consult the online list of 897 claimed rights. 898 899 13. Full Copyright Statement 900 901 Copyright (C) The Internet Society (1999). All Rights Reserved. 902 903 This document and translations of it may be copied and furnished to 904 others, and derivative works that comment on or otherwise explain it 905 or assist in its implementation may be prepared, copied, published 906 and distributed, in whole or in part, without restriction of any 907 kind, provided that the above copyright notice and this paragraph 908 are included on all such copies and derivative works. However, this 909 document itself may not be modified in any way, such as by removing 910 the copyright notice or references to the Internet Society or other 911 Internet organizations, except as needed for the purpose of 912 developing Internet standards in which case the procedures for 913 copyrights defined in the Internet Standards process must be 914 followed, or as required to translate it into languages other than 915 English. The limited permissions granted above are perpetual and 916 will not be revoked by the Internet Society or its successors or 917 assigns. This document and the information contained herein is 918 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 919 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 920 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 921 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 922 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 923 924 925 926 927 928S. Medvinsky, P. Lalwaney -16- 929