1 2 3 4Kerberos Working Group Karthik 5 Jaganathan 6Internet Draft Larry Zhu 7Document: draft-ietf-krb-wg-kerberos-referrals-03.txt John Brezak 8Category: Standards Track Microsoft 9 Mike Swift 10 University of 11 Washington 12 Jonathan Trostle 13 Cisco Systems 14 Expires: August 15 2004 16 17 18 Generating KDC Referrals to locate Kerberos realms 19 20 21Status of this Memo 22 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026 [1]. 25 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. Internet-Drafts are draft documents valid for a maximum of 30 six months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- Drafts 32 as reference material or to cite them other than as "work in 33 progress." 34 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 39 401. Abstract 41 42 The draft documents a new method for a Kerberos Key Distribution 43 Center (KDC) to respond to client requests for kerberos tickets when 44 the client does not have detailed configuration information on the 45 realms of users or services. The KDC will handle requests for 46 principals in other realms by returning either a referral error or a 47 cross-realm TGT to another realm on the referral path. The clients 48 will use this referral information to reach the realm of the target 49 principal and then receive the ticket. 50 512. Conventions used in this document 52 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 55 this document are to be interpreted as described in RFC-2119 [2]. 56 57 58 59Jaganathan Category - Standards Track 1 60 KDC Referrals August 2004 61 62 633. Introduction 64 65 Current implementations of the Kerberos AS and TGS protocols, as 66 defined in [3], use principal names constructed from a known user or 67 service name and realm. A service name is typically constructed from 68 a name of the service and the DNS host name of the computer that is 69 providing the service. Many existing deployments of Kerberos use a 70 single Kerberos realm where all users and services would be using 71 the same realm. However in an environment where there are multiple 72 trusted Kerberos realms, the client needs to be able to determine 73 what realm a particular user or service is in before making an AS or 74 TGS request. Traditionally this requires client configuration to 75 make this possible. 76 77 When having to deal with multiple trusted realms, users are forced 78 to know what realm they are in before they can obtain a ticket 79 granting ticket (TGT) with an AS request. However, in many cases the 80 user would like to use a more familiar name that is not directly 81 related to the realm of their Kerberos principal name. A good 82 example of this is an RFC-822 style email name. This document 83 describes a mechanism that would allow a user to specify a user 84 principal name that is an alias for the user's Kerberos principal 85 name. In practice this would be the name that the user specifies to 86 obtain a TGT from a Kerberos KDC. The user principal name no longer 87 has a direct relationship with the Kerberos principal or realm. Thus 88 the administrator is able to move the user's principal to other 89 realms without the user having to know that it happened. 90 91 Once a user has a TGT, they would like to be able to access services 92 in any trusted Kerberos realm. To do this requires that the client 93 be able to determine what realm the target service's host is in 94 before making the TGS request. Current implementations of Kerberos 95 typically have a table that maps DNS host names to corresponding 96 Kerberos realms. In order for this to work on the client, each 97 application canonicalizes the host name of the service by doing a 98 DNS lookup followed by a reverse lookup using the returned IP 99 address. The returned primary host name is then used in the 100 construction of the principal name for the target service. In order 101 for the correct realm to be added for the target host, the mapping 102 table [domain_to_realm] is consulted for the realm corresponding to 103 the DNS host name. The corresponding realm is then used to complete 104 the target service principal name. 105 106 This traditional mechanism requires that each client have very 107 detailed configuration information about the hosts that are 108 providing services and their corresponding realms. Having client 109 side configuration information can be very costly from an 110 administration point of view - especially if there are many realms 111 and computers in the environment. 112 113 There are also cases where specific DNS aliases (local names) have 114 been setup in an organization to refer to a server in another 115 organization (remote server). The server has different DNS names in 116 117Jaganathan Category - Standards Track 2 118 KDC Referrals August 2004 119 120 121 each organization and each organization has a Kerberos realm that is 122 configured to service DNS names within that organization. Ideally 123 users are able to authenticate to the server in the other 124 organization using the local server name. This would mean that the 125 local realm be able to produce a ticket to the remote server under 126 its name. You could give that remote server an identity in the local 127 realm and then have that remote server maintain a separate secret 128 for each alias it is known as. Alternatively you could arrange to 129 have the local realm issue a referral to the remote realm and notify 130 the requesting client of the server's remote name that should be 131 used in order to request a ticket. 132 133 This draft proposes a solution for these problems and simplifies 134 administration by minimizing the configuration information needed on 135 each computer using Kerberos. Specifically it describes a mechanism 136 to allow the KDC to handle Canonicalization of names, provide for 137 principal aliases for users and services and provide a mechanism for 138 the KDC to determine the trusted realm authentication path by being 139 able to generate referrals to other realms in order to locate 140 principals. 141 142 To rectify these problems, this draft introduces three new kinds of 143 KDC referrals: 144 145 1. AS ticket referrals, in which the client doesn't know which realm 146 contains a user account. 147 2. TGS ticket referrals, in which the client doesn't know which 148 realm contains a server account. 149 3. Cross realm shortcut referrals, in which the KDC chooses the next 150 path on a referral chain 151 1524. Realm Organization Model 153 154 This draft assumes that the world of principals is arranged on 155 multiple levels: the realm, the enterprise, and the world. A KDC may 156 issue tickets for any principal in its realm or cross-realm tickets 157 for realms with which it has a direct trust relationship. The KDC 158 also has access to a trusted name service that can resolve any name 159 from within its enterprise into a realm. This trusted name service 160 removes the need to use an untrusted DNS lookup for name resolution. 161 162 For example, consider the following configuration, where lines 163 indicate trust relationships: 164 165 MS.COM 166 / \ 167 / \ 168 OFFICE.MS.COM NT.MS.COM 169 170 In this configuration, all users in the MS.COM enterprise could have 171 a principal name such as alice@MS.COM, with the same realm portion. 172 In addition, servers at MS.COM should be able to have DNS host names 173 174 175Jaganathan Category - Standards Track 3 176 KDC Referrals August 2004 177 178 179 from any DNS domain independent of what Kerberos realm their 180 principal resides in. 181 1825. Client Name Canonicalization 183 184 A client account may have multiple principal names. More useful, 185 though, is a globally unique name that allows unification of email 186 and security principal names. For example, all users at MS may have 187 a client principal name of the form "joe@MS.COM" even though the 188 principals are contained in multiple realms. This global name is 189 again an alias for the true client principal name, which indicates 190 what realm contains the principal. Thus, accounts "alice" in the 191 realm NT.MS.COM and "bob" in OFFICE.MS.COM may logon as 192 "alice@MS.COM" and "bob@MS.COM". 193 194 This utilizes a new client principal name type, as the AS-REQ 195 message only contains a single realm field, and the realm portion of 196 this name doesn't correspond to any Kerberos realm. Thus, the entire 197 name "alice@MS.COM" is transmitted in the client name field of the 198 AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL. 199 200 KRB-NT-ENTERPRISE-PRINCIPAL 10 201 202 The KDC will recognize this name type and then transform the 203 requested name into the true principal name. The true principal name 204 can be using a name type different from the requested name type. 205 Typically the returned principal name will be a KRB-NT-PRINCIPAL. 206 The returned name will be the same in the AS response and in the 207 ticket. The KDC will always return a different name type than KRB- 208 NT-ENTERPRISE-PRINCIPAL. This is regardless of the presence of the 209 "canonicalize" KDC option. 210 211 If the "canonicalize" KDC option is set, then the KDC MAY change the 212 client principal name and type in the AS response and ticket 213 regardless of the name type of the client name in the request. For 214 example the AS request may specify a client name of "fred@MS.COM" as 215 an KRB-NT-PRINCIPAL with the "canonicalize" KDC option set and the 216 KDC will return with a client name of "104567" as a KRB-NT-UID. 217 2186. Requesting a referral 219 220 In order to request referrals, the Kerberos client must explicitly 221 request the canonicalize KDC option (bit 15) in the KDC options for 222 the TGS-REQ. This flag indicates to the KDC that the client is 223 prepared to receive a reply that contains a principal name other 224 than the one requested. Thus, the KDCOptions types is redefined as: 225 226 KDCOptions ::= BIT STRING { 227 reserved(0), 228 forwardable(1), 229 forwarded(2), 230 proxiable(3), 231 proxy(4), 232 233Jaganathan Category - Standards Track 4 234 KDC Referrals August 2004 235 236 237 allow-postdate(5), 238 postdated(6), 239 unused7(7), 240 renewable(8), 241 unused9(9), 242 unused10(10), 243 unused11(11), 244 canonicalize(15), 245 renewable-ok(27), 246 enc-tkt-in-skey(28), 247 renew(30), 248 validate(31) 249 } 250 251 The client should expect, when sending names with the "canonicalize" 252 KDC option, that names in the KDC's reply will be different than the 253 name in the request. 254 2556.1 Client Referrals 256 257 The simplest form of ticket referral is for a user requesting a 258 ticket using an AS-REQ. In this case, the client machine will send 259 the AS request to a convenient trusted realm, either the realm of 260 the client machine or the realm of the client name. In the case of 261 the name Alice@MS.COM, the client may optimistically choose to send 262 the request to MS.COM. The realm in the AS request is always the 263 name of the realm that the request is for as specified in [3]. 264 265 The client will send the string "alice@MS.COM" in the client 266 principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type 267 with the crealm set to MS.COM. The KDC will try to lookup the name 268 in its local account database. If the account is present in the 269 realm of the request, it MUST return a KDC reply structure with the 270 appropriate ticket. 271 272 If the account is not present in the realm specified in the request 273 and the "canonicalize" KDC option is set, the KDC will try to lookup 274 the entire name, Alice@MS.COM, using a name service. If this lookup 275 is unsuccessful, it MUST return the error 276 KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, it MUST 277 return an error KDC_ERR_WRONG_REALM (0x44) and in the error message 278 the crealm field will contain the the true realm of the client or 279 another realm that has better information about the client's true 280 realm. The client MUST NOT use a cname returned from a referral. 281 282 If the KDC contains the account locally and "canonicalize" KDC 283 option is not set, it MUST return a normal ticket. The client name 284 and realm portions of the ticket and KDC reply message MUST be the 285 client's true name in the realm, not the globally unique name. 286 287 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 288 new AS request with the same client principal name used to generate 289 the first referral to the realm specified by the realm field of the 290 291Jaganathan Category - Standards Track 5 292 KDC Referrals August 2004 293 294 295 kerberos error message from the first request. This request MUST 296 produce a valid AS response with a ticket for the canonical user 297 name. 298 299 An implementation should limit the number of referrals that it 300 processes to avoid infinite referral loops. A suggested limit is 5 301 referrals before giving up. In Microsoft�s implementation the 302 default limit is 3 since through the use of the global catalog any 303 domain in one forest is reachable from any other domain in another 304 trusting forest with 3 or less referrals. 305 3066.2 Service Referrals 307 308 The primary problem is that the KDC must return a referral ticket 309 rather than an error message as is done in AS request referrals. 310 There needs to be a place to include in the TGS response information 311 about what realm contains the service. This is done by returning 312 information about the service name in the pre-auth data field of the 313 KDC reply. 314 315 If the KDC resolves the service principal name into a principal in 316 the realm specified by the service realm name, it will return a 317 normal ticket. When using canonicalization, the client can omit the 318 service realm name. If it is supplied, it is used as a hint by the 319 KDC, but the service principal lookup is not constrained to locating 320 the service principal name in that specified realm. If the 321 "canonicalize" flag in the KDC options is not set, then the KDC MUST 322 only look up the name as a normal principal name in the specified 323 service realm. 324 325 If the "canonicalize" flag in the KDC options is set and the KDC 326 doesn't find the principal locally, the KDC can return a cross-realm 327 ticket granting ticket to the next hop on the trust path towards a 328 realm that may be able to resolve the principal name. 329 330 If the KDC can determine the service principal's realm, it SHOULD 331 return the service realm as KDC supplied pre-authentication data 332 element. The preauth data MUST be encrypted using the sub-session 333 key from the authenticator if present or the session key from the 334 ticket. 335 336 The data itself is an ASN.1 encoded structure containing the 337 server's realm, and if known, the real principal name. 338 339 PA-SERVER-REFERRAL-INFO 25 340 341 PA-SERVER-REFERRAL :: = KERB-ENCRYPTED-DATA 342 -- PA-SERVER-REFERRAL-DATA 343 344 PA-SERVER-REFERRAL-DATA ::= SEQUENCE { 345 referred-server-realm[0] KERB-REALM 346 referred-name[1] PrincipalName OPTIONAL 347 ... 348 349Jaganathan Category - Standards Track 6 350 KDC Referrals August 2004 351 352 353 } 354 355 356 If applicable to the encryption type, the key derivation value will 357 for the PA-SERVER-REFERRAL is 22. 358 359 If the referred-name field is present, the client MUST use that name 360 in a subsequent TGS request to the service realm when following the 361 referral. 362 363 The client will use this information to request a chain of cross- 364 realm ticket granting tickets until it reaches the realm of the 365 service, and can then expect to receive a valid service ticket. 366 367 However an implementation should limit the number of referrals that 368 it processes to avoid infinite referral loops. A suggested limit is 369 5 referrals before giving up. 370 371 This is an example of a client requesting a service ticket for a 372 service in realm NT.MS.COM where the client is in OFFICE.MS.COM. 373 374 +NC = Canonicalize KDCOption set 375 +PA-REFERRAL = returned PA-SERVER-REFERRAL-INFO 376 377 C: TGS-REQ sname=server/foo.nt.ms.com srealm=NULL +NC to 378 OFFICE.MS.COM 379 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 380 containing NT.MS.COM 381 C: TGS-REQ sname=krbtgt/NT.MS.COM@MS.COM +NC to MS.COM 382 S: TGS-REP sname=krbtgt/NT.MS.COM@MS.COM 383 C: TGS-REQ sname=server/foo.nt.ms.com srealm=NT.MS.COM +NC to 384 NT.MS.COM 385 S: TGS-REP sname=server/foo.nt.ms.com@NT.MS.COM 386 387 Notice that the client only specifies the service name in the 388 initial and final TGS request. 389 3907. Cross Realm Routing 391 392 The current Kerberos protocol requires the client to explicitly 393 request a cross-realm TGT for each pair of realms on a referral 394 chain. As a result, the client need to be aware of the trust 395 hierarchy and of any short-cut trusts (those that aren't parent- 396 child trusts). Instead, the client should be able to request a TGT 397 to the target realm from each realm on the route. The KDC will 398 determine the best path for the client and return a cross-realm TGT. 399 The client has to be aware that a request for a cross-realm TGT may 400 return a TGT for a realm different from the one requested. 401 402 For compatibility, the client MUST use the "canonicalize" KDC option 403 if it is able to use cross-realm routing from the KDC. 404 4058. Compatibility with earlier implementations of name canonicalization 406 407Jaganathan Category - Standards Track 7 408 KDC Referrals August 2004 409 410 411 412 The Microsoft Windows 2000 release included an earlier form of name- 413 canonicalization [4]. It has these differences: 414 415 1) The TGS referral data was returned inside of the KDC message as 416 "encrypted pre auth data". 417 418 KERB-ENCRYPTED-KDC-REPLY ::= SEQUENCE { 419 session-key[0] KERB-ENCRYPTION-KEY, 420 last-request[1] PKERB-LAST-REQUEST, 421 nonce[2] INTEGER, 422 key-expiration[3] KERB-TIME OPTIONAL, 423 flags[4] KERB-TICKET-FLAGS, 424 authtime[5] KERB-TIME, 425 starttime[6] KERB-TIME OPTIONAL, 426 endtime[7] KERB-TIME, 427 renew-until[8] KERB-TIME OPTIONAL, 428 server-realm[9] KERB-REALM, 429 server-name[10] KERB-PRINCIPAL-NAME, 430 client-addresses[11] PKERB-HOST-ADDRESSES 431 OPTIONAL, 432 encrypted-pa-data[12] SEQUENCE OF KERB-PA-DATA 433 OPTIONAL 434 } 435 436 2) The preauth data type definition in the encrypted preauth data is 437 as follows: 438 439 PA-SVR-REFERRAL-INFO 20 440 441 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 442 referred-server-name[1] PrincipalName OPTIONAL 443 referred-server-realm[0] KERB-REALM 444 } 445 446 4479. Security Considerations 448 449 In the case of TGS requests the client may be vulnerable to a denial 450 of service attack by an attacker that replays replies from previous 451 requests. The client can verify that the request was one of its own 452 by checking the client-address field or authtime field, though, so 453 the damage is limited and detectable. Clients MUST NOT process cross 454 realm referral TGTs if the KDC reply does not include the encrypted 455 PA-SERVER-REFERRAL-INFO. 456 457 For the AS exchange case, it is important that the logon mechanism 458 not trust a name that has not been used to authenticate the user. 459 For example, the name that the user enters as part of a logon 460 exchange may not be the name that the user authenticates as, given 461 that the KDC_ERR_WRONG_REALM error may have been returned. The 462 relevant Kerberos naming information for logon (if any), is the 463 464 465Jaganathan Category - Standards Track 8 466 KDC Referrals August 2004 467 468 469 client name and client realm in the service ticket targeted at the 470 workstation that was obtained using the user's initial TGT. 471 472 How the client name and client realm is mapped into a local account 473 for logon is a local matter, but the client logon mechanism MUST use 474 additional information such as the client realm and/or authorization 475 attributes from the service ticket presented to the workstation by 476 the user, when mapping the logon credentials to a local account on 477 the workstation. 478 47910. Acknowledgements 480 The authors wish to thank Ken Raeburn for his comments and 481 suggestions. 482 48311.1 Normative References 484 485 486 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 487 9, RFC 2026, October 1996. 488 489 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 490 Levels", BCP 14, RFC 2119, March 1997 491 492 3 Neuman, C., Kohl, J., Ts'o, T., Yu, T., Hartman, S., and K. 493 Raeburn, "The Kerberos Network Authentication Service (V5)", 494 draft-ietf-krb-wg-kerberos-clarifications-00.txt, February 22, 495 2002. Work in progress. 496 49711.2 Informative References 498 499 500 4 J. Trostle, I. Kosinovsky, and M. Swift,"Implementation of 501 Crossrealm Referral Handling in the MIT Kerberos Client", In 502 Network and Distributed System Security Symposium, February 2001. 503 504 50512. Author's Addresses 506 507 Karthik Jaganathan 508 Microsoft 509 One Microsoft Way 510 Redmond, Washington 511 Email: karthikj@Microsoft.com 512 513 Larry Zhu 514 Microsoft 515 One Microsoft Way 516 Redmond, Washington 517 Email: lzhu@Microsoft.com 518 519 Michael Swift 520 University of Washington 521 522Jaganathan Category - Standards Track 9 523 KDC Referrals August 2004 524 525 526 Seattle, Washington 527 Email: mikesw@cs.washington.edu 528 529 John Brezak 530 Microsoft 531 One Microsoft Way 532 Redmond, Washington 533 Email: jbrezak@Microsoft.com 534 535 Jonathan Trostle 536 Cisco Systems 537 170 W. Tasman Dr. 538 San Jose, CA 95134 539 Email: jtrostle@cisco.com 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580Jaganathan Category - Standards Track 10 581 KDC Referrals August 2004 582 583 584 Full Copyright Statement 585 586 Copyright (C) The Internet Society (1999). All Rights Reserved. 587 588 This document and translations of it may be copied and furnished to 589 others, and derivative works that comment on or otherwise explain it 590 or assist in its implementation may be prepared, copied, published 591 and distributed, in whole or in part, without restriction of any 592 kind, provided that the above copyright notice and this paragraph 593 are included on all such copies and derivative works. However, this 594 document itself may not be modified in any way, such as by removing 595 the copyright notice or references to the Internet Society or other 596 Internet organizations, except as needed for the purpose of 597 developing Internet standards in which case the procedures for 598 copyrights defined in the Internet Standards process must be 599 followed, or as required to translate it into languages other than 600 English. 601 602 The limited permissions granted above are perpetual and will not be 603 revoked by the Internet Society or its successors or assigns. 604 605 This document and the information contained herein is provided on an 606 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 607 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 608 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 609 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 610 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638Jaganathan Category - Standards Track 11 639