idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 28, 2011) is 4775 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 825 -- Looks like a reference, but probably isn't: '1' on line 824 -- Looks like a reference, but probably isn't: '2' on line 556 -- Looks like a reference, but probably isn't: '3' on line 557 -- Looks like a reference, but probably isn't: '4' on line 558 -- Looks like a reference, but probably isn't: '5' on line 559 -- Looks like a reference, but probably isn't: '6' on line 560 -- Looks like a reference, but probably isn't: '7' on line 561 -- Looks like a reference, but probably isn't: '8' on line 562 -- Looks like a reference, but probably isn't: '9' on line 563 -- Looks like a reference, but probably isn't: '10' on line 564 -- Looks like a reference, but probably isn't: '11' on line 565 -- Looks like a reference, but probably isn't: '12' on line 566 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos WORKING GROUP S. Hartman, Ed. 3 Internet-Draft Painless Security 4 Updates: 4120 (if approved) K. Raeburn 5 Intended status: Standards Track MIT 6 Expires: September 29, 2011 L. Zhu 7 Microsoft Corporation 8 March 28, 2011 10 Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm 11 Referrals 12 draft-ietf-krb-wg-kerberos-referrals-12 14 Abstract 16 The memo documents a method for a Kerberos Key Distribution Center 17 (KDC) to respond to client requests for Kerberos tickets when the 18 client does not have detailed configuration information on the realms 19 of users or services. The KDC will handle requests for principals in 20 other realms by returning either a referral error or a cross-realm 21 TGT to another realm on the referral path. The clients will use this 22 referral information to reach the realm of the target principal and 23 then receive the ticket. This memo also provides a mechanism for 24 verifying that a request has not been tampered with in transit. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 29, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 74 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 6 75 4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 6 76 4.1. Trust Assumptions . . . . . . . . . . . . . . . . . . . . 7 77 5. Enterprise Principal Name Type . . . . . . . . . . . . . . . . 8 78 6. Name Canonicalization . . . . . . . . . . . . . . . . . . . . 8 79 7. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 10 80 8. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 11 81 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 12 82 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 12 83 11. Negotiation of FAST and Detecting Modified Requests . . . . . 13 84 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 13. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 14 86 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 15. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 15.1. Shared-password case . . . . . . . . . . . . . . . . . . . 17 89 15.2. Preauthentication data . . . . . . . . . . . . . . . . . . 18 90 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 91 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 93 17.2. Informative References . . . . . . . . . . . . . . . . . . 19 94 Appendix A. Compatibility with Earlier Implementations of 95 Name Canonicalization . . . . . . . . . . . . . . . . 19 96 Appendix B. Document history [REMOVE BEFORE PUBLICATION] . . . . 20 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 Current implementations of the Kerberos AS and TGS protocols, as 102 defined in [RFC4120], use principal names constructed from a known 103 user or service name and realm. A service name is typically 104 constructed from a name of the service and the DNS host name of the 105 computer that is providing the service. Many existing deployments of 106 Kerberos use a single Kerberos realm where all users and services 107 would be using the same realm. However in an environment where there 108 are multiple Kerberos realms, the client needs to be able to 109 determine what realm a particular user or service is in before making 110 an AS or TGS request. Traditionally this requires client 111 configuration to make this possible. 113 When having to deal with multiple realms, users are forced to know 114 what realm they are in before they can obtain a ticket granting 115 ticket (TGT) with an AS request. However, in many cases the user 116 would like to use a more familiar name that is not directly related 117 to the realm of their Kerberos principal name. A good example of 118 this is an RFC 822 style email name. This document describes a 119 mechanism that would allow a user to specify a user principal name 120 that is an alias for the user's Kerberos principal name. In practice 121 this would be the name that the user specifies to obtain a TGT from a 122 Kerberos KDC. The user principal name no longer has a direct 123 relationship with the Kerberos principal or realm. Thus the 124 administrator is able to move the user's principal to other realms 125 without the user having to know that it happened. 127 Once a user has a TGT, they would like to be able to access services 128 in any Kerberos realm for which there is an authentication path from 129 the realm of their principal. To do this requires that the client be 130 able to determine what realm the target service principal is in 131 before making the TGS request. Current implementations of Kerberos 132 typically have a table that maps DNS host names to corresponding 133 Kerberos realms. The user-supplied host name or its domain component 134 is looked up in this table (often using the result of some form of 135 host name lookup performed with insecure DNS queries, in violation of 136 [RFC4120]). The corresponding realm is then used to complete the 137 target service principal name. Even if insecure DNS queries were not 138 used, managing this table is problematic. 140 This traditional mechanism requires that each client have very 141 detailed configuration information about the hosts that are providing 142 services and their corresponding realms. Having client side 143 configuration information can be very costly from an administration 144 point of view-- especially if there are many realms and computers in 145 the environment. 147 There are also cases where specific DNS aliases (local names) have 148 been setup in an organization to refer to a server in another 149 organization (remote server). The server has different DNS names in 150 each organization and each organization has a Kerberos realm that is 151 configured to service DNS names within that organization. Ideally 152 users are able to authenticate to the server in the other 153 organization using the local server name. This would mean that the 154 local realm be able to produce a ticket to the remote server under 155 its name. The administrator in the local realm could give that 156 remote server an identity in the local realm and then have that 157 remote server maintain a separate secret for each alias it is known 158 as. Alternatively the administrator could arrange to have the local 159 realm issue a referral to the remote realm and notify the requesting 160 client of the server's remote name that should be used in order to 161 request a ticket. 163 This memo proposes a solution for these problems and simplifies 164 administration by minimizing the configuration information needed on 165 each computer using Kerberos. Specifically it describes a mechanism 166 to allow the KDC to handle canonicalization of names, provide for 167 principal aliases for users and services and allow the KDC to 168 determine the trusted realm authentication path by being able to 169 generate referrals to other realms in order to locate principals. 171 Two kinds of KDC referrals are introduced in this memo: 173 1. Client referrals, in which the client doesn't know which realm 174 contains a user account. 175 2. Server referrals, in which the client doesn't know which realm 176 contains a server account. 178 These two types of referrals introduce new opportunities for an 179 attacker. In order to avoid these attacks, a mechanism is provided 180 to protect the integrity of the request between the client and KDC. 181 This mechanism compliments the Flexible Authentication through Secure 182 Tunnels (FAST) facility provided in 183 [I-D.ietf-krb-wg-preauth-framework]. A mechanism is provided to 184 negotiate the availability of FAST. Among other benefits this can be 185 used to protect errors generated by the referral process. 187 2. Conventions Used in This Document 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in [RFC2119]. 193 3. Requesting a Referral 195 In order to request referrals as defined in later sections, the 196 Kerberos client MUST explicitly request the canonicalize KDC option 197 (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to 198 the KDC that the client is prepared to receive a reply that contains 199 a principal name other than the one requested. 201 KDCOptions ::= KerberosFlags 202 -- canonicalize (15) 203 -- other KDCOptions values omitted 205 The client should expect, when sending names with the "canonicalize" 206 KDC option, that names in the KDC's reply MAY be different than the 207 name in the request. A referral TGT is a cross realm TGT that is 208 returned with the server name of the ticket being different from the 209 server name in the request [RFC4120]. 211 4. Realm Organization Model 213 This memo assumes that the world of principals is arranged on 214 multiple levels: the realm, the enterprise, and the world. A KDC may 215 issue tickets for any principal in its realm or cross-realm tickets 216 for realms with which it has a direct cross-realm relationship. The 217 KDC also has access to a trusted name service that can resolve any 218 name from within its enterprise into a realm closer along the 219 authentication path to the service. This trusted name service 220 removes the need to use an un-trusted DNS lookup for name resolution. 222 For example, consider the following configuration, where lines 223 indicate cross-realm relationships: 225 EXAMPLE.COM 226 / \ 227 / \ 228 ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM 230 In this configuration, all users in the EXAMPLE.COM enterprise could 231 have principal names such as alice@EXAMPLE.COM, with the same realm 232 portion. In addition, servers at EXAMPLE.COM should be able to have 233 DNS host names from any DNS domain independent of what Kerberos realm 234 their principals reside in. 236 4.1. Trust Assumptions 238 Two realms participate in any cross-realm relationship: an issuing 239 realm issues a cross-realm ticket and a consuming realm uses this 240 ticket. There is a degree of trust of the issuing realm by the 241 consuming realm implicit in this relationship. Whenever a service in 242 the consuming realm permits an authentication path containing the 243 issuing realm, that service trusts the issuing realm to accurately 244 represent the identity of the authenticated principal and any 245 information about the transited path. If the consuming realm's KDC 246 sets the transited policy checked flag, the KDC is making the same 247 trust assumption a service would. 249 This trust is transitive across a multi-hop authentication path. The 250 service's realm trusts each hop along the authentication path closer 251 to the client to accurately represent the authenticated identity and 252 to accurately represent transited information. Any KDC along this 253 path could impersonate the client. 255 KDC signed or issued authorization data often implies additional 256 trust. The implications of such trust from a security and 257 operational standpoint is an ongoing topic of discussion during the 258 development of this specification. As such, such discussion is out 259 of scope for this memo. 261 Administrators have several tools to limit trust caused by cross- 262 realm relationships. A service or KDC can control what 263 authentication paths are acceptable. For example if a given realm is 264 not permitted on the authentication path for a particular client then 265 that realm cannot affect trust placed in that client principal. 266 Consuming realms can exercise significant control by deciding what 267 principals to place on an access-control list. If no client using a 268 given issuing realm in authentication paths is permitted to access a 269 resource, then that issuing realm is not trusted in access decisions 270 regarding that resource. 272 Creating a cross-realm relationship implies relatively little 273 inherent trust in the issuing realm. Significant trust only applies 274 as principals dependent on that issuing realm are given access to 275 resources. However, two deployment constraints may imply 276 significantly greater trust is implied by the initial cross-realm 277 relationship. First, a number of realms provide access to any 278 principal to some resources. Access decisions involving these 279 resources involve a degree of trust in all issuing realms in the 280 transited graph. Secondly, many realms do not significantly 281 constrain what principals users of that realm may grant access. In 282 these realms, creating a cross-realm relationship delegates the 283 decision to trust that realm to users of the consuming realm. In 284 this situation, creating the cross-realm relationship is the primary 285 trust decision point under the administrator's control. 287 5. Enterprise Principal Name Type 289 The NT-ENTERPRISE type principal name contains one component, a 290 string of realm-defined content, which is intended to be used as an 291 alias for another principal name in some realm in the enterprise. It 292 is used for conveying the alias name, not for the real principal 293 names within the realms, and thus is only useful when name 294 canonicalization is requested. 296 The intent is to allow unification of email and security principal 297 names. For example, all users at EXAMPLE.COM may have a client 298 principal name of the form "joe@EXAMPLE.COM" even though the 299 principals are contained in multiple realms. This global name is 300 again an alias for the true client principal name, which indicates 301 what realm contains the principal. Thus, accounts "alice" in the 302 realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as 303 "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM". 305 This utilizes a new principal name type, as the KDC-REQ message only 306 contains a single client realm field, and the realm portion of this 307 name corresponds to the Kerberos realm with which the request is 308 made. Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a 309 single component in the client name field of the AS-REQ message, with 310 a name type of NT-ENTERPRISE [RFC4120] (and the local realm name). 311 The KDC will recognize this name type and then transform the 312 requested name into the true principal name if the client account 313 resides in the local realm. The true principal name can have a name 314 type different from the requested name type. Typically the true 315 principal name will be a NT-PRINCIPAL [RFC4120]. 317 6. Name Canonicalization 319 A service or account may have multiple principal names. For example, 320 if a host is known by multiple names, host-based services on it may 321 be known by multiple names in order to prevent the client from 322 needing a secure directory service to determine the correct hostname 323 to use. In order that the host should not need to be updated 324 whenever a new alias is created, the KDC may provide the mapping 325 information to the client in the credential acquisition process. 327 If the "canonicalize" KDC option is set, then the KDC MAY change the 328 client and server principal names and types in the AS response and 329 ticket returned from the name type of the client name in the request. 331 In a TGS exchange, the server principal name and type may be changed. 333 For example the AS request may specify a client name of "bob@ 334 EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC 335 option set and the KDC will return with a client name of "104567" as 336 a NT-UID. 338 (It is assumed that the client discovers whether the KDC supports the 339 NT-ENTERPRISE name type via out of band mechanisms.) 341 See Section 11 for a mechanism to detect modification of the request 342 between the client and KDC. However for best protection, Flexible 343 Authentication through Secure Tunneling (FAST) 344 [I-D.ietf-krb-wg-preauth-framework] or another mechanism that 345 protects the entire KDC exchange SHOULD be used. Clients MAY reject 346 responses from a KDC where the client or server name is changed if 347 the KDC does not support such a mechanism. Clients SHOULD reject an 348 AS response that changes the server name unless the response is 349 protected by such a mechanism or the new server name is one 350 explicitly expected by the client. For example, many clients permit 351 the realm name to be changed in an AS response even if the response 352 is not protected. See Section 15 for a discussion of the tradeoffs 353 in allowing unprotected responses. 355 In order to enable one party in a user-to-user exchange to confirm 356 the identity of another when only the alias is known, the KDC MAY 357 include the following authorization data element, wrapped in AD-KDC- 358 ISSUED, in the initial credentials and copy it from a ticket-granting 359 ticket into additional credentials: 361 AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD -- 362 login-aliases [0] SEQUENCE(1..MAX) OF PrincipalName, 363 } 365 The login-aliases field lists one or more of the aliases the 366 principal may have. 368 The recipient of this authenticator must check the AD-LOGIN-ALIAS 369 names, if present, in addition to the normal client name field, 370 against the identity of the party with which it wishes to 371 authenticate; either should be allowed to match. (Note that this is 372 not backwards compatible with [RFC4120]; if the server side of the 373 user-to-user exchange does not support this extension, and does not 374 know the true principal name, authentication may fail if the alias is 375 sought in the client name field.) 377 The use of AD-KDC-ISSUED authorization data elements in cross-realm 378 cases has not been well explored at this writing; hence we will only 379 specify the inclusion of this data in the one-realm case. The alias 380 information SHOULD be dropped in the general cross-realm case. 381 However, a realm MAY implement a policy of accepting and re-signing 382 (wrapping in a new AD-KDC-ISSUED element) alias information provided 383 by certain trusted realms, in the cross-realm ticket-granting 384 service. 386 The canonical principal name for an alias may not be in the form of a 387 ticket-granting service name, as (in a case of server name 388 canonicalization) that would be construed as a case of cross-realm 389 referral, described below. 391 7. Client Referrals 393 The simplest form of ticket referral is for a user requesting a 394 ticket using an AS-REQ. In this case, the client machine will send 395 the AS-REQ to a convenient realm trusted to map principals, for 396 example the realm of the client machine. In the case of the name 397 alice@EXAMPLE.COM, the client MAY optimistically choose to send the 398 request to EXAMPLE.COM. The realm in the AS-REQ is always the name 399 of the realm that the request is for as specified in [RFC4120]. 401 The KDC will try to lookup the name in its local account database. 402 If the account is present in the realm of the request, it SHOULD 403 return a KDC reply structure with the appropriate ticket. 405 If the account is not present in the realm specified in the request 406 and the "canonicalize" KDC option is set, the KDC may look up the 407 client principal name using some kind of name service or directory 408 service. If this lookup is unsuccessful, it MUST return the error 409 KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful, 410 it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the 411 error message the crealm field will contain either the true realm of 412 the client or another realm that MAY have better information about 413 the client's true realm. The client MUST NOT use the cname returned 414 in this error message. 416 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 417 new AS request with the same client principal name used to generate 418 the first referral to the realm specified by the realm field of the 419 Kerberos error message corresponding to the first request. (The 420 client realm name will be updated in the new request to refer to this 421 new realm.) The client SHOULD repeat these steps until it finds the 422 true realm of the client. To avoid infinite referral loops, an 423 implementation should limit the number of referrals. A suggested 424 limit is 5 referrals before giving up. 426 Since the same client name is sent to the referring and referred-to 427 realms, both realms must recognize the same client names. In 428 particular, the referring realm cannot (usefully) define principal 429 name aliases that the referred-to realm will not know. 431 The true principal name of the client, returned in AS-REQ, can be 432 validated in a subsequent TGS message exchange where its value is 433 communicated back to the KDC via the authenticator in the PA-TGS-REQ 434 padata [RFC4120]. However, this requires trusting the referred-to 435 realm's KDCs. Clients should limit the referral mappings they will 436 accept to realms trusted via some local policy. Some possible 437 factors that might be taken into consideration for such a policy 438 might include: 440 o Any realm indicated by the local KDC, if the returned KRB-ERROR 441 message is protected by some additional means, for example FAST 442 o A list of realms configured by an administrator 443 o Any realm accepted by the user when explicitly prompted 445 There is currently no provision for changing the client name in a 446 client referral response, because there is no method for verifying 447 that a man-in-the-middle attack did not change the requested name in 448 the request on the way to the KDC. 450 8. Server Referrals 452 The primary difference in server referrals is that the KDC returns a 453 referral TGT rather than an error message as is done in the client 454 referrals. There needs to be a place to include in the reply 455 information about what realm contains the server; this is done by 456 returning information about the server name in the pre-authentication 457 data field of the KDC reply [RFC4120], as specified later in this 458 section. 460 If the "canonicalize" flag in the KDC options is set and the KDC 461 doesn't find the principal locally, either as a regular principal or 462 as an alias for another local principal, the KDC MAY return a cross- 463 realm ticket granting ticket to the next hop on the trust path 464 towards a realm that may be able to resolve the principal name. The 465 true principal name of the server SHALL be returned in the padata of 466 the reply if it is different from what is specified the request. 468 The client will use this referral information to request a chain of 469 cross-realm ticket granting tickets until it reaches the realm of the 470 server, and can then expect to receive a valid service ticket. 472 However an implementation should limit the number of referrals that 473 it processes to avoid infinite referral loops. A suggested limit is 474 5 referrals before giving up. 476 The client may cache the mapping of the requested name to the name of 477 the next realm to use and the principal name to ask for. (See 478 Section 10.) 480 Here is an example of a client requesting a service ticket for a 481 service in realm DEV.EXAMPLE.COM where the client is in 482 ADMIN.EXAMPLE.COM. 484 +NC = Canonicalize KDCOption set 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 487 C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM 488 S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM 489 C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM 490 S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM 492 Note that any referral or alias processing of the server name in 493 user-to-user authentication should use the same data as client name 494 canonicalization or referral. Otherwise, the name used by one user 495 to log in may not be useable by another for user-to-user 496 authentication to the first. 498 9. Cross Realm Routing 500 RFC 4120 permits a KDC to return a closer referral ticket when a 501 cross-realm TGT is requested. This specification extends this 502 behavior when the canonicalize flag is set. When this flag is set, a 503 KDC MAY return a TGT for a realm closer to the service for any 504 service. XXX What should go in the realm field of the request to the 505 next realm? 507 10. Caching Information 509 It is possible that the client may wish to get additional credentials 510 for the same service principal, perhaps with different authorization- 511 data restrictions or other changed attributes. The return of a 512 server referral from a KDC can be taken as an indication that the 513 requested principal does not currently exist in the local realm. 514 Clearly, it would reduce network traffic if the clients could cache 515 that information and use it when acquiring the second set of 516 credentials for a service, rather than always having to re-check with 517 the local KDC to see if the name has been created locally. 519 When the TGT expires, the previously returned referral from the local 520 KDC should be considered invalid, and the local KDC must be asked 521 again for information for the desired service principal name. (Note 522 that the client may get back multiple referral TGTs from the local 523 KDC to the same remote realm, with different lifetimes. The lifetime 524 information SHOULD be properly associated with the requested service 525 principal names. Simply having another TGT for the same remote realm 526 does not extend the validity of previously acquired information about 527 one service principal name.) 529 Accordingly, KDC authors and maintainers should consider what factors 530 (e.g., DNS alias lifetimes) they may or may not wish to incorporate 531 into credential expiration times in cases of referrals. 533 11. Negotiation of FAST and Detecting Modified Requests 535 Implementations of this specification MUST support the FAST 536 negotiation mechanism described in this section. This mechanism 537 provides detection of KDC requests modified by an attacker when those 538 requests result in a reply instead of an error. In addition, this 539 mechanism provides a secure way to detect if a KDC supports FAST. 541 Clients conforming to this specification MUST send a new pre- 542 authentication data of type PA-REQ-ENC-PA-REP (TBD1) in all AS 543 requests and MAY send this padata type in TGS requests. The value of 544 this padata item SHOULD be empty and MUST be ignored by a receiving 545 KDC. Sending this padata item indicates support for this negotiation 546 mechanism. KDCs conforming to this specification must always set the 547 ticket flag enc-pa-rep(15) in all the issued tickets. This ticket 548 flag indicates KDC support for the mechanism. 550 The KDC response is extended to support an additional field 551 containing encrypted pre-authentication data. 553 EncKDCRepPart ::= SEQUENCE { 554 key [0] EncryptionKey, 555 last-req [1] LastReq, 556 nonce [2] UInt32, 557 key-expiration [3] KerberosTime OPTIONAL, 558 flags [4] TicketFlags, 559 authtime [5] KerberosTime, 560 starttime [6] KerberosTime OPTIONAL, 561 endtime [7] KerberosTime, 562 renew-till [8] KerberosTime OPTIONAL, 563 srealm [9] Realm, 564 sname [10] PrincipalName, 565 caddr [11] HostAddresses OPTIONAL, 566 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 567 } 569 The The encrypted-pa-data element MUST be absent unless either the 570 canonicalize KDC option is set or the PA-REQ-ENC-PA-REP padata item 571 is sent. 573 If the PA-REQ-ENC-PA-REP padata item is sent in the request, then the 574 KDC MUST include a PA-REQ-ENC-PA-REP padata item in the encrypted-pa- 575 data item of any generated KDC reply. The PA-REQ-ENC-PA-REP pa-data 576 value contains the checksum computed over the type AS-REQ or TGS-REQ 577 in the request. The checksum key is the reply key and the checksum 578 type is the required checksum type for the encryption type of the 579 reply key, and the key usage number is KEY_USAGE_AS_REQ (56). If the 580 KDC supports FAST, then the KDC MUST include a padata of type PA-FX- 581 FAST in any encrypted-pa-data sequence it generates. The value for 582 this padata item should be empty. 584 A client MUST reject a response for which it sent PA-REQ-ENC-PA-REP 585 if the ENC-PA-REP ticket flag is set and the PA-REQ-ENC-PA-REP padata 586 item is absent or the checksum is not successfully verified. 588 12. Open Issues 590 When should client name aliases be included in credentials? Should 591 all known client name aliases be included, or only the one used at 592 initial ticket acquisition? 594 13. Number Assignments 596 Most number registries in the Kerberos protocol have not been turned 597 over to IANA for management at the time of this writing, hence this 598 is not an "IANA Considerations" section. 600 Various values do need assigning for this draft: 601 AD-LOGIN-ALIAS 603 14. IANA Considerations 605 In the Kerberos pre-authentication and typed data registry at http:// 606 www.iana.org/assignments/kerberos-parameters/ 607 kerberos-parameters.xhtml#pre-authentication, the PA-REQ-ENC-PA-REP 608 pa-data item should be registered. Because of existing 609 implementations the value 149 is strongly preferred. 611 15. Security Considerations 613 For the AS exchange case, it is important that the logon mechanism 614 not trust a name that has not been used to authenticate the user. 615 For example, the name that the user enters as part of a logon 616 exchange may not be the name that the user authenticates as, given 617 that the KDC_ERR_WRONG_REALM error may have been returned. The 618 relevant Kerberos naming information for logon (if any), is the 619 client name and client realm in the service ticket targeted at the 620 workstation that was obtained using the user's initial TGT. That is, 621 rather than trusting the client name in the AS response, a 622 workstation SHOULD perform an AP-REQ authentication against itself as 623 a service and use the client name in the ticket issued for its 624 service by the KDC. 626 How the client name and client realm is mapped into a local account 627 for logon is a local matter, but the client logon mechanism MUST use 628 additional information such as the client realm and/or authorization 629 attributes from the service ticket presented to the workstation by 630 the user, when mapping the logon credentials to a local account on 631 the workstation. 633 Not all fields in an RFC 4120 KDC reply are protected. None of the 634 fields in an RFC 4120 AS request are protected and some information 635 in a TGS request may not be protected. The referrals mechanism 636 creates several opportunities for attack because of these unprotected 637 fields. FAST [I-D.ietf-krb-wg-preauth-framework] can be used to 638 completely mitigate these issues by protecting both the KDC request 639 and response. However, FAST requires that a client obtain an armor 640 ticket before authenticating. Not all realms permit all clients to 641 obtain armor tickets. Also, while it is expected to be uncommon, a 642 client might wish to use name canonicalization while obtaining an 643 armor ticket. The mechanism in Section 11 detects modification of 644 the request between the KDC and client, mitigating some attacks. 646 There is a wide deployed base of implementations that use name 647 canonicalization or server referrals that uses neither the 648 negotiation mechanism nor FAST. So, implementations may be faced 649 with only the limited protection afforded by RFC 4120, by the 650 negotiation mechanism discussed in this document, or by FAST. All 651 three situations are important to consider from a security 652 standpoint. 654 An attacker cannot mount a downgrade attack against a client. The 655 negotiation mechanism described in this document is securely 656 indicated by the presence of a ticket flag. So, a client will detect 657 if the facility was available but not used. It is possible for an 658 attacker to strip the indication that a client supports the 659 negotiation facility. The client will learn from the response that 660 this happened, but the KDC will not learn that the client is 661 attacked. So, for a single round-trip Kerberos exchange, the KDC may 662 believe the exchange was successful when the client detects an 663 attack. Packet loss or client failure can produce a similar result; 664 this is not a significant vulnerability. The negotiation facility 665 described in this document securely indicates the presence of FAST, 666 so if a client wishes to use FAST when it is available, an attacker 667 cannot force the client to downgrade away from FAST. An attacker MAY 668 be able to prevent a client from obtaining an armor ticket, for 669 example by responding to a request for anonymous PKINIT with an error 670 response. 672 If FAST is used, then the communications between the client and KDC 673 are protected. However name canonicalization places a new 674 responsibility for mapping principals onto the KDC. This can 675 increase the number of KDCs involved in an authentication which adds 676 additional trusted third parties to the exchange. 678 If only the negotiation mechanism is used, then the request from the 679 client to the KDC is protected, but not all of the response is 680 protected. In particular, the client name is not protected; the 681 ticket is also not protected. An attacker can potentially modify 682 these fields. Modification of the client name will result in a 683 denial of service. When the client attempts to authenticate to a 684 service (including the TGS), it constructs an AP-REQ message. This 685 message includes a client name which MUST match the client name in 686 the ticket according to RFC 4120. Thus if the client name is 687 changed, the resulting ticket will fail when used. This is 688 undesirable because the authentication is separated from the later 689 failure, which may confuse problem determination. If the ticket is 690 replaced with another ticket, then later authentication to a service 691 will fail because the client will not know the session key for the 692 other ticket. If the ticket is simply modified, then authentication 693 to a service will fail as with RFC 4120. More significant attacks 694 are possible if a KDC violates the requirements of RFC 4120 and 695 issues two tickets with the same session key or if a service violates 696 the requirements of RFC 4120 and does not check the client name 697 against that in the ticket. 699 There is an additional attack possible when FAST is not used against 700 KDC_ERR_WRONG_REALM. Since this is an error response not an AS 701 response, it is not protected by the negotiation mechanism. Thus, an 702 attacker may be able to convince a client to authenticate to a realm 703 other than the one intended. If an attacker is off-path this may 704 give the attacker an advantage in attacking the client's credentials. 705 Also, see the discussion of shared passwords below. 707 More serious attacks are possible if no protection beyond RFC 4120 is 708 used. In this case, neither the client name nor the service name is 709 protected between the client and KDC. In the general case, if an 710 attacker changes the client name, then authentication will fail 711 because the client will not have the right credentials (password, 712 certificate , or other) to authenticate as the user selected by the 713 attacker. However, see the discussion of shared passwords below. 714 Changing the server name can be a very significant attack. For 715 example if a user is authenticating in order to send some 716 confidential information, then the attacker could gain this 717 information by directing the user to a server under the attacker's 718 control. The server name in the response is protected by RFC 4120, 719 but not the one in the request. Fortunately, users are typically 720 authenticating to the "krbtgt" service in an AS exchange. Clients 721 that permit changes to the server name when no protection beyond RFC 722 4120 is in use SHOULD carefully restrict what service names are 723 acceptable. One critical case to consider is the password changing 724 service. When a user authenticates to change their password they use 725 an AS authentication directly to the password changing service. 726 Clients MUST restrict service name changes sufficiently that the 727 client ends up talking to the correct password changing service. 729 15.1. Shared-password case 731 A special case to examine is when the user is known (or correctly 732 suspected) to use the same password for multiple accounts. A man-in- 733 the-middle attacker can either alter the request on its way to the 734 KDC, changing the client principal name, or reply to the client with 735 a response previously send by the KDC in response to a request from 736 the attacker. The response received by the client can then be 737 decrypted by the user, though if the default "salt" generated from 738 the principal name is used to produce the user's key, a PA-ETYPE-INFO 739 or PA-ETYPE-INFO2 preauth record may need to be added or altered by 740 the attacker to cause the client software to generate the key needed 741 for the message it will receive. None of this requires the attacker 742 to know the user's password, and without further checking, could 743 cause the user to unknowingly use the wrong credentials. 745 In normal [RFC4120] operation, a generated AP-REQ message includes in 746 the Authenticator field a copy of the client's idea of its own 747 principal name. If this differs from the name in the KDC-generated 748 Ticket, the application server will reject the message. 750 With client name canonicalization as described in this document, the 751 client may get its principal name from the response from the KDC. 752 Using the wrong credentials may provide an advantage to an attacker. 753 For example if a client uses one principal for administrative 754 operations and one for less privileged operation, an attacker may 755 coerce a client into using the wrong privilege to either cause some 756 later operation to succeed or fail. 758 15.2. Preauthentication data 760 In cases of credential renewal, forwarding, or validation, if 761 credentials are sent to the KDC that are not an initial ticket- 762 granting ticket for the client's home realm, the encryption key used 763 to protect the TGS exchange is one known to a third party (namely, 764 the service for which the credential was issued). Consequently, in 765 such an exchange, the protection described earlier may be compromised 766 by the service. This is not generally believed to be a problem. If 767 it is, some form of explicit TGS armor could be added to FAST. 769 16. Acknowledgments 771 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 772 version of this document. 774 Karthik Jaganathan contributed to earlier versions. 776 Sam Hartman's work on this document was funded by the MIT Kerberos 777 Consortium. 779 17. References 781 17.1. Normative References 783 [I-D.ietf-krb-wg-preauth-framework] 784 Hartman, S. and L. Zhu, "A Generalized Framework for 785 Kerberos Pre-Authentication", 786 draft-ietf-krb-wg-preauth-framework-17 (work in progress), 787 June 2010. 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, March 1997. 792 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 793 Kerberos Network Authentication Service (V5)", RFC 4120, 794 July 2005. 796 17.2. Informative References 798 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 799 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 801 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 802 Housley, R., and W. Polk, "Internet X.509 Public Key 803 Infrastructure Certificate and Certificate Revocation List 804 (CRL) Profile", RFC 5280, May 2008. 806 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation 807 of Crossrealm Referral Handling in the MIT Kerberos 808 Client", Network and Distributed System Security 809 Symposium, February 2001. 811 Appendix A. Compatibility with Earlier Implementations of Name 812 Canonicalization 814 The Microsoft Windows 2000 and Windows 2003 releases included an 815 earlier form of name-canonicalization [XPR]. Here are the 816 differences: 818 2) The preauth data type definition in the encrypted preauth data is 819 as follows: 821 PA-SVR-REFERRAL-INFO 20 823 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 824 referred-name [1] PrincipalName OPTIONAL, 825 referred-realm [0] Realm 826 }} 828 3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is 829 encoded as a Subject Alternative Name (SAN) extension [RFC5280] in 830 the client's X.509 certificate. The type of the otherName field 831 for this SAN extension is AnotherName [RFC5280]. The type-id 832 field of the type AnotherName is id-ms-sc-logon-upn 833 (1.3.6.1.4.1.311.20.2.3) and the value field of the type 834 AnotherName is a KerberosString [RFC4120]. The value of this 835 KerberosString type is the single component in the name-string 836 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 838 In Microsoft's current implementation through the use of global 839 catalogs any domain in one forest is reachable from any other domain 840 in the same forest or another trusted forest with 3 or less 841 referrals. A forest is a collection of realms with hierarchical 842 trust relationships: there can be multiple trust trees in a forest; 843 each child and parent realm pair and each root realm pair have 844 bidirectional transitive direct rusts between them. 846 While we might want to permit multiple aliases to exist and even be 847 reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only 848 one NT-ENTERPRISE alias to exist, so this question had not previously 849 arisen. 851 Appendix B. Document history [REMOVE BEFORE PUBLICATION] 853 12 Refactor to take advantage of FAST and new protected negotiation 854 mechanism instead of providing our own. Simplify significantly 855 based on this. Remove the true principal name support for now 856 pending discussion in the WG. Add the new protected negotiation 857 mechanism. 858 11 Changed title. Better protection on server referral preauth data. 859 Support server name canonicalization. Rename ReferralInfo to 860 ClientReferralInfo. Disallow alias mapping to a TGT principal. 861 Explain why no name change in client referrals. Add empty IANA 862 Considerations. Add some notes on preauth data protection during 863 renewal etc. 864 10 Separate enterprise principal names into a separate section. Add 865 a little wording to suggest server principal name canonicalization 866 might be allowed; not fleshed out. Advise against AD-KDC-ISSUED 867 in cronn-realm cases. Advise policy checks on returned client 868 referral info, since there's no security. List number 869 assignments. Add security analysis of shared-password case. No 870 longer plan to remove Microsoft appendix. Add referral-valid- 871 until field. 872 09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain. 873 Rewrote description of existing practice. (Don't name the lookup 874 table consulted. Mention that DNS "canonicalization" is contrary 875 to [RFC4120].) Noted Microsoft behavior should be moved out into 876 a separate document. Changed some second-person references in the 877 introduction to identify the proper parties. Changed PA-CLIENT- 878 CANONICALIZED to use a separate type for the actual referral data, 879 add an extension marker to that type, and change the checksum key 880 from the "returned session key" to the "AS reply key". Changed 881 AD-LOGIN-ALIAS to contain a sequence of names, to be contained in 882 AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer 883 needed separate checksum. Attempt to clarify the cache lifetime 884 of referral information. 885 08 Moved Microsoft implementation info to appendix. Clarify lack of 886 local server name canonicalization. Added optional authz-data for 887 login alias, to support user-to-user case. Added requested- 888 principal-name to ServerReferralData. Added discussion of caching 889 information, and referral TGT lifetime. 890 07 Re-issued with new editor. Fixed up some references. Started 891 history. 893 Authors' Addresses 895 Sam hartman (editor) 896 Painless Security 898 Email: hartmans-ietf@mit.edu 900 Kenneth Raeburn 901 Massachusetts Institute of Technology 903 Email: raeburn@mit.edu 905 Larry Zhu 906 Microsoft Corporation 907 One Microsoft Way 908 Redmond, WA 98052 909 US 911 Email: lzhu@microsoft.com