CAT Working Group M. Swift Internet Draft Microsoft Document: draft-swift-win2k-krb-referrals-00.txt October 1999 Category: Informational Generating KDC Referrals to locate Kerberos realms Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The draft documents a new method for a Kerberos Key Distribution Center (KDC) to respond to client requests for tickets as is used in Microsoft's Windows 2000 implementation of Kerberos. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm TGT to another realm on the referral path. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction The Kerberos TGS and AS protocols, as defined in RFC 1510 [3], require that client software be able to parse principal names into a realm and an account portion. However, if a site want to deploy a Kerberos realm infrastructure separately from its DNS infrastructure, Kerberos must be able to handle the case where the client software does not know what realm contains a given service or user principal name. In addition, the current protocol requires the client to know the hierarchy of realms by explicitly asking for a Swift Category - Informational 1 KDC Referrals October 1999 referral to a specific realm rather than letting the KDC pick the next realm on the referral path. To rectify these problems, this draft introduces three new kinds of KDC referrals: 1. AS ticket referrals, in which the client doesnĘt know which realm contains a user account. 2. TGS ticket referrals, in which the client doesnĘt know which realm contains a server account. 3. Cross realm shortcut referrals, in which the KDC chooses the next path on a referral chain 4. Realm Organization Model This draft assumes that the world of principals is arranged on multiple levels: the realm, the enterprise, and the world. A KDC may issue tickets for any principal in its realm or cross-realm tickets for realms with which it has a direct trust relationship. The KDC also has access to a trusted directory or name service that can resolve any name from within its enterprise into a realm. This trusted name service removes the need to use an untrusted DNS lookup for name resolution. For example, consider the following configuration, where lines indicate trust relationships: MS.COM / \ / \ OFFICE.MS.COM NT.MS.COM In this configuration, all users in the MS.COM enterprise could have a principal name such as alice@ms.com, with the same realm portion. In addition, servers at MS.COM should be able to have DNS host names from any DNS domain independent of what Kerberos realm their principal resides in. 5. Principal Names 5.1 Service Principal Names The standard Kerberos model in RFC 1510 [3] gives each Kerberos principal a single name. However, if a service is reachable by several addresses, it may be useful for a principal to have multiple names. Consider a service running on a multi-homed machine. Rather than requiring a separate principal and password for each name it exports, a single account with multiple names could be used. Multiple names are also useful for services in that clients need not perform DNS lookups to resolve a host name into a full DNS address. Instead, the service may have a name for each of its supported host names, including its IP address. Nonetheless, it is still convenient Swift Category - Informational 2 KDC Referrals October 1999 for the service to not have to be aware of all these names. Thus a new name may be added to DNS for a service by updating DNS and the KDC database without having to notify the service. In addition, it implies that these aliases are globally unique: they do not include a specifier dictating what domain contains the principal. Thus, an alias for a server is of the form "name/name/name" and may be transmitted as any name type. 5.2 Client Principal Names Similarly, a client account may also have multiple principal names. More useful, though, is a globally unique name that allows unification of email and security principal names. For example, all users at Microsoft may have a client principal name of the form "joe@MS.COM" even though the principals are contained in multiple realms. This global name is again an alias for the true client principal name, which is indicates what realm contains the principal. Thus, accounts "alice" in the realm ntdev.MS.COM and "bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM". This change requires a new client principal name type, as the AS-REQ message only contains a single realm field, and the realm portion of this name doesn't correspond to any realm security realm. Thus, the entire name "alice@MS.COM" is transmitted in the client name field of the AS-REQ message, with a name type of KRB-NT-ENTERPRISE- PRINCIPAL. #define KRB-NT-ENTERPRISE-PRINCIPAL 10 5.3 Name Canonicalization In order to support name aliases, the Kerberos client must explicitly request the name-canonicalization KDC option (bit 12) in the ticket flags for the TGS-REQ. This option is an indicator to the KDC that if it fails to find the name in the local database as a normal principal name, it should try to look the name up as an alias both locally and in a global directory. This flag indicates to the KDC that the client is prepared to receive a reply with a different client or server principal name than the request. Thus, the KDCOptions types is redefined as: KDCOptions ::= BIT STRING { reserved(0), forwardable(1), forwarded(2), proxiable(3), proxy(4), allow-postdate(5), postdated(6), unused7(7), renewable(8), unused9(9), unused10(10), unused11(11), Swift Category - Informational 3 KDC Referrals October 1999 name-canonicalize(12), renewable-ok(27), enc-tkt-in-skey(28), renew(30), validate(31) } 6. Client Referrals The simplest form of ticket referral is for a user requesting a ticket using an AS-REQ. In this case, the client machine will send the AS request to a convenient realm, probably either the realm of the client machine or the realm portion of the client name. In the case of the name Alice@MS.COM, the client may optimistically choose to send the request to MS.COM. The client will send the string "alice@MS.COM" in the client principal name field using the KRB-NT- ENTERPRISE-PRINCIPAL name type. The KDC will try to lookup the name in its local account database. If the account is present, it will return a KDC reply structure with the appropriate ticket. If the account is not present and the name-canonicalize option is requested, it will try to lookup the entire name (Alice@MS.COM) in the global directory. If this lookup is unsuccessful, it will return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful, it will return an error KDC_ERR_WRONG_REALM (0x44) and in the error message, the cname and crealm field will contain the client name and the true realm of the client. If the KDC contains the account locally, it will return a normal ticket. The client name and realm portions of the ticket and KDC reply message will be the client's true name in the realm, not the globally unique name. If the client receives a KDC_ERR_WRONG_REALM error, it will issue a new AS request to the realm specified by the crealm field of the error message. 7. Server Referrals The server referral mechanism is a bit more complex than the client referral mechanism. The primary problem is that the KDC must return a referral ticket rather than an error message, so it must include in the TGS response information about what realm contains the service. This is done by returning information about the server name in the pre-auth data field of the KDC reply. If the KDC resolves the server principal name into a principal in its realm, it may return a normal ticket. If the name-canonicalize bit is not set, then the KDC should only look up the name as a normal principal name. Otherwise, it should search all aliases as well. The server principal name in both the ticket and the KDC reply should be the true server principal name instead of one of the aliases. This prevents the application server from needing to know about all its aliases. Swift Category - Informational 4 KDC Referrals October 1999 If the KDC doesnĘt find the principal locally but is able to resolved it into a realm from the global directory, then it should return a cross-realm ticket granting ticket to the next hop on the trust path towards that realm. In this case, the KDC will return the server realm as a PA data type. The data itself is an ASN.1 encoded structure containing the server's realm, and if known, true principal name. The preauthentication data type is KRB5-PADATA- SERVER-REFERRAL-INFO. #define KRB5-PADATA-SERVER-REFERRAL-INFO 20 KERB-PA-SERV-REFERRAL ::= SEQUENCE { referred-server-name[1] KERB-PRINCIPAL-NAME OPTIONAL, referred-server-realm[0] KERB-REALM } The client may use the referred-server-name field to tell if it already has a ticket to the server in its ticket cache. The client can use this information to request a chain of cross- realm ticket granting tickets until it reaches this realm, and can then expect to receive a valid service ticket. 8. Cross Realm Routing The current Kerberos protocol requires the client libraries to explicitly request a cross-realm TGT for each pair of realms on a referral chain. As a result, the client machines need to be aware of the trust hierarchy and of any short-cut trusts (those that arenĘt parent-child trusts). This requires a lot of configuration on the client. Instead, the client should be able to request a TGT to the target realm from each realm on the route. The KDC will determine the best path for the client and return a cross-realm TGT. The client software has to be aware that a request for a cross-realm TGT may return a TGT for a realm different from the one requested. 9. Security Considerations The original Kerberos specification stated that the server principal name in the KDC reply was the same as the server name in the request. These protocol changes break that assumption, so the client may be vulnerable to a denial of service attack by an attacker that replays replies from previous requests. It can verify that the request was one of its own by checking the client-address field or authtime field, though, so the damage is limited. 10. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Swift Category - Informational 5 KDC Referrals October 1999 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Kohl, J., Neuman, C., "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993 10. Author's Addresses Michael Swift Microsoft One Microsoft Way Redmond, Washington Email: mikesw@microsoft.com Swift Category - Informational 6 KDC Referrals October 1999 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Swift Category - Informational 7