idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-04.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.5 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 510. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 9) being 77 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 380, but not defined == Missing Reference: '6' is mentioned on line 364, but not defined == Missing Reference: '7' is mentioned on line 365, but not defined == Missing Reference: '8' is mentioned on line 366, but not defined == Missing Reference: '9' is mentioned on line 367, but not defined == Missing Reference: '10' is mentioned on line 368, but not defined == Missing Reference: '11' is mentioned on line 369, but not defined == Missing Reference: '12' is mentioned on line 370, but not defined ** Obsolete normative reference: RFC 821 (ref. '4') (Obsoleted by RFC 2821) Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Kerberos Working Group Karthik Jaganathan 2 Internet Draft Larry Zhu 3 Document: draft-ietf-krb-wg-kerberos-referrals-04.txt John Brezak 4 Category: Standards Track Microsoft 5 Mike Swift 6 University of Washington 7 Jonathan Trostle 8 Cisco Systems 9 Expires: January 2005 11 Generating KDC Referrals to locate Kerberos realms 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC-2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 28 Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The draft documents a method for a Kerberos Key Distribution Center 34 (KDC) to respond to client requests for Kerberos tickets when the 35 client does not have detailed configuration information on the realms 36 of users or services. The KDC will handle requests for principals in 37 other realms by returning either a referral error or a cross-realm 38 TGT to another realm on the referral path. The clients will use this 39 referral information to reach the realm of the target principal and 40 then receive the ticket. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119 [2]. 48 1. Introduction 50 KDC Referrals January 2005 52 Current implementations of the Kerberos AS and TGS protocols, as 53 defined in [3], use principal names constructed from a known user or 54 service name and realm. A service name is typically constructed from 55 a name of the service and the DNS host name of the computer that is 56 providing the service. Many existing deployments of Kerberos use a 57 single Kerberos realm where all users and services would be using the 58 same realm. However in an environment where there are multiple 59 trusted Kerberos realms, the client needs to be able to determine 60 what realm a particular user or service is in before making an AS or 61 TGS request. Traditionally this requires client configuration to make 62 this possible. 64 When having to deal with multiple trusted realms, users are forced to 65 know what realm they are in before they can obtain a ticket granting 66 ticket (TGT) with an AS request. However, in many cases the user 67 would like to use a more familiar name that is not directly related 68 to the realm of their Kerberos principal name. A good example of this 69 is an RFC-821 style email name [4]. This document describes a 70 mechanism that would allow a user to specify a user principal name 71 that is an alias for the user's Kerberos principal name. In practice 72 this would be the name that the user specifies to obtain a TGT from a 73 Kerberos KDC. The user principal name no longer has a direct 74 relationship with the Kerberos principal or realm. Thus the 75 administrator is able to move the user's principal to other realms 76 without the user having to know that it happened. 78 Once a user has a TGT, they would like to be able to access services 79 in any trusted Kerberos realm. To do this requires that the client be 80 able to determine what realm the target service principal is in 81 before making the TGS request. Current implementations of Kerberos 82 typically have a table that maps DNS host names to corresponding 83 Kerberos realms. In order for this to work on the client, each 84 application canonicalizes the host name of the service, for example 85 by doing a DNS lookup followed by a reverse lookup using the returned 86 IP address. The returned primary host name is then used in the 87 construction of the principal name for the target service. In order 88 for the correct realm to be added for the target host, the mapping 89 table [domain_to_realm] is consulted for the realm corresponding to 90 the DNS host name. The corresponding realm is then used to complete 91 the target service principal name. 93 This traditional mechanism requires that each client have very 94 detailed configuration information about the hosts that are providing 95 services and their corresponding realms. Having client side 96 configuration information can be very costly from an administration 97 point of view - especially if there are many realms and computers in 98 the environment. 100 KDC Referrals January 2005 102 There are also cases where specific DNS aliases (local names) have 103 been setup in an organization to refer to a server in another 104 organization (remote server). The server has different DNS names in 105 each organization and each organization has a Kerberos realm that is 106 configured to service DNS names within that organization. Ideally 107 users are able to authenticate to the server in the other 108 organization using the local server name. This would mean that the 109 local realm be able to produce a ticket to the remote server under 110 its name. You could give that remote server an identity in the local 111 realm and then have that remote server maintain a separate secret for 112 each alias it is known as. Alternatively you could arrange to have 113 the local realm issue a referral to the remote realm and notify the 114 requesting client of the server's remote name that should be used in 115 order to request a ticket. 117 This draft proposes a solution for these problems and simplifies 118 administration by minimizing the configuration information needed on 119 each computer using Kerberos. Specifically it describes a mechanism 120 to allow the KDC to handle canonicalization of names, provide for 121 principal aliases for users and services and provide a mechanism for 122 the KDC to determine the trusted realm authentication path by being 123 able to generate referrals to other realms in order to locate 124 principals. 126 To rectify these problems, this draft introduces three new kinds of 127 KDC referrals: 129 1. AS ticket referrals, in which the client doesn't know which realm 130 contains a user account. 131 2. TGS ticket referrals, in which the client doesn't know which realm 132 contains a server account. 133 3. Cross realm shortcut referrals, in which the KDC chooses the next 134 path on a referral chain 136 2. Requesting a referral 138 In order to request referrals defined in section 5, 6, and 7, the 139 Kerberos client MUST explicitly request the canonicalize KDC option 140 (bit 15) [3] for the AS-REQ or TGS-REQ. This flag indicates to the 141 KDC that the client is prepared to receive a reply that contains a 142 principal name other than the one requested. 144 KDCOptions ::= KerberosFlags 145 -- canonicalize (15) 146 -- other KDCOptions values omitted 148 The client should expect, when sending names with the "canonicalize" 149 KDC option, that names in the KDC's reply MAY be different than the 151 KDC Referrals January 2005 153 name in the request. A referral ticket is a cross realm TGT that is 154 returned when the sname of the ticket is not the sname in the request 155 [3]. 157 3. Realm Organization Model 159 This draft assumes that the world of principals is arranged on 160 multiple levels: the realm, the enterprise, and the world. A KDC may 161 issue tickets for any principal in its realm or cross-realm tickets 162 for realms with which it has a direct trust relationship. The KDC 163 also has access to a trusted name service that can resolve any name 164 from within its enterprise into a realm. This trusted name service 165 removes the need to use an un-trusted DNS lookup for name resolution. 167 For example, consider the following configuration, where lines 168 indicate trust relationships: 170 MS.COM 171 / \ 172 / \ 173 OFFICE.MS.COM NTDEV.MS.COM 175 In this configuration, all users in the MS.COM enterprise could have 176 a principal name such as alice@MS.COM, with the same realm portion. 177 In addition, servers at MS.COM should be able to have DNS host names 178 from any DNS domain independent of what Kerberos realm their 179 principals reside in. 181 4. Client Name Canonicalization 183 A client account may have multiple principal names. More useful, 184 though, is a globally unique name that allows unification of email 185 and security principal names. For example, all users at MS may have a 186 client principal name of the form "joe@MS.COM" even though the 187 principals are contained in multiple realms. This global name is 188 again an alias for the true client principal name, which indicates 189 what realm contains the principal. Thus, accounts "alice" in the 190 realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as 191 "alice@MS.COM" and "bob@MS.COM". 193 This utilizes a new client principal name type, as the AS-REQ message 194 only contains a single realm field, and the realm portion of this 195 name doesn't correspond to any Kerberos realm. Thus, the entire name 196 "alice@MS.COM" is transmitted as a single component in the client 197 name field of the AS-REQ message, with a name type of NT-ENTERPRISE 198 [3]. The KDC will recognize this name type and then transform the 200 KDC Referrals January 2005 202 requested name into the true principal name. The true principal name 203 can be using a name type different from the requested name type. 204 Typically the true principal name will be a NT-PRINCIPAL [3]. 206 If the "canonicalize" KDC option is set, then the KDC MAY change the 207 client principal name and type in the AS response and ticket returned 208 from the name type of the client name in the request. For example the 209 AS request may specify a client name of "bob@MS.COM" as an NT- 210 PRINCIPAL with the "canonicalize" KDC option set and the KDC will 211 return with a client name of "104567" as a NT-UID. 213 5. Client Referrals 215 The simplest form of ticket referral is for a user requesting a 216 ticket using an AS-REQ. In this case, the client machine will send 217 the AS-REQ to a convenient trusted realm, for example the realm of 218 the client machine. In the case of the name alice@MS.COM, the client 219 MAY optimistically choose to send the request to MS.COM. The realm in 220 the AS-REQ is always the name of the realm that the request is for as 221 specified in [3]. 223 The KDC will try to lookup the name in its local account database. If 224 the account is present in the realm of the request, it SHOULD return 225 a KDC reply structure with the appropriate ticket. 227 If the account is not present in the realm specified in the request 228 and the "canonicalize" KDC option is set, the KDC will try to lookup 229 the entire name, alice@MS.COM, using a name service. If this lookup 230 is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN 231 [3]. If the lookup is successful, it MUST return an error 232 KDC_ERR_WRONG_REALM [3] and in the error message the crealm field 233 will contain either the true realm of the client or another realm 234 that MAY have better information about the client's true realm. The 235 client MUST NOT use a cname returned from a referral. 237 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 238 new AS request with the same client principal name used to generate 239 the first referral to the realm specified by the realm field of the 240 Kerberos error message from the first request. The client SHOULD 241 repeat these steps until it finds the true realm of the client. To 242 avoid infinite referral loops, an implementation should limit the 243 number of referrals. A suggested limit is 5 referrals before giving 244 up. In Microsoft's current implementation through the use of global 245 catalogs any domain in one forest is reachable from any other domain 246 in the same forest or another trusted forest with 3 or less 247 referrals. 249 6. Service Referrals 251 KDC Referrals January 2005 253 The primary problem in service referrals is that the KDC must return 254 a referral ticket rather than an error message as is done in AS 255 ticket referrals. There needs to be a place to include in the TGS-REP 256 information about what realm contains the service. This is done by 257 returning information about the service name in the pre- 258 authentication data field of the KDC reply [3]. 260 If the KDC resolves the service principal name into a principal in 261 the realm specified by the service realm name, it will return a 262 normal ticket. 264 If the "canonicalize" flag in the KDC options is not set, the KDC 265 MUST only look up the name as a normal principal name in the 266 specified service realm. If the "canonicalize" flag in the KDC 267 options is set and the KDC doesn't find the principal locally, the 268 KDC MAY return a cross-realm ticket granting ticket to the next hop 269 on the trust path towards a realm that may be able to resolve the 270 principal name. 272 When a referral TGT is returned, the KDC MUST return the target realm 273 for the referral TGT as an KDC supplied pre-authentication data 274 element in the response. The pre-authentication data MUST be 275 encrypted using the sub-session key from the authenticator if present 276 or the session key from the ticket. The pre-authentication data 277 contains the referred realm, and if known, the real principal name. 279 PA-SERVER-REFERRAL 25 281 PA-SERVER-REFERRAL-DATA ::= EncryptedData 282 -- ServerReferalData -- 284 ServerReferralData ::= SEQUENCE { 285 referred-realm [0] Realm, 286 -- target realm of the referral TGT 287 referred-name [1] PrincipalName OPTIONAL, 288 -- service principal name, MAY differ 289 -- from the server name in the request 290 ... 291 } 293 Clients MUST NOT process referral tickets if the KDC response does 294 not contain the PA-SERVER-REFERRAL. 296 If applicable to the encryption type, the key usage value for the 297 encryption key used by PA-SERVER-REFERRAL is 26 if the session key 298 from the ticket is used or 27 if a sub-session key is used. 300 If the referred-name field is present, the client MUST use that name 302 KDC Referrals January 2005 304 in a subsequent TGS request to the service realm when following the 305 referral. 307 The client will use this information to request a chain of cross- 308 realm ticket granting tickets until it reaches the realm of the 309 service, and can then expect to receive a valid service ticket. 310 However an implementation should limit the number of referrals that 311 it processes to avoid infinite referral loops. A suggested limit is 5 312 referrals before giving up. 314 Here is an example of a client requesting a service ticket for a 315 service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM. 317 +NC = Canonicalize KDCOption set 318 +PA-REFERRAL = returned PA-SERVER-REFERRAL 319 C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to OFFICE.MS.COM 320 S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL 321 containing MS.COM as the referred realm with no referred name 322 C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to MS.COM 323 S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL 324 containing NTDEV.MS.COM as the referred realm with no referred 325 name 326 C: TGS-REQ sname=server/foo.ntdev.ms.com +NC to NTDEV.MS.COM 327 S: TGS-REP sname=server/foo.ntdev.ms.com@NTDEV.MS.COM 329 7. Cross Realm Routing 331 The current Kerberos protocol requires the client to explicitly 332 request a cross-realm TGT for each pair of realms on a referral 333 chain. As a result, the client need to be aware of the trust 334 hierarchy and of any short-cut trusts (those that aren't parent- 335 child trusts). 337 Instead, using this referral routing mechanism, The KDC will 338 determine the best path for the client and return a cross-realm TGT 339 as the referral TGT, and the target realm for this TGT in the PA- 340 SERVER-REFERRAL of the KDC reply. 342 If the "canonicalize" KDC option is not set, the KDC MUST NOT return 343 a referral ticket. Clients MUST NOT process referral tickets if the 344 KDC response does not contain the PA-SERVER-REFERRAL. 346 8. Compatibility with earlier implementations of name canonicalization 348 The Microsoft Windows 2000 and Windows 2003 releases included an 349 earlier form of name-canonicalization [5]. Here are the differences: 351 1) The TGS referral data is returned inside of the KDC message as 353 KDC Referrals January 2005 355 "encrypted pre-authentication data". 357 EncKDCRepPart ::= SEQUENCE { 358 key [0] EncryptionKey, 359 last-req [1] LastReq, 360 nonce [2] UInt32, 361 key-expiration [3] KerberosTime OPTIONAL, 362 flags [4] TicketFlags, 363 authtime [5] KerberosTime, 364 starttime [6] KerberosTime OPTIONAL, 365 endtime [7] KerberosTime, 366 renew-till [8] KerberosTime OPTIONAL, 367 srealm [9] Realm, 368 sname [10] PrincipalName, 369 caddr [11] HostAddresses OPTIONAL, 370 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 371 } 373 2) The preauth data type definition in the encrypted preauth data is 374 as follows: 376 PA-SVR-REFERRAL-INFO 20 378 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 379 referred-name [1] PrincipalName OPTIONAL, 380 referred-realm [0] Realm 381 } 383 9. Security Considerations 385 In the case of TGS requests the client may be vulnerable to a denial 386 of service attack by an attacker that replays replies from previous 387 requests. The client can verify that the request was one of its own 388 by checking the client-address field or authtime field, though, so 389 the damage is limited and detectable. 391 For the AS exchange case, it is important that the logon mechanism 392 not trust a name that has not been used to authenticate the user. 393 For example, the name that the user enters as part of a logon 394 exchange may not be the name that the user authenticates as, given 395 that the KDC_ERR_WRONG_REALM error may have been returned. The 396 relevant Kerberos naming information for logon (if any), is the 397 client name and client realm in the service ticket targeted at the 398 workstation that was obtained using the user's initial TGT. 400 How the client name and client realm is mapped into a local account 401 for logon is a local matter, but the client logon mechanism MUST use 402 additional information such as the client realm and/or authorization 404 KDC Referrals January 2005 406 attributes from the service ticket presented to the workstation by 407 the user, when mapping the logon credentials to a local account on 408 the workstation. 410 10. Acknowledgements 412 The authors wish to thank Ken Raeburn for his comments and 413 suggestions. 415 11. References 417 11.1 Normative References 419 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 420 9, RFC 2026, October 1996. 422 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 423 Levels", BCP 14, RFC 2119, March 1997. 425 [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 426 Network Authentication Service (V5)", draft-ietf-krb-wg-kerberos- 427 clarifications. Work in progress. 429 [4] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 430 1982. 432 11.2 Informative References 434 [5] Trostle, J., Kosinovsky, I., and Swift, M., "Implementation of 435 Crossrealm Referral Handling in the MIT Kerberos Client", In Network 436 and Distributed System Security Symposium, February 2001. 438 12. Author's Addresses 440 Karthik Jaganathan 441 Microsoft 442 One Microsoft Way 443 Redmond, Washington 444 Email: karthikj@Microsoft.com 446 Larry Zhu 447 Microsoft 448 One Microsoft Way 449 Redmond, Washington 450 Email: lzhu@Microsoft.com 452 Michael Swift 453 University of Washington 455 KDC Referrals January 2005 457 Seattle, Washington 458 Email: mikesw@cs.washington.edu 460 John Brezak 461 Microsoft 462 One Microsoft Way 463 Redmond, Washington 464 Email: jbrezak@Microsoft.com 466 Jonathan Trostle 467 Cisco Systems 468 170 W. Tasman Dr. 469 San Jose, CA 95134 470 Email: jtrostle@cisco.com 472 KDC Referrals January 2005 474 Copyright Statement 476 Copyright (C) The Internet Society (2004). This document is subject 477 to the rights, licenses and restrictions contained in BCP 78, and 478 except as set forth therein, the authors retain all their rights. 480 This document and the information contained herein are provided on an 481 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 482 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 483 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 484 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 485 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 486 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 488 Intellectual Property 490 The IETF takes no position regarding the validity or scope of any 491 Intellectual Property Rights or other rights that might be claimed to 492 pertain to the implementation or use of the technology described in 493 this document or the extent to which any license under such rights 494 might or might not be available; nor does it represent that it has 495 made any independent effort to identify any such rights. Information 496 on the procedures with respect to rights in RFC documents can be 497 found in BCP 78 and BCP 79. 499 Copies of IPR disclosures made to the IETF Secretariat and any 500 assurances of licenses to be made available, or the result of an 501 attempt made to obtain a general license or permission for the use of 502 such proprietary rights by implementers or users of this 503 specification can be obtained from the IETF on-line IPR repository at 504 http://www.ietf.org/ipr. 506 The IETF invites any interested party to bring to its attention any 507 copyrights, patents or patent applications, or other proprietary 508 rights that may cover technology that may be required to implement 509 this standard. Please address the information to the IETF at ietf- 510 ipr@ietf.org.