idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-14.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 (March 12, 2012) is 4422 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 792 -- Looks like a reference, but probably isn't: '1' on line 791 -- Looks like a reference, but probably isn't: '2' on line 540 -- Looks like a reference, but probably isn't: '3' on line 541 -- Looks like a reference, but probably isn't: '4' on line 542 -- Looks like a reference, but probably isn't: '5' on line 543 -- Looks like a reference, but probably isn't: '6' on line 544 -- Looks like a reference, but probably isn't: '7' on line 545 -- Looks like a reference, but probably isn't: '8' on line 546 -- Looks like a reference, but probably isn't: '9' on line 547 -- Looks like a reference, but probably isn't: '10' on line 548 -- Looks like a reference, but probably isn't: '11' on line 549 -- Looks like a reference, but probably isn't: '12' on line 550 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: September 13, 2012 L. Zhu 7 Microsoft Corporation 8 March 12, 2012 10 Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm 11 Referrals 12 draft-ietf-krb-wg-kerberos-referrals-14 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 September 13, 2012. 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 . . . . . 12 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 13.1. Shared-password case . . . . . . . . . . . . . . . . . . . 16 88 13.2. Preauthentication data . . . . . . . . . . . . . . . . . . 17 89 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 15.1. Normative References . . . . . . . . . . . . . . . . . . . 17 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. 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 alias 371 information SHOULD be dropped in the general cross-realm case. 372 However, a realm MAY implement a policy of accepting and re-signing 373 (wrapping in a new AD-KDC-ISSUED element) alias information provided 374 by certain trusted realms, in the cross-realm ticket-granting 375 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 referral 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 There is currently no provision for changing the client name in a 437 client referral response. 439 8. Server Referrals 441 The primary difference in server referrals is that the KDC returns a 442 referral TGT rather than an error message as is done in the client 443 referrals. 445 If the "canonicalize" flag in the KDC options is set and the KDC 446 doesn't find the principal locally, either as a regular principal or 447 as an alias for another local principal, the KDC MAY return a cross- 448 realm ticket granting ticket to the next hop on the trust path 449 towards a realm that may be able to resolve the principal name. 451 The client will use this referral information to request a chain of 452 cross-realm ticket granting tickets until it reaches the realm of the 453 server, and can then expect to receive a valid service ticket. 455 However an implementation should limit the number of referrals that 456 it processes to avoid infinite referral loops. A suggested limit is 457 5 referrals before giving up. 459 The client may cache the mapping of the requested name to the name of 460 the next realm to use and the principal name to ask for. (See 461 Section 10.) 463 Here is an example of a client requesting a service ticket for a 464 service in realm DEV.EXAMPLE.COM where the client is in 465 ADMIN.EXAMPLE.COM. 467 +NC = Canonicalize KDCOption set 468 C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM 469 S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM 470 C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM 471 S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM 472 C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM 473 S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM 475 Note that any referral or alias processing of the server name in 476 user-to-user authentication should use the same data as client name 477 canonicalization or referral. Otherwise, the name used by one user 478 to log in may not be useable by another for user-to-user 479 authentication to the first. 481 9. Cross Realm Routing 483 RFC 4120 permits a KDC to return a closer referral ticket when a 484 cross-realm TGT is requested. This specification extends this 485 behavior when the canonicalize flag is set. When this flag is set, a 486 KDC MAY return a TGT for a realm closer to the service for any 487 service as discussed in the previous section. When a client follows 488 such a referral, it including the realm of the referred-to realm in 489 the generated request. 491 10. Caching Information 493 It is possible that the client may wish to get additional credentials 494 for the same service principal, perhaps with different authorization- 495 data restrictions or other changed attributes. The return of a 496 server referral from a KDC can be taken as an indication that the 497 requested principal does not currently exist in the local realm. 498 Clearly, it would reduce network traffic if the clients could cache 499 that information and use it when acquiring the second set of 500 credentials for a service, rather than always having to re-check with 501 the local KDC to see if the name has been created locally. 503 When the TGT expires, the previously returned referral from the local 504 KDC should be considered invalid, and the local KDC must be asked 505 again for information for the desired service principal name. (Note 506 that the client may get back multiple referral TGTs from the local 507 KDC to the same remote realm, with different lifetimes. The lifetime 508 information SHOULD be properly associated with the requested service 509 principal names. Simply having another TGT for the same remote realm 510 does not extend the validity of previously acquired information about 511 one service principal name.) 513 Accordingly, KDC authors and maintainers should consider what factors 514 (e.g., DNS alias lifetimes) they may or may not wish to incorporate 515 into credential expiration times in cases of referrals. 517 11. Negotiation of FAST and Detecting Modified Requests 519 Implementations of this specification MUST support the FAST 520 negotiation mechanism described in this section. This mechanism 521 provides detection of KDC requests modified by an attacker when those 522 requests result in a reply instead of an error. In addition, this 523 mechanism provides a secure way to detect if a KDC supports FAST. 525 Clients conforming to this specification MUST send a new pre- 526 authentication data of type PA-REQ-ENC-PA-REP (TBD1) in all AS 527 requests and MAY send this padata type in TGS requests. The value of 528 this padata item SHOULD be empty and MUST be ignored by a receiving 529 KDC. Sending this padata item indicates support for this negotiation 530 mechanism. KDCs conforming to this specification must always set the 531 ticket flag enc-pa-rep(15) in all the issued tickets. This ticket 532 flag indicates KDC support for the mechanism. 534 The KDC response is extended to support an additional field 535 containing encrypted pre-authentication data. 537 EncKDCRepPart ::= SEQUENCE { 538 key [0] EncryptionKey, 539 last-req [1] LastReq, 540 nonce [2] UInt32, 541 key-expiration [3] KerberosTime OPTIONAL, 542 flags [4] TicketFlags, 543 authtime [5] KerberosTime, 544 starttime [6] KerberosTime OPTIONAL, 545 endtime [7] KerberosTime, 546 renew-till [8] KerberosTime OPTIONAL, 547 srealm [9] Realm, 548 sname [10] PrincipalName, 549 caddr [11] HostAddresses OPTIONAL, 550 encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL 551 } 553 The The encrypted-pa-data element MUST be absent unless either the 554 canonicalize KDC option is set or the PA-REQ-ENC-PA-REP padata item 555 is sent. 557 If the PA-REQ-ENC-PA-REP padata item is sent in the request, then the 558 KDC MUST include a PA-REQ-ENC-PA-REP padata item in the encrypted-pa- 559 data item of any generated KDC reply. The PA-REQ-ENC-PA-REP pa-data 560 value contains the checksum computed over the type AS-REQ or TGS-REQ 561 in the request. The checksum key is the reply key and the checksum 562 type is the required checksum type for the encryption type of the 563 reply key, and the key usage number is KEY_USAGE_AS_REQ (56). If the 564 KDC supports FAST, then the KDC MUST include a padata of type PA-FX- 565 FAST in any encrypted-pa-data sequence it generates. The value for 566 this padata item should be empty. 568 A client MUST reject a response for which it sent PA-REQ-ENC-PA-REP 569 if the ENC-PA-REP ticket flag is set and the PA-REQ-ENC-PA-REP padata 570 item is absent or the checksum is not successfully verified. 572 12. IANA Considerations 574 In the Kerberos pre-authentication and typed data registry at http:// 575 www.iana.org/assignments/kerberos-parameters/ 576 kerberos-parameters.xhtml#pre-authentication, the PA-REQ-ENC-PA-REP 577 pa-data item should be registered. Because of existing 578 implementations the value 149 is strongly preferred. 580 13. Security Considerations 582 For the AS exchange case, it is important that the logon mechanism 583 not trust a name that has not been used to authenticate the user. 584 For example, the name that the user enters as part of a logon 585 exchange may not be the name that the user authenticates as, given 586 that the KDC_ERR_WRONG_REALM error may have been returned. The 587 relevant Kerberos naming information for logon (if any), is the 588 client name and client realm in the service ticket targeted at the 589 workstation that was obtained using the user's initial TGT. That is, 590 rather than trusting the client name in the AS response, a 591 workstation SHOULD perform an AP-REQ authentication against itself as 592 a service and use the client name in the ticket issued for its 593 service by the KDC. 595 How the client name and client realm is mapped into a local account 596 for logon is a local matter, but the client logon mechanism MUST use 597 additional information such as the client realm and/or authorization 598 attributes from the service ticket presented to the workstation by 599 the user, when mapping the logon credentials to a local account on 600 the workstation. 602 Not all fields in an RFC 4120 KDC reply are protected. None of the 603 fields in an RFC 4120 AS request are protected and some information 604 in a TGS request may not be protected. The referrals mechanism 605 creates several opportunities for attack because of these unprotected 606 fields. FAST [RFC6113] can be used to completely mitigate these 607 issues by protecting both the KDC request and response. However, 608 FAST requires that a client obtain an armor ticket before 609 authenticating. Not all realms permit all clients to obtain armor 610 tickets. Also, while it is expected to be uncommon, a client might 611 wish to use name canonicalization while obtaining an armor ticket. 612 The mechanism in Section 11 detects modification of the request 613 between the KDC and client, mitigating some attacks. 615 There is a wide deployed base of implementations that use name 616 canonicalization or server referrals that uses neither the 617 negotiation mechanism nor FAST. So, implementations may be faced 618 with only the limited protection afforded by RFC 4120, by the 619 negotiation mechanism discussed in this document, or by FAST. All 620 three situations are important to consider from a security 621 standpoint. 623 An attacker cannot mount a downgrade attack against a client. The 624 negotiation mechanism described in this document is securely 625 indicated by the presence of a ticket flag. So, a client will detect 626 if the facility was available but not used. It is possible for an 627 attacker to strip the indication that a client supports the 628 negotiation facility. The client will learn from the response that 629 this happened, but the KDC will not learn that the client is 630 attacked. So, for a single round-trip Kerberos exchange, the KDC may 631 believe the exchange was successful when the client detects an 632 attack. Packet loss or client failure can produce a similar result; 633 this is not a significant vulnerability. The negotiation facility 634 described in this document securely indicates the presence of FAST, 635 so if a client wishes to use FAST when it is available, an attacker 636 cannot force the client to downgrade away from FAST. An attacker MAY 637 be able to prevent a client from obtaining an armor ticket, for 638 example by responding to a request for anonymous PKINIT with an error 639 response. 641 If FAST is used, then the communications between the client and KDC 642 are protected. However name canonicalization places a new 643 responsibility for mapping principals onto the KDC. This can 644 increase the number of KDCs involved in an authentication which adds 645 additional trusted third parties to the exchange. 647 If only the negotiation mechanism is used, then the request from the 648 client to the KDC is protected, but not all of the response is 649 protected. In particular, the client name is not protected; the 650 ticket is also not protected. An attacker can potentially modify 651 these fields. Modification of the client name will result in a 652 denial of service. When the client attempts to authenticate to a 653 service (including the TGS), it constructs an AP-REQ message. This 654 message includes a client name which MUST match the client name in 655 the ticket according to RFC 4120. Thus if the client name is 656 changed, the resulting ticket will fail when used. This is 657 undesirable because the authentication is separated from the later 658 failure, which may confuse problem determination. If the ticket is 659 replaced with another ticket, then later authentication to a service 660 will fail because the client will not know the session key for the 661 other ticket. If the ticket is simply modified, then authentication 662 to a service will fail as with RFC 4120. More significant attacks 663 are possible if a KDC violates the requirements of RFC 4120 and 664 issues two tickets with the same session key or if a service violates 665 the requirements of RFC 4120 and does not check the client name 666 against that in the ticket. 668 There is an additional attack possible when FAST is not used against 669 KDC_ERR_WRONG_REALM. Since this is an error response not an AS 670 response, it is not protected by the negotiation mechanism. Thus, an 671 attacker may be able to convince a client to authenticate to a realm 672 other than the one intended. If an attacker is off-path this may 673 give the attacker an advantage in attacking the client's credentials. 674 Also, see the discussion of shared passwords below. 676 More serious attacks are possible if no protection beyond RFC 4120 is 677 used. In this case, neither the client name nor the service name is 678 protected between the client and KDC. In the general case, if an 679 attacker changes the client name, then authentication will fail 680 because the client will not have the right credentials (password, 681 certificate , or other) to authenticate as the user selected by the 682 attacker. However, see the discussion of shared passwords below. 683 Changing the server name can be a very significant attack. For 684 example if a user is authenticating in order to send some 685 confidential information, then the attacker could gain this 686 information by directing the user to a server under the attacker's 687 control. The server name in the response is protected by RFC 4120, 688 but not the one in the request. Fortunately, users are typically 689 authenticating to the "krbtgt" service in an AS exchange. Clients 690 that permit changes to the server name when no protection beyond RFC 691 4120 is in use SHOULD carefully restrict what service names are 692 acceptable. One critical case to consider is the password changing 693 service. When a user authenticates to change their password they use 694 an AS authentication directly to the password changing service. 695 Clients MUST restrict service name changes sufficiently that the 696 client ends up talking to the correct password changing service. 698 13.1. Shared-password case 700 A special case to examine is when the user is known (or correctly 701 suspected) to use the same password for multiple accounts. A man-in- 702 the-middle attacker can either alter the request on its way to the 703 KDC, changing the client principal name, or reply to the client with 704 a response previously send by the KDC in response to a request from 705 the attacker. The response received by the client can then be 706 decrypted by the user, though if the default "salt" generated from 707 the principal name is used to produce the user's key, a PA-ETYPE-INFO 708 or PA-ETYPE-INFO2 preauth record may need to be added or altered by 709 the attacker to cause the client software to generate the key needed 710 for the message it will receive. None of this requires the attacker 711 to know the user's password, and without further checking, could 712 cause the user to unknowingly use the wrong credentials. 714 In normal [RFC4120] operation, a generated AP-REQ message includes in 715 the Authenticator field a copy of the client's idea of its own 716 principal name. If this differs from the name in the KDC-generated 717 Ticket, the application server will reject the message. 719 With client name canonicalization as described in this document, the 720 client may get its principal name from the response from the KDC. 721 Using the wrong credentials may provide an advantage to an attacker. 722 For example if a client uses one principal for administrative 723 operations and one for less privileged operation, an attacker may 724 coerce a client into using the wrong privilege to either cause some 725 later operation to succeed or fail. 727 13.2. Preauthentication data 729 In cases of credential renewal, forwarding, or validation, if 730 credentials are sent to the KDC that are not an initial ticket- 731 granting ticket for the client's home realm, the encryption key used 732 to protect the TGS exchange is one known to a third party (namely, 733 the service for which the credential was issued). Consequently, in 734 such an exchange, the protection described earlier may be compromised 735 by the service. This is not generally believed to be a problem. If 736 it is, some form of explicit TGS armor could be added to FAST. 738 14. Acknowledgments 740 John Brezak, Mike Swift, and Jonathan Trostle wrote the initial 741 version of this document. 743 Karthik Jaganathan contributed to earlier versions. 745 Sam Hartman's work on this document was funded by the MIT Kerberos 746 Consortium. 748 15. References 750 15.1. Normative References 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, March 1997. 755 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 756 Kerberos Network Authentication Service (V5)", RFC 4120, 757 July 2005. 759 [RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for 760 Kerberos Pre-Authentication", RFC 6113, April 2011. 762 15.2. Informative References 764 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 765 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 767 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 768 Housley, R., and W. Polk, "Internet X.509 Public Key 769 Infrastructure Certificate and Certificate Revocation List 770 (CRL) Profile", RFC 5280, May 2008. 772 [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation 773 of Crossrealm Referral Handling in the MIT Kerberos 774 Client", Network and Distributed System Security 775 Symposium, February 2001. 777 Appendix A. Compatibility with Earlier Implementations of Name 778 Canonicalization 780 The Microsoft Windows 2000 and Windows 2003 releases included an 781 earlier form of name-canonicalization [XPR]. Here are the 782 differences: 784 1) Windows include an additional encrypted padata element. The 785 preauth data type definition in the encrypted preauth data is as 786 follows: 788 PA-SVR-REFERRAL-INFO 20 790 PA-SVR-REFERRAL-DATA ::= SEQUENCE { 791 referred-name [1] PrincipalName OPTIONAL, 792 referred-realm [0] Realm 793 }} 795 The referred-principal is never sent. The referred-realm is 796 included in TGS replies and includes the realm name of the 797 realm to which the client is referred. This information is 798 redundant with the realm in the second component of the 799 returned TGT. 801 2) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is 802 encoded as a Subject Alternative Name (SAN) extension [RFC5280] in 803 the client's X.509 certificate. The type of the otherName field 804 for this SAN extension is AnotherName [RFC5280]. The type-id 805 field of the type AnotherName is id-ms-sc-logon-upn 806 (1.3.6.1.4.1.311.20.2.3) and the value field of the type 807 AnotherName is a KerberosString [RFC4120]. The value of this 808 KerberosString type is the single component in the name-string 809 [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. 811 In Microsoft's current implementation through the use of global 812 catalogs any domain in one forest is reachable from any other domain 813 in the same forest or another trusted forest with 3 or less 814 referrals. A forest is a collection of realms with hierarchical 815 trust relationships: there can be multiple trust trees in a forest; 816 each child and parent realm pair and each root realm pair have 817 bidirectional transitive direct rusts between them. 819 While we might want to permit multiple aliases to exist and even be 820 reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only 821 one NT-ENTERPRISE alias to exist, so this question had not previously 822 arisen. 824 Appendix B. Document history [REMOVE BEFORE PUBLICATION] 826 13 Better reflect that we are not solving the gnuftp.raeburn.org use 827 case. Clean up other references to information in padata. Fix 828 the Microsoft appendix based on discussions with them 829 12 Refactor to take advantage of FAST and new protected negotiation 830 mechanism instead of providing our own. Simplify significantly 831 based on this. Remove the true principal name support for now 832 pending discussion in the WG. Add the new protected negotiation 833 mechanism. 834 11 Changed title. Better protection on server referral preauth data. 835 Support server name canonicalization. Rename ReferralInfo to 836 ClientReferralInfo. Disallow alias mapping to a TGT principal. 837 Explain why no name change in client referrals. Add empty IANA 838 Considerations. Add some notes on preauth data protection during 839 renewal etc. 840 10 Separate enterprise principal names into a separate section. Add 841 a little wording to suggest server principal name canonicalization 842 might be allowed; not fleshed out. Advise against AD-KDC-ISSUED 843 in cronn-realm cases. Advise policy checks on returned client 844 referral info, since there's no security. List number 845 assignments. Add security analysis of shared-password case. No 846 longer plan to remove Microsoft appendix. Add referral-valid- 847 until field. 849 09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain. 850 Rewrote description of existing practice. (Don't name the lookup 851 table consulted. Mention that DNS "canonicalization" is contrary 852 to [RFC4120].) Noted Microsoft behavior should be moved out into 853 a separate document. Changed some second-person references in the 854 introduction to identify the proper parties. Changed PA-CLIENT- 855 CANONICALIZED to use a separate type for the actual referral data, 856 add an extension marker to that type, and change the checksum key 857 from the "returned session key" to the "AS reply key". Changed 858 AD-LOGIN-ALIAS to contain a sequence of names, to be contained in 859 AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer 860 needed separate checksum. Attempt to clarify the cache lifetime 861 of referral information. 862 08 Moved Microsoft implementation info to appendix. Clarify lack of 863 local server name canonicalization. Added optional authz-data for 864 login alias, to support user-to-user case. Added requested- 865 principal-name to ServerReferralData. Added discussion of caching 866 information, and referral TGT lifetime. 867 07 Re-issued with new editor. Fixed up some references. Started 868 history. 870 Authors' Addresses 872 Sam hartman (editor) 873 Painless Security 875 Email: hartmans-ietf@mit.edu 877 Kenneth Raeburn 878 Massachusetts Institute of Technology 880 Email: raeburn@mit.edu 882 Larry Zhu 883 Microsoft Corporation 884 One Microsoft Way 885 Redmond, WA 98052 886 US 888 Email: lzhu@microsoft.com