1Kerberos Working Group Karthik Jaganathan 2Internet Draft Larry Zhu 3Document: draft-ietf-krb-wg-kerberos-referrals-04.txt John Brezak 4Category: Standards Track Microsoft 5 Mike Swift 6 University of Washington 7 Jonathan Trostle 8 Cisco Systems 9 Expires: January 2005 10 11 12 Generating KDC Referrals to locate Kerberos realms 13 14 15Status of this Memo 16 17 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC-2026 [1]. 20 21 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 29 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 33 Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 37Abstract 38 39 40 The draft documents a method for a Kerberos Key Distribution Center 41 (KDC) to respond to client requests for Kerberos tickets when the 42 client does not have detailed configuration information on the realms 43 of users or services. The KDC will handle requests for principals in 44 other realms by returning either a referral error or a cross-realm 45 TGT to another realm on the referral path. The clients will use this 46 referral information to reach the realm of the target principal and 47 then receive the ticket. 48 49 50Conventions used in this document 51 52 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [2]. 56 57 581. Introduction 59 60 61 62 63Jaganathan [Page 1] 64 65 66 67 68 69 70 KDC Referrals January 2005 71 72 73 74 Current implementations of the Kerberos AS and TGS protocols, as 75 defined in [3], use principal names constructed from a known user or 76 service name and realm. A service name is typically constructed from 77 a name of the service and the DNS host name of the computer that is 78 providing the service. Many existing deployments of Kerberos use a 79 single Kerberos realm where all users and services would be using the 80 same realm. However in an environment where there are multiple 81 trusted Kerberos realms, the client needs to be able to determine 82 what realm a particular user or service is in before making an AS or 83 TGS request. Traditionally this requires client configuration to make 84 this possible. 85 86 87 When having to deal with multiple trusted realms, users are forced to 88 know what realm they are in before they can obtain a ticket granting 89 ticket (TGT) with an AS request. However, in many cases the user 90 would like to use a more familiar name that is not directly related 91 to the realm of their Kerberos principal name. A good example of this 92 is an RFC-821 style email name [4]. This document describes a 93 mechanism that would allow a user to specify a user principal name 94 that is an alias for the user's Kerberos principal name. In practice 95 this would be the name that the user specifies to obtain a TGT from a 96 Kerberos KDC. The user principal name no longer has a direct 97 relationship with the Kerberos principal or realm. Thus the 98 administrator is able to move the user's principal to other realms 99 without the user having to know that it happened. 100 101 102 Once a user has a TGT, they would like to be able to access services 103 in any trusted Kerberos realm. To do this requires that the client be 104 able to determine what realm the target service principal is in 105 before making the TGS request. Current implementations of Kerberos 106 typically have a table that maps DNS host names to corresponding 107 Kerberos realms. In order for this to work on the client, each 108 application canonicalizes the host name of the service, for example 109 by doing a DNS lookup followed by a reverse lookup using the returned 110 IP address. The returned primary host name is then used in the 111 construction of the principal name for the target service. In order 112 for the correct realm to be added for the target host, the mapping 113 table [domain_to_realm] is consulted for the realm corresponding to 114 the DNS host name. The corresponding realm is then used to complete 115 the target service principal name. 116 117 118 This traditional mechanism requires that each client have very 119 detailed configuration information about the hosts that are providing 120 services and their corresponding realms. Having client side 121 configuration information can be very costly from an administration 122 point of view - especially if there are many realms and computers in 123 the environment. 124 125 126 127 128 129Jaganathan [Page 2] 130 131 132 133 134 135 136 KDC Referrals January 2005 137 138 139 140 There are also cases where specific DNS aliases (local names) have 141 been setup in an organization to refer to a server in another 142 organization (remote server). The server has different DNS names in 143 each organization and each organization has a Kerberos realm that is 144 configured to service DNS names within that organization. Ideally 145 users are able to authenticate to the server in the other 146 organization using the local server name. This would mean that the 147 local realm be able to produce a ticket to the remote server under 148 its name. You could give that remote server an identity in the local 149 realm and then have that remote server maintain a separate secret for 150 each alias it is known as. Alternatively you could arrange to have 151 the local realm issue a referral to the remote realm and notify the 152 requesting client of the server's remote name that should be used in 153 order to request a ticket. 154 155 156 This draft proposes a solution for these problems and simplifies 157 administration by minimizing the configuration information needed on 158 each computer using Kerberos. Specifically it describes a mechanism 159 to allow the KDC to handle canonicalization of names, provide for 160 principal aliases for users and services and provide a mechanism for 161 the KDC to determine the trusted realm authentication path by being 162 able to generate referrals to other realms in order to locate 163 principals. 164 165 166 To rectify these problems, this draft introduces three new kinds of 167 KDC referrals: 168 169 170 1. AS ticket referrals, in which the client doesn't know which realm 171 contains a user account. 172 2. TGS ticket referrals, in which the client doesn't know which realm 173 contains a server account. 174 3. Cross realm shortcut referrals, in which the KDC chooses the next 175 path on a referral chain 176 177 1782. Requesting a referral 179 180 181 In order to request referrals defined in section 5, 6, and 7, the 182 Kerberos client MUST explicitly request the canonicalize KDC option 183 (bit 15) [3] for the AS-REQ or TGS-REQ. This flag indicates to the 184 KDC that the client is prepared to receive a reply that contains a 185 principal name other than the one requested. 186 187 188 KDCOptions ::= KerberosFlags 189 -- canonicalize (15) 190 -- other KDCOptions values omitted 191 192 193 The client should expect, when sending names with the "canonicalize" 194 KDC option, that names in the KDC's reply MAY be different than the 195 196 197 198 199Jaganathan [Page 3] 200 201 202 203 204 205 206 KDC Referrals January 2005 207 208 209 210 name in the request. A referral ticket is a cross realm TGT that is 211 returned when the sname of the ticket is not the sname in the request 212 [3]. 213 214 2153. Realm Organization Model 216 217 218 This draft assumes that the world of principals is arranged on 219 multiple levels: the realm, the enterprise, and the world. A KDC may 220 issue tickets for any principal in its realm or cross-realm tickets 221 for realms with which it has a direct trust relationship. The KDC 222 also has access to a trusted name service that can resolve any name 223 from within its enterprise into a realm. This trusted name service 224 removes the need to use an un-trusted DNS lookup for name resolution. 225 226 227 For example, consider the following configuration, where lines 228 indicate trust relationships: 229 230 231 232 MS.COM 233 / \ 234 / \ 235 OFFICE.MS.COM NTDEV.MS.COM 236 237 238 239 In this configuration, all users in the MS.COM enterprise could have 240 a principal name such as alice@MS.COM, with the same realm portion. 241 In addition, servers at MS.COM should be able to have DNS host names 242 from any DNS domain independent of what Kerberos realm their 243 principals reside in. 244 245 2464. Client Name Canonicalization 247 248 249 A client account may have multiple principal names. More useful, 250 though, is a globally unique name that allows unification of email 251 and security principal names. For example, all users at MS may have a 252 client principal name of the form "joe@MS.COM" even though the 253 principals are contained in multiple realms. This global name is 254 again an alias for the true client principal name, which indicates 255 what realm contains the principal. Thus, accounts "alice" in the 256 realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as 257 "alice@MS.COM" and "bob@MS.COM". 258 259 260 This utilizes a new client principal name type, as the AS-REQ message 261 only contains a single realm field, and the realm portion of this 262 name doesn't correspond to any Kerberos realm. Thus, the entire name 263 "alice@MS.COM" is transmitted as a single component in the client 264 name field of the AS-REQ message, with a name type of NT-ENTERPRISE 265 [3]. The KDC will recognize this name type and then transform the 266 267 268 269 270Jaganathan [Page 4] 271 272 273 274 275 276 277 KDC Referrals January 2005 278 279 280 281 requested name into the true principal name. The true principal name 282 can be using a name type different from the requested name type. 283 Typically the true principal name will be a NT-PRINCIPAL [3]. 284 285 286 If the "canonicalize" KDC option is set, then the KDC MAY change the 287 client principal name and type in the AS response and ticket returned 288 from the name type of the client name in the request. For example the 289 AS request may specify a client name of "bob@MS.COM" as an NT- 290 PRINCIPAL with the "canonicalize" KDC option set and the KDC will 291 return with a client name of "104567" as a NT-UID. 292 293 2945. Client Referrals 295 296 297 The simplest form of ticket referral is for a user requesting a 298 ticket using an AS-REQ. In this case, the client machine will send 299 the AS-REQ to a convenient trusted realm, for example the realm of 300 the client machine. In the case of the name alice@MS.COM, the client 301 MAY optimistically choose to send the request to MS.COM. The realm in 302 the AS-REQ is always the name of the realm that the request is for as 303 specified in [3]. 304 305 306 The KDC will try to lookup the name in its local account database. If 307 the account is present in the realm of the request, it SHOULD return 308 a KDC reply structure with the appropriate ticket. 309 310 311 If the account is not present in the realm specified in the request 312 and the "canonicalize" KDC option is set, the KDC will try to lookup 313 the entire name, alice@MS.COM, using a name service. If this lookup 314 is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN 315 [3]. If the lookup is successful, it MUST return an error 316 KDC_ERR_WRONG_REALM [3] and in the error message the crealm field 317 will contain either the true realm of the client or another realm 318 that MAY have better information about the client's true realm. The 319 client MUST NOT use a cname returned from a referral. 320 321 322 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 323 new AS request with the same client principal name used to generate 324 the first referral to the realm specified by the realm field of the 325 Kerberos error message from the first request. The client SHOULD 326 repeat these steps until it finds the true realm of the client. To 327 avoid infinite referral loops, an implementation should limit the 328 number of referrals. A suggested limit is 5 referrals before giving 329 up. In Microsoft's current implementation through the use of global 330 catalogs any domain in one forest is reachable from any other domain 331 in the same forest or another trusted forest with 3 or less 332 referrals. 333 334 3356. Service Referrals 336 337 338 339 340Jaganathan [Page 5] 341 342 343 344 345 346 347 KDC Referrals January 2005 348 349 350 351 The primary problem in service referrals is that the KDC must return 352 a referral ticket rather than an error message as is done in AS 353 ticket referrals. There needs to be a place to include in the TGS-REP 354 information about what realm contains the service. This is done by 355 returning information about the service name in the pre- 356 authentication data field of the KDC reply [3]. 357 358 359 If the KDC resolves the service principal name into a principal in 360 the realm specified by the service realm name, it will return a 361 normal ticket. 362 363 364 If the "canonicalize" flag in the KDC options is not set, the KDC 365 MUST only look up the name as a normal principal name in the 366 specified service realm. If the "canonicalize" flag in the KDC 367 options is set and the KDC doesn't find the principal locally, the 368 KDC MAY return a cross-realm ticket granting ticket to the next hop 369 on the trust path towards a realm that may be able to resolve the 370 principal name. 371 372 373 When a referral TGT is returned, the KDC MUST return the target realm 374 for the referral TGT as an KDC supplied pre-authentication data 375 element in the response. The pre-authentication data MUST be 376 encrypted using the sub-session key from the authenticator if present 377 or the session key from the ticket. The pre-authentication data 378 contains the referred realm, and if known, the real principal name. 379 380 381 PA-SERVER-REFERRAL 25 382 383 384 PA-SERVER-REFERRAL-DATA ::= EncryptedData 385 -- ServerReferalData -- 386 387 388 ServerReferralData ::= SEQUENCE { 389 referred-realm [0] Realm, 390 -- target realm of the referral TGT 391 referred-name [1] PrincipalName OPTIONAL, 392 -- service principal name, MAY differ 393 -- from the server name in the request 394 ... 395 } 396 397 398 Clients MUST NOT process referral tickets if the KDC response does 399 not contain the PA-SERVER-REFERRAL. 400 401 402 If applicable to the encryption type, the key usage value for the 403 encryption key used by PA-SERVER-REFERRAL is 26 if the session key 404 from the ticket is used or 27 if a sub-session key is used. 405 406 407 If the referred-name field is present, the client MUST use that name 408 409 410 411 412Jaganathan [Page 6] 413 414 415 416 417 418 419 KDC Referrals January 2005 420 421 422 423 in a subsequent TGS request to the service realm when following the 424 referral. 425 426 427 The client will use this information to request a chain of cross- 428 realm ticket granting tickets until it reaches the realm of the 429 service, and can then expect to receive a valid service ticket. 430 However an implementation should limit the number of referrals that 431 it processes to avoid infinite referral loops. A suggested limit is 5 432 referrals before giving up. 433 434 435 Here is an example of a client requesting a service ticket for a 436 service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM. 437 438 439 +NC = Canonicalize KDCOption set 440 +PA-REFERRAL = returned PA-SERVER-REFERRAL 441 C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to OFFICE.MS.COM 442 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 443 containing MS.COM as the referred realm with no referred name 444 C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to MS.COM 445 S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL 446 containing NTDEV.MS.COM as the referred realm with no referred 447 name 448 C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to NTDEV.MS.COM 449 S: TGS-REP sname=server/foo.ntdev.ms.com@NTDEV.MS.COM 450 451 4527. Cross Realm Routing 453 454 455 The current Kerberos protocol requires the client to explicitly 456 request a cross-realm TGT for each pair of realms on a referral 457 chain. As a result, the client need to be aware of the trust 458 hierarchy and of any short-cut trusts (those that aren't parent- 459 child trusts). 460 461 462 Instead, using this referral routing mechanism, The KDC will 463 determine the best path for the client and return a cross-realm TGT 464 as the referral TGT, and the target realm for this TGT in the PA- 465 SERVER-REFERRAL of the KDC reply. 466 467 468 If the "canonicalize" KDC option is not set, the KDC MUST NOT return 469 a referral ticket. Clients MUST NOT process referral tickets if the 470 KDC response does not contain the PA-SERVER-REFERRAL. 471 472 4738. Compatibility with earlier implementations of name canonicalization 474 475 476 The Microsoft Windows 2000 and Windows 2003 releases included an 477 earlier form of name-canonicalization [5]. Here are the differences: 478 479 480 1) The TGS referral data is returned inside of the KDC message as 481 482 483 484 485Jaganathan [Page 7] 486 487 488 489 490 491 492 KDC Referrals January 2005 493 494 495 496 "encrypted pre-authentication data". 497 498 499 EncKDCRepPart ::= SEQUENCE { 500 key [0] EncryptionKey, 501 last-req [1] LastReq, 502 nonce [2] UInt32, 503 key-expiration [3] KerberosTime OPTIONAL, 504 flags [4] TicketFlags, 505 authtime [5] KerberosTime, 506 starttime [6] KerberosTime OPTIONAL, 507 endtime [7] KerberosTime, 508 renew-till [8] KerberosTime OPTIONAL, 509 srealm [9] Realm, 510 sname [10] PrincipalName, 511 caddr [11] HostAddresses OPTIONAL, 512 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 513 } 514 515 516 2) The preauth data type definition in the encrypted preauth data is 517 as follows: 518 519 520 PA-SVR-REFERRAL-INFO 20 521 522 523 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 524 referred-name [1] PrincipalName OPTIONAL, 525 referred-realm [0] Realm 526 } 527 528 5299. Security Considerations 530 531 532 In the case of TGS requests the client may be vulnerable to a denial 533 of service attack by an attacker that replays replies from previous 534 requests. The client can verify that the request was one of its own 535 by checking the client-address field or authtime field, though, so 536 the damage is limited and detectable. 537 538 539 For the AS exchange case, it is important that the logon mechanism 540 not trust a name that has not been used to authenticate the user. 541 For example, the name that the user enters as part of a logon 542 exchange may not be the name that the user authenticates as, given 543 that the KDC_ERR_WRONG_REALM error may have been returned. The 544 relevant Kerberos naming information for logon (if any), is the 545 client name and client realm in the service ticket targeted at the 546 workstation that was obtained using the user's initial TGT. 547 548 549 How the client name and client realm is mapped into a local account 550 for logon is a local matter, but the client logon mechanism MUST use 551 additional information such as the client realm and/or authorization 552 553 554 555 556Jaganathan [Page 8] 557 558 559 560 561 562 563 KDC Referrals January 2005 564 565 566 567 attributes from the service ticket presented to the workstation by 568 the user, when mapping the logon credentials to a local account on 569 the workstation. 570 571 57210. Acknowledgements 573 574 575 The authors wish to thank Ken Raeburn for his comments and 576 suggestions. 577 578 57911. References 580 581 58211.1 Normative References 583 584 585 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 586 9, RFC 2026, October 1996. 587 588 589 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 590 Levels", BCP 14, RFC 2119, March 1997. 591 592 593 [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 594 Network Authentication Service (V5)", draft-ietf-krb-wg-kerberos- 595 clarifications. Work in progress. 596 597 598 [4] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 599 1982. 600 601 60211.2 Informative References 603 604 605 [5] Trostle, J., Kosinovsky, I., and Swift, M., "Implementation of 606 Crossrealm Referral Handling in the MIT Kerberos Client", In Network 607 and Distributed System Security Symposium, February 2001. 608 609 61012. Author's Addresses 611 612 613 Karthik Jaganathan 614 Microsoft 615 One Microsoft Way 616 Redmond, Washington 617 Email: karthikj@Microsoft.com 618 619 620 Larry Zhu 621 Microsoft 622 One Microsoft Way 623 Redmond, Washington 624 Email: lzhu@Microsoft.com 625 626 627 Michael Swift 628 University of Washington 629 630 631 632 633Jaganathan [Page 9] 634 635 636 637 638 639 640 KDC Referrals January 2005 641 642 643 644 Seattle, Washington 645 Email: mikesw@cs.washington.edu 646 647 648 John Brezak 649 Microsoft 650 One Microsoft Way 651 Redmond, Washington 652 Email: jbrezak@Microsoft.com 653 654 655 Jonathan Trostle 656 Cisco Systems 657 170 W. Tasman Dr. 658 San Jose, CA 95134 659 Email: jtrostle@cisco.com 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698Jaganathan [Page 10] 699 700 701 702 703 704 705 KDC Referrals January 2005 706 707 708 709Copyright Statement 710 711 712 Copyright (C) The Internet Society (2004). This document is subject 713 to the rights, licenses and restrictions contained in BCP 78, and 714 except as set forth therein, the authors retain all their rights. 715 716 717 This document and the information contained herein are provided on an 718 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 719 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 720 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 721 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 722 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 724 725 726Intellectual Property 727 728 729 The IETF takes no position regarding the validity or scope of any 730 Intellectual Property Rights or other rights that might be claimed to 731 pertain to the implementation or use of the technology described in 732 this document or the extent to which any license under such rights 733 might or might not be available; nor does it represent that it has 734 made any independent effort to identify any such rights. Information 735 on the procedures with respect to rights in RFC documents can be 736 found in BCP 78 and BCP 79. 737 738 739 Copies of IPR disclosures made to the IETF Secretariat and any 740 assurances of licenses to be made available, or the result of an 741 attempt made to obtain a general license or permission for the use of 742 such proprietary rights by implementers or users of this 743 specification can be obtained from the IETF on-line IPR repository at 744 http://www.ietf.org/ipr. 745 746 747 The IETF invites any interested party to bring to its attention any 748 copyrights, patents or patent applications, or other proprietary 749 rights that may cover technology that may be required to implement 750 this standard. Please address the information to the IETF at ietf- 751 ipr@ietf.org. 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767Jaganathan [Page 11]