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