idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-10.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 735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 759. 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 (February 25, 2008) is 5904 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 654 -- Looks like a reference, but probably isn't: '1' on line 653 -- Looks like a reference, but probably isn't: '2' on line 634 -- Looks like a reference, but probably isn't: '3' on line 635 -- Looks like a reference, but probably isn't: '4' on line 636 -- Looks like a reference, but probably isn't: '5' on line 637 -- Looks like a reference, but probably isn't: '6' on line 638 -- Looks like a reference, but probably isn't: '7' on line 639 -- Looks like a reference, but probably isn't: '8' on line 640 -- Looks like a reference, but probably isn't: '9' on line 641 -- Looks like a reference, but probably isn't: '10' on line 642 -- Looks like a reference, but probably isn't: '11' on line 643 -- Looks like a reference, but probably isn't: '12' on line 644 -- 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 Kerberos Working Group K. Raeburn 3 Internet-Draft MIT 4 Updates: 4120 (if approved) L. Zhu 5 Intended status: Standards Track Microsoft Corporation 6 Expires: August 28, 2008 February 25, 2008 8 Generating KDC Referrals to Locate Kerberos Realms 9 draft-ietf-krb-wg-kerberos-referrals-10 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 August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 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. Enterprise Principal Name Type . . . . . . . . . . . . . . . . 5 58 6. Name Canonicalization . . . . . . . . . . . . . . . . . . . . 5 59 7. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 7 60 8. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 9 61 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 11 62 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11 63 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 12 65 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 13.1. Shared-password case . . . . . . . . . . . . . . . . . . 13 67 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 68 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 70 15.2. Informative References . . . . . . . . . . . . . . . . . 14 71 Appendix A. Compatibility with Earlier Implementations of 72 Name Canonicalization . . . . . . . . . . . . . . . . 14 73 Appendix B. Document history [REMOVE BEFORE PUBLICATION] . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Intellectual Property and Copyright Statements . . . . . . . . . . 18 77 1. Introduction 79 Current implementations of the Kerberos AS and TGS protocols, as 80 defined in [RFC4120], use principal names constructed from a known 81 user or service name and realm. A service name is typically 82 constructed from a name of the service and the DNS host name of the 83 computer that is providing the service. Many existing deployments of 84 Kerberos use a single Kerberos realm where all users and services 85 would be using the same realm. However in an environment where there 86 are multiple trusted Kerberos realms, the client needs to be able to 87 determine what realm a particular user or service is in before making 88 an AS or TGS request. Traditionally this requires client 89 configuration to make this possible. 91 When having to deal with multiple trusted realms, users are forced to 92 know what realm they are in before they can obtain a ticket granting 93 ticket (TGT) with an AS request. However, in many cases the user 94 would like to use a more familiar name that is not directly related 95 to the realm of their Kerberos principal name. A good example of 96 this is an RFC 822 style email name. This document describes a 97 mechanism that would allow a user to specify a user principal name 98 that is an alias for the user's Kerberos principal name. In practice 99 this would be the name that the user specifies to obtain a TGT from a 100 Kerberos KDC. The user principal name no longer has a direct 101 relationship with the Kerberos principal or realm. Thus the 102 administrator is able to move the user's principal to other realms 103 without the user having to know that it happened. 105 Once a user has a TGT, they would like to be able to access services 106 in any trusted Kerberos realm. To do this requires that the client 107 be able to determine what realm the target service principal is in 108 before making the TGS request. Current implementations of Kerberos 109 typically have a table that maps DNS host names to corresponding 110 Kerberos realms. The user-supplied host name or its domain component 111 is looked up in this table (often using the result of some form of 112 host name lookup performed with insecure DNS queries, in violation of 113 [RFC4120]). The corresponding realm is then used to complete the 114 target service principal name. 116 This traditional mechanism requires that each client have very 117 detailed configuration information about the hosts that are providing 118 services and their corresponding realms. Having client side 119 configuration information can be very costly from an administration 120 point of view - especially if there are many realms and computers in 121 the environment. 123 There are also cases where specific DNS aliases (local names) have 124 been setup in an organization to refer to a server in another 125 organization (remote server). The server has different DNS names in 126 each organization and each organization has a Kerberos realm that is 127 configured to service DNS names within that organization. Ideally 128 users are able to authenticate to the server in the other 129 organization using the local server name. This would mean that the 130 local realm be able to produce a ticket to the remote server under 131 its name. The administrator in the local realm could give that 132 remote server an identity in the local realm and then have that 133 remote server maintain a separate secret for each alias it is known 134 as. Alternatively the administrator could arrange to have the local 135 realm issue a referral to the remote realm and notify the requesting 136 client of the server's remote name that should be used in order to 137 request a ticket. 139 This memo proposes a solution for these problems and simplifies 140 administration by minimizing the configuration information needed on 141 each computer using Kerberos. Specifically it describes a mechanism 142 to allow the KDC to handle canonicalization of names, provide for 143 principal aliases for users and services and allow the KDC to 144 determine the trusted realm authentication path by being able to 145 generate referrals to other realms in order to locate principals. 147 Two kinds of KDC referrals are introduced in this memo: 149 1. Client referrals, in which the client doesn't know which realm 150 contains a user account. 151 2. Server referrals, in which the client doesn't know which realm 152 contains a server account. 154 2. Conventions Used in This Document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 3. Requesting a Referral 162 In order to request referrals defined in section 5, 6, and 7, the 163 Kerberos client MUST explicitly request the canonicalize KDC option 164 (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to 165 the KDC that the client is prepared to receive a reply that contains 166 a principal name other than the one requested. 168 KDCOptions ::= KerberosFlags 169 -- canonicalize (15) 170 -- other KDCOptions values omitted 172 The client should expect, when sending names with the "canonicalize" 173 KDC option, that names in the KDC's reply MAY be different than the 174 name in the request. A referral TGT is a cross realm TGT that is 175 returned with the server name of the ticket being different from the 176 server name in the request [RFC4120]. 178 4. Realm Organization Model 180 This memo assumes that the world of principals is arranged on 181 multiple levels: the realm, the enterprise, and the world. A KDC may 182 issue tickets for any principal in its realm or cross-realm tickets 183 for realms with which it has a direct trust relationship. The KDC 184 also has access to a trusted name service that can resolve any name 185 from within its enterprise into a realm. This trusted name service 186 removes the need to use an un-trusted DNS lookup for name resolution. 188 For example, consider the following configuration, where lines 189 indicate trust relationships: 191 EXAMPLE.COM 192 / \ 193 / \ 194 ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM 196 In this configuration, all users in the EXAMPLE.COM enterprise could 197 have principal names such as alice@EXAMPLE.COM, with the same realm 198 portion. In addition, servers at EXAMPLE.COM should be able to have 199 DNS host names from any DNS domain independent of what Kerberos realm 200 their principals reside in. 202 5. Enterprise Principal Name Type 204 The NT-ENTERPRISE type principal name contains one component, a 205 string of realm-defined content, which is intended to be used as an 206 alias for another principal name in some realm in the enterprise. It 207 is used for conveying the alias name, not for the real principal 208 names within the realms, and thus is only useful when name 209 canonicalization is requested. 211 6. Name Canonicalization 213 A service or account may have multiple principal names. More useful, 214 though, is a globally unique name that allows unification of email 215 and security principal names. For example, all users at EXAMPLE.COM 216 may have a client principal name of the form "joe@EXAMPLE.COM" even 217 though the principals are contained in multiple realms. This global 218 name is again an alias for the true client principal name, which 219 indicates what realm contains the principal. Thus, accounts "alice" 220 in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log 221 on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM". 223 This utilizes a new client principal name type, as the AS-REQ message 224 only contains a single realm field, and the realm portion of this 225 name corresponds to the Kerberos realm with which the request is 226 made. Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a 227 single component in the client name field of the AS-REQ message, with 228 a name type of NT-ENTERPRISE [RFC4120] (and the local realm name). 229 The KDC will recognize this name type and then transform the 230 requested name into the true principal name if the client account 231 resides in the local realm. The true principal name can have a name 232 type different from the requested name type. Typically the true 233 principal name will be a NT-PRINCIPAL [RFC4120]. 235 If the "canonicalize" KDC option is set, then the KDC MAY change the 236 client principal name and type in the AS response and ticket returned 237 from the name type of the client name in the request, and include a 238 mandatory PA-DATA object authenticating the client name mapping: 240 ReferralInfo ::= SEQUENCE { 241 requested-name [0] PrincipalName, 242 mapped-name [1] PrincipalName, 243 ... 244 } 245 PA-CLIENT-CANONICALIZED ::= SEQUENCE { 246 names [0] ReferralInfo, 247 canon-checksum [1] Checksum 248 } 250 The canon-checksum field is computed over the DER encoding of the 251 names sequences, using the AS reply key and a key usage value of 252 (TBD). 254 If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is 255 not included. If the client name is changed, and the PA-CLIENT- 256 CANONICALIZED field does not exist, or the checksum cannot be 257 verified, or the requested-name field doesn't match the client name 258 in the originally-transmitted request, the client should discard the 259 response. 261 For example the AS request may specify a client name of "bob@ 262 EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC 263 option set and the KDC will return with a client name of "104567" as 264 a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT- 265 ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the 266 NT-UID "104567" principal as the mapped-name. 268 (It is assumed that the client discovers whether the KDC supports the 269 NT-ENTERPRISE name type via out of band mechanisms.) 271 In order to enable one party in a user-to-user exchange to confirm 272 the identity of another when only the alias is known, the KDC MAY 273 include the following authorization data element, wrapped in AD-KDC- 274 ISSUED, in the initial credentials and copy it from a ticket-granting 275 ticket into additional credentials: 277 AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD -- 278 login-aliases [0] SEQUENCE(1..MAX) OF PrincipalName, 279 } 281 The login-aliases field lists one or more of the aliases the 282 principal may have used in the initial ticket request. 284 The recipient of this authenticator must check the AD-LOGIN-ALIAS 285 names, if present, in addition to the normal client name field, 286 against the identity of the party with which it wishes to 287 authenticate; either should be allowed to match. (Note that this is 288 not backwards compatible with [RFC4120]; if the server side of the 289 user-to-user exchange does not support this extension, and does not 290 know the true principal name, authentication may fail if the alias is 291 sought in the client name field.) 293 The use of AD-KDC-ISSUED authorization data elements in cross-realm 294 cases has not been well explored at this writing; hence we will only 295 specify the inclusion of this data in the one-realm case. The alias 296 information should be dropped in the general cross-realm case. 297 However, a realm may implement a policy of accepting and re-signing 298 (wrapping in a new AD-KDC-ISSUED element) alias information provided 299 by certain other realms in the cross-realm ticket-granting service. 301 7. Client Referrals 303 The simplest form of ticket referral is for a user requesting a 304 ticket using an AS-REQ. In this case, the client machine will send 305 the AS-REQ to a convenient trusted realm, for example the realm of 306 the client machine. In the case of the name alice@EXAMPLE.COM, the 307 client MAY optimistically choose to send the request to EXAMPLE.COM. 308 The realm in the AS-REQ is always the name of the realm that the 309 request is for as specified in [RFC4120]. 311 The KDC will try to lookup the name in its local account database. 312 If the account is present in the realm of the request, it SHOULD 313 return a KDC reply structure with the appropriate ticket. 315 If the account is not present in the realm specified in the request 316 and the "canonicalize" KDC option is set, the KDC will try to lookup 317 the entire name, alice@EXAMPLE.COM, using a name service. If this 318 lookup is unsuccessful, it MUST return the error 319 KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful, 320 it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the 321 error message the crealm field will contain either the true realm of 322 the client or another realm that MAY have better information about 323 the client's true realm. The client SHALL NOT use a cname returned 324 from a Kerberos error until that name is validated. 326 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 327 new AS request with the same client principal name used to generate 328 the first referral to the realm specified by the realm field of the 329 Kerberos error message corresponding to the first request. (The 330 client realm name will be updated in the new request to refer to this 331 new realm.) The client SHOULD repeat these steps until it finds the 332 true realm of the client. To avoid infinite referral loops, an 333 implementation should limit the number of referrals. A suggested 334 limit is 5 referrals before giving up. 336 Since the same client name is sent to the referring and referred-to 337 realms, both realms must recognize the same client names. In 338 particular, the referring realm cannot (usefully) define principal 339 name aliases that the referred-to realm will not know. 341 The true principal name of the client, returned in AS-REQ, can be 342 validated in a subsequent TGS message exchange where its value is 343 communicated back to the KDC via the authenticator in the PA-TGS-REQ 344 padata [RFC4120]. However, this requires trusting the referred-to 345 realm's KDCs. Clients should limit the referral mappings they will 346 accept to realms trusted via some local policy. Some possible 347 factors that might be taken into consideration for such a policy 348 might include: 350 o Any realm indicated by the local KDC, if the returned KRB-ERROR 351 message is protected, for example using a public key known to be 352 associated with the KDC 353 o A list of realms configured by an administrator 354 o Any realm accepted by the user when explicitly prompted 356 8. Server Referrals 358 The primary difference in server referrals is that the KDC MUST 359 return a referral TGT rather than an error message as is done in the 360 client referrals. There needs to be a place to include in the reply 361 information about what realm contains the server. This is done by 362 returning information about the server name in the pre-authentication 363 data field of the KDC reply [RFC4120], as specified later in this 364 section. 366 If the KDC resolves the server principal name into a principal in the 367 realm specified by the service realm name, it will return a normal 368 ticket. 370 If the "canonicalize" flag in the KDC options is not set, the KDC 371 MUST only look up the name as a normal principal name in the 372 specified server realm. If the "canonicalize" flag in the KDC 373 options is set and the KDC doesn't find the principal locally, the 374 KDC MAY return a cross-realm ticket granting ticket to the next hop 375 on the trust path towards a realm that may be able to resolve the 376 principal name. The true principal name of the server SHALL be 377 returned in the padata of the reply if it is different from what is 378 specified the request. 380 When a referral TGT is returned, the KDC MUST return the target realm 381 for the referral TGT as an KDC supplied pre-authentication data 382 element in the response. This referral information in pre- 383 authentication data MUST be encrypted using the session key from the 384 reply ticket. The key usage value for the encryption operation used 385 by PA-SERVER-REFERRAL is 26. 387 The pre-authentication data returned by the KDC, which contains the 388 referred realm and the true principal name of server, is encoded in 389 DER as follows. 391 PA-SERVER-REFERRAL 25 393 PA-SERVER-REFERRAL-DATA ::= EncryptedData 394 -- ServerReferralData -- 396 ServerReferralData ::= SEQUENCE { 397 referred-realm [0] Realm OPTIONAL, 398 -- target realm of the referral TGT 399 true-principal-name [1] PrincipalName OPTIONAL, 400 -- true server principal name 401 requested-principal-name [2] PrincipalName OPTIONAL, 402 -- requested server name 403 referral-valid-until [3] KerberosTime OPTIONAL, 404 ... 405 } 407 Clients SHALL NOT accept a reply ticket in which the server principal 408 name is different from that of the request, if the KDC response does 409 not contain a PA-SERVER-REFERRAL padata entry. 411 The requested-principal-name MUST be included by the KDC, and MUST be 412 verified by the client, if the client sent an AS-REQ, as protection 413 against a man-in-the-middle modification to the AS-REQ message. 415 The referred-realm field is present if and only if the returned 416 ticket is a referral TGT, not a service ticket for the requested 417 server principal. 419 When a referral TGT is returned and the true-principal-name field is 420 present, the client MUST use that name in the subsequent requests to 421 the server realm when following the referral. 423 Client SHALL NOT accept a true server principal name for a service 424 ticket if the true-principal-name field is not present in the PA- 425 SERVER-REFERRAL data. 427 The client will use this referral information to request a chain of 428 cross-realm ticket granting tickets until it reaches the realm of the 429 server, and can then expect to receive a valid service ticket. 431 However an implementation should limit the number of referrals that 432 it processes to avoid infinite referral loops. A suggested limit is 433 5 referrals before giving up. 435 The client may cache the mapping of the requested name to the name of 436 the next realm to use and the principal name to ask for. (See 437 Section 10.) The referral-valid-until field, if present, conveys how 438 long this information is valid for. 440 Here is an example of a client requesting a service ticket for a 441 service in realm DEV.EXAMPLE.COM where the client is in 442 ADMIN.EXAMPLE.COM. 444 +NC = Canonicalize KDCOption set 445 +PA-REFERRAL = returned PA-SERVER-REFERRAL 446 C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM 447 S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL 448 containing EXAMPLE.COM as the referred realm with no 449 true-principal-name 450 C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM 451 S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL 452 containing DEV.EXAMPLE.COM as the referred realm with no 453 true-principal-name 454 C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM 455 S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM 457 Note that any referral or alias processing of the server name in 458 user-to-user authentication should use the same data as client name 459 canonicalization or referral. Otherwise, the name used by one user 460 to log in may not be useable by another for user-to-user 461 authentication to the first. 463 9. Cross Realm Routing 465 The current Kerberos protocol requires the client to explicitly 466 request a cross-realm TGT for each pair of realms on a referral 467 chain. As a result, the client need to be aware of the trust 468 hierarchy and of any short-cut trusts (those that aren't parent- 469 child trusts). 471 Instead, using the server referral routing mechanism as defined in 472 Section 8, The KDC will determine the best path for the client and 473 return a cross-realm TGT as the referral TGT, and the target realm 474 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 476 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 477 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 478 response does not contain the PA-SERVER-REFERRAL padata. 480 10. Caching Information 482 It is possible that the client may wish to get additional credentials 483 for the same service principal, perhaps with different authorization- 484 data restrictions or other changed attributes. The return of a 485 server referral from a KDC can be taken as an indication that the 486 requested principal does not currently exist in the local realm. 487 Clearly, it would reduce network traffic if the clients could cache 488 that information and use it when acquiring the second set of 489 credentials for a service, rather than always having to re-check with 490 the local KDC to see if the name has been created locally. 492 If the referral-valid-until field is provided in the PA-SERVER- 493 REFERRAL-DATA message, it indicates the expiration time of this data; 494 if it is not included, the expiration time of the TGT is used. When 495 the TGT expires, the previously returned referral from the local KDC 496 should be considered invalid, and the local KDC must be asked again 497 for information for the desired service principal name. (Note that 498 the client may get back multiple referral TGTs from the local KDC to 499 the same remote realm, with different lifetimes. The lifetime 500 information must be properly associated with the requested service 501 principal names. Simply having another TGT for the same remote realm 502 does not extend the validity of previously acquired information about 503 one service principal name.) If the client is still in contact with 504 the service and needs to reauthenticate to the same service 505 regardless of local service principal name assignments, it should use 506 the referred-realm and true-principal-name values when requesting new 507 credentials. 509 Accordingly, KDC authors and maintainers should consider what factors 510 (e.g., DNS alias lifetimes) they may or may not wish to incorporate 511 into credential expiration times in cases of referrals. 513 11. Open Issues 515 Client referral info validation 517 When should client name aliases be included in credentials? Should 518 all known client name aliases be included, or only the one used at 519 initial ticket acquisition? 521 Should list the policies that need to be defined. 523 More examples: u2u, policy checks, maybe cross-realm. 525 Restore server name canonicalization from early drafts. 527 12. Number Assignments 529 Most number registries in the Kerberos protocol have not been turned 530 over to IANA for management at the time of this writing, hence this 531 is not an "IANA Considerations" section. 533 Various values do need assigning for this draft: 534 AD-LOGIN-ALIAS 535 PA-CLIENT-CANONICALIZED 536 key usage value for PA-CLIENT-CANONICALIZED field canon-checksum 538 13. Security Considerations 540 For the AS exchange case, it is important that the logon mechanism 541 not trust a name that has not been used to authenticate the user. 542 For example, the name that the user enters as part of a logon 543 exchange may not be the name that the user authenticates as, given 544 that the KDC_ERR_WRONG_REALM error may have been returned. The 545 relevant Kerberos naming information for logon (if any), is the 546 client name and client realm in the service ticket targeted at the 547 workstation that was obtained using the user's initial TGT. 549 How the client name and client realm is mapped into a local account 550 for logon is a local matter, but the client logon mechanism MUST use 551 additional information such as the client realm and/or authorization 552 attributes from the service ticket presented to the workstation by 553 the user, when mapping the logon credentials to a local account on 554 the workstation. 556 13.1. Shared-password case 558 A special case to examine is when the user is known (or correctly 559 suspected) to use the same password for multiple accounts. A man-in- 560 the-middle attacker can either alter the request on its way to the 561 KDC, changing the client principal name, or reply to the client with 562 a response previously send by the KDC in response to a request from 563 the attacker. The response received by the client can then be 564 decrypted by the user, though if the default "salt" generated from 565 the principal name is used to produce the user's key, a PA-ETYPE-INFO 566 or PA-ETYPE-INFO2 preauth record may need to be added or altered by 567 the attacker to cause the client software to generate the key needed 568 for the message it will receive. None of this requires the attacker 569 to know the user's password, and without further checking, could 570 cause the user to unknowingly use the wrong credentials. 572 In normal [RFC4120] operation, a generated AP-REQ message includes in 573 the Authenticator field a copy of the client's idea of its own 574 principal name. If this differs from the name in the KDC-generated 575 Ticket, the application server will reject the message. 577 With client name canonicalization as described in this document, the 578 client may get its principal name from the response from the KDC. 579 Requiring the PA-CLIENT-CANONICALIZED data lets the client securely 580 check that the requested name was not altered in transit. If the PA- 581 CLIENT-CANONICALIZED data is absent, the client can use the principal 582 name it requested. 584 14. Acknowledgments 586 Sam Hartman and authors came up with the idea of using the ticket key 587 to encrypt the referral data, which prevents cut and paste attack 588 using the referral data and referral TGTs. 590 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 591 version of this document. 593 Karthik Jaganathan contributed to earlier versions. 595 15. References 597 15.1. Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 603 Kerberos Network Authentication Service (V5)", RFC 4120, 604 July 2005. 606 15.2. Informative References 608 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 609 X.509 Public Key Infrastructure Certificate and 610 Certificate Revocation List (CRL) Profile", RFC 3280, 611 April 2002. 613 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 614 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 616 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation 617 of Crossrealm Referral Handling in the MIT Kerberos 618 Client", Network and Distributed System Security 619 Symposium, February 2001. 621 Appendix A. Compatibility with Earlier Implementations of Name 622 Canonicalization 624 The Microsoft Windows 2000 and Windows 2003 releases included an 625 earlier form of name-canonicalization [XPR]. Here are the 626 differences: 628 1) The TGS referral data is returned inside of the KDC message as 629 "encrypted pre-authentication data". 631 EncKDCRepPart ::= SEQUENCE { 632 key [0] EncryptionKey, 633 last-req [1] LastReq, 634 nonce [2] UInt32, 635 key-expiration [3] KerberosTime OPTIONAL, 636 flags [4] TicketFlags, 637 authtime [5] KerberosTime, 638 starttime [6] KerberosTime OPTIONAL, 639 endtime [7] KerberosTime, 640 renew-till [8] KerberosTime OPTIONAL, 641 srealm [9] Realm, 642 sname [10] PrincipalName, 643 caddr [11] HostAddresses OPTIONAL, 644 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 645 } 647 2) The preauth data type definition in the encrypted preauth data is 648 as follows: 650 PA-SVR-REFERRAL-INFO 20 652 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 653 referred-name [1] PrincipalName OPTIONAL, 654 referred-realm [0] Realm 655 }} 657 3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is 658 encoded as a Subject Alternative Name (SAN) extension [RFC3280] in 659 the client's X.509 certificate. The type of the otherName field 660 for this SAN extension is AnotherName [RFC3280]. The type-id 661 field of the type AnotherName is id-ms-sc-logon-upn 662 (1.3.6.1.4.1.311.20.2.3) and the value field of the type 663 AnotherName is a KerberosString [RFC4120]. The value of this 664 KerberosString type is the single component in the name-string 665 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 667 In Microsoft's current implementation through the use of global 668 catalogs any domain in one forest is reachable from any other domain 669 in the same forest or another trusted forest with 3 or less 670 referrals. A forest is a collection of realms with hierarchical 671 trust relationships: there can be multiple trust trees in a forest; 672 each child and parent realm pair and each root realm pair have 673 bidirectional transitive direct rusts between them. 675 While we might want to permit multiple aliases to exist and even be 676 reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only 677 one NT-ENTERPRISE alias to exist, so this question had not previously 678 arisen. 680 Appendix B. Document history [REMOVE BEFORE PUBLICATION] 682 10 TBD 683 09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain. 684 Rewrote description of existing practice. (Don't name the lookup 685 table consulted. Mention that DNS "canonicalization" is contrary 686 to [RFC4120].) Noted Microsoft behavior should be moved out into 687 a separate document. Changed some second-person references in the 688 introduction to identify the proper parties. Changed PA-CLIENT- 689 CANONICALIZED to use a separate type for the actual referral data, 690 add an extension marker to that type, and change the checksum key 691 from the "returned session key" to the "AS reply key". Changed 692 AD-LOGIN-ALIAS to contain a sequence of names, to be contained in 693 AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer 694 needed separate checksum. Attempt to clarify the cache lifetime 695 of referral information. 696 08 Moved Microsoft implementation info to appendix. Clarify lack of 697 local server name canonicalization. Added optional authz-data for 698 login alias, to support user-to-user case. Added requested- 699 principal-name to ServerReferralData. Added discussion of caching 700 information, and referral TGT lifetime. 701 07 Re-issued with new editor. Fixed up some references. Started 702 history. 704 Authors' Addresses 706 Kenneth Raeburn 707 Massachusetts Institute of Technology 708 77 Massachusetts Avenue 709 Cambridge, MA 02139 710 US 712 Email: raeburn@mit.edu 713 Larry Zhu 714 Microsoft Corporation 715 One Microsoft Way 716 Redmond, WA 98052 717 US 719 Email: lzhu@microsoft.com 721 Full Copyright Statement 723 Copyright (C) The IETF Trust (2008). 725 This document is subject to the rights, licenses and restrictions 726 contained in BCP 78, and except as set forth therein, the authors 727 retain all their rights. 729 This document and the information contained herein are provided on an 730 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 731 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 732 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 733 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 734 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 735 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 737 Intellectual Property 739 The IETF takes no position regarding the validity or scope of any 740 Intellectual Property Rights or other rights that might be claimed to 741 pertain to the implementation or use of the technology described in 742 this document or the extent to which any license under such rights 743 might or might not be available; nor does it represent that it has 744 made any independent effort to identify any such rights. Information 745 on the procedures with respect to rights in RFC documents can be 746 found in BCP 78 and BCP 79. 748 Copies of IPR disclosures made to the IETF Secretariat and any 749 assurances of licenses to be made available, or the result of an 750 attempt made to obtain a general license or permission for the use of 751 such proprietary rights by implementers or users of this 752 specification can be obtained from the IETF on-line IPR repository at 753 http://www.ietf.org/ipr. 755 The IETF invites any interested party to bring to its attention any 756 copyrights, patents or patent applications, or other proprietary 757 rights that may cover technology that may be required to implement 758 this standard. Please address the information to the IETF at 759 ietf-ipr@ietf.org. 761 Acknowledgment 763 Funding for the RFC Editor function is provided by the IETF 764 Administrative Support Activity (IASA).