HEIMDAL: move code from source4/heimdal* to third_party/heimdal*

This makes it clearer that we always want to do heimdal changes
via the lorikeet-heimdal repository.

Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz>

Autobuild-User(master): Joseph Sutton <jsutton@samba.org>
Autobuild-Date(master): Wed Jan 19 21:41:59 UTC 2022 on sn-devel-184

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]
+