idnits 2.17.1 draft-ietf-krb-wg-kerberos-referrals-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 725 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 8471 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) -- Missing reference section? '1' on line 462 looks like a reference -- Missing reference section? '2' on line 49 looks like a reference -- Missing reference section? '3' on line 176 looks like a reference -- Missing reference section? '0' on line 461 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group M. Swift 3 Internet Draft University of WA 4 Document: draft-ietf-krb-wg-kerberos-referrals-00.txt J. Brezak 5 Category: Standards Track Microsoft 6 J. Trostle 7 Cisco Systems 8 K. Raeburn 9 MIT 10 February 2001 12 Generating KDC Referrals to locate Kerberos realms 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 [1]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 1. Abstract 35 The draft documents a new method for a Kerberos Key Distribution 36 Center (KDC) to respond to client requests for kerberos tickets when 37 the client does not have detailed configuration information on the 38 realms of users or services. The KDC will handle requests for 39 principals in other realms by returning either a referral error or a 40 cross-realm TGT to another realm on the referral path. The clients 41 will use this referral information to reach the realm of the target 42 principal and then receive the ticket. 44 2. Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 48 this document are to be interpreted as described in RFC-2119 [2]. 50 3. Introduction 52 Swift Category - Standards Track 1 54 KDC Referrals February 2001 56 Current implementations of the Kerberos AS and TGS protocols, as 57 defined in RFC 1510 [3], use principal names constructed from a 58 known user or service name and realm. A service name is typically 59 constructed from a name of the service and the DNS host name of the 60 computer that is providing the service. Many existing deployments of 61 Kerberos use a single Kerberos realm where all users and services 62 would be using the same realm. However in an environment where there 63 are multiple trusted Kerberos realms, the client needs to be able to 64 determine what realm a particular user or service is in before 65 making an AS or TGS request. Traditionally this requires client 66 configuration to make this possible. 68 When having to deal with multiple trusted realms, users are forced 69 to know what realm they are in before they can obtain a ticket 70 granting ticket (TGT) with an AS request. However, in many cases the 71 user would like to use a more familiar name that is not directly 72 related to the realm of their Kerberos principal name. A good 73 example of this is an RFC-822 style email name. This document 74 describes a mechanism that would allow a user to specify a user 75 principal name that is an alias for the user's Kerberos principal 76 name. In practice this would be the name that the user specifies to 77 obtain a TGT from a Kerberos KDC. The user principal name no longer 78 has a direct relationship with the Kerberos principal or realm. Thus 79 the administrator is able to move the user's principal to other 80 realms without the user having to know that it happened. 82 Once a user has a TGT, they would like to be able to access services 83 in any trusted Kerberos realm. To do this requires that the client 84 be able to determine what realm the target service's host is in 85 before making the TGS request. Current implementations of Kerberos 86 typically have a table that maps DNS host names to corresponding 87 Kerberos realms. In order for this to work on the client, each 88 application canonicalizes the host name of the service by doing a 89 DNS lookup followed by a reverse lookup using the returned IP 90 address. The returned primary host name is then used in the 91 construction of the principal name for the target service. In order 92 for the correct realm to be added for the target host, the mapping 93 table [domain_to_realm] is consulted for the realm corresponding to 94 the DNS host name. The corresponding realm is then used to complete 95 the target service principal name. 97 This traditional mechanism requires that each client have very 98 detailed configuration information about the hosts that are 99 providing services and their corresponding realms. Having client 100 side configuration information can be very costly from an 101 administration point of view - especially if there are many realms 102 and computers in the environment. 104 Current implementations of Kerberos also have difficulty with 105 services on hosts that can have multiple host names (multi-homed 106 hosts). Traditionally, each host name would need to have a distinct 107 principal and a corresponding key. An extreme example of this would 108 be a Web server with multiple host names for each domain that it is 110 Swift Category - Standards Track 2 112 KDC Referrals February 2001 114 supporting. Principal aliases allow multi-homed hosts to have a 115 single Kerberos principal (with a single key) that can have 116 identities for each distinct host name. This mechanism allows the 117 Kerberos client to request a service ticket for the distinct 118 hostname and allows the KDC to return a ticket for the single 119 principal that the host is using. This canonical principal name 120 allows the host to only have to manage a single key for all of the 121 identities that it supports. In addition, the client only needs to 122 know the realm of the canonical service name, not all of the 123 identities. 125 This draft proposes a solution for these problems and simplifies 126 administration by minimizing the configuration information needed on 127 each computer using Kerberos. Specifically it describes a mechanism 128 to allow the KDC to handle Canonicalization of names, provide for 129 principal aliases for users and services and provide a mechanism for 130 the KDC to determine the trusted realm authentication path by being 131 able to generate referrals to other realms in order to locate 132 principals. 134 To rectify these problems, this draft introduces three new kinds of 135 KDC referrals: 137 1. AS ticket referrals, in which the client doesn't know which realm 138 contains a user account. 139 2. TGS ticket referrals, in which the client doesn't know which 140 realm contains a server account. 141 3. Cross realm shortcut referrals, in which the KDC chooses the next 142 path on a referral chain 144 4. Realm Organization Model 146 This draft assumes that the world of principals is arranged on 147 multiple levels: the realm, the enterprise, and the world. A KDC may 148 issue tickets for any principal in its realm or cross-realm tickets 149 for realms with which it has a direct trust relationship. The KDC 150 also has access to a trusted name service that can resolve any name 151 from within its enterprise into a realm. This trusted name service 152 removes the need to use an untrusted DNS lookup for name resolution. 154 For example, consider the following configuration, where lines 155 indicate trust relationships: 157 MS.COM 158 / \ 159 / \ 160 OFFICE.MS.COM NT.MS.COM 162 In this configuration, all users in the MS.COM enterprise could have 163 a principal name such as alice@MS.COM, with the same realm portion. 164 In addition, servers at MS.COM should be able to have DNS host names 165 from any DNS domain independent of what Kerberos realm their 166 principal resides in. 168 Swift Category - Standards Track 3 170 KDC Referrals February 2001 172 5. Principal Names 174 5.1 Service Principal Names 176 The standard Kerberos model in RFC 1510 [3] gives each Kerberos 177 principal a single name. However, if a service is reachable by 178 several addresses, it is useful for a principal to have multiple 179 names. Consider a service running on a multi-homed machine. Rather 180 than requiring a separate principal and password for each name it 181 exports, a single account with multiple names could be used. 183 Multiple names are also useful for services in that clients need not 184 perform DNS lookups to resolve a host name into a full DNS address. 185 Instead, the service may have a name for each of its supported host 186 names, including its IP address. Nonetheless, it is still convenient 187 for the service to not have to be aware of all these names. Thus a 188 new name may be added to DNS for a service by updating DNS and the 189 KDC database without having to notify the service. In addition, it 190 implies that these aliases are globally unique: they do not include 191 a specifier dictating what realm contains the principal. Thus, an 192 alias for a server is of the form "class/instance/name" and may be 193 transmitted as any name type. 195 5.2 Client Principal Names 197 Similarly, a client account may also have multiple principal names. 198 More useful, though, is a globally unique name that allows 199 unification of email and security principal names. For example, all 200 users at MS may have a client principal name of the form 201 "joe@MS.COM" even though the principals are contained in multiple 202 realms. This global name is again an alias for the true client 203 principal name, which is indicates what realm contains the 204 principal. Thus, accounts "alice" in the realm ntdev.MS.COM and 205 "bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM". 206 This requires a new client principal name type, as the AS-REQ 207 message only contains a single realm field, and the realm portion of 208 this name doesn't correspond to any Kerberos realm. Thus, the entire 209 name "alice@MS.COM" is transmitted in the client name field of the 210 AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL. 212 KRB-NT-ENTERPRISE-PRINCIPAL 10 214 5.3 Name Canonicalization 216 In order to support name aliases, the Kerberos client must 217 explicitly request the name-canonicalization KDC option (bit 15) in 218 the ticket flags for the TGS-REQ. This flag indicates to the KDC 219 that the client is prepared to receive a reply with a different 220 client or server principal name than the request. Thus, the 221 KDCOptions types is redefined as: 223 KDCOptions ::= BIT STRING { 225 Swift Category - Standards Track 4 227 KDC Referrals February 2001 229 reserved(0), 230 forwardable(1), 231 forwarded(2), 232 proxiable(3), 233 proxy(4), 234 allow-postdate(5), 235 postdated(6), 236 unused7(7), 237 renewable(8), 238 unused9(9), 239 unused10(10), 240 unused11(11), 241 name-canonicalize(15), 242 renewable-ok(27), 243 enc-tkt-in-skey(28), 244 renew(30), 245 validate(31) 246 } 248 6. Client Referrals 250 The simplest form of ticket referral is for a user requesting a 251 ticket using an AS-REQ. In this case, the client machine will send 252 the AS request to a convenient trusted realm, either the realm of 253 the client machine or the realm of the client name. In the case of 254 the name Alice@MS.COM, the client may optimistically choose to send 255 the request to MS.COM. 257 The client will send the string "alice@MS.COM" in the client 258 principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type 259 with the crealm set to MS.COM. The KDC will try to lookup the name 260 in its local account database. If the account is present in the 261 crealm of the request, it MUST return a KDC reply structure with the 262 appropriate ticket. If the account is not present in the crealm 263 specified in the request and the name-canonicalize flag in the 264 KDCoptions is set, the KDC will try to lookup the entire name, 265 Alice@MS.COM, using a name service. If this lookup is unsuccessful, 266 it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup 267 is successful, it MUST return an error KDC_ERR_WRONG_REALM (0x44) 268 and in the error message the cname and crealm field MUST contain the 269 client name and the true realm of the client. If the KDC contains 270 the account locally, it MUST return a normal ticket. The client name 271 and realm portions of the ticket and KDC reply message MUST be the 272 client's true name in the realm, not the globally unique name. 274 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 275 new AS request with the same client principal name used to generate 276 the first referral to the realm specified by the crealm field of the 277 kerberos error message from the first request. This request MUST 278 produce a valid AS response with a ticket for the canonical user 279 name. The ticket MUST also include the ticket extension containing 280 the TE-REFERRAL-DATA with the referred-names set to the name from 282 Swift Category - Standards Track 5 284 KDC Referrals February 2001 286 the AS request. Any other error or referral will terminate the 287 request and result in a failed AS request. 289 7. Server Referrals 291 The server referral mechanism is a bit more complex than the client 292 referral mechanism. The primary problem is that the KDC must return 293 a referral ticket rather than an error message, so it will include 294 in the TGS response information about what realm contains the 295 service. This is done by returning information about the server name 296 in the pre-auth data field of the KDC reply. 298 If the KDC resolves the server principal name into a principal in 299 its realm, it may return a normal ticket. If the name-canonicalize 300 flag in the KDCoptions is not set, then the KDC MUST only look up 301 the name as a normal principal name. Otherwise, it MUST search all 302 aliases as well. The server principal name in both the ticket and 303 the KDC reply MUST be the true server principal name instead of one 304 of the aliases. This frees the application server from needing to 305 know about all its aliases. 307 If the name-canonicalize flag in the KDCoptions is set and the KDC 308 doesn't find the principal locally, the KDC can return a cross-realm 309 ticket granting ticket to the next hop on the trust path towards a 310 realm that may be able to resolve the principal name. 312 If the KDC can determine the service principal's realm, it can 313 return the server realm as ticket extension data. The ticket 314 extension MUST be encrypted using the session key from the ticket, 315 and the same etype as is used to protect the TGS reply body. 317 The data itself is an ASN.1 encoded structure containing the 318 server's realm, and if known, canonical principal name and alias 319 names. The first name in the sequence is the canonical principal 320 name. 322 TE-REFERRAL-INFO 20 324 TE-REFERRAL-DATA ::= SEQUENCE { 325 referred-server-realm[0] KERB-REALM 326 referred-names[1] SEQUENCE OF 327 PrincipalNames OPTIONAL 328 } 330 The client can use this information to request a chain of cross- 331 realm ticket granting tickets until it reaches the realm of the 332 server, and can then expect to receive a valid service ticket. 334 In order to facilitate cross-realm interoperability, a client SHOULD 335 NOT send short names in TGS requests to the KDC. A short name is 336 defined as a Kerberos name that includes a DNS name that is not 337 fully qualified. The client MAY use forward DNS lookups to obtain 339 Swift Category - Standards Track 6 341 KDC Referrals February 2001 343 the long name that corresponds to the user entered short name (the 344 short name will be a prefix of the corresponding long name). 346 The client may use the referred-names field to tell if it already 347 has a ticket to the server in its ticket cache. 349 The client can use this information to request a chain of cross- 350 realm ticket granting tickets until it reaches the realm of the 351 server, and can then expect to receive a valid service ticket. 352 However an implementation should limit the number of referrals that 353 it processes to avoid infinite referral loops. A suggested limit is 354 5 referrals before giving up. 356 8. Cross Realm Routing 358 The current Kerberos protocol requires the client to explicitly 359 request a cross-realm TGT for each pair of realms on a referral 360 chain. As a result, the client machines need to be aware of the 361 trust hierarchy and of any short-cut trusts (those that aren't 362 parent-child trusts). This requires more configurations on the 363 client. Instead, the client should be able to request a TGT to the 364 target realm from each realm on the route. The KDC will determine 365 the best path for the client and return a cross-realm TGT. The 366 client has to be aware that a request for a cross-realm TGT may 367 return a TGT for a realm different from the one requested. 369 9. Security Considerations 371 The original Kerberos specification stated that the server principal 372 name in the KDC reply was the same as the server name in the 373 request. These protocol changes break that assumption, so the client 374 may be vulnerable to a denial of service attack by an attacker that 375 replays replies from previous requests. It can verify that the 376 request was one of its own by checking the client-address field or 377 authtime field, though, so the damage is limited and detectable. 379 For the AS exchange case, it is important that the logon mechanism 380 not trust a name that has not been used to authenticate the user. 381 For example, the name that the user enters as part of a logon 382 exchange may not be the name that the user authenticates as, given 383 that the KDC_ERR_WRONG_REALM error may have been returned. The 384 relevant Kerberos naming information for logon (if any), is the 385 client name and client realm in the service ticket targeted at the 386 workstation that was obtained using the user's initial TGT. 388 How the client name and client realm is mapped into a local account 389 for logon is a local matter, but the client logon mechanism MUST use 390 additional information such as the client realm and/or authorization 391 attributes from the service ticket presented to the workstation by 392 the user, when mapping the logon credentials to a local account on 393 the workstation. 395 10. Discussion 397 Swift Category - Standards Track 7 399 KDC Referrals February 2001 401 This section contains issues and suggestions that need to be 402 incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]: 404 1) No means to do name canonicalization if you're not 405 authenticating. Is it okay to require credentials in order to do 406 canonicalization? If so, how about this: Send a TGS_REQ for the 407 service name you have. If you get back a TGS_REP for a service, 408 great; pull out the name and throw out the credentials. If you 409 get back a TGS_REP for a TGT service, ask again in the specified 410 realm. If you get back a KRB_ERROR because policy prohibits you 411 from authenticating to that service, we can add to the 412 specification that the {realm,sname} in the KRB_ERROR must be the 413 canonical name, and the checksum must be used. As long as the 414 checksum is present, it's still a secure exchange with the KDC. 416 If we have to be able to do name canonicalization without any 417 sort of credentials, either client-side (tickets) or server-side 418 (tickets automatically acquired via service key), I think we just 419 lose. But maybe GSSAPI should be changed if that's the case. 421 2) Can't refer to another realm and specify a different service name 422 to give to that realm's KDC. The local KDC can tell you a 423 different service name or a different realm name, but not both. 424 This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type 425 of case I've mentioned. 427 Except ... the KDC-REP structure includes padata and ticket 428 extensions fields that are extensible. We could add a required 429 value to one of them -- perhaps only in the case where you return 430 a TGT when not asked -- that contains signed information about 431 the principal name to ask for in the other realm. (It would have 432 to be required, otherwise a man-in-the-middle could make it go 433 away.) Signing would be done using the session key for the TGS. 435 3) Secure canonicalization of service name in AS_REQ. If the 436 response is an AS_REP, we need a way to tell that the altered 437 server name wasn't a result of a MITM attack on the AS_REQ 438 message. Again, the KDC-REP extensible fields could have a new 439 required value added when name canonicalization happens, 440 indicating what the original principal name (in the AS_REQ 441 message) was, and signed using the same key as protects the 442 AS_REP. If it doesn't match what the client requested, the 443 messages were altered in transit. 445 4) Client name needs referral to another realm, and server name 446 needs canonicalization of some sort. The above fixes wouldn't 447 work for this case, and I'm not even sure which KDC should be 448 doing the canonicalization anyways. 450 The other-principal-name datum would probably look something like: 452 Swift Category - Standards Track 8 454 KDC Referrals February 2001 456 PrincipalAndNonce ::= SEQUENCE { 457 name[0] PrincipalName, 458 nonce[1] INTEGER -- copied from KDC_REQ 459 } 460 SignedPrincipal ::= SEQUENCE { 461 name-and-nonce[0] PrincipalAndNonce, 462 cksum[1] Checksum 463 } 464 {PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal 465 {PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal 467 with the checksum computed over the encoding of the 'name-and-nonce' 468 field, and appropriate PA- or TE- numbers assigned. I don't have a 469 strong opinion on whether it'd be a pa-data or ticket extension; 470 conceptually it seems like an abuse of either, but, well, I think 471 I'd rather abuse them than leave the facility both in and 472 inadequate. 474 The nonce is needed because multiple exchanges may be made with the 475 same key, and these extension fields aren't packed in with the other 476 encrypted data in the same response, so a MITM could pick apart 477 multiple messages and mix-and-match components. (In a TGS_REQ 478 exchange, a subsession key would help, but it's not required.) 480 The extension field would be required to prevent a MITM from 481 discarding the field from a response; a flag bit in a protected part 482 of the message (probably in 'flags' in EncKDCRepPart) could also let 483 us know of a cases where the information can be omitted, namely, 484 when no name change is done. Perhaps the bit should be set to 485 indicate that a name change *was* done, and clear if it wasn't, 486 making the no-change case more directly compatible with RFC1510. 488 11. References 490 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 491 9, RFC 2026, October 1996. 493 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 494 Levels", BCP 14, RFC 2119, March 1997 496 3 Kohl, J., Neuman, C., "The Kerberos Network Authentication 497 Service (V5)", RFC 1510, September 1993 499 12. Author's Addresses 501 Michael Swift 502 University of Washington 503 Seattle, Washington 504 Email: mikesw@cs.washington.edu 506 John Brezak 508 Swift Category - Standards Track 9 510 KDC Referrals February 2001 512 Microsoft 513 One Microsoft Way 514 Redmond, Washington 515 Email: jbrezak@Microsoft.com 517 Jonathan Trostle 518 Cisco Systems 519 170 W. Tasman Dr. 520 San Jose, CA 95134 521 Email: jtrostle@cisco.com 523 Kenneth Raeburn 524 Massachusetts Institute of Technology 77 525 Massachusetts Avenue 526 Cambridge, Massachusetts 02139 527 Email: raeburn@mit.edu 529 Swift Category - Standards Track 10 531 KDC Referrals February 2001 533 Full Copyright Statement 535 Copyright (C) The Internet Society (1999). All Rights Reserved. 537 This document and translations of it may be copied and furnished to 538 others, and derivative works that comment on or otherwise explain it 539 or assist in its implementation may be prepared, copied, published 540 and distributed, in whole or in part, without restriction of any 541 kind, provided that the above copyright notice and this paragraph 542 are included on all such copies and derivative works. However, this 543 document itself may not be modified in any way, such as by removing 544 the copyright notice or references to the Internet Society or other 545 Internet organizations, except as needed for the purpose of 546 developing Internet standards in which case the procedures for 547 copyrights defined in the Internet Standards process must be 548 followed, or as required to translate it into languages other than 549 English. 551 The limited permissions granted above are perpetual and will not be 552 revoked by the Internet Society or its successors or assigns. 554 This document and the information contained herein is provided on an 555 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 556 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 557 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 558 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 559 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 561 Swift Category - Standards Track 11