1 2 3Kerberos Working Group M. Swift 4Internet Draft University of WA 5Document: draft-ietf-krb-wg-kerberos-referrals-00.txt J. Brezak 6Category: Standards Track Microsoft 7 J. Trostle 8 Cisco Systems 9 K. Raeburn 10 MIT 11 February 2001 12 13 14 Generating KDC Referrals to locate Kerberos realms 15 16 17Status of this Memo 18 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026 [1]. 21 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. Internet-Drafts are draft documents valid for a maximum of 26 six months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- Drafts 28 as reference material or to cite them other than as "work in 29 progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 361. Abstract 37 38 The draft documents a new method for a Kerberos Key Distribution 39 Center (KDC) to respond to client requests for kerberos tickets when 40 the client does not have detailed configuration information on the 41 realms of users or services. The KDC will handle requests for 42 principals in other realms by returning either a referral error or a 43 cross-realm TGT to another realm on the referral path. The clients 44 will use this referral information to reach the realm of the target 45 principal and then receive the ticket. 46 472. Conventions used in this document 48 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC-2119 [2]. 52 533. Introduction 54 55 56 57 58Swift Category - Standards Track 1 59 60 61 62 63 64 65 66 67 KDC Referrals February 2001 68 69 70 Current implementations of the Kerberos AS and TGS protocols, as 71 defined in RFC 1510 [3], use principal names constructed from a 72 known user or service name and realm. A service name is typically 73 constructed from a name of the service and the DNS host name of the 74 computer that is providing the service. Many existing deployments of 75 Kerberos use a single Kerberos realm where all users and services 76 would be using the same realm. However in an environment where there 77 are multiple trusted Kerberos realms, the client needs to be able to 78 determine what realm a particular user or service is in before 79 making an AS or TGS request. Traditionally this requires client 80 configuration to make this possible. 81 82 When having to deal with multiple trusted realms, users are forced 83 to know what realm they are in before they can obtain a ticket 84 granting ticket (TGT) with an AS request. However, in many cases the 85 user would like to use a more familiar name that is not directly 86 related to the realm of their Kerberos principal name. A good 87 example of this is an RFC-822 style email name. This document 88 describes a mechanism that would allow a user to specify a user 89 principal name that is an alias for the user's Kerberos principal 90 name. In practice this would be the name that the user specifies to 91 obtain a TGT from a Kerberos KDC. The user principal name no longer 92 has a direct relationship with the Kerberos principal or realm. Thus 93 the administrator is able to move the user's principal to other 94 realms without the user having to know that it happened. 95 96 Once a user has a TGT, they would like to be able to access services 97 in any trusted Kerberos realm. To do this requires that the client 98 be able to determine what realm the target service's host is in 99 before making the TGS request. Current implementations of Kerberos 100 typically have a table that maps DNS host names to corresponding 101 Kerberos realms. In order for this to work on the client, each 102 application canonicalizes the host name of the service by doing a 103 DNS lookup followed by a reverse lookup using the returned IP 104 address. The returned primary host name is then used in the 105 construction of the principal name for the target service. In order 106 for the correct realm to be added for the target host, the mapping 107 table [domain_to_realm] is consulted for the realm corresponding to 108 the DNS host name. The corresponding realm is then used to complete 109 the target service principal name. 110 111 This traditional mechanism requires that each client have very 112 detailed configuration information about the hosts that are 113 providing services and their corresponding realms. Having client 114 side configuration information can be very costly from an 115 administration point of view - especially if there are many realms 116 and computers in the environment. 117 118 Current implementations of Kerberos also have difficulty with 119 services on hosts that can have multiple host names (multi-homed 120 hosts). Traditionally, each host name would need to have a distinct 121 principal and a corresponding key. An extreme example of this would 122 be a Web server with multiple host names for each domain that it is 123 124Swift Category - Standards Track 2 125 126 127 128 129 130 131 132 133 KDC Referrals February 2001 134 135 136 supporting. Principal aliases allow multi-homed hosts to have a 137 single Kerberos principal (with a single key) that can have 138 identities for each distinct host name. This mechanism allows the 139 Kerberos client to request a service ticket for the distinct 140 hostname and allows the KDC to return a ticket for the single 141 principal that the host is using. This canonical principal name 142 allows the host to only have to manage a single key for all of the 143 identities that it supports. In addition, the client only needs to 144 know the realm of the canonical service name, not all of the 145 identities. 146 147 This draft proposes a solution for these problems and simplifies 148 administration by minimizing the configuration information needed on 149 each computer using Kerberos. Specifically it describes a mechanism 150 to allow the KDC to handle Canonicalization of names, provide for 151 principal aliases for users and services and provide a mechanism for 152 the KDC to determine the trusted realm authentication path by being 153 able to generate referrals to other realms in order to locate 154 principals. 155 156 To rectify these problems, this draft introduces three new kinds of 157 KDC referrals: 158 159 1. AS ticket referrals, in which the client doesn't know which realm 160 contains a user account. 161 2. TGS ticket referrals, in which the client doesn't know which 162 realm contains a server account. 163 3. Cross realm shortcut referrals, in which the KDC chooses the next 164 path on a referral chain 165 1664. Realm Organization Model 167 168 This draft assumes that the world of principals is arranged on 169 multiple levels: the realm, the enterprise, and the world. A KDC may 170 issue tickets for any principal in its realm or cross-realm tickets 171 for realms with which it has a direct trust relationship. The KDC 172 also has access to a trusted name service that can resolve any name 173 from within its enterprise into a realm. This trusted name service 174 removes the need to use an untrusted DNS lookup for name resolution. 175 176 For example, consider the following configuration, where lines 177 indicate trust relationships: 178 179 MS.COM 180 / \ 181 / \ 182 OFFICE.MS.COM NT.MS.COM 183 184 In this configuration, all users in the MS.COM enterprise could have 185 a principal name such as alice@MS.COM, with the same realm portion. 186 In addition, servers at MS.COM should be able to have DNS host names 187 from any DNS domain independent of what Kerberos realm their 188 principal resides in. 189 190Swift Category - Standards Track 3 191 192 193 194 195 196 197 198 199 KDC Referrals February 2001 200 201 202 2035. Principal Names 204 2055.1 Service Principal Names 206 207 The standard Kerberos model in RFC 1510 [3] gives each Kerberos 208 principal a single name. However, if a service is reachable by 209 several addresses, it is useful for a principal to have multiple 210 names. Consider a service running on a multi-homed machine. Rather 211 than requiring a separate principal and password for each name it 212 exports, a single account with multiple names could be used. 213 214 Multiple names are also useful for services in that clients need not 215 perform DNS lookups to resolve a host name into a full DNS address. 216 Instead, the service may have a name for each of its supported host 217 names, including its IP address. Nonetheless, it is still convenient 218 for the service to not have to be aware of all these names. Thus a 219 new name may be added to DNS for a service by updating DNS and the 220 KDC database without having to notify the service. In addition, it 221 implies that these aliases are globally unique: they do not include 222 a specifier dictating what realm contains the principal. Thus, an 223 alias for a server is of the form "class/instance/name" and may be 224 transmitted as any name type. 225 2265.2 Client Principal Names 227 228 Similarly, a client account may also have multiple principal names. 229 More useful, though, is a globally unique name that allows 230 unification of email and security principal names. For example, all 231 users at MS may have a client principal name of the form 232 "joe@MS.COM" even though the principals are contained in multiple 233 realms. This global name is again an alias for the true client 234 principal name, which is indicates what realm contains the 235 principal. Thus, accounts "alice" in the realm ntdev.MS.COM and 236 "bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM". 237 This requires a new client principal name type, as the AS-REQ 238 message only contains a single realm field, and the realm portion of 239 this name doesn't correspond to any Kerberos realm. Thus, the entire 240 name "alice@MS.COM" is transmitted in the client name field of the 241 AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL. 242 243 KRB-NT-ENTERPRISE-PRINCIPAL 10 244 2455.3 Name Canonicalization 246 247 In order to support name aliases, the Kerberos client must 248 explicitly request the name-canonicalization KDC option (bit 15) in 249 the ticket flags for the TGS-REQ. This flag indicates to the KDC 250 that the client is prepared to receive a reply with a different 251 client or server principal name than the request. Thus, the 252 KDCOptions types is redefined as: 253 254 KDCOptions ::= BIT STRING { 255 256Swift Category - Standards Track 4 257 258 259 260 261 262 263 264 265 KDC Referrals February 2001 266 267 268 reserved(0), 269 forwardable(1), 270 forwarded(2), 271 proxiable(3), 272 proxy(4), 273 allow-postdate(5), 274 postdated(6), 275 unused7(7), 276 renewable(8), 277 unused9(9), 278 unused10(10), 279 unused11(11), 280 name-canonicalize(15), 281 renewable-ok(27), 282 enc-tkt-in-skey(28), 283 renew(30), 284 validate(31) 285 } 286 2876. Client Referrals 288 289 The simplest form of ticket referral is for a user requesting a 290 ticket using an AS-REQ. In this case, the client machine will send 291 the AS request to a convenient trusted realm, either the realm of 292 the client machine or the realm of the client name. In the case of 293 the name Alice@MS.COM, the client may optimistically choose to send 294 the request to MS.COM. 295 296 The client will send the string "alice@MS.COM" in the client 297 principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type 298 with the crealm set to MS.COM. The KDC will try to lookup the name 299 in its local account database. If the account is present in the 300 crealm of the request, it MUST return a KDC reply structure with the 301 appropriate ticket. If the account is not present in the crealm 302 specified in the request and the name-canonicalize flag in the 303 KDCoptions is set, the KDC will try to lookup the entire name, 304 Alice@MS.COM, using a name service. If this lookup is unsuccessful, 305 it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup 306 is successful, it MUST return an error KDC_ERR_WRONG_REALM (0x44) 307 and in the error message the cname and crealm field MUST contain the 308 client name and the true realm of the client. If the KDC contains 309 the account locally, it MUST return a normal ticket. The client name 310 and realm portions of the ticket and KDC reply message MUST be the 311 client's true name in the realm, not the globally unique name. 312 313 If the client receives a KDC_ERR_WRONG_REALM error, it will issue a 314 new AS request with the same client principal name used to generate 315 the first referral to the realm specified by the crealm field of the 316 kerberos error message from the first request. This request MUST 317 produce a valid AS response with a ticket for the canonical user 318 name. The ticket MUST also include the ticket extension containing 319 the TE-REFERRAL-DATA with the referred-names set to the name from 320 321 322Swift Category - Standards Track 5 323 324 325 326 327 328 329 330 331 KDC Referrals February 2001 332 333 334 the AS request. Any other error or referral will terminate the 335 request and result in a failed AS request. 336 3377. Server Referrals 338 339 The server referral mechanism is a bit more complex than the client 340 referral mechanism. The primary problem is that the KDC must return 341 a referral ticket rather than an error message, so it will include 342 in the TGS response information about what realm contains the 343 service. This is done by returning information about the server name 344 in the pre-auth data field of the KDC reply. 345 346 If the KDC resolves the server principal name into a principal in 347 its realm, it may return a normal ticket. If the name-canonicalize 348 flag in the KDCoptions is not set, then the KDC MUST only look up 349 the name as a normal principal name. Otherwise, it MUST search all 350 aliases as well. The server principal name in both the ticket and 351 the KDC reply MUST be the true server principal name instead of one 352 of the aliases. This frees the application server from needing to 353 know about all its aliases. 354 355 If the name-canonicalize flag in the KDCoptions is set and the KDC 356 doesn't find the principal locally, the KDC can return a cross-realm 357 ticket granting ticket to the next hop on the trust path towards a 358 realm that may be able to resolve the principal name. 359 360 If the KDC can determine the service principal's realm, it can 361 return the server realm as ticket extension data. The ticket 362 extension MUST be encrypted using the session key from the ticket, 363 and the same etype as is used to protect the TGS reply body. 364 365 The data itself is an ASN.1 encoded structure containing the 366 server's realm, and if known, canonical principal name and alias 367 names. The first name in the sequence is the canonical principal 368 name. 369 370 TE-REFERRAL-INFO 20 371 372 TE-REFERRAL-DATA ::= SEQUENCE { 373 referred-server-realm[0] KERB-REALM 374 referred-names[1] SEQUENCE OF 375 PrincipalNames OPTIONAL 376 } 377 378 379 The client can use this information to request a chain of cross- 380 realm ticket granting tickets until it reaches the realm of the 381 server, and can then expect to receive a valid service ticket. 382 383 In order to facilitate cross-realm interoperability, a client SHOULD 384 NOT send short names in TGS requests to the KDC. A short name is 385 defined as a Kerberos name that includes a DNS name that is not 386 fully qualified. The client MAY use forward DNS lookups to obtain 387 388Swift Category - Standards Track 6 389 390 391 392 393 394 395 396 397 KDC Referrals February 2001 398 399 400 the long name that corresponds to the user entered short name (the 401 short name will be a prefix of the corresponding long name). 402 403 The client may use the referred-names field to tell if it already 404 has a ticket to the server in its ticket cache. 405 406 The client can use this information to request a chain of cross- 407 realm ticket granting tickets until it reaches the realm of the 408 server, and can then expect to receive a valid service ticket. 409 However an implementation should limit the number of referrals that 410 it processes to avoid infinite referral loops. A suggested limit is 411 5 referrals before giving up. 412 4138. Cross Realm Routing 414 415 The current Kerberos protocol requires the client to explicitly 416 request a cross-realm TGT for each pair of realms on a referral 417 chain. As a result, the client machines need to be aware of the 418 trust hierarchy and of any short-cut trusts (those that aren't 419 parent-child trusts). This requires more configurations on the 420 client. Instead, the client should be able to request a TGT to the 421 target realm from each realm on the route. The KDC will determine 422 the best path for the client and return a cross-realm TGT. The 423 client has to be aware that a request for a cross-realm TGT may 424 return a TGT for a realm different from the one requested. 425 4269. Security Considerations 427 428 The original Kerberos specification stated that the server principal 429 name in the KDC reply was the same as the server name in the 430 request. These protocol changes break that assumption, so the client 431 may be vulnerable to a denial of service attack by an attacker that 432 replays replies from previous requests. It can verify that the 433 request was one of its own by checking the client-address field or 434 authtime field, though, so the damage is limited and detectable. 435 436 For the AS exchange case, it is important that the logon mechanism 437 not trust a name that has not been used to authenticate the user. 438 For example, the name that the user enters as part of a logon 439 exchange may not be the name that the user authenticates as, given 440 that the KDC_ERR_WRONG_REALM error may have been returned. The 441 relevant Kerberos naming information for logon (if any), is the 442 client name and client realm in the service ticket targeted at the 443 workstation that was obtained using the user's initial TGT. 444 445 How the client name and client realm is mapped into a local account 446 for logon is a local matter, but the client logon mechanism MUST use 447 additional information such as the client realm and/or authorization 448 attributes from the service ticket presented to the workstation by 449 the user, when mapping the logon credentials to a local account on 450 the workstation. 451 45210. Discussion 453 454Swift Category - Standards Track 7 455 456 457 458 459 460 461 462 463 KDC Referrals February 2001 464 465 466 467 This section contains issues and suggestions that need to be 468 incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]: 469 470 1) No means to do name canonicalization if you're not 471 authenticating. Is it okay to require credentials in order to do 472 canonicalization? If so, how about this: Send a TGS_REQ for the 473 service name you have. If you get back a TGS_REP for a service, 474 great; pull out the name and throw out the credentials. If you 475 get back a TGS_REP for a TGT service, ask again in the specified 476 realm. If you get back a KRB_ERROR because policy prohibits you 477 from authenticating to that service, we can add to the 478 specification that the {realm,sname} in the KRB_ERROR must be the 479 canonical name, and the checksum must be used. As long as the 480 checksum is present, it's still a secure exchange with the KDC. 481 482 If we have to be able to do name canonicalization without any 483 sort of credentials, either client-side (tickets) or server-side 484 (tickets automatically acquired via service key), I think we just 485 lose. But maybe GSSAPI should be changed if that's the case. 486 487 2) Can't refer to another realm and specify a different service name 488 to give to that realm's KDC. The local KDC can tell you a 489 different service name or a different realm name, but not both. 490 This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type 491 of case I've mentioned. 492 493 Except ... the KDC-REP structure includes padata and ticket 494 extensions fields that are extensible. We could add a required 495 value to one of them -- perhaps only in the case where you return 496 a TGT when not asked -- that contains signed information about 497 the principal name to ask for in the other realm. (It would have 498 to be required, otherwise a man-in-the-middle could make it go 499 away.) Signing would be done using the session key for the TGS. 500 501 3) Secure canonicalization of service name in AS_REQ. If the 502 response is an AS_REP, we need a way to tell that the altered 503 server name wasn't a result of a MITM attack on the AS_REQ 504 message. Again, the KDC-REP extensible fields could have a new 505 required value added when name canonicalization happens, 506 indicating what the original principal name (in the AS_REQ 507 message) was, and signed using the same key as protects the 508 AS_REP. If it doesn't match what the client requested, the 509 messages were altered in transit. 510 511 4) Client name needs referral to another realm, and server name 512 needs canonicalization of some sort. The above fixes wouldn't 513 work for this case, and I'm not even sure which KDC should be 514 doing the canonicalization anyways. 515 516 517 The other-principal-name datum would probably look something like: 518 519 520Swift Category - Standards Track 8 521 522 523 524 525 526 527 528 529 KDC Referrals February 2001 530 531 532 PrincipalAndNonce ::= SEQUENCE { 533 name[0] PrincipalName, 534 nonce[1] INTEGER -- copied from KDC_REQ 535 } 536 SignedPrincipal ::= SEQUENCE { 537 name-and-nonce[0] PrincipalAndNonce, 538 cksum[1] Checksum 539 } 540 {PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal 541 {PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal 542 543 with the checksum computed over the encoding of the 'name-and-nonce' 544 field, and appropriate PA- or TE- numbers assigned. I don't have a 545 strong opinion on whether it'd be a pa-data or ticket extension; 546 conceptually it seems like an abuse of either, but, well, I think 547 I'd rather abuse them than leave the facility both in and 548 inadequate. 549 550 The nonce is needed because multiple exchanges may be made with the 551 same key, and these extension fields aren't packed in with the other 552 encrypted data in the same response, so a MITM could pick apart 553 multiple messages and mix-and-match components. (In a TGS_REQ 554 exchange, a subsession key would help, but it's not required.) 555 556 The extension field would be required to prevent a MITM from 557 discarding the field from a response; a flag bit in a protected part 558 of the message (probably in 'flags' in EncKDCRepPart) could also let 559 us know of a cases where the information can be omitted, namely, 560 when no name change is done. Perhaps the bit should be set to 561 indicate that a name change *was* done, and clear if it wasn't, 562 making the no-change case more directly compatible with RFC1510. 563 56411. References 565 566 567 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 568 9, RFC 2026, October 1996. 569 570 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 571 Levels", BCP 14, RFC 2119, March 1997 572 573 3 Kohl, J., Neuman, C., "The Kerberos Network Authentication 574 Service (V5)", RFC 1510, September 1993 575 576 57712. Author's Addresses 578 579 Michael Swift 580 University of Washington 581 Seattle, Washington 582 Email: mikesw@cs.washington.edu 583 584 John Brezak 585 586Swift Category - Standards Track 9 587 588 589 590 591 592 593 594 595 KDC Referrals February 2001 596 597 598 Microsoft 599 One Microsoft Way 600 Redmond, Washington 601 Email: jbrezak@Microsoft.com 602 603 Jonathan Trostle 604 Cisco Systems 605 170 W. Tasman Dr. 606 San Jose, CA 95134 607 Email: jtrostle@cisco.com 608 609 Kenneth Raeburn 610 Massachusetts Institute of Technology 77 611 Massachusetts Avenue 612 Cambridge, Massachusetts 02139 613 Email: raeburn@mit.edu 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652Swift Category - Standards Track 10 653 654 655 656 657 658 659 660 661 KDC Referrals February 2001 662 663 664 Full Copyright Statement 665 666 Copyright (C) The Internet Society (1999). All Rights Reserved. 667 668 This document and translations of it may be copied and furnished to 669 others, and derivative works that comment on or otherwise explain it 670 or assist in its implementation may be prepared, copied, published 671 and distributed, in whole or in part, without restriction of any 672 kind, provided that the above copyright notice and this paragraph 673 are included on all such copies and derivative works. However, this 674 document itself may not be modified in any way, such as by removing 675 the copyright notice or references to the Internet Society or other 676 Internet organizations, except as needed for the purpose of 677 developing Internet standards in which case the procedures for 678 copyrights defined in the Internet Standards process must be 679 followed, or as required to translate it into languages other than 680 English. 681 682 The limited permissions granted above are perpetual and will not be 683 revoked by the Internet Society or its successors or assigns. 684 685 This document and the information contained herein is provided on an 686 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 687 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 688 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 689 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 690 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718Swift Category - Standards Track 11 719 720 721 722 723 724 725 726