diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt')
-rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt | 896 |
1 files changed, 896 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt new file mode 100644 index 00000000000..24e3ace21d4 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-09.txt @@ -0,0 +1,896 @@ + + + +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] + |