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