idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 697. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2007) is 6261 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 589 -- Looks like a reference, but probably isn't: '1' on line 588 -- Looks like a reference, but probably isn't: '2' on line 569 -- Looks like a reference, but probably isn't: '3' on line 570 -- Looks like a reference, but probably isn't: '4' on line 571 -- Looks like a reference, but probably isn't: '5' on line 572 -- Looks like a reference, but probably isn't: '6' on line 573 -- Looks like a reference, but probably isn't: '7' on line 574 -- Looks like a reference, but probably isn't: '8' on line 575 -- Looks like a reference, but probably isn't: '9' on line 576 -- Looks like a reference, but probably isn't: '10' on line 577 -- Looks like a reference, but probably isn't: '11' on line 578 -- Looks like a reference, but probably isn't: '12' on line 579 -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP K. Raeburn 3 Internet-Draft MIT 4 Updates: 4120 (if approved) L. Zhu 5 Intended status: Standards Track Microsoft Corporation 6 Expires: September 6, 2007 March 5, 2007 8 Generating KDC Referrals to Locate Kerberos Realms 9 draft-ietf-krb-wg-kerberos-referrals-09 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 6, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The memo documents a method for a Kerberos Key Distribution Center 43 (KDC) to respond to client requests for Kerberos tickets when the 44 client does not have detailed configuration information on the realms 45 of users or services. The KDC will handle requests for principals in 46 other realms by returning either a referral error or a cross-realm 47 TGT to another realm on the referral path. The clients will use this 48 referral information to reach the realm of the target principal and 49 then receive the ticket. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 55 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4 56 4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5 57 5. Client Name Canonicalization . . . . . . . . . . . . . . . . . 5 58 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 7 59 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 8 60 8. Server Name Canonicalization (Informative) . . . . . . . . . . 10 61 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 10 62 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11 63 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 66 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 14.2. Informative References . . . . . . . . . . . . . . . . . 12 69 Appendix A. Compatibility with Earlier Implementations of 70 Name Canonicalization . . . . . . . . . . . . . . . . 13 71 Appendix B. Document history . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 73 Intellectual Property and Copyright Statements . . . . . . . . . . 16 75 1. Introduction 77 Current implementations of the Kerberos AS and TGS protocols, as 78 defined in [RFC4120], use principal names constructed from a known 79 user or service name and realm. A service name is typically 80 constructed from a name of the service and the DNS host name of the 81 computer that is providing the service. Many existing deployments of 82 Kerberos use a single Kerberos realm where all users and services 83 would be using the same realm. However in an environment where there 84 are multiple trusted Kerberos realms, the client needs to be able to 85 determine what realm a particular user or service is in before making 86 an AS or TGS request. Traditionally this requires client 87 configuration to make this possible. 89 When having to deal with multiple trusted realms, users are forced to 90 know what realm they are in before they can obtain a ticket granting 91 ticket (TGT) with an AS request. However, in many cases the user 92 would like to use a more familiar name that is not directly related 93 to the realm of their Kerberos principal name. A good example of 94 this is an RFC 822 style email name. This document describes a 95 mechanism that would allow a user to specify a user principal name 96 that is an alias for the user's Kerberos principal name. In practice 97 this would be the name that the user specifies to obtain a TGT from a 98 Kerberos KDC. The user principal name no longer has a direct 99 relationship with the Kerberos principal or realm. Thus the 100 administrator is able to move the user's principal to other realms 101 without the user having to know that it happened. 103 Once a user has a TGT, they would like to be able to access services 104 in any trusted Kerberos realm. To do this requires that the client 105 be able to determine what realm the target service principal is in 106 before making the TGS request. Current implementations of Kerberos 107 typically have a table that maps DNS host names to corresponding 108 Kerberos realms. The user-supplied host name or its domain component 109 is looked up in this table (often using the result of some form of 110 host name lookup performed with insecure DNS queries, in violation of 111 [RFC4120]). The corresponding realm is then used to complete the 112 target service principal name. 114 This traditional mechanism requires that each client have very 115 detailed configuration information about the hosts that are providing 116 services and their corresponding realms. Having client side 117 configuration information can be very costly from an administration 118 point of view - especially if there are many realms and computers in 119 the environment. 121 There are also cases where specific DNS aliases (local names) have 122 been setup in an organization to refer to a server in another 123 organization (remote server). The server has different DNS names in 124 each organization and each organization has a Kerberos realm that is 125 configured to service DNS names within that organization. Ideally 126 users are able to authenticate to the server in the other 127 organization using the local server name. This would mean that the 128 local realm be able to produce a ticket to the remote server under 129 its name. The administrator in the local realm could give that 130 remote server an identity in the local realm and then have that 131 remote server maintain a separate secret for each alias it is known 132 as. Alternatively the administrator could arrange to have the local 133 realm issue a referral to the remote realm and notify the requesting 134 client of the server's remote name that should be used in order to 135 request a ticket. 137 This memo proposes a solution for these problems and simplifies 138 administration by minimizing the configuration information needed on 139 each computer using Kerberos. Specifically it describes a mechanism 140 to allow the KDC to handle canonicalization of names, provide for 141 principal aliases for users and services and allow the KDC to 142 determine the trusted realm authentication path by being able to 143 generate referrals to other realms in order to locate principals. 145 Two kinds of KDC referrals are introduced in this memo: 147 1. Client referrals, in which the client doesn't know which realm 148 contains a user account. 149 2. Server referrals, in which the client doesn't know which realm 150 contains a server account. 152 2. Conventions Used in This Document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 3. Requesting a Referral 160 In order to request referrals defined in section 5, 6, and 7, the 161 Kerberos client MUST explicitly request the canonicalize KDC option 162 (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to 163 the KDC that the client is prepared to receive a reply that contains 164 a principal name other than the one requested. 166 KDCOptions ::= KerberosFlags 167 -- canonicalize (15) 168 -- other KDCOptions values omitted 170 The client should expect, when sending names with the "canonicalize" 171 KDC option, that names in the KDC's reply MAY be different than the 172 name in the request. A referral TGT is a cross realm TGT that is 173 returned with the server name of the ticket being different from the 174 server name in the request [RFC4120]. 176 4. Realm Organization Model 178 This memo assumes that the world of principals is arranged on 179 multiple levels: the realm, the enterprise, and the world. A KDC may 180 issue tickets for any principal in its realm or cross-realm tickets 181 for realms with which it has a direct trust relationship. The KDC 182 also has access to a trusted name service that can resolve any name 183 from within its enterprise into a realm. This trusted name service 184 removes the need to use an un-trusted DNS lookup for name resolution. 186 For example, consider the following configuration, where lines 187 indicate trust relationships: 189 EXAMPLE.COM 190 / \ 191 / \ 192 ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM 194 In this configuration, all users in the EXAMPLE.COM enterprise could 195 have principal names such as alice@EXAMPLE.COM, with the same realm 196 portion. In addition, servers at EXAMPLE.COM should be able to have 197 DNS host names from any DNS domain independent of what Kerberos realm 198 their principals reside in. 200 5. Client Name Canonicalization 202 A client account may have multiple principal names. More useful, 203 though, is a globally unique name that allows unification of email 204 and security principal names. For example, all users at EXAMPLE.COM 205 may have a client principal name of the form "joe@EXAMPLE.COM" even 206 though the principals are contained in multiple realms. This global 207 name is again an alias for the true client principal name, which 208 indicates what realm contains the principal. Thus, accounts "alice" 209 in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log 210 on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM". 212 This utilizes a new client principal name type, as the AS-REQ message 213 only contains a single realm field, and the realm portion of this 214 name corresponds to the Kerberos realm with which the request is 215 made. Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a 216 single component in the client name field of the AS-REQ message, with 217 a name type of NT-ENTERPRISE [RFC4120] (and the local realm name). 218 The KDC will recognize this name type and then transform the 219 requested name into the true principal name if the client account 220 resides in the local realm. The true principal name can have a name 221 type different from the requested name type. Typically the true 222 principal name will be a NT-PRINCIPAL [RFC4120]. 224 If the "canonicalize" KDC option is set, then the KDC MAY change the 225 client principal name and type in the AS response and ticket returned 226 from the name type of the client name in the request, and include a 227 mandatory PA-DATA object authenticating the client name mapping: 229 ReferralInfo ::= SEQUENCE { 230 requested-name [0] PrincipalName, 231 mapped-name [1] PrincipalName, 232 ... 233 } 234 PA-CLIENT-CANONICALIZED ::= SEQUENCE { 235 names [0] ReferralInfo, 236 canon-checksum [1] Checksum 237 } 239 The canon-checksum field is computed over the DER encoding of the 240 names sequences, using the AS reply key and a key usage value of 241 (TBD). 243 If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is 244 not included. If the client name is changed, and the PA-CLIENT- 245 CANONICALIZED field does not exist, or the checksum cannot be 246 verified, or the requested-name field doesn't match the client name 247 in the originally-transmitted request, the client should discard the 248 response. 250 For example the AS request may specify a client name of "bob@ 251 EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC 252 option set and the KDC will return with a client name of "104567" as 253 a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT- 254 ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the 255 NT-UID "104567" principal as the mapped-name. 257 (It is assumed that the client discovers whether the KDC supports the 258 NT-ENTERPRISE name type via out of band mechanisms.) 260 In order to enable one party in a user-to-user exchange to confirm 261 the identity of another when only the alias is known, the KDC MAY 262 include the following authorization data element, wrapped in AD-KDC- 263 ISSUED, in the initial credentials and copy it from a ticket-granting 264 ticket into additional credentials: 266 AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD -- 267 login-aliases [0] SEQUENCE(1..MAX) OF PrincipalName, 268 } 270 The login-aliases field lists one or more of the aliases the 271 principal may have used in the initial ticket request. 273 The recipient of this authenticator must check the AD-LOGIN-ALIAS 274 names, if present, in addition to the normal client name field, 275 against the identity of the party with which it wishes to 276 authenticate; either should be allowed to match. (Note that this is 277 not backwards compatible with [RFC4120]; if the server side of the 278 user-to-user exchange does not support this extension, and does not 279 know the true principal name, authentication may fail if the alias is 280 sought in the client name field.) 282 6. Client Referrals 284 The simplest form of ticket referral is for a user requesting a 285 ticket using an AS-REQ. In this case, the client machine will send 286 the AS-REQ to a convenient trusted realm, for example the realm of 287 the client machine. In the case of the name alice@EXAMPLE.COM, the 288 client MAY optimistically choose to send the request to EXAMPLE.COM. 289 The realm in the AS-REQ is always the name of the realm that the 290 request is for as specified in [RFC4120]. 292 The KDC will try to lookup the name in its local account database. 293 If the account is present in the realm of the request, it SHOULD 294 return a KDC reply structure with the appropriate ticket. 296 If the account is not present in the realm specified in the request 297 and the "canonicalize" KDC option is set, the KDC will try to lookup 298 the entire name, alice@EXAMPLE.COM, using a name service. If this 299 lookup is unsuccessful, it MUST return the error 300 KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful, 301 it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the 302 error message the crealm field will contain either the true realm of 303 the client or another realm that MAY have better information about 304 the client's true realm. The client SHALL NOT use a cname returned 305 from a Kerberos error until that name is validated. 307 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 308 new AS request with the same client principal name used to generate 309 the first referral to the realm specified by the realm field of the 310 Kerberos error message corresponding to the first request. (The 311 client realm name will be updated in the new request to refer to this 312 new realm.) The client SHOULD repeat these steps until it finds the 313 true realm of the client. To avoid infinite referral loops, an 314 implementation should limit the number of referrals. A suggested 315 limit is 5 referrals before giving up. 317 Since the same client name is sent to the referring and referred-to 318 realms, both realms must recognize the same client names. In 319 particular, the referring realm cannot (usefully) define principal 320 name aliases that the referred-to realm will not know. 322 The true principal name of the client, returned in AS-REQ, can be 323 validated in a subsequent TGS message exchange where its value is 324 communicated back to the KDC via the authenticator in the PA-TGS-REQ 325 padata [RFC4120]. 327 7. Server Referrals 329 The primary difference in server referrals is that the KDC MUST 330 return a referral TGT rather than an error message as is done in the 331 client referrals. There needs to be a place to include in the reply 332 information about what realm contains the server. This is done by 333 returning information about the server name in the pre-authentication 334 data field of the KDC reply [RFC4120], as specified later in this 335 section. 337 If the KDC resolves the server principal name into a principal in the 338 realm specified by the service realm name, it will return a normal 339 ticket. 341 If the "canonicalize" flag in the KDC options is not set, the KDC 342 MUST only look up the name as a normal principal name in the 343 specified server realm. If the "canonicalize" flag in the KDC 344 options is set and the KDC doesn't find the principal locally, the 345 KDC MAY return a cross-realm ticket granting ticket to the next hop 346 on the trust path towards a realm that may be able to resolve the 347 principal name. The true principal name of the server SHALL be 348 returned in the padata of the reply if it is different from what is 349 specified the request. 351 When a referral TGT is returned, the KDC MUST return the target realm 352 for the referral TGT as an KDC supplied pre-authentication data 353 element in the response. This referral information in pre- 354 authentication data MUST be encrypted using the session key from the 355 reply ticket. The key usage value for the encryption operation used 356 by PA-SERVER-REFERRAL is 26. 358 The pre-authentication data returned by the KDC, which contains the 359 referred realm and the true principal name of server, is encoded in 360 DER as follows. 362 PA-SERVER-REFERRAL 25 364 PA-SERVER-REFERRAL-DATA ::= EncryptedData 365 -- ServerReferralData -- 367 ServerReferralData ::= SEQUENCE { 368 referred-realm [0] Realm OPTIONAL, 369 -- target realm of the referral TGT 370 true-principal-name [1] PrincipalName OPTIONAL, 371 -- true server principal name 372 requested-principal-name [2] PrincipalName OPTIONAL, 373 -- requested server name 374 ... 375 } 377 Clients SHALL NOT accept a reply ticket, whose the server principal 378 name is different from that of the request, if the KDC response does 379 not contain a PA-SERVER-REFERRAL padata entry. 381 The requested-principal-name MUST be included by the KDC, and MUST be 382 verified by the client, if the client sent an AS-REQ, as protection 383 against a man-in-the-middle modification to the AS-REQ message. 385 The referred-realm field is present if and only if the returned 386 ticket is a referral TGT, not a service ticket for the requested 387 server principal. 389 When a referral TGT is returned and the true-principal-name field is 390 present, the client MUST use that name in the subsequent requests to 391 the server realm when following the referral. 393 Client SHALL NOT accept a true server principal name for a service 394 ticket if the true-principal-name field is not present in the PA- 395 SERVER-REFERRAL data. 397 The client will use this referral information to request a chain of 398 cross-realm ticket granting tickets until it reaches the realm of the 399 server, and can then expect to receive a valid service ticket. 401 However an implementation should limit the number of referrals that 402 it processes to avoid infinite referral loops. A suggested limit is 403 5 referrals before giving up. 405 Here is an example of a client requesting a service ticket for a 406 service in realm DEV.EXAMPLE.COM where the client is in 407 ADMIN.EXAMPLE.COM. 409 +NC = Canonicalize KDCOption set 410 +PA-REFERRAL = returned PA-SERVER-REFERRAL 411 C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM 412 S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL 413 containing EXAMPLE.COM as the referred realm with no 414 true-principal-name 415 C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM 416 S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL 417 containing DEV.EXAMPLE.COM as the referred realm with no 418 true-principal-name 419 C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM 420 S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM 422 Note that any referral or alias processing of the server name in 423 user-to-user authentication should use the same data as client name 424 canonicalization or referral. Otherwise, the name used by one user 425 to log in may not be useable by another for user-to-user 426 authentication to the first. 428 8. Server Name Canonicalization (Informative) 430 No attempt is being made in this document to provide a means for 431 dealing with local-realm server principal name canonicalization or 432 aliasing. The most obvious use case for this would be a hostname- 433 based service principal name ("host/foobar.example.com"), with a DNS 434 alias ("foo") for the server host which is used by the client. There 435 are other ways this can be handled, currently, though they may 436 require additional configuration on the application server or KDC or 437 both. 439 9. Cross Realm Routing 441 The current Kerberos protocol requires the client to explicitly 442 request a cross-realm TGT for each pair of realms on a referral 443 chain. As a result, the client need to be aware of the trust 444 hierarchy and of any short-cut trusts (those that aren't parent- 445 child trusts). 447 Instead, using the server referral routing mechanism as defined in 448 Section 7, The KDC will determine the best path for the client and 449 return a cross-realm TGT as the referral TGT, and the target realm 450 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 452 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 453 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 454 response does not contain the PA-SERVER-REFERRAL padata. 456 10. Caching Information 458 It is possible that the client may wish to get additional credentials 459 for the same service principal, perhaps with different authorization- 460 data restrictions or other changed attributes. The return of a 461 server referral from a KDC can be taken as an indication that the 462 requested principal does not currently exist in the local realm. 463 Clearly, it would reduce network traffic if the clients could cache 464 that information and use it when acquiring the second set of 465 credentials for a service, rather than always having to re-check with 466 the local KDC to see if the name has been created locally. 468 Rather than introduce a new timeout field for this cached 469 information, we can use the lifetime of the returned TGT in this 470 case. When the TGT expires, the previously returned referral from 471 the local KDC should be considered invalid, and the local KDC must be 472 asked again for information for the desired service principal name. 473 (Note that the client may get back multiple referral TGTs from the 474 local KDC to the same remote realm, with different lifetimes. The 475 lifetime information must be properly associated with the requested 476 service principal names. Simply having another TGT for the same 477 remote realm does not extend the validity of previously acquired 478 information about one service principal name.) If the client is 479 still in contact with the service and needs to reauthenticate to the 480 same service regardless of local service principal name assignments, 481 it should use the referred-realm and true-principal-name values when 482 requesting new credentials. 484 Accordingly, KDC authors and maintainers should consider what factors 485 (e.g., DNS alias lifetimes) they may or may not wish to incorporate 486 into credential expiration times in cases of referrals. 488 11. Open Issues 490 When should client name aliases be included in credentials? 492 Should all known client name aliases be included, or only the one 493 used at initial ticket acquisition? 495 We still don't discuss what "validation" of the returned information 496 means. 498 12. Security Considerations 500 For the AS exchange case, it is important that the logon mechanism 501 not trust a name that has not been used to authenticate the user. 502 For example, the name that the user enters as part of a logon 503 exchange may not be the name that the user authenticates as, given 504 that the KDC_ERR_WRONG_REALM error may have been returned. The 505 relevant Kerberos naming information for logon (if any), is the 506 client name and client realm in the service ticket targeted at the 507 workstation that was obtained using the user's initial TGT. 509 How the client name and client realm is mapped into a local account 510 for logon is a local matter, but the client logon mechanism MUST use 511 additional information such as the client realm and/or authorization 512 attributes from the service ticket presented to the workstation by 513 the user, when mapping the logon credentials to a local account on 514 the workstation. 516 13. Acknowledgments 518 Sam Hartman and authors came up with the idea of using the ticket key 519 to encrypt the referral data, which prevents cut and paste attack 520 using the referral data and referral TGTs. 522 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 523 version of this document. 525 Karthik Jaganathan contributed to earlier versions. 527 14. References 529 14.1. Normative References 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, March 1997. 534 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 535 Kerberos Network Authentication Service (V5)", RFC 4120, 536 July 2005. 538 14.2. Informative References 540 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 541 X.509 Public Key Infrastructure Certificate and 542 Certificate Revocation List (CRL) Profile", RFC 3280, 543 April 2002. 545 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 546 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 548 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation 549 of Crossrealm Referral Handling in the MIT Kerberos 550 Client", Network and Distributed System Security 551 Symposium, February 2001. 553 Appendix A. Compatibility with Earlier Implementations of Name 554 Canonicalization 556 (Remove this section when Microsoft publishes this information in a 557 separate document.) 559 The Microsoft Windows 2000 and Windows 2003 releases included an 560 earlier form of name-canonicalization [XPR]. Here are the 561 differences: 563 1) The TGS referral data is returned inside of the KDC message as 564 "encrypted pre-authentication data". 566 EncKDCRepPart ::= SEQUENCE { 567 key [0] EncryptionKey, 568 last-req [1] LastReq, 569 nonce [2] UInt32, 570 key-expiration [3] KerberosTime OPTIONAL, 571 flags [4] TicketFlags, 572 authtime [5] KerberosTime, 573 starttime [6] KerberosTime OPTIONAL, 574 endtime [7] KerberosTime, 575 renew-till [8] KerberosTime OPTIONAL, 576 srealm [9] Realm, 577 sname [10] PrincipalName, 578 caddr [11] HostAddresses OPTIONAL, 579 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 580 } 582 2) The preauth data type definition in the encrypted preauth data is 583 as follows: 585 PA-SVR-REFERRAL-INFO 20 587 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 588 referred-name [1] PrincipalName OPTIONAL, 589 referred-realm [0] Realm 590 }} 592 3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is 593 encoded as a Subject Alternative Name (SAN) extension [RFC3280] in 594 the client's X.509 certificate. The type of the otherName field 595 for this SAN extension is AnotherName [RFC3280]. The type-id 596 field of the type AnotherName is id-ms-sc-logon-upn 597 (1.3.6.1.4.1.311.20.2.3) and the value field of the type 598 AnotherName is a KerberosString [RFC4120]. The value of this 599 KerberosString type is the single component in the name-string 600 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 602 In Microsoft's current implementation through the use of global 603 catalogs any domain in one forest is reachable from any other domain 604 in the same forest or another trusted forest with 3 or less 605 referrals. A forest is a collection of realms with hierarchical 606 trust relationships: there can be multiple trust trees in a forest; 607 each child and parent realm pair and each root realm pair have 608 bidirectional transitive direct rusts between them. 610 While we might want to permit multiple aliases to exist and even be 611 reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only 612 one NT-ENTERPRISE alias to exist, so this question had not previously 613 arisen. 615 Appendix B. Document history 617 [REMOVE BEFORE PUBLICATION.] 619 09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain. 620 Rewrote description of existing practice. (Don't name the lookup 621 table consulted. Mention that DNS "canonicalization" is contrary 622 to [RFC4120].) Noted Microsoft behavior should be moved out into 623 a separate document. Changed some second-person references in the 624 introduction to identify the proper parties. Changed PA-CLIENT- 625 CANONICALIZED to use a separate type for the actual referral data, 626 add an extension marker to that type, and change the checksum key 627 from the "returned session key" to the "AS reply key". Changed 628 AD-LOGIN-ALIAS to contain a sequence of names, to be contained in 629 AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer 630 needed separate checksum. Attempt to clarify the cache lifetime 631 of referral information. 633 08 Moved Microsoft implementation info to appendix. Clarify lack of 634 local server name canonicalization. Added optional authz-data for 635 login alias, to support user-to-user case. Added requested- 636 principal-name to ServerReferralData. Added discussion of caching 637 information, and referral TGT lifetime. 638 07 Re-issued with new editor. Fixed up some references. Started 639 history. 641 Authors' Addresses 643 Kenneth Raeburn 644 Massachusetts Institute of Technology 645 77 Massachusetts Avenue 646 Cambridge, MA 02139 647 US 649 Email: raeburn@mit.edu 651 Larry Zhu 652 Microsoft Corporation 653 One Microsoft Way 654 Redmond, WA 98052 655 US 657 Email: lzhu@microsoft.com 659 Full Copyright Statement 661 Copyright (C) The IETF Trust (2007). 663 This document is subject to the rights, licenses and restrictions 664 contained in BCP 78, and except as set forth therein, the authors 665 retain all their rights. 667 This document and the information contained herein are provided on an 668 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 669 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 670 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 671 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 672 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 673 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 675 Intellectual Property 677 The IETF takes no position regarding the validity or scope of any 678 Intellectual Property Rights or other rights that might be claimed to 679 pertain to the implementation or use of the technology described in 680 this document or the extent to which any license under such rights 681 might or might not be available; nor does it represent that it has 682 made any independent effort to identify any such rights. Information 683 on the procedures with respect to rights in RFC documents can be 684 found in BCP 78 and BCP 79. 686 Copies of IPR disclosures made to the IETF Secretariat and any 687 assurances of licenses to be made available, or the result of an 688 attempt made to obtain a general license or permission for the use of 689 such proprietary rights by implementers or users of this 690 specification can be obtained from the IETF on-line IPR repository at 691 http://www.ietf.org/ipr. 693 The IETF invites any interested party to bring to its attention any 694 copyrights, patents or patent applications, or other proprietary 695 rights that may cover technology that may be required to implement 696 this standard. Please address the information to the IETF at 697 ietf-ipr@ietf.org. 699 Acknowledgment 701 Funding for the RFC Editor function is provided by the IETF 702 Administrative Support Activity (IASA).