add an invalid protection level to the enum

[heimdal.git] / doc / standardisation / draft-ietf-krb-wg-kerberos-referrals-11.txt

NETWORK WORKING GROUP                                         K. Raeburn
Internet-Draft                                                       MIT
Updates: 4120 (if approved)                                       L. Zhu
Intended status: Standards Track                   Microsoft Corporation
Expires: January 15, 2009                                  July 14, 2008


 Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm
                               Referrals
                draft-ietf-krb-wg-kerberos-referrals-11

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 January 15, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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



Raeburn & Zhu           Expires January 15, 2009                [Page 1]
\f
Internet-Draft                KDC Referrals                    July 2008


   referral information to reach the realm of the target principal and
   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.  Enterprise Principal Name Type . . . . . . . . . . . . . . . .  5
   6.  Name Canonicalization  . . . . . . . . . . . . . . . . . . . .  6
   7.  Client Referrals . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Server Referrals . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Cross Realm Routing  . . . . . . . . . . . . . . . . . . . . . 12
   10. Caching Information  . . . . . . . . . . . . . . . . . . . . . 12
   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   12. Number Assignments . . . . . . . . . . . . . . . . . . . . . . 13
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
     14.1.  Shared-password case  . . . . . . . . . . . . . . . . . . 14
     14.2.  Preauthentication data  . . . . . . . . . . . . . . . . . 14
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     16.1.  Normative References  . . . . . . . . . . . . . . . . . . 15
     16.2.  Informative References  . . . . . . . . . . . . . . . . . 15
   Appendix A.  Compatibility with Earlier Implementations of
                Name Canonicalization . . . . . . . . . . . . . . . . 15
   Appendix B.  Document history [REMOVE BEFORE PUBLICATION]  . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19




















Raeburn & Zhu           Expires January 15, 2009                [Page 2]
\f
Internet-Draft                KDC Referrals                    July 2008


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 January 15, 2009                [Page 3]
\f
Internet-Draft                KDC Referrals                    July 2008


   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 as defined in later sections, 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 January 15, 2009                [Page 4]
\f
Internet-Draft                KDC Referrals                    July 2008


                   -- 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.  Enterprise Principal Name Type

   The NT-ENTERPRISE type principal name contains one component, a
   string of realm-defined content, which is intended to be used as an
   alias for another principal name in some realm in the enterprise.  It
   is used for conveying the alias name, not for the real principal
   names within the realms, and thus is only useful when name
   canonicalization is requested.

   The intent is to allow 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



Raeburn & Zhu           Expires January 15, 2009                [Page 5]
\f
Internet-Draft                KDC Referrals                    July 2008


   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 principal name type, as the KDC-REQ message only
   contains a single client realm field, and the realm portion of this
   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].


6.  Name Canonicalization

   A service or account may have multiple principal names.  For example,
   if a host is known by multiple names, host-based services on it may
   be known by multiple names in order to prevent the client from
   needing a secure directory service to determine the correct hostname
   to use.  In order that the host should not need to be updated
   whenever a new alias is created, the KDC may provide the mapping
   information to the client in the credential acquisition process.

   If the "canonicalize" KDC option is set, then the KDC MAY change the
   client and server principal names and types in the AS response and
   ticket returned from the name type of the client name in the request.
   In a TGS exchange, the server principal name and type may be changed.

   If the client principal name is changed in an AS exchange, the KDC
   must include a mandatory PA-DATA object authenticating the client
   name mapping:

   ClientReferralInfo ::= SEQUENCE {
     requested-name  [0] PrincipalName,
     mapped-name     [1] PrincipalName,
     ...
   }
   PA-CLIENT-CANONICALIZED ::= SEQUENCE {
     names          [0] ClientReferralInfo,
     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



Raeburn & Zhu           Expires January 15, 2009                [Page 6]
\f
Internet-Draft                KDC Referrals                    July 2008


   (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.)

   If the server name is changed, a PA-SERVER-REFERRAL preauth data
   entry MUST be supplied by the KDC and validated by the client.

   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
   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.

   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.)

   The use of AD-KDC-ISSUED authorization data elements in cross-realm
   cases has not been well explored at this writing; hence we will only
   specify the inclusion of this data in the one-realm case.  The alias
   information SHOULD be dropped in the general cross-realm case.



Raeburn & Zhu           Expires January 15, 2009                [Page 7]
\f
Internet-Draft                KDC Referrals                    July 2008


   However, a realm MAY implement a policy of accepting and re-signing
   (wrapping in a new AD-KDC-ISSUED element) alias information provided
   by certain trusted realms, in the cross-realm ticket-granting
   service.

   The canonical principal name for an alias may not be in the form of a
   ticket-granting service name, as (in a case of server name
   canonicalization) that would be construed as a case of cross-realm
   referral, described below.


7.  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 may look up the
   client principal name using some kind of name service or directory
   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 the cname returned
   in this error message.

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



Raeburn & Zhu           Expires January 15, 2009                [Page 8]
\f
Internet-Draft                KDC Referrals                    July 2008


   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].  However, this requires trusting the referred-to
   realm's KDCs.  Clients should limit the referral mappings they will
   accept to realms trusted via some local policy.  Some possible
   factors that might be taken into consideration for such a policy
   might include:

   o  Any realm indicated by the local KDC, if the returned KRB-ERROR
      message is protected by some additional means, for example using a
      preauthentication scheme using a public key known to be associated
      with the KDC, or an IPsec tunnel known to have the desired KDC as
      the remote endpoint
   o  A list of realms configured by an administrator
   o  Any realm accepted by the user when explicitly prompted

   There is currently no provision for changing the client name in a
   client referral response, because there is no method for verifying
   that a man-in-the-middle attack did not change the requested name in
   the request on the way to the KDC.


8.  Server Referrals

   The primary difference in server referrals is that the KDC returns 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 "canonicalize" flag in the KDC options is set and the KDC
   doesn't find the principal locally, either as a regular principal or
   as an alias for another local principal, 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



Raeburn & Zhu           Expires January 15, 2009                [Page 9]
\f
Internet-Draft                KDC Referrals                    July 2008


   reply ticket.  The key usage value for the encryption operation used
   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

         SERVER-REFERRAL-DATA ::= EncryptedData
                               -- ServerReferralData
                               -- returned session key, ku=26

         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
                referral-valid-until     [3] KerberosTime OPTIONAL,
                rep-cksum                [4] Checksum,
                               -- associated {AS,TGS}-REP with no padata
                               -- reply key, ku=[TBD]
                ...
         }

   The rep-cksum field is a checksum computed over the DER encoding of
   the AS-REP or TGS-REP message with which the SERVER-REFERRAL-DATA is
   included, but with the padata field omitted.  It SHOULD be computed
   using the mandatory-to-implement checksum type associated with the
   encryption type of the reply key.  (Encrypting the referral data in
   with the reply key but without the checksum only proves that it was
   generated by one of the parties with access to the reply key; it is
   not proof against cut-and-paste attacks combining parts of different
   KDC replies using the same reply key.)

   Clients SHALL NOT accept a reply ticket in which 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



Raeburn & Zhu           Expires January 15, 2009               [Page 10]
\f
Internet-Draft                KDC Referrals                    July 2008


   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.

   The client may cache the mapping of the requested name to the name of
   the next realm to use and the principal name to ask for.  (See
   Section 10.)  The referral-valid-until field, if present, conveys how
   long this information is valid for.

   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.






Raeburn & Zhu           Expires January 15, 2009               [Page 11]
\f
Internet-Draft                KDC Referrals                    July 2008


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 8, 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.

   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.

   If the referral-valid-until field is provided in the PA-SERVER-
   REFERRAL-DATA message, it indicates the expiration time of this data;
   if it is not included, the expiration time of the TGT is used.  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



Raeburn & Zhu           Expires January 15, 2009               [Page 12]
\f
Internet-Draft                KDC Referrals                    July 2008


   (e.g., DNS alias lifetimes) they may or may not wish to incorporate
   into credential expiration times in cases of referrals.


11.  Open Issues

   Client referral info validation

   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?

   Should list the policies that need to be defined.

   More examples: u2u, policy checks, maybe cross-realm.

   Possibly generalize the integrity/privacy protection on
   ServerReferralData into a general padata wrapper?

   Is PA-SERVER-REFERRAL needed in a TGS exchange?

   Do we need to send requested-name fields, or can we just include them
   in checksums?


12.  Number Assignments

   Most number registries in the Kerberos protocol have not been turned
   over to IANA for management at the time of this writing, hence this
   is not an "IANA Considerations" section.

   Various values do need assigning for this draft:
      AD-LOGIN-ALIAS
      PA-CLIENT-CANONICALIZED
      key usage value for PA-CLIENT-CANONICALIZED field canon-checksum


13.  IANA Considerations

   None at present.


14.  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



Raeburn & Zhu           Expires January 15, 2009               [Page 13]
\f
Internet-Draft                KDC Referrals                    July 2008


   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.

14.1.  Shared-password case

   A special case to examine is when the user is known (or correctly
   suspected) to use the same password for multiple accounts.  A man-in-
   the-middle attacker can either alter the request on its way to the
   KDC, changing the client principal name, or reply to the client with
   a response previously send by the KDC in response to a request from
   the attacker.  The response received by the client can then be
   decrypted by the user, though if the default "salt" generated from
   the principal name is used to produce the user's key, a PA-ETYPE-INFO
   or PA-ETYPE-INFO2 preauth record may need to be added or altered by
   the attacker to cause the client software to generate the key needed
   for the message it will receive.  None of this requires the attacker
   to know the user's password, and without further checking, could
   cause the user to unknowingly use the wrong credentials.

   In normal [RFC4120] operation, a generated AP-REQ message includes in
   the Authenticator field a copy of the client's idea of its own
   principal name.  If this differs from the name in the KDC-generated
   Ticket, the application server will reject the message.

   With client name canonicalization as described in this document, the
   client may get its principal name from the response from the KDC.
   Requiring the PA-CLIENT-CANONICALIZED data lets the client securely
   check that the requested name was not altered in transit.  If the PA-
   CLIENT-CANONICALIZED data is absent, the client can use the principal
   name it requested.

14.2.  Preauthentication data

   In cases of credential renewal, forwarding, or validation, if
   credentials are sent to the KDC that are not an initial ticket-
   granting ticket for the client's home realm, the encryption key used
   to protect the TGS exchange is one known to a third party (namely,
   the service for which the credential was issued).  Consequently, in
   such an exchange, the protection described earlier for the



Raeburn & Zhu           Expires January 15, 2009               [Page 14]
\f
Internet-Draft                KDC Referrals                    July 2008


   preauthentication data cannot be assumed to provide a secure channel
   between the KDC and the client, and such preauth data MUST NOT be
   trusted for any information that needs to come from the KDC.


15.  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.


16.  References

16.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.

16.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.

   [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

   The Microsoft Windows 2000 and Windows 2003 releases included an



Raeburn & Zhu           Expires January 15, 2009               [Page 15]
\f
Internet-Draft                KDC Referrals                    July 2008


   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:



          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



Raeburn & Zhu           Expires January 15, 2009               [Page 16]
\f
Internet-Draft                KDC Referrals                    July 2008


   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]

   11 Changed title.  Better protection on server referral preauth data.
      Support server name canonicalization.  Rename ReferralInfo to
      ClientReferralInfo.  Disallow alias mapping to a TGT principal.
      Explain why no name change in client referrals.  Add empty IANA
      Considerations.  Add some notes on preauth data protection during
      renewal etc.
   10 Separate enterprise principal names into a separate section.  Add
      a little wording to suggest server principal name canonicalization
      might be allowed; not fleshed out.  Advise against AD-KDC-ISSUED
      in cronn-realm cases.  Advise policy checks on returned client
      referral info, since there's no security.  List number
      assignments.  Add security analysis of shared-password case.  No
      longer plan to remove Microsoft appendix.  Add referral-valid-
      until field.
   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.
   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.





Raeburn & Zhu           Expires January 15, 2009               [Page 17]
\f
Internet-Draft                KDC Referrals                    July 2008


   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 January 15, 2009               [Page 18]
\f
Internet-Draft                KDC Referrals                    July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 January 15, 2009               [Page 19]
\f