1 2 3 4NETWORK WORKING GROUP K. Raeburn 5Internet-Draft MIT 6Updates: 4120 (if approved) L. Zhu 7Intended status: Standards Track Microsoft Corporation 8Expires: January 15, 2009 July 14, 2008 9 10 11 Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm 12 Referrals 13 draft-ietf-krb-wg-kerberos-referrals-11 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 January 15, 2009. 39 40Copyright Notice 41 42 Copyright (C) The IETF Trust (2008). 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 & Zhu Expires January 15, 2009 [Page 1] 56 57Internet-Draft KDC Referrals July 2008 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. Enterprise Principal Name Type . . . . . . . . . . . . . . . . 5 71 6. Name Canonicalization . . . . . . . . . . . . . . . . . . . . 6 72 7. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 9 74 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 12 75 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 12 76 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 13 78 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 14.1. Shared-password case . . . . . . . . . . . . . . . . . . 14 81 14.2. Preauthentication data . . . . . . . . . . . . . . . . . 14 82 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 83 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 16.1. Normative References . . . . . . . . . . . . . . . . . . 15 85 16.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Appendix A. Compatibility with Earlier Implementations of 87 Name Canonicalization . . . . . . . . . . . . . . . . 15 88 Appendix B. Document history [REMOVE BEFORE PUBLICATION] . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 90 Intellectual Property and Copyright Statements . . . . . . . . . . 19 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Raeburn & Zhu Expires January 15, 2009 [Page 2] 112 113Internet-Draft KDC Referrals July 2008 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 January 15, 2009 [Page 3] 168 169Internet-Draft KDC Referrals July 2008 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 as defined in later sections, 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 January 15, 2009 [Page 4] 224 225Internet-Draft KDC Referrals July 2008 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. Enterprise Principal Name Type 263 264 The NT-ENTERPRISE type principal name contains one component, a 265 string of realm-defined content, which is intended to be used as an 266 alias for another principal name in some realm in the enterprise. It 267 is used for conveying the alias name, not for the real principal 268 names within the realms, and thus is only useful when name 269 canonicalization is requested. 270 271 The intent is to allow unification of email and security principal 272 names. For example, all users at EXAMPLE.COM may have a client 273 principal name of the form "joe@EXAMPLE.COM" even though the 274 principals are contained in multiple realms. This global name is 275 again an alias for the true client principal name, which indicates 276 277 278 279Raeburn & Zhu Expires January 15, 2009 [Page 5] 280 281Internet-Draft KDC Referrals July 2008 282 283 284 what realm contains the principal. Thus, accounts "alice" in the 285 realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as 286 "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM". 287 288 This utilizes a new principal name type, as the KDC-REQ message only 289 contains a single client realm field, and the realm portion of this 290 name corresponds to the Kerberos realm with which the request is 291 made. Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a 292 single component in the client name field of the AS-REQ message, with 293 a name type of NT-ENTERPRISE [RFC4120] (and the local realm name). 294 The KDC will recognize this name type and then transform the 295 requested name into the true principal name if the client account 296 resides in the local realm. The true principal name can have a name 297 type different from the requested name type. Typically the true 298 principal name will be a NT-PRINCIPAL [RFC4120]. 299 300 3016. Name Canonicalization 302 303 A service or account may have multiple principal names. For example, 304 if a host is known by multiple names, host-based services on it may 305 be known by multiple names in order to prevent the client from 306 needing a secure directory service to determine the correct hostname 307 to use. In order that the host should not need to be updated 308 whenever a new alias is created, the KDC may provide the mapping 309 information to the client in the credential acquisition process. 310 311 If the "canonicalize" KDC option is set, then the KDC MAY change the 312 client and server principal names and types in the AS response and 313 ticket returned from the name type of the client name in the request. 314 In a TGS exchange, the server principal name and type may be changed. 315 316 If the client principal name is changed in an AS exchange, the KDC 317 must include a mandatory PA-DATA object authenticating the client 318 name mapping: 319 320 ClientReferralInfo ::= SEQUENCE { 321 requested-name [0] PrincipalName, 322 mapped-name [1] PrincipalName, 323 ... 324 } 325 PA-CLIENT-CANONICALIZED ::= SEQUENCE { 326 names [0] ClientReferralInfo, 327 canon-checksum [1] Checksum 328 } 329 330 The canon-checksum field is computed over the DER encoding of the 331 names sequences, using the AS reply key and a key usage value of 332 333 334 335Raeburn & Zhu Expires January 15, 2009 [Page 6] 336 337Internet-Draft KDC Referrals July 2008 338 339 340 (TBD). 341 342 If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is 343 not included. If the client name is changed, and the PA-CLIENT- 344 CANONICALIZED field does not exist, or the checksum cannot be 345 verified, or the requested-name field doesn't match the client name 346 in the originally-transmitted request, the client should discard the 347 response. 348 349 For example the AS request may specify a client name of "bob@ 350 EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC 351 option set and the KDC will return with a client name of "104567" as 352 a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT- 353 ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the 354 NT-UID "104567" principal as the mapped-name. 355 356 (It is assumed that the client discovers whether the KDC supports the 357 NT-ENTERPRISE name type via out of band mechanisms.) 358 359 If the server name is changed, a PA-SERVER-REFERRAL preauth data 360 entry MUST be supplied by the KDC and validated by the client. 361 362 In order to enable one party in a user-to-user exchange to confirm 363 the identity of another when only the alias is known, the KDC MAY 364 include the following authorization data element, wrapped in AD-KDC- 365 ISSUED, in the initial credentials and copy it from a ticket-granting 366 ticket into additional credentials: 367 368 AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD -- 369 login-aliases [0] SEQUENCE(1..MAX) OF PrincipalName, 370 } 371 372 The login-aliases field lists one or more of the aliases the 373 principal may have. 374 375 The recipient of this authenticator must check the AD-LOGIN-ALIAS 376 names, if present, in addition to the normal client name field, 377 against the identity of the party with which it wishes to 378 authenticate; either should be allowed to match. (Note that this is 379 not backwards compatible with [RFC4120]; if the server side of the 380 user-to-user exchange does not support this extension, and does not 381 know the true principal name, authentication may fail if the alias is 382 sought in the client name field.) 383 384 The use of AD-KDC-ISSUED authorization data elements in cross-realm 385 cases has not been well explored at this writing; hence we will only 386 specify the inclusion of this data in the one-realm case. The alias 387 information SHOULD be dropped in the general cross-realm case. 388 389 390 391Raeburn & Zhu Expires January 15, 2009 [Page 7] 392 393Internet-Draft KDC Referrals July 2008 394 395 396 However, a realm MAY implement a policy of accepting and re-signing 397 (wrapping in a new AD-KDC-ISSUED element) alias information provided 398 by certain trusted realms, in the cross-realm ticket-granting 399 service. 400 401 The canonical principal name for an alias may not be in the form of a 402 ticket-granting service name, as (in a case of server name 403 canonicalization) that would be construed as a case of cross-realm 404 referral, described below. 405 406 4077. Client Referrals 408 409 The simplest form of ticket referral is for a user requesting a 410 ticket using an AS-REQ. In this case, the client machine will send 411 the AS-REQ to a convenient trusted realm, for example the realm of 412 the client machine. In the case of the name alice@EXAMPLE.COM, the 413 client MAY optimistically choose to send the request to EXAMPLE.COM. 414 The realm in the AS-REQ is always the name of the realm that the 415 request is for as specified in [RFC4120]. 416 417 The KDC will try to lookup the name in its local account database. 418 If the account is present in the realm of the request, it SHOULD 419 return a KDC reply structure with the appropriate ticket. 420 421 If the account is not present in the realm specified in the request 422 and the "canonicalize" KDC option is set, the KDC may look up the 423 client principal name using some kind of name service or directory 424 service. If this lookup is unsuccessful, it MUST return the error 425 KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful, 426 it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the 427 error message the crealm field will contain either the true realm of 428 the client or another realm that MAY have better information about 429 the client's true realm. The client SHALL NOT use the cname returned 430 in this error message. 431 432 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 433 new AS request with the same client principal name used to generate 434 the first referral to the realm specified by the realm field of the 435 Kerberos error message corresponding to the first request. (The 436 client realm name will be updated in the new request to refer to this 437 new realm.) The client SHOULD repeat these steps until it finds the 438 true realm of the client. To avoid infinite referral loops, an 439 implementation should limit the number of referrals. A suggested 440 limit is 5 referrals before giving up. 441 442 Since the same client name is sent to the referring and referred-to 443 realms, both realms must recognize the same client names. In 444 445 446 447Raeburn & Zhu Expires January 15, 2009 [Page 8] 448 449Internet-Draft KDC Referrals July 2008 450 451 452 particular, the referring realm cannot (usefully) define principal 453 name aliases that the referred-to realm will not know. 454 455 The true principal name of the client, returned in AS-REQ, can be 456 validated in a subsequent TGS message exchange where its value is 457 communicated back to the KDC via the authenticator in the PA-TGS-REQ 458 padata [RFC4120]. However, this requires trusting the referred-to 459 realm's KDCs. Clients should limit the referral mappings they will 460 accept to realms trusted via some local policy. Some possible 461 factors that might be taken into consideration for such a policy 462 might include: 463 464 o Any realm indicated by the local KDC, if the returned KRB-ERROR 465 message is protected by some additional means, for example using a 466 preauthentication scheme using a public key known to be associated 467 with the KDC, or an IPsec tunnel known to have the desired KDC as 468 the remote endpoint 469 o A list of realms configured by an administrator 470 o Any realm accepted by the user when explicitly prompted 471 472 There is currently no provision for changing the client name in a 473 client referral response, because there is no method for verifying 474 that a man-in-the-middle attack did not change the requested name in 475 the request on the way to the KDC. 476 477 4788. Server Referrals 479 480 The primary difference in server referrals is that the KDC returns a 481 referral TGT rather than an error message as is done in the client 482 referrals. There needs to be a place to include in the reply 483 information about what realm contains the server; this is done by 484 returning information about the server name in the pre-authentication 485 data field of the KDC reply [RFC4120], as specified later in this 486 section. 487 488 If the "canonicalize" flag in the KDC options is set and the KDC 489 doesn't find the principal locally, either as a regular principal or 490 as an alias for another local principal, the KDC MAY return a cross- 491 realm ticket granting ticket to the next hop on the trust path 492 towards a realm that may be able to resolve the principal name. The 493 true principal name of the server SHALL be returned in the padata of 494 the reply if it is different from what is specified the request. 495 496 When a referral TGT is returned, the KDC MUST return the target realm 497 for the referral TGT as an KDC supplied pre-authentication data 498 element in the response. This referral information in pre- 499 authentication data MUST be encrypted using the session key from the 500 501 502 503Raeburn & Zhu Expires January 15, 2009 [Page 9] 504 505Internet-Draft KDC Referrals July 2008 506 507 508 reply ticket. The key usage value for the encryption operation used 509 by PA-SERVER-REFERRAL is 26. 510 511 The pre-authentication data returned by the KDC, which contains the 512 referred realm and the true principal name of server, is encoded in 513 DER as follows. 514 515 516 PA-SERVER-REFERRAL 25 517 518 SERVER-REFERRAL-DATA ::= EncryptedData 519 -- ServerReferralData 520 -- returned session key, ku=26 521 522 ServerReferralData ::= SEQUENCE { 523 referred-realm [0] Realm OPTIONAL, 524 -- target realm of the referral TGT 525 true-principal-name [1] PrincipalName OPTIONAL, 526 -- true server principal name 527 requested-principal-name [2] PrincipalName OPTIONAL, 528 -- requested server name 529 referral-valid-until [3] KerberosTime OPTIONAL, 530 rep-cksum [4] Checksum, 531 -- associated {AS,TGS}-REP with no padata 532 -- reply key, ku=[TBD] 533 ... 534 } 535 536 The rep-cksum field is a checksum computed over the DER encoding of 537 the AS-REP or TGS-REP message with which the SERVER-REFERRAL-DATA is 538 included, but with the padata field omitted. It SHOULD be computed 539 using the mandatory-to-implement checksum type associated with the 540 encryption type of the reply key. (Encrypting the referral data in 541 with the reply key but without the checksum only proves that it was 542 generated by one of the parties with access to the reply key; it is 543 not proof against cut-and-paste attacks combining parts of different 544 KDC replies using the same reply key.) 545 546 Clients SHALL NOT accept a reply ticket in which the server principal 547 name is different from that of the request, if the KDC response does 548 not contain a PA-SERVER-REFERRAL padata entry. 549 550 The requested-principal-name MUST be included by the KDC, and MUST be 551 verified by the client, if the client sent an AS-REQ, as protection 552 against a man-in-the-middle modification to the AS-REQ message. 553 554 The referred-realm field is present if and only if the returned 555 ticket is a referral TGT, not a service ticket for the requested 556 557 558 559Raeburn & Zhu Expires January 15, 2009 [Page 10] 560 561Internet-Draft KDC Referrals July 2008 562 563 564 server principal. 565 566 When a referral TGT is returned and the true-principal-name field is 567 present, the client MUST use that name in the subsequent requests to 568 the server realm when following the referral. 569 570 Client SHALL NOT accept a true server principal name for a service 571 ticket if the true-principal-name field is not present in the PA- 572 SERVER-REFERRAL data. 573 574 The client will use this referral information to request a chain of 575 cross-realm ticket granting tickets until it reaches the realm of the 576 server, and can then expect to receive a valid service ticket. 577 578 However an implementation should limit the number of referrals that 579 it processes to avoid infinite referral loops. A suggested limit is 580 5 referrals before giving up. 581 582 The client may cache the mapping of the requested name to the name of 583 the next realm to use and the principal name to ask for. (See 584 Section 10.) The referral-valid-until field, if present, conveys how 585 long this information is valid for. 586 587 Here is an example of a client requesting a service ticket for a 588 service in realm DEV.EXAMPLE.COM where the client is in 589 ADMIN.EXAMPLE.COM. 590 591 +NC = Canonicalize KDCOption set 592 +PA-REFERRAL = returned PA-SERVER-REFERRAL 593 C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM 594 S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL 595 containing EXAMPLE.COM as the referred realm with no 596 true-principal-name 597 C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM 598 S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL 599 containing DEV.EXAMPLE.COM as the referred realm with no 600 true-principal-name 601 C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM 602 S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM 603 604 Note that any referral or alias processing of the server name in 605 user-to-user authentication should use the same data as client name 606 canonicalization or referral. Otherwise, the name used by one user 607 to log in may not be useable by another for user-to-user 608 authentication to the first. 609 610 611 612 613 614 615Raeburn & Zhu Expires January 15, 2009 [Page 11] 616 617Internet-Draft KDC Referrals July 2008 618 619 6209. Cross Realm Routing 621 622 The current Kerberos protocol requires the client to explicitly 623 request a cross-realm TGT for each pair of realms on a referral 624 chain. As a result, the client need to be aware of the trust 625 hierarchy and of any short-cut trusts (those that aren't parent- 626 child trusts). 627 628 Instead, using the server referral routing mechanism as defined in 629 Section 8, The KDC will determine the best path for the client and 630 return a cross-realm TGT as the referral TGT, and the target realm 631 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 632 633 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 634 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 635 response does not contain the PA-SERVER-REFERRAL padata. 636 637 63810. Caching Information 639 640 It is possible that the client may wish to get additional credentials 641 for the same service principal, perhaps with different authorization- 642 data restrictions or other changed attributes. The return of a 643 server referral from a KDC can be taken as an indication that the 644 requested principal does not currently exist in the local realm. 645 Clearly, it would reduce network traffic if the clients could cache 646 that information and use it when acquiring the second set of 647 credentials for a service, rather than always having to re-check with 648 the local KDC to see if the name has been created locally. 649 650 If the referral-valid-until field is provided in the PA-SERVER- 651 REFERRAL-DATA message, it indicates the expiration time of this data; 652 if it is not included, the expiration time of the TGT is used. When 653 the TGT expires, the previously returned referral from the local KDC 654 should be considered invalid, and the local KDC must be asked again 655 for information for the desired service principal name. (Note that 656 the client may get back multiple referral TGTs from the local KDC to 657 the same remote realm, with different lifetimes. The lifetime 658 information must be properly associated with the requested service 659 principal names. Simply having another TGT for the same remote realm 660 does not extend the validity of previously acquired information about 661 one service principal name.) If the client is still in contact with 662 the service and needs to reauthenticate to the same service 663 regardless of local service principal name assignments, it should use 664 the referred-realm and true-principal-name values when requesting new 665 credentials. 666 667 Accordingly, KDC authors and maintainers should consider what factors 668 669 670 671Raeburn & Zhu Expires January 15, 2009 [Page 12] 672 673Internet-Draft KDC Referrals July 2008 674 675 676 (e.g., DNS alias lifetimes) they may or may not wish to incorporate 677 into credential expiration times in cases of referrals. 678 679 68011. Open Issues 681 682 Client referral info validation 683 684 When should client name aliases be included in credentials? Should 685 all known client name aliases be included, or only the one used at 686 initial ticket acquisition? 687 688 Should list the policies that need to be defined. 689 690 More examples: u2u, policy checks, maybe cross-realm. 691 692 Possibly generalize the integrity/privacy protection on 693 ServerReferralData into a general padata wrapper? 694 695 Is PA-SERVER-REFERRAL needed in a TGS exchange? 696 697 Do we need to send requested-name fields, or can we just include them 698 in checksums? 699 700 70112. Number Assignments 702 703 Most number registries in the Kerberos protocol have not been turned 704 over to IANA for management at the time of this writing, hence this 705 is not an "IANA Considerations" section. 706 707 Various values do need assigning for this draft: 708 AD-LOGIN-ALIAS 709 PA-CLIENT-CANONICALIZED 710 key usage value for PA-CLIENT-CANONICALIZED field canon-checksum 711 712 71313. IANA Considerations 714 715 None at present. 716 717 71814. Security Considerations 719 720 For the AS exchange case, it is important that the logon mechanism 721 not trust a name that has not been used to authenticate the user. 722 For example, the name that the user enters as part of a logon 723 exchange may not be the name that the user authenticates as, given 724 725 726 727Raeburn & Zhu Expires January 15, 2009 [Page 13] 728 729Internet-Draft KDC Referrals July 2008 730 731 732 that the KDC_ERR_WRONG_REALM error may have been returned. The 733 relevant Kerberos naming information for logon (if any), is the 734 client name and client realm in the service ticket targeted at the 735 workstation that was obtained using the user's initial TGT. 736 737 How the client name and client realm is mapped into a local account 738 for logon is a local matter, but the client logon mechanism MUST use 739 additional information such as the client realm and/or authorization 740 attributes from the service ticket presented to the workstation by 741 the user, when mapping the logon credentials to a local account on 742 the workstation. 743 74414.1. Shared-password case 745 746 A special case to examine is when the user is known (or correctly 747 suspected) to use the same password for multiple accounts. A man-in- 748 the-middle attacker can either alter the request on its way to the 749 KDC, changing the client principal name, or reply to the client with 750 a response previously send by the KDC in response to a request from 751 the attacker. The response received by the client can then be 752 decrypted by the user, though if the default "salt" generated from 753 the principal name is used to produce the user's key, a PA-ETYPE-INFO 754 or PA-ETYPE-INFO2 preauth record may need to be added or altered by 755 the attacker to cause the client software to generate the key needed 756 for the message it will receive. None of this requires the attacker 757 to know the user's password, and without further checking, could 758 cause the user to unknowingly use the wrong credentials. 759 760 In normal [RFC4120] operation, a generated AP-REQ message includes in 761 the Authenticator field a copy of the client's idea of its own 762 principal name. If this differs from the name in the KDC-generated 763 Ticket, the application server will reject the message. 764 765 With client name canonicalization as described in this document, the 766 client may get its principal name from the response from the KDC. 767 Requiring the PA-CLIENT-CANONICALIZED data lets the client securely 768 check that the requested name was not altered in transit. If the PA- 769 CLIENT-CANONICALIZED data is absent, the client can use the principal 770 name it requested. 771 77214.2. Preauthentication data 773 774 In cases of credential renewal, forwarding, or validation, if 775 credentials are sent to the KDC that are not an initial ticket- 776 granting ticket for the client's home realm, the encryption key used 777 to protect the TGS exchange is one known to a third party (namely, 778 the service for which the credential was issued). Consequently, in 779 such an exchange, the protection described earlier for the 780 781 782 783Raeburn & Zhu Expires January 15, 2009 [Page 14] 784 785Internet-Draft KDC Referrals July 2008 786 787 788 preauthentication data cannot be assumed to provide a secure channel 789 between the KDC and the client, and such preauth data MUST NOT be 790 trusted for any information that needs to come from the KDC. 791 792 79315. Acknowledgments 794 795 Sam Hartman and authors came up with the idea of using the ticket key 796 to encrypt the referral data, which prevents cut and paste attack 797 using the referral data and referral TGTs. 798 799 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 800 version of this document. 801 802 Karthik Jaganathan contributed to earlier versions. 803 804 80516. References 806 80716.1. Normative References 808 809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 810 Requirement Levels", BCP 14, RFC 2119, March 1997. 811 812 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 813 Kerberos Network Authentication Service (V5)", RFC 4120, 814 July 2005. 815 81616.2. Informative References 817 818 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 819 X.509 Public Key Infrastructure Certificate and 820 Certificate Revocation List (CRL) Profile", RFC 3280, 821 April 2002. 822 823 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 824 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 825 826 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation 827 of Crossrealm Referral Handling in the MIT Kerberos 828 Client", Network and Distributed System Security 829 Symposium, February 2001. 830 831 832Appendix A. Compatibility with Earlier Implementations of Name 833 Canonicalization 834 835 The Microsoft Windows 2000 and Windows 2003 releases included an 836 837 838 839Raeburn & Zhu Expires January 15, 2009 [Page 15] 840 841Internet-Draft KDC Referrals July 2008 842 843 844 earlier form of name-canonicalization [XPR]. Here are the 845 differences: 846 847 1) The TGS referral data is returned inside of the KDC message as 848 "encrypted pre-authentication data". 849 850 851 852 EncKDCRepPart ::= SEQUENCE { 853 key [0] EncryptionKey, 854 last-req [1] LastReq, 855 nonce [2] UInt32, 856 key-expiration [3] KerberosTime OPTIONAL, 857 flags [4] TicketFlags, 858 authtime [5] KerberosTime, 859 starttime [6] KerberosTime OPTIONAL, 860 endtime [7] KerberosTime, 861 renew-till [8] KerberosTime OPTIONAL, 862 srealm [9] Realm, 863 sname [10] PrincipalName, 864 caddr [11] HostAddresses OPTIONAL, 865 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 866 } 867 868 2) The preauth data type definition in the encrypted preauth data is 869 as follows: 870 871 872 873 PA-SVR-REFERRAL-INFO 20 874 875 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 876 referred-name [1] PrincipalName OPTIONAL, 877 referred-realm [0] Realm 878 }} 879 880 3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is 881 encoded as a Subject Alternative Name (SAN) extension [RFC3280] in 882 the client's X.509 certificate. The type of the otherName field 883 for this SAN extension is AnotherName [RFC3280]. The type-id 884 field of the type AnotherName is id-ms-sc-logon-upn 885 (1.3.6.1.4.1.311.20.2.3) and the value field of the type 886 AnotherName is a KerberosString [RFC4120]. The value of this 887 KerberosString type is the single component in the name-string 888 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 889 890 In Microsoft's current implementation through the use of global 891 catalogs any domain in one forest is reachable from any other domain 892 893 894 895Raeburn & Zhu Expires January 15, 2009 [Page 16] 896 897Internet-Draft KDC Referrals July 2008 898 899 900 in the same forest or another trusted forest with 3 or less 901 referrals. A forest is a collection of realms with hierarchical 902 trust relationships: there can be multiple trust trees in a forest; 903 each child and parent realm pair and each root realm pair have 904 bidirectional transitive direct rusts between them. 905 906 While we might want to permit multiple aliases to exist and even be 907 reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only 908 one NT-ENTERPRISE alias to exist, so this question had not previously 909 arisen. 910 911 912Appendix B. Document history [REMOVE BEFORE PUBLICATION] 913 914 11 Changed title. Better protection on server referral preauth data. 915 Support server name canonicalization. Rename ReferralInfo to 916 ClientReferralInfo. Disallow alias mapping to a TGT principal. 917 Explain why no name change in client referrals. Add empty IANA 918 Considerations. Add some notes on preauth data protection during 919 renewal etc. 920 10 Separate enterprise principal names into a separate section. Add 921 a little wording to suggest server principal name canonicalization 922 might be allowed; not fleshed out. Advise against AD-KDC-ISSUED 923 in cronn-realm cases. Advise policy checks on returned client 924 referral info, since there's no security. List number 925 assignments. Add security analysis of shared-password case. No 926 longer plan to remove Microsoft appendix. Add referral-valid- 927 until field. 928 09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain. 929 Rewrote description of existing practice. (Don't name the lookup 930 table consulted. Mention that DNS "canonicalization" is contrary 931 to [RFC4120].) Noted Microsoft behavior should be moved out into 932 a separate document. Changed some second-person references in the 933 introduction to identify the proper parties. Changed PA-CLIENT- 934 CANONICALIZED to use a separate type for the actual referral data, 935 add an extension marker to that type, and change the checksum key 936 from the "returned session key" to the "AS reply key". Changed 937 AD-LOGIN-ALIAS to contain a sequence of names, to be contained in 938 AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer 939 needed separate checksum. Attempt to clarify the cache lifetime 940 of referral information. 941 08 Moved Microsoft implementation info to appendix. Clarify lack of 942 local server name canonicalization. Added optional authz-data for 943 login alias, to support user-to-user case. Added requested- 944 principal-name to ServerReferralData. Added discussion of caching 945 information, and referral TGT lifetime. 946 947 948 949 950 951Raeburn & Zhu Expires January 15, 2009 [Page 17] 952 953Internet-Draft KDC Referrals July 2008 954 955 956 07 Re-issued with new editor. Fixed up some references. Started 957 history. 958 959 960Authors' Addresses 961 962 Kenneth Raeburn 963 Massachusetts Institute of Technology 964 77 Massachusetts Avenue 965 Cambridge, MA 02139 966 US 967 968 Email: raeburn@mit.edu 969 970 971 Larry Zhu 972 Microsoft Corporation 973 One Microsoft Way 974 Redmond, WA 98052 975 US 976 977 Email: lzhu@microsoft.com 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007Raeburn & Zhu Expires January 15, 2009 [Page 18] 1008 1009Internet-Draft KDC Referrals July 2008 1010 1011 1012Full Copyright Statement 1013 1014 Copyright (C) The IETF Trust (2008). 1015 1016 This document is subject to the rights, licenses and restrictions 1017 contained in BCP 78, and except as set forth therein, the authors 1018 retain all their rights. 1019 1020 This document and the information contained herein are provided on an 1021 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1022 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1023 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1024 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1025 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1026 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1027 1028 1029Intellectual Property 1030 1031 The IETF takes no position regarding the validity or scope of any 1032 Intellectual Property Rights or other rights that might be claimed to 1033 pertain to the implementation or use of the technology described in 1034 this document or the extent to which any license under such rights 1035 might or might not be available; nor does it represent that it has 1036 made any independent effort to identify any such rights. Information 1037 on the procedures with respect to rights in RFC documents can be 1038 found in BCP 78 and BCP 79. 1039 1040 Copies of IPR disclosures made to the IETF Secretariat and any 1041 assurances of licenses to be made available, or the result of an 1042 attempt made to obtain a general license or permission for the use of 1043 such proprietary rights by implementers or users of this 1044 specification can be obtained from the IETF on-line IPR repository at 1045 http://www.ietf.org/ipr. 1046 1047 The IETF invites any interested party to bring to its attention any 1048 copyrights, patents or patent applications, or other proprietary 1049 rights that may cover technology that may be required to implement 1050 this standard. Please address the information to the IETF at 1051 ietf-ipr@ietf.org. 1052 1053 1054Acknowledgment 1055 1056 Funding for the RFC Editor function is provided by the IETF 1057 Administrative Support Activity (IASA). 1058 1059 1060 1061 1062 1063Raeburn & Zhu Expires January 15, 2009 [Page 19] 1064 1065