idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-08.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 671. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. -- 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 RFC 3978 Section 5.4 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 (June 25, 2006) is 6515 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 588 -- Looks like a reference, but probably isn't: '1' on line 587 -- Looks like a reference, but probably isn't: '2' on line 568 -- Looks like a reference, but probably isn't: '3' on line 569 -- Looks like a reference, but probably isn't: '4' on line 570 -- Looks like a reference, but probably isn't: '5' on line 571 -- Looks like a reference, but probably isn't: '6' on line 572 -- Looks like a reference, but probably isn't: '7' on line 573 -- Looks like a reference, but probably isn't: '8' on line 574 -- Looks like a reference, but probably isn't: '9' on line 575 -- Looks like a reference, but probably isn't: '10' on line 576 -- Looks like a reference, but probably isn't: '11' on line 577 -- Looks like a reference, but probably isn't: '12' on line 578 -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 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 Expires: December 27, 2006 K. Jaganathan 6 Microsoft Corporation 7 June 25, 2006 9 Generating KDC Referrals to Locate Kerberos Realms 10 draft-ietf-krb-wg-kerberos-referrals-08 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 27, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The memo documents a method for a Kerberos Key Distribution Center 44 (KDC) to respond to client requests for Kerberos tickets when the 45 client does not have detailed configuration information on the realms 46 of users or services. The KDC will handle requests for principals in 47 other realms by returning either a referral error or a cross-realm 48 TGT to another realm on the referral path. The clients will use this 49 referral information to reach the realm of the target principal and 50 then receive the ticket. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 56 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4 57 4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5 58 5. Client Name Canonicalization . . . . . . . . . . . . . . . . . 5 59 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 8 61 8. Server Name Canonicalization (Informative) . . . . . . . . . . 10 62 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 10 63 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11 64 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 67 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 14.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Appendix A. Compatibility with Earlier Implementations of 71 Name Canonicalization . . . . . . . . . . . . . . . . 13 72 Appendix B. Document history . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . . . . 16 76 1. Introduction 78 Current implementations of the Kerberos AS and TGS protocols, as 79 defined in [RFC4120], use principal names constructed from a known 80 user or service name and realm. A service name is typically 81 constructed from a name of the service and the DNS host name of the 82 computer that is providing the service. Many existing deployments of 83 Kerberos use a single Kerberos realm where all users and services 84 would be using the same realm. However in an environment where there 85 are multiple trusted Kerberos realms, the client needs to be able to 86 determine what realm a particular user or service is in before making 87 an AS or TGS request. Traditionally this requires client 88 configuration to make this possible. 90 When having to deal with multiple trusted realms, users are forced to 91 know what realm they are in before they can obtain a ticket granting 92 ticket (TGT) with an AS request. However, in many cases the user 93 would like to use a more familiar name that is not directly related 94 to the realm of their Kerberos principal name. A good example of 95 this is an RFC 822 style email name. This document describes a 96 mechanism that would allow a user to specify a user principal name 97 that is an alias for the user's Kerberos principal name. In practice 98 this would be the name that the user specifies to obtain a TGT from a 99 Kerberos KDC. The user principal name no longer has a direct 100 relationship with the Kerberos principal or realm. Thus the 101 administrator is able to move the user's principal to other realms 102 without the user having to know that it happened. 104 Once a user has a TGT, they would like to be able to access services 105 in any trusted Kerberos realm. To do this requires that the client 106 be able to determine what realm the target service principal is in 107 before making the TGS request. Current implementations of Kerberos 108 typically have a table that maps DNS host names to corresponding 109 Kerberos realms. In order for this to work on the client, each 110 application canonicalizes the host name of the service, for example 111 by doing a DNS lookup followed by a reverse lookup using the returned 112 IP address. The returned primary host name is then used in the 113 construction of the principal name for the target service. In order 114 for the correct realm to be added for the target host, the mapping 115 table [domain_to_realm] is consulted for the realm corresponding to 116 the DNS host name. The corresponding realm is then used to complete 117 the target service principal name. 119 This traditional mechanism requires that each client have very 120 detailed configuration information about the hosts that are providing 121 services and their corresponding realms. Having client side 122 configuration information can be very costly from an administration 123 point of view - especially if there are many realms and computers in 124 the environment. 126 There are also cases where specific DNS aliases (local names) have 127 been setup in an organization to refer to a server in another 128 organization (remote server). The server has different DNS names in 129 each organization and each organization has a Kerberos realm that is 130 configured to service DNS names within that organization. Ideally 131 users are able to authenticate to the server in the other 132 organization using the local server name. This would mean that the 133 local realm be able to produce a ticket to the remote server under 134 its name. You could give that remote server an identity in the local 135 realm and then have that remote server maintain a separate secret for 136 each alias it is known as. Alternatively you could arrange to have 137 the local realm issue a referral to the remote realm and notify the 138 requesting client of the server's remote name that should be used in 139 order to request a ticket. 141 This memo proposes a solution for these problems and simplifies 142 administration by minimizing the configuration information needed on 143 each computer using Kerberos. Specifically it describes a mechanism 144 to allow the KDC to handle canonicalization of names, provide for 145 principal aliases for users and services and provide a mechanism for 146 the KDC to determine the trusted realm authentication path by being 147 able to generate referrals to other realms in order to locate 148 principals. 150 Two kinds of KDC referrals are introduced in this memo: 152 1. Client referrals, in which the client doesn't know which realm 153 contains a user account. 154 2. Server referrals, in which the client doesn't know which realm 155 contains a server account. 157 2. Conventions Used in This Document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 3. Requesting a Referral 165 In order to request referrals defined in section 5, 6, and 7, the 166 Kerberos client MUST explicitly request the canonicalize KDC option 167 (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to 168 the KDC that the client is prepared to receive a reply that contains 169 a principal name other than the one requested. 171 KDCOptions ::= KerberosFlags 172 -- canonicalize (15) 173 -- other KDCOptions values omitted 175 The client should expect, when sending names with the "canonicalize" 176 KDC option, that names in the KDC's reply MAY be different than the 177 name in the request. A referral TGT is a cross realm TGT that is 178 returned with the server name of the ticket being different from the 179 server name in the request [RFC4120]. 181 4. Realm Organization Model 183 This memo assumes that the world of principals is arranged on 184 multiple levels: the realm, the enterprise, and the world. A KDC may 185 issue tickets for any principal in its realm or cross-realm tickets 186 for realms with which it has a direct trust relationship. The KDC 187 also has access to a trusted name service that can resolve any name 188 from within its enterprise into a realm. This trusted name service 189 removes the need to use an un-trusted DNS lookup for name resolution. 191 For example, consider the following configuration, where lines 192 indicate trust relationships: 194 MS.COM 195 / \ 196 / \ 197 OFFICE.MS.COM NTDEV.MS.COM 199 In this configuration, all users in the MS.COM enterprise could have 200 a principal name such as alice@MS.COM, with the same realm portion. 201 In addition, servers at MS.COM should be able to have DNS host names 202 from any DNS domain independent of what Kerberos realm their 203 principals reside in. 205 5. Client Name Canonicalization 207 A client account may have multiple principal names. More useful, 208 though, is a globally unique name that allows unification of email 209 and security principal names. For example, all users at MS may have 210 a client principal name of the form "joe@MS.COM" even though the 211 principals are contained in multiple realms. This global name is 212 again an alias for the true client principal name, which indicates 213 what realm contains the principal. Thus, accounts "alice" in the 214 realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may log on as "alice@ 215 MS.COM" and "bob@MS.COM". 217 This utilizes a new client principal name type, as the AS-REQ message 218 only contains a single realm field, and the realm portion of this 219 name doesn't correspond to any Kerberos realm. Thus, the entire name 220 "alice@MS.COM" is transmitted as a single component in the client 221 name field of the AS-REQ message, with a name type of NT-ENTERPRISE 222 [RFC4120] (and the local realm name). The KDC will recognize this 223 name type and then transform the requested name into the true 224 principal name. The true principal name can be using a name type 225 different from the requested name type. Typically the true principal 226 name will be a NT-PRINCIPAL [RFC4120]. 228 If the "canonicalize" KDC option is set, then the KDC MAY change the 229 client principal name and type in the AS response and ticket returned 230 from the name type of the client name in the request, and include a 231 mandatory PA-DATA object authenticating the client name mapping: 233 PA-CLIENT-CANONICALIZED ::= SEQUENCE { 234 names [0] SEQUENCE { 235 requested-name [0] PrincipalName, 236 real-name [1] PrincipalName 237 }, 238 canon-checksum [1] Checksum 239 } 241 The canon-checksum field is computed over the DER encoding of the 242 names sequences, using the returned session key and a key usage value 243 of (TBD). 245 If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is 246 not included. If the client name is changed, and the PA-CLIENT- 247 CANONICALIZED field does not exist, or the checksum cannot be 248 verified, or the requested-name field doesn't match the originally- 249 transmitted request, the client should discard the response. 251 For example the AS request may specify a client name of "bob@MS.COM" 252 as an NT-ENTERPRISE name with the "canonicalize" KDC option set and 253 the KDC will return with a client name of "104567" as a NT-UID, and a 254 PA-CLIENT-CANONICALIZED field listing the NT-ENTERPRISE "bob@MS.COM" 255 principal as the requested-name and the NT-UID "104567" principal as 256 the real-name. 258 It is assumed that the client discovers whether the KDC supports the 259 NT-ENTERPRISE name type via out of band mechanisms. 261 In order to enable one party in a user-to-user exchange to confirm 262 the identity of another when only the alias is known, the KDC MAY 263 include the following authorization data element, wrapped in AD-IF- 264 RELEVANT, in the initial credentials and copy it from a ticket- 265 granting ticket into additional credentials: 267 AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD -- 268 login-alias [0] PrincipalName, 269 checksum [1] Checksum 270 } 272 (Q: Wrapped inside KDCIssued too? Use SEQUENCE OF PrincipalName?) 274 The checksum is computed over the DER encoding of the login-alias 275 field using (WHICH KEY? If recipient can forge it, the KDC can't 276 trust it when returned, and would have to verify that the alias is 277 valid before copying it to additional credentials) and a key usage 278 number of (TBD). 280 The recipient of this authenticator must check the AD-LOGIN-ALIAS 281 name, if present, in addition to the normal client name field, 282 against the identity of the party with which it wishes to 283 authenticate; either should be allowed to match. (Note that this is 284 not backwards compatible with [RFC4120]; if the server side of the 285 user-to-user exchange does not support this extension, and does not 286 know the true principal name, authentication may fail if the alias is 287 sought in the client name field.) 289 6. Client Referrals 291 The simplest form of ticket referral is for a user requesting a 292 ticket using an AS-REQ. In this case, the client machine will send 293 the AS-REQ to a convenient trusted realm, for example the realm of 294 the client machine. In the case of the name alice@MS.COM, the client 295 MAY optimistically choose to send the request to MS.COM. The realm 296 in the AS-REQ is always the name of the realm that the request is for 297 as specified in [RFC4120]. 299 The KDC will try to lookup the name in its local account database. 300 If the account is present in the realm of the request, it SHOULD 301 return a KDC reply structure with the appropriate ticket. 303 If the account is not present in the realm specified in the request 304 and the "canonicalize" KDC option is set, the KDC will try to lookup 305 the entire name, alice@MS.COM, using a name service. If this lookup 306 is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN 307 [RFC4120]. If the lookup is successful, it MUST return an error 308 KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm 309 field will contain either the true realm of the client or another 310 realm that MAY have better information about the client's true realm. 311 The client SHALL NOT use a cname returned from a referral until that 312 name is validated. 314 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 315 new AS request with the same client principal name used to generate 316 the first referral to the realm specified by the realm field of the 317 Kerberos error message from the first request. (The client realm 318 name will be updated in the new request to refer to this new realm.) 319 The client SHOULD repeat these steps until it finds the true realm of 320 the client. To avoid infinite referral loops, an implementation 321 should limit the number of referrals. A suggested limit is 5 322 referrals before giving up. 324 Since the same client name is sent to the referring and referred-to 325 realms, both realms must recognize the same client names. In 326 particular, the referring realm cannot (usefully) define principal 327 name aliases that the referred-to realm will not know. 329 The true principal name of the client, returned in AS-REQ, can be 330 validated in a subsequent TGS message exchange where its value is 331 communicated back to the KDC via the authenticator in the PA-TGS-REQ 332 padata [RFC4120]. 334 7. Server Referrals 336 The primary difference in server referrals is that the KDC MUST 337 return a referral TGT rather than an error message as is done in the 338 client referrals. There needs to be a place to include in the reply 339 information about what realm contains the server. This is done by 340 returning information about the server name in the pre-authentication 341 data field of the KDC reply [RFC4120], as specified later in this 342 section. 344 If the KDC resolves the server principal name into a principal in the 345 realm specified by the service realm name, it will return a normal 346 ticket. 348 If the "canonicalize" flag in the KDC options is not set, the KDC 349 MUST only look up the name as a normal principal name in the 350 specified server realm. If the "canonicalize" flag in the KDC 351 options is set and the KDC doesn't find the principal locally, the 352 KDC MAY return a cross-realm ticket granting ticket to the next hop 353 on the trust path towards a realm that may be able to resolve the 354 principal name. The true principal name of the server SHALL be 355 returned in the padata of the reply if it is different from what is 356 specified the request. 358 When a referral TGT is returned, the KDC MUST return the target realm 359 for the referral TGT as an KDC supplied pre-authentication data 360 element in the response. This referral information in pre- 361 authentication data MUST be encrypted using the session key from the 362 reply ticket. The key usage value for the encryption operation used 363 by PA-SERVER-REFERRAL is 26. 365 The pre-authentication data returned by the KDC, which contains the 366 referred realm and the true principal name of server, is encoded in 367 DER as follows. 369 PA-SERVER-REFERRAL 25 371 PA-SERVER-REFERRAL-DATA ::= EncryptedData 372 -- ServerReferralData -- 374 ServerReferralData ::= SEQUENCE { 375 referred-realm [0] Realm OPTIONAL, 376 -- target realm of the referral TGT 377 true-principal-name [1] PrincipalName OPTIONAL, 378 -- true server principal name 379 requested-principal-name [2] PrincipalName OPTIONAL, 380 -- requested server name 381 ... 382 } 384 Clients SHALL NOT accept a reply ticket, whose the server principal 385 name is different from that of the request, if the KDC response does 386 not contain a PA-SERVER-REFERRAL padata entry. 388 The requested-principal-name MUST be included by the KDC, and MUST be 389 verified by the client, if the client sent an AS-REQ, as protection 390 against a man-in-the-middle modification to the AS-REQ message. 392 (Note that with the forthcoming rfc1510ter, the AS-REP may include an 393 option checksum of the AS-REQ, in which case this check would no 394 longer be necessary.) 396 The referred-realm field is present if and only if the returned 397 ticket is a referral TGT, not a service ticket for the requested 398 server principal. 400 When a referral TGT is returned and the true-principal-name field is 401 present, the client MUST use that name in the subsequent requests to 402 the server realm when following the referral. 404 Client SHALL NOT accept a true server principal name for a service 405 ticket if the true-principal-name field is not present in the PA- 406 SERVER-REFERRAL data. 408 The client will use this referral information to request a chain of 409 cross-realm ticket granting tickets until it reaches the realm of the 410 server, and can then expect to receive a valid service ticket. 412 However an implementation should limit the number of referrals that 413 it processes to avoid infinite referral loops. A suggested limit is 414 5 referrals before giving up. 416 Here is an example of a client requesting a service ticket for a 417 service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM. 419 +NC = Canonicalize KDCOption set 420 +PA-REFERRAL = returned PA-SERVER-REFERRAL 421 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM 422 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 423 containing MS.COM as the referred realm with no 424 true-principal-name 425 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM 426 S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL 427 containing NTDEV.MS.COM as the referred realm with no 428 true-principal-name 429 C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM 430 S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM 432 Note that any referral or alias processing of the server name in 433 user-to-user authentication should use the same data as client name 434 canonicalization or referral. Otherwise, the name used by one user 435 to log in may not be useable by another for user-to-user 436 authentication to the first. 438 8. Server Name Canonicalization (Informative) 440 No attempt is being made in this document to provide a means for 441 dealing with local-realm server principal name canonicalization or 442 aliasing. The most obvious use case for this would be a hostname- 443 based service principal name ("host/foobar.example.com"), with a DNS 444 alias ("foo") for the server host which is used by the client. There 445 are other ways this can be handled, currently, though they may 446 require additional configuration on the application server or KDC or 447 both. 449 9. Cross Realm Routing 451 The current Kerberos protocol requires the client to explicitly 452 request a cross-realm TGT for each pair of realms on a referral 453 chain. As a result, the client need to be aware of the trust 454 hierarchy and of any short-cut trusts (those that aren't parent- 455 child trusts). 457 Instead, using the server referral routing mechanism as defined in 458 Section 7, The KDC will determine the best path for the client and 459 return a cross-realm TGT as the referral TGT, and the target realm 460 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 462 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 463 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 464 response does not contain the PA-SERVER-REFERRAL padata. 466 10. Caching Information 468 It is possible that the client may wish to get additional credentials 469 for the same service principal, perhaps with different authorization- 470 data restrictions or other changed attributes. The return of a 471 server referral from a KDC can be taken as an indication that the 472 requested principal does not currently exist in the local realm. 473 Clearly, it would reduce network traffic if the clientn could cache 474 that information and use it when acquiring the second set of 475 credentials for a service, rather than always having to re-check with 476 the local KDC to see if the name has been created locally. 478 Rather than introduce a new timeout field for this cached 479 information, we can use the lifetime of the returned TGT in this 480 case. When the TGT expires, the previously returned referral from 481 the local KDC should be considered invalid, and the local KDC must be 482 asked again for information for the desired service principal name. 483 If the client is still in contact with the service and needs to 484 reauthenticate to the same service regardless of local service 485 principal name assignments, it should use the referred-realm and 486 true-principal-name values when requesting new credentials. 488 Accordingly, KDC authors and maintainers should consider what factors 489 (e.g., DNS alias lifetimes) they may or may not wish to incorporate 490 into credential expiration times in cases of referrals. 492 11. Open Issues 494 When should client name aliases be included in credentials? 496 Should all known client name aliases be included, or only the one 497 used at initial ticket acquisition? 499 12. Security Considerations 501 For the AS exchange case, it is important that the logon mechanism 502 not trust a name that has not been used to authenticate the user. 503 For example, the name that the user enters as part of a logon 504 exchange may not be the name that the user authenticates as, given 505 that the KDC_ERR_WRONG_REALM error may have been returned. The 506 relevant Kerberos naming information for logon (if any), is the 507 client name and client realm in the service ticket targeted at the 508 workstation that was obtained using the user's initial TGT. 510 How the client name and client realm is mapped into a local account 511 for logon is a local matter, but the client logon mechanism MUST use 512 additional information such as the client realm and/or authorization 513 attributes from the service ticket presented to the workstation by 514 the user, when mapping the logon credentials to a local account on 515 the workstation. 517 13. Acknowledgments 519 Sam Hartman and authors came up with the idea of using the ticket key 520 to encrypt the referral data, which prevents cut and paste attack 521 using the referral data and referral TGTs. 523 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 524 version of this document. 526 14. References 528 14.1. Normative References 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 534 Kerberos Network Authentication Service (V5)", RFC 4120, 535 July 2005. 537 14.2. Informative References 539 [I-D.ietf-cat-kerberos-pk-init] 540 Tung, B. and L. Zhu, "Public Key Cryptography for Initial 541 Authentication in Kerberos", 542 draft-ietf-cat-kerberos-pk-init-34 (work in progress), 543 February 2006. 545 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 546 X.509 Public Key Infrastructure Certificate and 547 Certificate Revocation List (CRL) Profile", RFC 3280, 548 April 2002. 550 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation 551 of Crossrealm Referral Handling in the MIT Kerberos 552 Client", Network and Distributed System Security 553 Symposium, February 2001. 555 Appendix A. Compatibility with Earlier Implementations of Name 556 Canonicalization 558 The Microsoft Windows 2000 and Windows 2003 releases included an 559 earlier form of name-canonicalization [XPR]. Here are the 560 differences: 562 1) The TGS referral data is returned inside of the KDC message as 563 "encrypted pre-authentication data". 565 EncKDCRepPart ::= SEQUENCE { 566 key [0] EncryptionKey, 567 last-req [1] LastReq, 568 nonce [2] UInt32, 569 key-expiration [3] KerberosTime OPTIONAL, 570 flags [4] TicketFlags, 571 authtime [5] KerberosTime, 572 starttime [6] KerberosTime OPTIONAL, 573 endtime [7] KerberosTime, 574 renew-till [8] KerberosTime OPTIONAL, 575 srealm [9] Realm, 576 sname [10] PrincipalName, 577 caddr [11] HostAddresses OPTIONAL, 578 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 579 } 581 2) The preauth data type definition in the encrypted preauth data is 582 as follows: 584 PA-SVR-REFERRAL-INFO 20 586 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 587 referred-name [1] PrincipalName OPTIONAL, 588 referred-realm [0] Realm 589 }} 591 3) When [I-D.ietf-cat-kerberos-pk-init] is used, the NT-ENTERPRISE 592 client name is encoded as a Subject Alternative Name (SAN) 593 extension [RFC3280] in the client's X.509 certificate. The type 594 of the otherName field for this SAN extension is AnotherName 595 [RFC3280]. The type-id field of the type AnotherName is id-ms-sc- 596 logon-upn (1.3.6.1.4.1.311.20.2.3) and the value field of the type 597 AnotherName is a KerberosString [RFC4120]. The value of this 598 KerberosString type is the single component in the name-string 599 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 601 In Microsoft's current implementation through the use of global 602 catalogs any domain in one forest is reachable from any other domain 603 in the same forest or another trusted forest with 3 or less 604 referrals. A forest is a collection of realms with hierarchical 605 trust relationships: there can be multiple trust trees in a forest; 606 each child and parent realm pair and each root realm pair have 607 bidirectional transitive direct rusts between them. 609 While we might want to permit multiple aliases to exist and even be 610 reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only 611 one alias to exist, so this question had not previously arisen. 613 Appendix B. Document history 615 08 Moved Microsoft implementation info to appendix. Clarify lack of 616 local server name canonicalization. Added optional authz-data for 617 login alias, to support user-to-user case. Added requested- 618 principal-name to ServerReferralData. Added discussion of caching 619 information, and referral TGT lifetime. 620 07 Re-issued with new editor. Fixed up some references. Started 621 history. 623 Authors' Addresses 625 Kenneth Raeburn 626 Massachusetts Institute of Technology 627 77 Massachusetts Avenue 628 Cambridge, MA 02139 629 US 631 Email: raeburn@mit.edu 633 Larry Zhu 634 Microsoft Corporation 635 One Microsoft Way 636 Redmond, WA 98052 637 US 639 Email: lzhu@microsoft.com 641 Karthik Jaganathan 642 Microsoft Corporation 643 One Microsoft Way 644 Redmond, WA 98052 645 US 647 Email: karthikj@microsoft.com 649 Intellectual Property Statement 651 The IETF takes no position regarding the validity or scope of any 652 Intellectual Property Rights or other rights that might be claimed to 653 pertain to the implementation or use of the technology described in 654 this document or the extent to which any license under such rights 655 might or might not be available; nor does it represent that it has 656 made any independent effort to identify any such rights. Information 657 on the procedures with respect to rights in RFC documents can be 658 found in BCP 78 and BCP 79. 660 Copies of IPR disclosures made to the IETF Secretariat and any 661 assurances of licenses to be made available, or the result of an 662 attempt made to obtain a general license or permission for the use of 663 such proprietary rights by implementers or users of this 664 specification can be obtained from the IETF on-line IPR repository at 665 http://www.ietf.org/ipr. 667 The IETF invites any interested party to bring to its attention any 668 copyrights, patents or patent applications, or other proprietary 669 rights that may cover technology that may be required to implement 670 this standard. Please address the information to the IETF at 671 ietf-ipr@ietf.org. 673 Disclaimer of Validity 675 This document and the information contained herein are provided on an 676 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 677 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 678 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 679 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 680 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 681 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 683 Copyright Statement 685 Copyright (C) The Internet Society (2006). This document is subject 686 to the rights, licenses and restrictions contained in BCP 78, and 687 except as set forth therein, the authors retain all their rights. 689 Acknowledgment 691 Funding for the RFC Editor function is currently provided by the 692 Internet Society.