idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-11.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, updated by RFC 4748 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 835. 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 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 (July 14, 2008) is 5758 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 715 -- Looks like a reference, but probably isn't: '1' on line 714 -- Looks like a reference, but probably isn't: '2' on line 695 -- Looks like a reference, but probably isn't: '3' on line 696 -- Looks like a reference, but probably isn't: '4' on line 697 -- Looks like a reference, but probably isn't: '5' on line 698 -- Looks like a reference, but probably isn't: '6' on line 699 -- Looks like a reference, but probably isn't: '7' on line 700 -- Looks like a reference, but probably isn't: '8' on line 701 -- Looks like a reference, but probably isn't: '9' on line 702 -- Looks like a reference, but probably isn't: '10' on line 703 -- Looks like a reference, but probably isn't: '11' on line 704 -- Looks like a reference, but probably isn't: '12' on line 705 -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) Summary: 1 error (**), 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: January 15, 2009 July 14, 2008 8 Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm 9 Referrals 10 draft-ietf-krb-wg-kerberos-referrals-11 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 January 15, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 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. Enterprise Principal Name Type . . . . . . . . . . . . . . . . 5 59 6. Name Canonicalization . . . . . . . . . . . . . . . . . . . . 6 60 7. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 8 61 8. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 9 62 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 12 63 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 12 64 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 13 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 14.1. Shared-password case . . . . . . . . . . . . . . . . . . 14 69 14.2. Preauthentication data . . . . . . . . . . . . . . . . . 14 70 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 71 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 16.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 16.2. Informative References . . . . . . . . . . . . . . . . . 15 74 Appendix A. Compatibility with Earlier Implementations of 75 Name Canonicalization . . . . . . . . . . . . . . . . 15 76 Appendix B. Document history [REMOVE BEFORE PUBLICATION] . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 78 Intellectual Property and Copyright Statements . . . . . . . . . . 19 80 1. Introduction 82 Current implementations of the Kerberos AS and TGS protocols, as 83 defined in [RFC4120], use principal names constructed from a known 84 user or service name and realm. A service name is typically 85 constructed from a name of the service and the DNS host name of the 86 computer that is providing the service. Many existing deployments of 87 Kerberos use a single Kerberos realm where all users and services 88 would be using the same realm. However in an environment where there 89 are multiple trusted Kerberos realms, the client needs to be able to 90 determine what realm a particular user or service is in before making 91 an AS or TGS request. Traditionally this requires client 92 configuration to make this possible. 94 When having to deal with multiple trusted realms, users are forced to 95 know what realm they are in before they can obtain a ticket granting 96 ticket (TGT) with an AS request. However, in many cases the user 97 would like to use a more familiar name that is not directly related 98 to the realm of their Kerberos principal name. A good example of 99 this is an RFC 822 style email name. This document describes a 100 mechanism that would allow a user to specify a user principal name 101 that is an alias for the user's Kerberos principal name. In practice 102 this would be the name that the user specifies to obtain a TGT from a 103 Kerberos KDC. The user principal name no longer has a direct 104 relationship with the Kerberos principal or realm. Thus the 105 administrator is able to move the user's principal to other realms 106 without the user having to know that it happened. 108 Once a user has a TGT, they would like to be able to access services 109 in any trusted Kerberos realm. To do this requires that the client 110 be able to determine what realm the target service principal is in 111 before making the TGS request. Current implementations of Kerberos 112 typically have a table that maps DNS host names to corresponding 113 Kerberos realms. The user-supplied host name or its domain component 114 is looked up in this table (often using the result of some form of 115 host name lookup performed with insecure DNS queries, in violation of 116 [RFC4120]). The corresponding realm is then used to complete the 117 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. The administrator in the local realm could give that 135 remote server an identity in the local realm and then have that 136 remote server maintain a separate secret for each alias it is known 137 as. Alternatively the administrator could arrange to have the local 138 realm issue a referral to the remote realm and notify the requesting 139 client of the server's remote name that should be used in order to 140 request a ticket. 142 This memo proposes a solution for these problems and simplifies 143 administration by minimizing the configuration information needed on 144 each computer using Kerberos. Specifically it describes a mechanism 145 to allow the KDC to handle canonicalization of names, provide for 146 principal aliases for users and services and allow the KDC to 147 determine the trusted realm authentication path by being able to 148 generate referrals to other realms in order to locate 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 as defined in later sections, 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 EXAMPLE.COM 195 / \ 196 / \ 197 ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM 199 In this configuration, all users in the EXAMPLE.COM enterprise could 200 have principal names such as alice@EXAMPLE.COM, with the same realm 201 portion. In addition, servers at EXAMPLE.COM should be able to have 202 DNS host names from any DNS domain independent of what Kerberos realm 203 their principals reside in. 205 5. Enterprise Principal Name Type 207 The NT-ENTERPRISE type principal name contains one component, a 208 string of realm-defined content, which is intended to be used as an 209 alias for another principal name in some realm in the enterprise. It 210 is used for conveying the alias name, not for the real principal 211 names within the realms, and thus is only useful when name 212 canonicalization is requested. 214 The intent is to allow unification of email and security principal 215 names. For example, all users at EXAMPLE.COM may have a client 216 principal name of the form "joe@EXAMPLE.COM" even though the 217 principals are contained in multiple realms. This global name is 218 again an alias for the true client principal name, which indicates 219 what realm contains the principal. Thus, accounts "alice" in the 220 realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as 221 "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM". 223 This utilizes a new principal name type, as the KDC-REQ message only 224 contains a single client 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 6. Name Canonicalization 237 A service or account may have multiple principal names. For example, 238 if a host is known by multiple names, host-based services on it may 239 be known by multiple names in order to prevent the client from 240 needing a secure directory service to determine the correct hostname 241 to use. In order that the host should not need to be updated 242 whenever a new alias is created, the KDC may provide the mapping 243 information to the client in the credential acquisition process. 245 If the "canonicalize" KDC option is set, then the KDC MAY change the 246 client and server principal names and types in the AS response and 247 ticket returned from the name type of the client name in the request. 248 In a TGS exchange, the server principal name and type may be changed. 250 If the client principal name is changed in an AS exchange, the KDC 251 must include a mandatory PA-DATA object authenticating the client 252 name mapping: 254 ClientReferralInfo ::= SEQUENCE { 255 requested-name [0] PrincipalName, 256 mapped-name [1] PrincipalName, 257 ... 258 } 259 PA-CLIENT-CANONICALIZED ::= SEQUENCE { 260 names [0] ClientReferralInfo, 261 canon-checksum [1] Checksum 262 } 264 The canon-checksum field is computed over the DER encoding of the 265 names sequences, using the AS reply key and a key usage value of 266 (TBD). 268 If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is 269 not included. If the client name is changed, and the PA-CLIENT- 270 CANONICALIZED field does not exist, or the checksum cannot be 271 verified, or the requested-name field doesn't match the client name 272 in the originally-transmitted request, the client should discard the 273 response. 275 For example the AS request may specify a client name of "bob@ 276 EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC 277 option set and the KDC will return with a client name of "104567" as 278 a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT- 279 ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the 280 NT-UID "104567" principal as the mapped-name. 282 (It is assumed that the client discovers whether the KDC supports the 283 NT-ENTERPRISE name type via out of band mechanisms.) 285 If the server name is changed, a PA-SERVER-REFERRAL preauth data 286 entry MUST be supplied by the KDC and validated by the client. 288 In order to enable one party in a user-to-user exchange to confirm 289 the identity of another when only the alias is known, the KDC MAY 290 include the following authorization data element, wrapped in AD-KDC- 291 ISSUED, in the initial credentials and copy it from a ticket-granting 292 ticket into additional credentials: 294 AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD -- 295 login-aliases [0] SEQUENCE(1..MAX) OF PrincipalName, 296 } 298 The login-aliases field lists one or more of the aliases the 299 principal may have. 301 The recipient of this authenticator must check the AD-LOGIN-ALIAS 302 names, if present, in addition to the normal client name field, 303 against the identity of the party with which it wishes to 304 authenticate; either should be allowed to match. (Note that this is 305 not backwards compatible with [RFC4120]; if the server side of the 306 user-to-user exchange does not support this extension, and does not 307 know the true principal name, authentication may fail if the alias is 308 sought in the client name field.) 310 The use of AD-KDC-ISSUED authorization data elements in cross-realm 311 cases has not been well explored at this writing; hence we will only 312 specify the inclusion of this data in the one-realm case. The alias 313 information SHOULD be dropped in the general cross-realm case. 315 However, a realm MAY implement a policy of accepting and re-signing 316 (wrapping in a new AD-KDC-ISSUED element) alias information provided 317 by certain trusted realms, in the cross-realm ticket-granting 318 service. 320 The canonical principal name for an alias may not be in the form of a 321 ticket-granting service name, as (in a case of server name 322 canonicalization) that would be construed as a case of cross-realm 323 referral, described below. 325 7. Client Referrals 327 The simplest form of ticket referral is for a user requesting a 328 ticket using an AS-REQ. In this case, the client machine will send 329 the AS-REQ to a convenient trusted realm, for example the realm of 330 the client machine. In the case of the name alice@EXAMPLE.COM, the 331 client MAY optimistically choose to send the request to EXAMPLE.COM. 332 The realm in the AS-REQ is always the name of the realm that the 333 request is for as specified in [RFC4120]. 335 The KDC will try to lookup the name in its local account database. 336 If the account is present in the realm of the request, it SHOULD 337 return a KDC reply structure with the appropriate ticket. 339 If the account is not present in the realm specified in the request 340 and the "canonicalize" KDC option is set, the KDC may look up the 341 client principal name using some kind of name service or directory 342 service. If this lookup is unsuccessful, it MUST return the error 343 KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful, 344 it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the 345 error message the crealm field will contain either the true realm of 346 the client or another realm that MAY have better information about 347 the client's true realm. The client SHALL NOT use the cname returned 348 in this error message. 350 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 351 new AS request with the same client principal name used to generate 352 the first referral to the realm specified by the realm field of the 353 Kerberos error message corresponding to the first request. (The 354 client realm name will be updated in the new request to refer to this 355 new realm.) The client SHOULD repeat these steps until it finds the 356 true realm of the client. To avoid infinite referral loops, an 357 implementation should limit the number of referrals. A suggested 358 limit is 5 referrals before giving up. 360 Since the same client name is sent to the referring and referred-to 361 realms, both realms must recognize the same client names. In 362 particular, the referring realm cannot (usefully) define principal 363 name aliases that the referred-to realm will not know. 365 The true principal name of the client, returned in AS-REQ, can be 366 validated in a subsequent TGS message exchange where its value is 367 communicated back to the KDC via the authenticator in the PA-TGS-REQ 368 padata [RFC4120]. However, this requires trusting the referred-to 369 realm's KDCs. Clients should limit the referral mappings they will 370 accept to realms trusted via some local policy. Some possible 371 factors that might be taken into consideration for such a policy 372 might include: 374 o Any realm indicated by the local KDC, if the returned KRB-ERROR 375 message is protected by some additional means, for example using a 376 preauthentication scheme using a public key known to be associated 377 with the KDC, or an IPsec tunnel known to have the desired KDC as 378 the remote endpoint 379 o A list of realms configured by an administrator 380 o Any realm accepted by the user when explicitly prompted 382 There is currently no provision for changing the client name in a 383 client referral response, because there is no method for verifying 384 that a man-in-the-middle attack did not change the requested name in 385 the request on the way to the KDC. 387 8. Server Referrals 389 The primary difference in server referrals is that the KDC returns a 390 referral TGT rather than an error message as is done in the client 391 referrals. There needs to be a place to include in the reply 392 information about what realm contains the server; this is done by 393 returning information about the server name in the pre-authentication 394 data field of the KDC reply [RFC4120], as specified later in this 395 section. 397 If the "canonicalize" flag in the KDC options is set and the KDC 398 doesn't find the principal locally, either as a regular principal or 399 as an alias for another local principal, the KDC MAY return a cross- 400 realm ticket granting ticket to the next hop on the trust path 401 towards a realm that may be able to resolve the principal name. The 402 true principal name of the server SHALL be returned in the padata of 403 the reply if it is different from what is specified the request. 405 When a referral TGT is returned, the KDC MUST return the target realm 406 for the referral TGT as an KDC supplied pre-authentication data 407 element in the response. This referral information in pre- 408 authentication data MUST be encrypted using the session key from the 409 reply ticket. The key usage value for the encryption operation used 410 by PA-SERVER-REFERRAL is 26. 412 The pre-authentication data returned by the KDC, which contains the 413 referred realm and the true principal name of server, is encoded in 414 DER as follows. 416 PA-SERVER-REFERRAL 25 418 SERVER-REFERRAL-DATA ::= EncryptedData 419 -- ServerReferralData 420 -- returned session key, ku=26 422 ServerReferralData ::= SEQUENCE { 423 referred-realm [0] Realm OPTIONAL, 424 -- target realm of the referral TGT 425 true-principal-name [1] PrincipalName OPTIONAL, 426 -- true server principal name 427 requested-principal-name [2] PrincipalName OPTIONAL, 428 -- requested server name 429 referral-valid-until [3] KerberosTime OPTIONAL, 430 rep-cksum [4] Checksum, 431 -- associated {AS,TGS}-REP with no padata 432 -- reply key, ku=[TBD] 433 ... 434 } 436 The rep-cksum field is a checksum computed over the DER encoding of 437 the AS-REP or TGS-REP message with which the SERVER-REFERRAL-DATA is 438 included, but with the padata field omitted. It SHOULD be computed 439 using the mandatory-to-implement checksum type associated with the 440 encryption type of the reply key. (Encrypting the referral data in 441 with the reply key but without the checksum only proves that it was 442 generated by one of the parties with access to the reply key; it is 443 not proof against cut-and-paste attacks combining parts of different 444 KDC replies using the same reply key.) 446 Clients SHALL NOT accept a reply ticket in which the server principal 447 name is different from that of the request, if the KDC response does 448 not contain a PA-SERVER-REFERRAL padata entry. 450 The requested-principal-name MUST be included by the KDC, and MUST be 451 verified by the client, if the client sent an AS-REQ, as protection 452 against a man-in-the-middle modification to the AS-REQ message. 454 The referred-realm field is present if and only if the returned 455 ticket is a referral TGT, not a service ticket for the requested 456 server principal. 458 When a referral TGT is returned and the true-principal-name field is 459 present, the client MUST use that name in the subsequent requests to 460 the server realm when following the referral. 462 Client SHALL NOT accept a true server principal name for a service 463 ticket if the true-principal-name field is not present in the PA- 464 SERVER-REFERRAL data. 466 The client will use this referral information to request a chain of 467 cross-realm ticket granting tickets until it reaches the realm of the 468 server, and can then expect to receive a valid service ticket. 470 However an implementation should limit the number of referrals that 471 it processes to avoid infinite referral loops. A suggested limit is 472 5 referrals before giving up. 474 The client may cache the mapping of the requested name to the name of 475 the next realm to use and the principal name to ask for. (See 476 Section 10.) The referral-valid-until field, if present, conveys how 477 long this information is valid for. 479 Here is an example of a client requesting a service ticket for a 480 service in realm DEV.EXAMPLE.COM where the client is in 481 ADMIN.EXAMPLE.COM. 483 +NC = Canonicalize KDCOption set 484 +PA-REFERRAL = returned PA-SERVER-REFERRAL 485 C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM 486 S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL 487 containing EXAMPLE.COM as the referred realm with no 488 true-principal-name 489 C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM 490 S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL 491 containing DEV.EXAMPLE.COM as the referred realm with no 492 true-principal-name 493 C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM 494 S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM 496 Note that any referral or alias processing of the server name in 497 user-to-user authentication should use the same data as client name 498 canonicalization or referral. Otherwise, the name used by one user 499 to log in may not be useable by another for user-to-user 500 authentication to the first. 502 9. Cross Realm Routing 504 The current Kerberos protocol requires the client to explicitly 505 request a cross-realm TGT for each pair of realms on a referral 506 chain. As a result, the client need to be aware of the trust 507 hierarchy and of any short-cut trusts (those that aren't parent- 508 child trusts). 510 Instead, using the server referral routing mechanism as defined in 511 Section 8, The KDC will determine the best path for the client and 512 return a cross-realm TGT as the referral TGT, and the target realm 513 for this TGT in the PA-SERVER-REFERRAL of the KDC reply. 515 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return 516 a referral TGT. Clients SHALL NOT process referral TGTs if the KDC 517 response does not contain the PA-SERVER-REFERRAL padata. 519 10. Caching Information 521 It is possible that the client may wish to get additional credentials 522 for the same service principal, perhaps with different authorization- 523 data restrictions or other changed attributes. The return of a 524 server referral from a KDC can be taken as an indication that the 525 requested principal does not currently exist in the local realm. 526 Clearly, it would reduce network traffic if the clients could cache 527 that information and use it when acquiring the second set of 528 credentials for a service, rather than always having to re-check with 529 the local KDC to see if the name has been created locally. 531 If the referral-valid-until field is provided in the PA-SERVER- 532 REFERRAL-DATA message, it indicates the expiration time of this data; 533 if it is not included, the expiration time of the TGT is used. When 534 the TGT expires, the previously returned referral from the local KDC 535 should be considered invalid, and the local KDC must be asked again 536 for information for the desired service principal name. (Note that 537 the client may get back multiple referral TGTs from the local KDC to 538 the same remote realm, with different lifetimes. The lifetime 539 information must be properly associated with the requested service 540 principal names. Simply having another TGT for the same remote realm 541 does not extend the validity of previously acquired information about 542 one service principal name.) If the client is still in contact with 543 the service and needs to reauthenticate to the same service 544 regardless of local service principal name assignments, it should use 545 the referred-realm and true-principal-name values when requesting new 546 credentials. 548 Accordingly, KDC authors and maintainers should consider what factors 549 (e.g., DNS alias lifetimes) they may or may not wish to incorporate 550 into credential expiration times in cases of referrals. 552 11. Open Issues 554 Client referral info validation 556 When should client name aliases be included in credentials? Should 557 all known client name aliases be included, or only the one used at 558 initial ticket acquisition? 560 Should list the policies that need to be defined. 562 More examples: u2u, policy checks, maybe cross-realm. 564 Possibly generalize the integrity/privacy protection on 565 ServerReferralData into a general padata wrapper? 567 Is PA-SERVER-REFERRAL needed in a TGS exchange? 569 Do we need to send requested-name fields, or can we just include them 570 in checksums? 572 12. Number Assignments 574 Most number registries in the Kerberos protocol have not been turned 575 over to IANA for management at the time of this writing, hence this 576 is not an "IANA Considerations" section. 578 Various values do need assigning for this draft: 579 AD-LOGIN-ALIAS 580 PA-CLIENT-CANONICALIZED 581 key usage value for PA-CLIENT-CANONICALIZED field canon-checksum 583 13. IANA Considerations 585 None at present. 587 14. Security Considerations 589 For the AS exchange case, it is important that the logon mechanism 590 not trust a name that has not been used to authenticate the user. 591 For example, the name that the user enters as part of a logon 592 exchange may not be the name that the user authenticates as, given 593 that the KDC_ERR_WRONG_REALM error may have been returned. The 594 relevant Kerberos naming information for logon (if any), is the 595 client name and client realm in the service ticket targeted at the 596 workstation that was obtained using the user's initial TGT. 598 How the client name and client realm is mapped into a local account 599 for logon is a local matter, but the client logon mechanism MUST use 600 additional information such as the client realm and/or authorization 601 attributes from the service ticket presented to the workstation by 602 the user, when mapping the logon credentials to a local account on 603 the workstation. 605 14.1. Shared-password case 607 A special case to examine is when the user is known (or correctly 608 suspected) to use the same password for multiple accounts. A man-in- 609 the-middle attacker can either alter the request on its way to the 610 KDC, changing the client principal name, or reply to the client with 611 a response previously send by the KDC in response to a request from 612 the attacker. The response received by the client can then be 613 decrypted by the user, though if the default "salt" generated from 614 the principal name is used to produce the user's key, a PA-ETYPE-INFO 615 or PA-ETYPE-INFO2 preauth record may need to be added or altered by 616 the attacker to cause the client software to generate the key needed 617 for the message it will receive. None of this requires the attacker 618 to know the user's password, and without further checking, could 619 cause the user to unknowingly use the wrong credentials. 621 In normal [RFC4120] operation, a generated AP-REQ message includes in 622 the Authenticator field a copy of the client's idea of its own 623 principal name. If this differs from the name in the KDC-generated 624 Ticket, the application server will reject the message. 626 With client name canonicalization as described in this document, the 627 client may get its principal name from the response from the KDC. 628 Requiring the PA-CLIENT-CANONICALIZED data lets the client securely 629 check that the requested name was not altered in transit. If the PA- 630 CLIENT-CANONICALIZED data is absent, the client can use the principal 631 name it requested. 633 14.2. Preauthentication data 635 In cases of credential renewal, forwarding, or validation, if 636 credentials are sent to the KDC that are not an initial ticket- 637 granting ticket for the client's home realm, the encryption key used 638 to protect the TGS exchange is one known to a third party (namely, 639 the service for which the credential was issued). Consequently, in 640 such an exchange, the protection described earlier for the 641 preauthentication data cannot be assumed to provide a secure channel 642 between the KDC and the client, and such preauth data MUST NOT be 643 trusted for any information that needs to come from the KDC. 645 15. Acknowledgments 647 Sam Hartman and authors came up with the idea of using the ticket key 648 to encrypt the referral data, which prevents cut and paste attack 649 using the referral data and referral TGTs. 651 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 652 version of this document. 654 Karthik Jaganathan contributed to earlier versions. 656 16. References 658 16.1. Normative References 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 664 Kerberos Network Authentication Service (V5)", RFC 4120, 665 July 2005. 667 16.2. Informative References 669 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 670 X.509 Public Key Infrastructure Certificate and 671 Certificate Revocation List (CRL) Profile", RFC 3280, 672 April 2002. 674 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 675 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 677 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation 678 of Crossrealm Referral Handling in the MIT Kerberos 679 Client", Network and Distributed System Security 680 Symposium, February 2001. 682 Appendix A. Compatibility with Earlier Implementations of Name 683 Canonicalization 685 The Microsoft Windows 2000 and Windows 2003 releases included an 686 earlier form of name-canonicalization [XPR]. Here are the 687 differences: 689 1) The TGS referral data is returned inside of the KDC message as 690 "encrypted pre-authentication data". 692 EncKDCRepPart ::= SEQUENCE { 693 key [0] EncryptionKey, 694 last-req [1] LastReq, 695 nonce [2] UInt32, 696 key-expiration [3] KerberosTime OPTIONAL, 697 flags [4] TicketFlags, 698 authtime [5] KerberosTime, 699 starttime [6] KerberosTime OPTIONAL, 700 endtime [7] KerberosTime, 701 renew-till [8] KerberosTime OPTIONAL, 702 srealm [9] Realm, 703 sname [10] PrincipalName, 704 caddr [11] HostAddresses OPTIONAL, 705 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 706 } 708 2) The preauth data type definition in the encrypted preauth data is 709 as follows: 711 PA-SVR-REFERRAL-INFO 20 713 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 714 referred-name [1] PrincipalName OPTIONAL, 715 referred-realm [0] Realm 716 }} 718 3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is 719 encoded as a Subject Alternative Name (SAN) extension [RFC3280] in 720 the client's X.509 certificate. The type of the otherName field 721 for this SAN extension is AnotherName [RFC3280]. The type-id 722 field of the type AnotherName is id-ms-sc-logon-upn 723 (1.3.6.1.4.1.311.20.2.3) and the value field of the type 724 AnotherName is a KerberosString [RFC4120]. The value of this 725 KerberosString type is the single component in the name-string 726 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 728 In Microsoft's current implementation through the use of global 729 catalogs any domain in one forest is reachable from any other domain 730 in the same forest or another trusted forest with 3 or less 731 referrals. A forest is a collection of realms with hierarchical 732 trust relationships: there can be multiple trust trees in a forest; 733 each child and parent realm pair and each root realm pair have 734 bidirectional transitive direct rusts between them. 736 While we might want to permit multiple aliases to exist and even be 737 reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only 738 one NT-ENTERPRISE alias to exist, so this question had not previously 739 arisen. 741 Appendix B. Document history [REMOVE BEFORE PUBLICATION] 743 11 Changed title. Better protection on server referral preauth data. 744 Support server name canonicalization. Rename ReferralInfo to 745 ClientReferralInfo. Disallow alias mapping to a TGT principal. 746 Explain why no name change in client referrals. Add empty IANA 747 Considerations. Add some notes on preauth data protection during 748 renewal etc. 749 10 Separate enterprise principal names into a separate section. Add 750 a little wording to suggest server principal name canonicalization 751 might be allowed; not fleshed out. Advise against AD-KDC-ISSUED 752 in cronn-realm cases. Advise policy checks on returned client 753 referral info, since there's no security. List number 754 assignments. Add security analysis of shared-password case. No 755 longer plan to remove Microsoft appendix. Add referral-valid- 756 until field. 757 09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain. 758 Rewrote description of existing practice. (Don't name the lookup 759 table consulted. Mention that DNS "canonicalization" is contrary 760 to [RFC4120].) Noted Microsoft behavior should be moved out into 761 a separate document. Changed some second-person references in the 762 introduction to identify the proper parties. Changed PA-CLIENT- 763 CANONICALIZED to use a separate type for the actual referral data, 764 add an extension marker to that type, and change the checksum key 765 from the "returned session key" to the "AS reply key". Changed 766 AD-LOGIN-ALIAS to contain a sequence of names, to be contained in 767 AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer 768 needed separate checksum. Attempt to clarify the cache lifetime 769 of referral information. 770 08 Moved Microsoft implementation info to appendix. Clarify lack of 771 local server name canonicalization. Added optional authz-data for 772 login alias, to support user-to-user case. Added requested- 773 principal-name to ServerReferralData. Added discussion of caching 774 information, and referral TGT lifetime. 776 07 Re-issued with new editor. Fixed up some references. Started 777 history. 779 Authors' Addresses 781 Kenneth Raeburn 782 Massachusetts Institute of Technology 783 77 Massachusetts Avenue 784 Cambridge, MA 02139 785 US 787 Email: raeburn@mit.edu 789 Larry Zhu 790 Microsoft Corporation 791 One Microsoft Way 792 Redmond, WA 98052 793 US 795 Email: lzhu@microsoft.com 797 Full Copyright Statement 799 Copyright (C) The IETF Trust (2008). 801 This document is subject to the rights, licenses and restrictions 802 contained in BCP 78, and except as set forth therein, the authors 803 retain all their rights. 805 This document and the information contained herein are provided on an 806 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 807 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 808 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 809 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 810 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 811 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 813 Intellectual Property 815 The IETF takes no position regarding the validity or scope of any 816 Intellectual Property Rights or other rights that might be claimed to 817 pertain to the implementation or use of the technology described in 818 this document or the extent to which any license under such rights 819 might or might not be available; nor does it represent that it has 820 made any independent effort to identify any such rights. Information 821 on the procedures with respect to rights in RFC documents can be 822 found in BCP 78 and BCP 79. 824 Copies of IPR disclosures made to the IETF Secretariat and any 825 assurances of licenses to be made available, or the result of an 826 attempt made to obtain a general license or permission for the use of 827 such proprietary rights by implementers or users of this 828 specification can be obtained from the IETF on-line IPR repository at 829 http://www.ietf.org/ipr. 831 The IETF invites any interested party to bring to its attention any 832 copyrights, patents or patent applications, or other proprietary 833 rights that may cover technology that may be required to implement 834 this standard. Please address the information to the IETF at 835 ietf-ipr@ietf.org. 837 Acknowledgment 839 Funding for the RFC Editor function is provided by the IETF 840 Administrative Support Activity (IASA).