NETWORK WORKING GROUP K. Raeburn Internet-Draft MIT Updates: 4120 (if approved) L. Zhu Intended status: Standards Track Microsoft Corporation Expires: September 6, 2007 March 5, 2007 Generating KDC Referrals to Locate Kerberos Realms draft-ietf-krb-wg-kerberos-referrals-09 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. 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. The clients will use this referral information to reach the realm of the target principal and Raeburn & Zhu Expires September 6, 2007 [Page 1] Internet-Draft KDC Referrals March 2007 then receive the ticket. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4 4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5 5. Client Name Canonicalization . . . . . . . . . . . . . . . . . 5 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 7 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 8 8. Server Name Canonicalization (Informative) . . . . . . . . . . 10 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 10 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 14.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Compatibility with Earlier Implementations of Name Canonicalization . . . . . . . . . . . . . . . . 13 Appendix B. Document history . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Raeburn & Zhu Expires September 6, 2007 [Page 2] Internet-Draft KDC Referrals March 2007 1. Introduction Current implementations of the Kerberos AS and TGS protocols, as defined in [RFC4120], use principal names constructed from a known user or service name and realm. A service name is typically constructed from a name of the service and the DNS host name of the computer that is providing the service. Many existing deployments of Kerberos use a single Kerberos realm where all users and services would be using the same realm. However in an environment where there are multiple trusted Kerberos realms, the client needs to be able to determine what realm a particular user or service is in before making an AS or TGS request. Traditionally this requires client configuration to make this possible. When having to deal with multiple trusted realms, users are forced to know what realm they are in before they can obtain a ticket granting ticket (TGT) with an AS request. However, in many cases the user would like to use a more familiar name that is not directly related to the realm of their Kerberos principal name. A good example of this is an RFC 822 style email name. This document describes a mechanism that would allow a user to specify a user principal name that is an alias for the user's Kerberos principal name. In practice this would be the name that the user specifies to obtain a TGT from a Kerberos KDC. The user principal name no longer has a direct relationship with the Kerberos principal or realm. Thus the administrator is able to move the user's principal to other realms without the user having to know that it happened. Once a user has a TGT, they would like to be able to access services in any trusted Kerberos realm. To do this requires that the client be able to determine what realm the target service principal is in before making the TGS request. Current implementations of Kerberos typically have a table that maps DNS host names to corresponding Kerberos realms. The user-supplied host name or its domain component is looked up in this table (often using the result of some form of host name lookup performed with insecure DNS queries, in violation of [RFC4120]). The corresponding realm is then used to complete the target service principal name. This traditional mechanism requires that each client have very detailed configuration information about the hosts that are providing services and their corresponding realms. Having client side configuration information can be very costly from an administration point of view - especially if there are many realms and computers in the environment. There are also cases where specific DNS aliases (local names) have been setup in an organization to refer to a server in another Raeburn & Zhu Expires September 6, 2007 [Page 3] Internet-Draft KDC Referrals March 2007 organization (remote server). The server has different DNS names in each organization and each organization has a Kerberos realm that is configured to service DNS names within that organization. Ideally users are able to authenticate to the server in the other organization using the local server name. This would mean that the local realm be able to produce a ticket to the remote server under its name. The administrator in the local realm could give that remote server an identity in the local realm and then have that remote server maintain a separate secret for each alias it is known as. Alternatively the administrator could arrange to have the local realm issue a referral to the remote realm and notify the requesting client of the server's remote name that should be used in order to request a ticket. This memo proposes a solution for these problems and simplifies administration by minimizing the configuration information needed on each computer using Kerberos. Specifically it describes a mechanism to allow the KDC to handle canonicalization of names, provide for principal aliases for users and services and allow the KDC to determine the trusted realm authentication path by being able to generate referrals to other realms in order to locate principals. Two kinds of KDC referrals are introduced in this memo: 1. Client referrals, in which the client doesn't know which realm contains a user account. 2. Server referrals, in which the client doesn't know which realm contains a server account. 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 [RFC2119]. 3. Requesting a Referral In order to request referrals defined in section 5, 6, and 7, the Kerberos client MUST explicitly request the canonicalize KDC option (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to the KDC that the client is prepared to receive a reply that contains a principal name other than the one requested. KDCOptions ::= KerberosFlags -- canonicalize (15) Raeburn & Zhu Expires September 6, 2007 [Page 4] Internet-Draft KDC Referrals March 2007 -- other KDCOptions values omitted The client should expect, when sending names with the "canonicalize" KDC option, that names in the KDC's reply MAY be different than the name in the request. A referral TGT is a cross realm TGT that is returned with the server name of the ticket being different from the server name in the request [RFC4120]. 4. Realm Organization Model This memo 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 name service that can resolve any name from within its enterprise into a realm. This trusted name service removes the need to use an un-trusted DNS lookup for name resolution. For example, consider the following configuration, where lines indicate trust relationships: EXAMPLE.COM / \ / \ ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM In this configuration, all users in the EXAMPLE.COM enterprise could have principal names such as alice@EXAMPLE.COM, with the same realm portion. In addition, servers at EXAMPLE.COM should be able to have DNS host names from any DNS domain independent of what Kerberos realm their principals reside in. 5. Client Name Canonicalization A client account may 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 EXAMPLE.COM may have a client principal name of the form "joe@EXAMPLE.COM" even though the principals are contained in multiple realms. This global name is again an alias for the true client principal name, which indicates what realm contains the principal. Thus, accounts "alice" in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM". This utilizes a new client principal name type, as the AS-REQ message only contains a single realm field, and the realm portion of this Raeburn & Zhu Expires September 6, 2007 [Page 5] Internet-Draft KDC Referrals March 2007 name corresponds to the Kerberos realm with which the request is made. Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a single component in the client name field of the AS-REQ message, with a name type of NT-ENTERPRISE [RFC4120] (and the local realm name). The KDC will recognize this name type and then transform the requested name into the true principal name if the client account resides in the local realm. The true principal name can have a name type different from the requested name type. Typically the true principal name will be a NT-PRINCIPAL [RFC4120]. If the "canonicalize" KDC option is set, then the KDC MAY change the client principal name and type in the AS response and ticket returned from the name type of the client name in the request, and include a mandatory PA-DATA object authenticating the client name mapping: ReferralInfo ::= SEQUENCE { requested-name [0] PrincipalName, mapped-name [1] PrincipalName, ... } PA-CLIENT-CANONICALIZED ::= SEQUENCE { names [0] ReferralInfo, canon-checksum [1] Checksum } The canon-checksum field is computed over the DER encoding of the names sequences, using the AS reply key and a key usage value of (TBD). If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is not included. If the client name is changed, and the PA-CLIENT- CANONICALIZED field does not exist, or the checksum cannot be verified, or the requested-name field doesn't match the client name in the originally-transmitted request, the client should discard the response. For example the AS request may specify a client name of "bob@ EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC option set and the KDC will return with a client name of "104567" as a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT- ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the NT-UID "104567" principal as the mapped-name. (It is assumed that the client discovers whether the KDC supports the NT-ENTERPRISE name type via out of band mechanisms.) In order to enable one party in a user-to-user exchange to confirm the identity of another when only the alias is known, the KDC MAY Raeburn & Zhu Expires September 6, 2007 [Page 6] Internet-Draft KDC Referrals March 2007 include the following authorization data element, wrapped in AD-KDC- ISSUED, in the initial credentials and copy it from a ticket-granting ticket into additional credentials: AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD -- login-aliases [0] SEQUENCE(1..MAX) OF PrincipalName, } The login-aliases field lists one or more of the aliases the principal may have used in the initial ticket request. The recipient of this authenticator must check the AD-LOGIN-ALIAS names, if present, in addition to the normal client name field, against the identity of the party with which it wishes to authenticate; either should be allowed to match. (Note that this is not backwards compatible with [RFC4120]; if the server side of the user-to-user exchange does not support this extension, and does not know the true principal name, authentication may fail if the alias is sought in the client name field.) 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-REQ to a convenient trusted realm, for example the realm of the client machine. In the case of the name alice@EXAMPLE.COM, the client MAY optimistically choose to send the request to EXAMPLE.COM. The realm in the AS-REQ is always the name of the realm that the request is for as specified in [RFC4120]. The KDC will try to lookup the name in its local account database. If the account is present in the realm of the request, it SHOULD return a KDC reply structure with the appropriate ticket. If the account is not present in the realm specified in the request and the "canonicalize" KDC option is set, the KDC will try to lookup the entire name, alice@EXAMPLE.COM, using a name service. If this lookup is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful, it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the error message the crealm field will contain either the true realm of the client or another realm that MAY have better information about the client's true realm. The client SHALL NOT use a cname returned from a Kerberos error until that name is validated. If the client receives a KDC_ERR_WRONG_REALM error, it will issue a new AS request with the same client principal name used to generate Raeburn & Zhu Expires September 6, 2007 [Page 7] Internet-Draft KDC Referrals March 2007 the first referral to the realm specified by the realm field of the Kerberos error message corresponding to the first request. (The client realm name will be updated in the new request to refer to this new realm.) The client SHOULD repeat these steps until it finds the true realm of the client. To avoid infinite referral loops, an implementation should limit the number of referrals. A suggested limit is 5 referrals before giving up. Since the same client name is sent to the referring and referred-to realms, both realms must recognize the same client names. In particular, the referring realm cannot (usefully) define principal name aliases that the referred-to realm will not know. The true principal name of the client, returned in AS-REQ, can be validated in a subsequent TGS message exchange where its value is communicated back to the KDC via the authenticator in the PA-TGS-REQ padata [RFC4120]. 7. Server Referrals The primary difference in server referrals is that the KDC MUST return a referral TGT rather than an error message as is done in the client referrals. There needs to be a place to include in the reply information about what realm contains the server. This is done by returning information about the server name in the pre-authentication data field of the KDC reply [RFC4120], as specified later in this section. If the KDC resolves the server principal name into a principal in the realm specified by the service realm name, it will return a normal ticket. If the "canonicalize" flag in the KDC options is not set, the KDC MUST only look up the name as a normal principal name in the specified server realm. If the "canonicalize" flag in the KDC options is set and the KDC doesn't find the principal locally, the KDC MAY return a cross-realm ticket granting ticket to the next hop on the trust path towards a realm that may be able to resolve the principal name. The true principal name of the server SHALL be returned in the padata of the reply if it is different from what is specified the request. When a referral TGT is returned, the KDC MUST return the target realm for the referral TGT as an KDC supplied pre-authentication data element in the response. This referral information in pre- authentication data MUST be encrypted using the session key from the reply ticket. The key usage value for the encryption operation used Raeburn & Zhu Expires September 6, 2007 [Page 8] Internet-Draft KDC Referrals March 2007 by PA-SERVER-REFERRAL is 26. The pre-authentication data returned by the KDC, which contains the referred realm and the true principal name of server, is encoded in DER as follows. PA-SERVER-REFERRAL 25 PA-SERVER-REFERRAL-DATA ::= EncryptedData -- ServerReferralData -- ServerReferralData ::= SEQUENCE { referred-realm [0] Realm OPTIONAL, -- target realm of the referral TGT true-principal-name [1] PrincipalName OPTIONAL, -- true server principal name requested-principal-name [2] PrincipalName OPTIONAL, -- requested server name ... } Clients SHALL NOT accept a reply ticket, whose the server principal name is different from that of the request, if the KDC response does not contain a PA-SERVER-REFERRAL padata entry. The requested-principal-name MUST be included by the KDC, and MUST be verified by the client, if the client sent an AS-REQ, as protection against a man-in-the-middle modification to the AS-REQ message. The referred-realm field is present if and only if the returned ticket is a referral TGT, not a service ticket for the requested server principal. When a referral TGT is returned and the true-principal-name field is present, the client MUST use that name in the subsequent requests to the server realm when following the referral. Client SHALL NOT accept a true server principal name for a service ticket if the true-principal-name field is not present in the PA- SERVER-REFERRAL data. The client will use this referral information to request a chain of cross-realm ticket granting tickets until it reaches the realm of the server, and can then expect to receive a valid service ticket. However an implementation should limit the number of referrals that it processes to avoid infinite referral loops. A suggested limit is 5 referrals before giving up. Raeburn & Zhu Expires September 6, 2007 [Page 9] Internet-Draft KDC Referrals March 2007 Here is an example of a client requesting a service ticket for a service in realm DEV.EXAMPLE.COM where the client is in ADMIN.EXAMPLE.COM. +NC = Canonicalize KDCOption set +PA-REFERRAL = returned PA-SERVER-REFERRAL C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL containing EXAMPLE.COM as the referred realm with no true-principal-name C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL containing DEV.EXAMPLE.COM as the referred realm with no true-principal-name C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM Note that any referral or alias processing of the server name in user-to-user authentication should use the same data as client name canonicalization or referral. Otherwise, the name used by one user to log in may not be useable by another for user-to-user authentication to the first. 8. Server Name Canonicalization (Informative) No attempt is being made in this document to provide a means for dealing with local-realm server principal name canonicalization or aliasing. The most obvious use case for this would be a hostname- based service principal name ("host/foobar.example.com"), with a DNS alias ("foo") for the server host which is used by the client. There are other ways this can be handled, currently, though they may require additional configuration on the application server or KDC or both. 9. Cross Realm Routing The current Kerberos protocol requires the client to explicitly request a cross-realm TGT for each pair of realms on a referral chain. As a result, the client need to be aware of the trust hierarchy and of any short-cut trusts (those that aren't parent- child trusts). Instead, using the server referral routing mechanism as defined in Section 7, The KDC will determine the best path for the client and return a cross-realm TGT as the referral TGT, and the target realm for this TGT in the PA-SERVER-REFERRAL of the KDC reply. Raeburn & Zhu Expires September 6, 2007 [Page 10] Internet-Draft KDC Referrals March 2007 If the "canonicalize" KDC option is not set, the KDC SHALL NOT return a referral TGT. Clients SHALL NOT process referral TGTs if the KDC response does not contain the PA-SERVER-REFERRAL padata. 10. Caching Information It is possible that the client may wish to get additional credentials for the same service principal, perhaps with different authorization- data restrictions or other changed attributes. The return of a server referral from a KDC can be taken as an indication that the requested principal does not currently exist in the local realm. Clearly, it would reduce network traffic if the clients could cache that information and use it when acquiring the second set of credentials for a service, rather than always having to re-check with the local KDC to see if the name has been created locally. Rather than introduce a new timeout field for this cached information, we can use the lifetime of the returned TGT in this case. When the TGT expires, the previously returned referral from the local KDC should be considered invalid, and the local KDC must be asked again for information for the desired service principal name. (Note that the client may get back multiple referral TGTs from the local KDC to the same remote realm, with different lifetimes. The lifetime information must be properly associated with the requested service principal names. Simply having another TGT for the same remote realm does not extend the validity of previously acquired information about one service principal name.) If the client is still in contact with the service and needs to reauthenticate to the same service regardless of local service principal name assignments, it should use the referred-realm and true-principal-name values when requesting new credentials. Accordingly, KDC authors and maintainers should consider what factors (e.g., DNS alias lifetimes) they may or may not wish to incorporate into credential expiration times in cases of referrals. 11. Open Issues When should client name aliases be included in credentials? Should all known client name aliases be included, or only the one used at initial ticket acquisition? We still don't discuss what "validation" of the returned information means. Raeburn & Zhu Expires September 6, 2007 [Page 11] Internet-Draft KDC Referrals March 2007 12. Security Considerations For the AS exchange case, it is important that the logon mechanism not trust a name that has not been used to authenticate the user. For example, the name that the user enters as part of a logon exchange may not be the name that the user authenticates as, given that the KDC_ERR_WRONG_REALM error may have been returned. The relevant Kerberos naming information for logon (if any), is the client name and client realm in the service ticket targeted at the workstation that was obtained using the user's initial TGT. How the client name and client realm is mapped into a local account for logon is a local matter, but the client logon mechanism MUST use additional information such as the client realm and/or authorization attributes from the service ticket presented to the workstation by the user, when mapping the logon credentials to a local account on the workstation. 13. Acknowledgments Sam Hartman and authors came up with the idea of using the ticket key to encrypt the referral data, which prevents cut and paste attack using the referral data and referral TGTs. John Brezak, Mike Swift, and Jonathan Trostle wrote the initial version of this document. Karthik Jaganathan contributed to earlier versions. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. 14.2. Informative References [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. Raeburn & Zhu Expires September 6, 2007 [Page 12] Internet-Draft KDC Referrals March 2007 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation of Crossrealm Referral Handling in the MIT Kerberos Client", Network and Distributed System Security Symposium, February 2001. Appendix A. Compatibility with Earlier Implementations of Name Canonicalization (Remove this section when Microsoft publishes this information in a separate document.) The Microsoft Windows 2000 and Windows 2003 releases included an earlier form of name-canonicalization [XPR]. Here are the differences: 1) The TGS referral data is returned inside of the KDC message as "encrypted pre-authentication data". EncKDCRepPart ::= SEQUENCE { key [0] EncryptionKey, last-req [1] LastReq, nonce [2] UInt32, key-expiration [3] KerberosTime OPTIONAL, flags [4] TicketFlags, authtime [5] KerberosTime, starttime [6] KerberosTime OPTIONAL, endtime [7] KerberosTime, renew-till [8] KerberosTime OPTIONAL, srealm [9] Realm, sname [10] PrincipalName, caddr [11] HostAddresses OPTIONAL, encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL } 2) The preauth data type definition in the encrypted preauth data is as follows: Raeburn & Zhu Expires September 6, 2007 [Page 13] Internet-Draft KDC Referrals March 2007 PA-SVR-REFERRAL-INFO 20 PA-SVR-REFERRAL-DATA ::= SEQUENCE { referred-name [1] PrincipalName OPTIONAL, referred-realm [0] Realm }} 3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is encoded as a Subject Alternative Name (SAN) extension [RFC3280] in the client's X.509 certificate. The type of the otherName field for this SAN extension is AnotherName [RFC3280]. The type-id field of the type AnotherName is id-ms-sc-logon-upn (1.3.6.1.4.1.311.20.2.3) and the value field of the type AnotherName is a KerberosString [RFC4120]. The value of this KerberosString type is the single component in the name-string [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. In Microsoft's current implementation through the use of global catalogs any domain in one forest is reachable from any other domain in the same forest or another trusted forest with 3 or less referrals. A forest is a collection of realms with hierarchical trust relationships: there can be multiple trust trees in a forest; each child and parent realm pair and each root realm pair have bidirectional transitive direct rusts between them. While we might want to permit multiple aliases to exist and even be reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only one NT-ENTERPRISE alias to exist, so this question had not previously arisen. Appendix B. Document history [REMOVE BEFORE PUBLICATION.] 09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain. Rewrote description of existing practice. (Don't name the lookup table consulted. Mention that DNS "canonicalization" is contrary to [RFC4120].) Noted Microsoft behavior should be moved out into a separate document. Changed some second-person references in the introduction to identify the proper parties. Changed PA-CLIENT- CANONICALIZED to use a separate type for the actual referral data, add an extension marker to that type, and change the checksum key from the "returned session key" to the "AS reply key". Changed AD-LOGIN-ALIAS to contain a sequence of names, to be contained in AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer needed separate checksum. Attempt to clarify the cache lifetime of referral information. Raeburn & Zhu Expires September 6, 2007 [Page 14] Internet-Draft KDC Referrals March 2007 08 Moved Microsoft implementation info to appendix. Clarify lack of local server name canonicalization. Added optional authz-data for login alias, to support user-to-user case. Added requested- principal-name to ServerReferralData. Added discussion of caching information, and referral TGT lifetime. 07 Re-issued with new editor. Fixed up some references. Started history. Authors' Addresses Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139 US Email: raeburn@mit.edu Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Email: lzhu@microsoft.com Raeburn & Zhu Expires September 6, 2007 [Page 15] Internet-Draft KDC Referrals March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Raeburn & Zhu Expires September 6, 2007 [Page 16]