1 2 3 4NETWORK WORKING GROUP K. Raeburn 5Internet-Draft MIT 6Updates: 4120 (if approved) L. Zhu 7Expires: December 27, 2006 K. Jaganathan 8 Microsoft Corporation 9 June 25, 2006 10 11 12 Generating KDC Referrals to Locate Kerberos Realms 13 draft-ietf-krb-wg-kerberos-referrals-08 14 15Status of this Memo 16 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 26 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 31 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 34 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 37 38 This Internet-Draft will expire on December 27, 2006. 39 40Copyright Notice 41 42 Copyright (C) The Internet Society (2006). 43 44Abstract 45 46 The memo documents a method for a Kerberos Key Distribution Center 47 (KDC) to respond to client requests for Kerberos tickets when the 48 client does not have detailed configuration information on the realms 49 of users or services. The KDC will handle requests for principals in 50 other realms by returning either a referral error or a cross-realm 51 TGT to another realm on the referral path. The clients will use this 52 53 54 55Raeburn, et al. Expires December 27, 2006 [Page 1] 56 57Internet-Draft KDC Referrals June 2006 58 59 60 referral information to reach the realm of the target principal and 61 then receive the ticket. 62 63 64Table of Contents 65 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 68 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4 69 4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5 70 5. Client Name Canonicalization . . . . . . . . . . . . . . . . . 5 71 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Server Name Canonicalization (Informative) . . . . . . . . . . 10 74 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 10 75 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11 76 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 14.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Appendix A. Compatibility with Earlier Implementations of 83 Name Canonicalization . . . . . . . . . . . . . . . . 13 84 Appendix B. Document history . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 86 Intellectual Property and Copyright Statements . . . . . . . . . . 16 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Raeburn, et al. Expires December 27, 2006 [Page 2] 112 113Internet-Draft KDC Referrals June 2006 114 115 1161. Introduction 117 118 Current implementations of the Kerberos AS and TGS protocols, as 119 defined in [RFC4120], use principal names constructed from a known 120 user or service name and realm. A service name is typically 121 constructed from a name of the service and the DNS host name of the 122 computer that is providing the service. Many existing deployments of 123 Kerberos use a single Kerberos realm where all users and services 124 would be using the same realm. However in an environment where there 125 are multiple trusted Kerberos realms, the client needs to be able to 126 determine what realm a particular user or service is in before making 127 an AS or TGS request. Traditionally this requires client 128 configuration to make this possible. 129 130 When having to deal with multiple trusted realms, users are forced to 131 know what realm they are in before they can obtain a ticket granting 132 ticket (TGT) with an AS request. However, in many cases the user 133 would like to use a more familiar name that is not directly related 134 to the realm of their Kerberos principal name. A good example of 135 this is an RFC 822 style email name. This document describes a 136 mechanism that would allow a user to specify a user principal name 137 that is an alias for the user's Kerberos principal name. In practice 138 this would be the name that the user specifies to obtain a TGT from a 139 Kerberos KDC. The user principal name no longer has a direct 140 relationship with the Kerberos principal or realm. Thus the 141 administrator is able to move the user's principal to other realms 142 without the user having to know that it happened. 143 144 Once a user has a TGT, they would like to be able to access services 145 in any trusted Kerberos realm. To do this requires that the client 146 be able to determine what realm the target service principal is in 147 before making the TGS request. Current implementations of Kerberos 148 typically have a table that maps DNS host names to corresponding 149 Kerberos realms. In order for this to work on the client, each 150 application canonicalizes the host name of the service, for example 151 by doing a DNS lookup followed by a reverse lookup using the returned 152 IP address. The returned primary host name is then used in the 153 construction of the principal name for the target service. In order 154 for the correct realm to be added for the target host, the mapping 155 table [domain_to_realm] is consulted for the realm corresponding to 156 the DNS host name. The corresponding realm is then used to complete 157 the target service principal name. 158 159 This traditional mechanism requires that each client have very 160 detailed configuration information about the hosts that are providing 161 services and their corresponding realms. Having client side 162 configuration information can be very costly from an administration 163 point of view - especially if there are many realms and computers in 164 165 166 167Raeburn, et al. Expires December 27, 2006 [Page 3] 168 169Internet-Draft KDC Referrals June 2006 170 171 172 the environment. 173 174 There are also cases where specific DNS aliases (local names) have 175 been setup in an organization to refer to a server in another 176 organization (remote server). The server has different DNS names in 177 each organization and each organization has a Kerberos realm that is 178 configured to service DNS names within that organization. Ideally 179 users are able to authenticate to the server in the other 180 organization using the local server name. This would mean that the 181 local realm be able to produce a ticket to the remote server under 182 its name. You could give that remote server an identity in the local 183 realm and then have that remote server maintain a separate secret for 184 each alias it is known as. Alternatively you could arrange to have 185 the local realm issue a referral to the remote realm and notify the 186 requesting client of the server's remote name that should be used in 187 order to request a ticket. 188 189 This memo proposes a solution for these problems and simplifies 190 administration by minimizing the configuration information needed on 191 each computer using Kerberos. Specifically it describes a mechanism 192 to allow the KDC to handle canonicalization of names, provide for 193 principal aliases for users and services and provide a mechanism for 194 the KDC to determine the trusted realm authentication path by being 195 able to generate referrals to other realms in order to locate 196 principals. 197 198 Two kinds of KDC referrals are introduced in this memo: 199 200 1. Client referrals, in which the client doesn't know which realm 201 contains a user account. 202 2. Server referrals, in which the client doesn't know which realm 203 contains a server account. 204 205 2062. Conventions Used in This Document 207 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in [RFC2119]. 211 212 2133. Requesting a Referral 214 215 In order to request referrals defined in section 5, 6, and 7, the 216 Kerberos client MUST explicitly request the canonicalize KDC option 217 (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to 218 the KDC that the client is prepared to receive a reply that contains 219 a principal name other than the one requested. 220 221 222 223Raeburn, et al. Expires December 27, 2006 [Page 4] 224 225Internet-Draft KDC Referrals June 2006 226 227 228 KDCOptions ::= KerberosFlags 229 -- canonicalize (15) 230 -- other KDCOptions values omitted 231 232 The client should expect, when sending names with the "canonicalize" 233 KDC option, that names in the KDC's reply MAY be different than the 234 name in the request. A referral TGT is a cross realm TGT that is 235 returned with the server name of the ticket being different from the 236 server name in the request [RFC4120]. 237 238 2394. Realm Organization Model 240 241 This memo assumes that the world of principals is arranged on 242 multiple levels: the realm, the enterprise, and the world. A KDC may 243 issue tickets for any principal in its realm or cross-realm tickets 244 for realms with which it has a direct trust relationship. The KDC 245 also has access to a trusted name service that can resolve any name 246 from within its enterprise into a realm. This trusted name service 247 removes the need to use an un-trusted DNS lookup for name resolution. 248 249 For example, consider the following configuration, where lines 250 indicate trust relationships: 251 252 MS.COM 253 / \ 254 / \ 255 OFFICE.MS.COM NTDEV.MS.COM 256 257 In this configuration, all users in the MS.COM enterprise could have 258 a principal name such as alice@MS.COM, with the same realm portion. 259 In addition, servers at MS.COM should be able to have DNS host names 260 from any DNS domain independent of what Kerberos realm their 261 principals reside in. 262 263 2645. Client Name Canonicalization 265 266 A client account may have multiple principal names. More useful, 267 though, is a globally unique name that allows unification of email 268 and security principal names. For example, all users at MS may have 269 a client principal name of the form "joe@MS.COM" even though the 270 principals are contained in multiple realms. This global name is 271 again an alias for the true client principal name, which indicates 272 what realm contains the principal. Thus, accounts "alice" in the 273 realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may log on as "alice@ 274 MS.COM" and "bob@MS.COM". 275 276 277 278 279Raeburn, et al. Expires December 27, 2006 [Page 5] 280 281Internet-Draft KDC Referrals June 2006 282 283 284 This utilizes a new client principal name type, as the AS-REQ message 285 only contains a single realm field, and the realm portion of this 286 name doesn't correspond to any Kerberos realm. Thus, the entire name 287 "alice@MS.COM" is transmitted as a single component in the client 288 name field of the AS-REQ message, with a name type of NT-ENTERPRISE 289 [RFC4120] (and the local realm name). The KDC will recognize this 290 name type and then transform the requested name into the true 291 principal name. The true principal name can be using a name type 292 different from the requested name type. Typically the true principal 293 name will be a NT-PRINCIPAL [RFC4120]. 294 295 If the "canonicalize" KDC option is set, then the KDC MAY change the 296 client principal name and type in the AS response and ticket returned 297 from the name type of the client name in the request, and include a 298 mandatory PA-DATA object authenticating the client name mapping: 299 300 PA-CLIENT-CANONICALIZED ::= SEQUENCE { 301 names [0] SEQUENCE { 302 requested-name [0] PrincipalName, 303 real-name [1] PrincipalName 304 }, 305 canon-checksum [1] Checksum 306 } 307 308 The canon-checksum field is computed over the DER encoding of the 309 names sequences, using the returned session key and a key usage value 310 of (TBD). 311 312 If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is 313 not included. If the client name is changed, and the PA-CLIENT- 314 CANONICALIZED field does not exist, or the checksum cannot be 315 verified, or the requested-name field doesn't match the originally- 316 transmitted request, the client should discard the response. 317 318 For example the AS request may specify a client name of "bob@MS.COM" 319 as an NT-ENTERPRISE name with the "canonicalize" KDC option set and 320 the KDC will return with a client name of "104567" as a NT-UID, and a 321 PA-CLIENT-CANONICALIZED field listing the NT-ENTERPRISE "bob@MS.COM" 322 principal as the requested-name and the NT-UID "104567" principal as 323 the real-name. 324 325 It is assumed that the client discovers whether the KDC supports the 326 NT-ENTERPRISE name type via out of band mechanisms. 327 328 In order to enable one party in a user-to-user exchange to confirm 329 the identity of another when only the alias is known, the KDC MAY 330 include the following authorization data element, wrapped in AD-IF- 331 RELEVANT, in the initial credentials and copy it from a ticket- 332 333 334 335Raeburn, et al. Expires December 27, 2006 [Page 6] 336 337Internet-Draft KDC Referrals June 2006 338 339 340 granting ticket into additional credentials: 341 342 AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD -- 343 login-alias [0] PrincipalName, 344 checksum [1] Checksum 345 } 346 347 (Q: Wrapped inside KDCIssued too? Use SEQUENCE OF PrincipalName?) 348 349 The checksum is computed over the DER encoding of the login-alias 350 field using (WHICH KEY? If recipient can forge it, the KDC can't 351 trust it when returned, and would have to verify that the alias is 352 valid before copying it to additional credentials) and a key usage 353 number of (TBD). 354 355 The recipient of this authenticator must check the AD-LOGIN-ALIAS 356 name, if present, in addition to the normal client name field, 357 against the identity of the party with which it wishes to 358 authenticate; either should be allowed to match. (Note that this is 359 not backwards compatible with [RFC4120]; if the server side of the 360 user-to-user exchange does not support this extension, and does not 361 know the true principal name, authentication may fail if the alias is 362 sought in the client name field.) 363 364 3656. Client Referrals 366 367 The simplest form of ticket referral is for a user requesting a 368 ticket using an AS-REQ. In this case, the client machine will send 369 the AS-REQ to a convenient trusted realm, for example the realm of 370 the client machine. In the case of the name alice@MS.COM, the client 371 MAY optimistically choose to send the request to MS.COM. The realm 372 in the AS-REQ is always the name of the realm that the request is for 373 as specified in [RFC4120]. 374 375 The KDC will try to lookup the name in its local account database. 376 If the account is present in the realm of the request, it SHOULD 377 return a KDC reply structure with the appropriate ticket. 378 379 If the account is not present in the realm specified in the request 380 and the "canonicalize" KDC option is set, the KDC will try to lookup 381 the entire name, alice@MS.COM, using a name service. If this lookup 382 is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN 383 [RFC4120]. If the lookup is successful, it MUST return an error 384 KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm 385 field will contain either the true realm of the client or another 386 realm that MAY have better information about the client's true realm. 387 The client SHALL NOT use a cname returned from a referral until that 388 389 390 391Raeburn, et al. Expires December 27, 2006 [Page 7] 392 393Internet-Draft KDC Referrals June 2006 394 395 396 name is validated. 397 398 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 399 new AS request with the same client principal name used to generate 400 the first referral to the realm specified by the realm field of the 401 Kerberos error message from the first request. (The client realm 402 name will be updated in the new request to refer to this new realm.) 403 The client SHOULD repeat these steps until it finds the true realm of 404 the client. To avoid infinite referral loops, an implementation 405 should limit the number of referrals. A suggested limit is 5 406 referrals before giving up. 407 408 Since the same client name is sent to the referring and referred-to 409 realms, both realms must recognize the same client names. In 410 particular, the referring realm cannot (usefully) define principal 411 name aliases that the referred-to realm will not know. 412 413 The true principal name of the client, returned in AS-REQ, can be 414 validated in a subsequent TGS message exchange where its value is 415 communicated back to the KDC via the authenticator in the PA-TGS-REQ 416 padata [RFC4120]. 417 418 4197. Server Referrals 420 421 The primary difference in server referrals is that the KDC MUST 422 return a referral TGT rather than an error message as is done in the 423 client referrals. There needs to be a place to include in the reply 424 information about what realm contains the server. This is done by 425 returning information about the server name in the pre-authentication 426 data field of the KDC reply [RFC4120], as specified later in this 427 section. 428 429 If the KDC resolves the server principal name into a principal in the 430 realm specified by the service realm name, it will return a normal 431 ticket. 432 433 If the "canonicalize" flag in the KDC options is not set, the KDC 434 MUST only look up the name as a normal principal name in the 435 specified server realm. If the "canonicalize" flag in the KDC 436 options is set and the KDC doesn't find the principal locally, the 437 KDC MAY return a cross-realm ticket granting ticket to the next hop 438 on the trust path towards a realm that may be able to resolve the 439 principal name. The true principal name of the server SHALL be 440 returned in the padata of the reply if it is different from what is 441 specified the request. 442 443 When a referral TGT is returned, the KDC MUST return the target realm 444 445 446 447Raeburn, et al. Expires December 27, 2006 [Page 8] 448 449Internet-Draft KDC Referrals June 2006 450 451 452 for the referral TGT as an KDC supplied pre-authentication data 453 element in the response. This referral information in pre- 454 authentication data MUST be encrypted using the session key from the 455 reply ticket. The key usage value for the encryption operation used 456 by PA-SERVER-REFERRAL is 26. 457 458 The pre-authentication data returned by the KDC, which contains the 459 referred realm and the true principal name of server, is encoded in 460 DER as follows. 461 462 PA-SERVER-REFERRAL 25 463 464 PA-SERVER-REFERRAL-DATA ::= EncryptedData 465 -- ServerReferralData -- 466 467 ServerReferralData ::= SEQUENCE { 468 referred-realm [0] Realm OPTIONAL, 469 -- target realm of the referral TGT 470 true-principal-name [1] PrincipalName OPTIONAL, 471 -- true server principal name 472 requested-principal-name [2] PrincipalName OPTIONAL, 473 -- requested server name 474 ... 475 } 476 477 Clients SHALL NOT accept a reply ticket, whose the server principal 478 name is different from that of the request, if the KDC response does 479 not contain a PA-SERVER-REFERRAL padata entry. 480 481 The requested-principal-name MUST be included by the KDC, and MUST be 482 verified by the client, if the client sent an AS-REQ, as protection 483 against a man-in-the-middle modification to the AS-REQ message. 484 485 (Note that with the forthcoming rfc1510ter, the AS-REP may include an 486 option checksum of the AS-REQ, in which case this check would no 487 longer be necessary.) 488 489 The referred-realm field is present if and only if the returned 490 ticket is a referral TGT, not a service ticket for the requested 491 server principal. 492 493 When a referral TGT is returned and the true-principal-name field is 494 present, the client MUST use that name in the subsequent requests to 495 the server realm when following the referral. 496 497 Client SHALL NOT accept a true server principal name for a service 498 ticket if the true-principal-name field is not present in the PA- 499 SERVER-REFERRAL data. 500 501 502 503Raeburn, et al. Expires December 27, 2006 [Page 9] 504 505Internet-Draft KDC Referrals June 2006 506 507 508 The client will use this referral information to request a chain of 509 cross-realm ticket granting tickets until it reaches the realm of the 510 server, and can then expect to receive a valid service ticket. 511 512 However an implementation should limit the number of referrals that 513 it processes to avoid infinite referral loops. A suggested limit is 514 5 referrals before giving up. 515 516 Here is an example of a client requesting a service ticket for a 517 service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM. 518 519 +NC = Canonicalize KDCOption set 520 +PA-REFERRAL = returned PA-SERVER-REFERRAL 521 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM 522 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 523 containing MS.COM as the referred realm with no 524 true-principal-name 525 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM 526 S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL 527 containing NTDEV.MS.COM as the referred realm with no 528 true-principal-name 529 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM 530 S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM 531 532 Note that any referral or alias processing of the server name in 533 user-to-user authentication should use the same data as client name 534 canonicalization or referral. Otherwise, the name used by one user 535 to log in may not be useable by another for user-to-user 536 authentication to the first. 537 538 5398. Server Name Canonicalization (Informative) 540 541 No attempt is being made in this document to provide a means for 542 dealing with local-realm server principal name canonicalization or 543 aliasing. The most obvious use case for this would be a hostname- 544 based service principal name ("host/foobar.example.com"), with a DNS 545 alias ("foo") for the server host which is used by the client. There 546 are other ways this can be handled, currently, though they may 547 require additional configuration on the application server or KDC or 548 both. 549 550 5519. Cross Realm Routing 552 553 The current Kerberos protocol requires the client to explicitly 554 request a cross-realm TGT for each pair of realms on a referral 555 chain. As a result, the client need to be aware of the trust 556 557 558 559Raeburn, et al. Expires December 27, 2006 [Page 10] 560 561Internet-Draft KDC Referrals June 2006 562 563 564 hierarchy and of any short-cut trusts (those that aren't parent- 565 child trusts). 566 567 Instead, using the server referral routing mechanism as defined in 568 Section 7, The KDC will determine the best path for the client and 569 return a cross-realm TGT as the referral TGT, and the target realm 570 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 571 572 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 573 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 574 response does not contain the PA-SERVER-REFERRAL padata. 575 576 57710. Caching Information 578 579 It is possible that the client may wish to get additional credentials 580 for the same service principal, perhaps with different authorization- 581 data restrictions or other changed attributes. The return of a 582 server referral from a KDC can be taken as an indication that the 583 requested principal does not currently exist in the local realm. 584 Clearly, it would reduce network traffic if the clientn could cache 585 that information and use it when acquiring the second set of 586 credentials for a service, rather than always having to re-check with 587 the local KDC to see if the name has been created locally. 588 589 Rather than introduce a new timeout field for this cached 590 information, we can use the lifetime of the returned TGT in this 591 case. When the TGT expires, the previously returned referral from 592 the local KDC should be considered invalid, and the local KDC must be 593 asked again for information for the desired service principal name. 594 If the client is still in contact with the service and needs to 595 reauthenticate to the same service regardless of local service 596 principal name assignments, it should use the referred-realm and 597 true-principal-name values when requesting new credentials. 598 599 Accordingly, KDC authors and maintainers should consider what factors 600 (e.g., DNS alias lifetimes) they may or may not wish to incorporate 601 into credential expiration times in cases of referrals. 602 603 60411. Open Issues 605 606 When should client name aliases be included in credentials? 607 608 Should all known client name aliases be included, or only the one 609 used at initial ticket acquisition? 610 611 612 613 614 615Raeburn, et al. Expires December 27, 2006 [Page 11] 616 617Internet-Draft KDC Referrals June 2006 618 619 62012. Security Considerations 621 622 For the AS exchange case, it is important that the logon mechanism 623 not trust a name that has not been used to authenticate the user. 624 For example, the name that the user enters as part of a logon 625 exchange may not be the name that the user authenticates as, given 626 that the KDC_ERR_WRONG_REALM error may have been returned. The 627 relevant Kerberos naming information for logon (if any), is the 628 client name and client realm in the service ticket targeted at the 629 workstation that was obtained using the user's initial TGT. 630 631 How the client name and client realm is mapped into a local account 632 for logon is a local matter, but the client logon mechanism MUST use 633 additional information such as the client realm and/or authorization 634 attributes from the service ticket presented to the workstation by 635 the user, when mapping the logon credentials to a local account on 636 the workstation. 637 638 63913. Acknowledgments 640 641 Sam Hartman and authors came up with the idea of using the ticket key 642 to encrypt the referral data, which prevents cut and paste attack 643 using the referral data and referral TGTs. 644 645 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 646 version of this document. 647 648 64914. References 650 65114.1. Normative References 652 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, March 1997. 655 656 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 657 Kerberos Network Authentication Service (V5)", RFC 4120, 658 July 2005. 659 66014.2. Informative References 661 662 [I-D.ietf-cat-kerberos-pk-init] 663 Tung, B. and L. Zhu, "Public Key Cryptography for Initial 664 Authentication in Kerberos", 665 draft-ietf-cat-kerberos-pk-init-34 (work in progress), 666 February 2006. 667 668 669 670 671Raeburn, et al. Expires December 27, 2006 [Page 12] 672 673Internet-Draft KDC Referrals June 2006 674 675 676 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 677 X.509 Public Key Infrastructure Certificate and 678 Certificate Revocation List (CRL) Profile", RFC 3280, 679 April 2002. 680 681 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation 682 of Crossrealm Referral Handling in the MIT Kerberos 683 Client", Network and Distributed System Security 684 Symposium, February 2001. 685 686 687Appendix A. Compatibility with Earlier Implementations of Name 688 Canonicalization 689 690 The Microsoft Windows 2000 and Windows 2003 releases included an 691 earlier form of name-canonicalization [XPR]. Here are the 692 differences: 693 694 1) The TGS referral data is returned inside of the KDC message as 695 "encrypted pre-authentication data". 696 697 698 699 EncKDCRepPart ::= SEQUENCE { 700 key [0] EncryptionKey, 701 last-req [1] LastReq, 702 nonce [2] UInt32, 703 key-expiration [3] KerberosTime OPTIONAL, 704 flags [4] TicketFlags, 705 authtime [5] KerberosTime, 706 starttime [6] KerberosTime OPTIONAL, 707 endtime [7] KerberosTime, 708 renew-till [8] KerberosTime OPTIONAL, 709 srealm [9] Realm, 710 sname [10] PrincipalName, 711 caddr [11] HostAddresses OPTIONAL, 712 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 713 } 714 715 2) The preauth data type definition in the encrypted preauth data is 716 as follows: 717 718 719 720 721 722 723 724 725 726 727Raeburn, et al. Expires December 27, 2006 [Page 13] 728 729Internet-Draft KDC Referrals June 2006 730 731 732 PA-SVR-REFERRAL-INFO 20 733 734 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 735 referred-name [1] PrincipalName OPTIONAL, 736 referred-realm [0] Realm 737 }} 738 739 3) When [I-D.ietf-cat-kerberos-pk-init] is used, the NT-ENTERPRISE 740 client name is encoded as a Subject Alternative Name (SAN) 741 extension [RFC3280] in the client's X.509 certificate. The type 742 of the otherName field for this SAN extension is AnotherName 743 [RFC3280]. The type-id field of the type AnotherName is id-ms-sc- 744 logon-upn (1.3.6.1.4.1.311.20.2.3) and the value field of the type 745 AnotherName is a KerberosString [RFC4120]. The value of this 746 KerberosString type is the single component in the name-string 747 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 748 749 In Microsoft's current implementation through the use of global 750 catalogs any domain in one forest is reachable from any other domain 751 in the same forest or another trusted forest with 3 or less 752 referrals. A forest is a collection of realms with hierarchical 753 trust relationships: there can be multiple trust trees in a forest; 754 each child and parent realm pair and each root realm pair have 755 bidirectional transitive direct rusts between them. 756 757 While we might want to permit multiple aliases to exist and even be 758 reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only 759 one alias to exist, so this question had not previously arisen. 760 761 762Appendix B. Document history 763 764 08 Moved Microsoft implementation info to appendix. Clarify lack of 765 local server name canonicalization. Added optional authz-data for 766 login alias, to support user-to-user case. Added requested- 767 principal-name to ServerReferralData. Added discussion of caching 768 information, and referral TGT lifetime. 769 07 Re-issued with new editor. Fixed up some references. Started 770 history. 771 772 773 774 775 776 777 778 779 780 781 782 783Raeburn, et al. Expires December 27, 2006 [Page 14] 784 785Internet-Draft KDC Referrals June 2006 786 787 788Authors' Addresses 789 790 Kenneth Raeburn 791 Massachusetts Institute of Technology 792 77 Massachusetts Avenue 793 Cambridge, MA 02139 794 US 795 796 Email: raeburn@mit.edu 797 798 799 Larry Zhu 800 Microsoft Corporation 801 One Microsoft Way 802 Redmond, WA 98052 803 US 804 805 Email: lzhu@microsoft.com 806 807 808 Karthik Jaganathan 809 Microsoft Corporation 810 One Microsoft Way 811 Redmond, WA 98052 812 US 813 814 Email: karthikj@microsoft.com 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839Raeburn, et al. Expires December 27, 2006 [Page 15] 840 841Internet-Draft KDC Referrals June 2006 842 843 844Intellectual Property Statement 845 846 The IETF takes no position regarding the validity or scope of any 847 Intellectual Property Rights or other rights that might be claimed to 848 pertain to the implementation or use of the technology described in 849 this document or the extent to which any license under such rights 850 might or might not be available; nor does it represent that it has 851 made any independent effort to identify any such rights. Information 852 on the procedures with respect to rights in RFC documents can be 853 found in BCP 78 and BCP 79. 854 855 Copies of IPR disclosures made to the IETF Secretariat and any 856 assurances of licenses to be made available, or the result of an 857 attempt made to obtain a general license or permission for the use of 858 such proprietary rights by implementers or users of this 859 specification can be obtained from the IETF on-line IPR repository at 860 http://www.ietf.org/ipr. 861 862 The IETF invites any interested party to bring to its attention any 863 copyrights, patents or patent applications, or other proprietary 864 rights that may cover technology that may be required to implement 865 this standard. Please address the information to the IETF at 866 ietf-ipr@ietf.org. 867 868 869Disclaimer of Validity 870 871 This document and the information contained herein are provided on an 872 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 873 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 874 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 875 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 876 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 877 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 878 879 880Copyright Statement 881 882 Copyright (C) The Internet Society (2006). This document is subject 883 to the rights, licenses and restrictions contained in BCP 78, and 884 except as set forth therein, the authors retain all their rights. 885 886 887Acknowledgment 888 889 Funding for the RFC Editor function is currently provided by the 890 Internet Society. 891 892 893 894 895Raeburn, et al. Expires December 27, 2006 [Page 16] 896 897