Kerberos Working Group                                         M. Swift
Internet Draft                                         University of WA
Document: draft-ietf-krb-wg-kerberos-referrals-01.txt         J. Brezak
Category: Standards Track                                     Microsoft
                                                             J. Trostle
                                                          Cisco Systems
                                                              July 2001


           Generating KDC Referrals to locate Kerberos realms


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1. Abstract

   The draft documents a new method for a Kerberos Key Distribution
   Center (KDC) to respond to client requests for 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 then receive the ticket.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].

3. Introduction

   Current implementations of the Kerberos AS and TGS protocols, as
   defined in RFC 1510 [3], use principal names constructed from a
   known user or service name and realm. A service name is typically


Swift                 Category - Standards Track                     1








                            KDC Referrals               February 2001


   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's host is in
   before making the TGS request. Current implementations of Kerberos
   typically have a table that maps DNS host names to corresponding
   Kerberos realms. In order for this to work on the client, each
   application canonicalizes the host name of the service by doing a
   DNS lookup followed by a reverse lookup using the returned IP
   address. The returned primary host name is then used in the
   construction of the principal name for the target service. In order
   for the correct realm to be added for the target host, the mapping
   table [domain_to_realm] is consulted for the realm corresponding to
   the DNS host name. 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
   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

Swift                 Category - Standards Track                     2








                            KDC Referrals               February 2001


   its name. You 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 you 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 draft 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 provide a mechanism for
   the KDC to determine the trusted realm authentication path by being
   able to generate referrals to other realms in order to locate
   principals.

   To rectify these problems, this draft introduces three new kinds of
   KDC referrals:

   1. AS ticket referrals, in which the client doesn't know which realm
      contains a user account.
   2. TGS ticket referrals, in which the client doesn't know which
      realm contains a server account.
   3. Cross realm shortcut referrals, in which the KDC chooses the next
      path on a referral chain

4. Realm Organization Model

   This draft assumes that the world of principals is arranged on
   multiple levels: the realm, the enterprise, and the world. A KDC may
   issue tickets for any principal in its realm or cross-realm tickets
   for realms with which it has a direct trust relationship. The KDC
   also has access to a trusted name service that can resolve any name
   from within its enterprise into a realm. This trusted name service
   removes the need to use an untrusted DNS lookup for name resolution.

   For example, consider the following configuration, where lines
   indicate trust relationships:

                  MS.COM
                /        \
               /          \
        OFFICE.MS.COM    NT.MS.COM

   In this configuration, all users in the MS.COM enterprise could have
   a principal name such as alice@MS.COM, with the same realm portion.
   In addition, servers at MS.COM should be able to have DNS host names
   from any DNS domain independent of what Kerberos realm their
   principal resides in.

5. Client Principal Names



Swift                 Category - Standards Track                     3








                            KDC Referrals               February 2001


   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 MS may have
   a client principal name of the form "joe@MS.COM" even though the
   principals are contained in multiple realms. This global name is
   again an alias for the true client principal name, which indicates
   what realm contains the principal. Thus, accounts "alice" in the
   realm ntdev.MS.COM and "bob" in office.MS.COM may logon as
   "alice@MS.COM" and "bob@MS.COM".

   This utilizes a new client principal name type, as the AS-REQ
   message only contains a single realm field, and the realm portion of
   this name doesn't correspond to any Kerberos realm. Thus, the entire
   name "alice@MS.COM" is transmitted in the client name field of the
   AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL.

        KRB-NT-ENTERPRISE-PRINCIPAL     10

   The KDC will recognize this name type and then transform the
   requested name into the true principal name. The true principal name
   can be using a name type different from the requested name type.

6. Requesting a referral

   In order to request referrals, the Kerberos client must explicitly
   request the canonicalize KDC option (bit 15) in the KDC options for
   the TGS-REQ. This flag indicates to the KDC that the client is
   prepared to receive a reply that is a cross-realm TGT. Thus, the
   KDCOptions types is redefined as:

        KDCOptions ::=   BIT STRING {
                          reserved(0),
                          forwardable(1),
                          forwarded(2),
                          proxiable(3),
                          proxy(4),
                          allow-postdate(5),
                          postdated(6),
                          unused7(7),
                          renewable(8),
                          unused9(9),
                          unused10(10),
                          unused11(11),
                          canonicalize(15),
                          renewable-ok(27),
                          enc-tkt-in-skey(28),
                          renew(30),
                          validate(31)
         }

6.1 Client Referrals



Swift                 Category - Standards Track                     4








                            KDC Referrals               February 2001


   The simplest form of ticket referral is for a user requesting a
   ticket using an AS-REQ. In this case, the client machine will send
   the AS request to a convenient trusted realm, either the realm of
   the client machine or the realm of the client name. In the case of
   the name Alice@MS.COM, the client may optimistically choose to send
   the request to MS.COM.

   The client will send the string "alice@MS.COM" in the client
   principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type
   with the crealm set to MS.COM. 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 MUST 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 flag in the KDCoptions
   is set, the KDC will try to lookup the entire name, Alice@MS.COM,
   using a name service. If this lookup is unsuccessful, it MUST return
   the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup is successful,
   it MUST return an error KDC_ERR_WRONG_REALM (0x44) and in the error
   message the cname and crealm field will contain the client name and
   the true realm of the client. If the KDC contains the account
   locally, it MUST return a normal ticket. The client name and realm
   portions of the ticket and KDC reply message MUST be the client's
   true name in the realm, not the globally unique name.

   If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
   new AS request 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 from the first request. This request MUST
   produce a valid AS response with a ticket for the canonical user
   name. The ticket MUST also include the ticket extension containing
   the TE-REFERRAL-DATA with the referred-names set to the name from
   the AS request. Any other error or referral will terminate the
   request and result in a failed AS request.

   [Discussion: Can a PA-REFERRAL-DATA be used instead of a ticket
   extension?]

6.2 Server Referrals

   The server referral mechanism is a bit more complex than the client
   referral mechanism. The primary problem is that the KDC must return
   a referral ticket rather than an error message. There needs to be a
   place to include in the TGS response information about what realm
   contains the service. This is done by returning information about
   the server name in the pre-auth data field of the KDC reply.

   If the KDC resolves the server principal name into a principal in
   its realm, it will return a normal ticket. If the canonicalize flag
   in the KDCoptions is not set, then the KDC MUST only look up the
   name as a normal principal name.

   If the canonicalize flag in the KDCoptions is set and the KDC
   doesn't find the principal locally, the KDC can return a cross-realm

Swift                 Category - Standards Track                     5








                            KDC Referrals               February 2001


   ticket granting ticket to the next hop on the trust path towards a
   realm that may be able to resolve the principal name.

   If the KDC can determine the service principal's realm, it SHOULD
   return the server realm as ticket extension data. The ticket
   extension MUST be encrypted using the session key from the ticket,
   and the same etype as is used to protect the TGS reply body.

   [Discussion: Can preauth data be used instead of a ticket-extension
   for this purpose?]

   The data itself is an ASN.1 encoded structure containing the
   server's realm, and if known, canonical principal name.

                TE-REFERRAL-INFO        20

                TE-REFERRAL-DATA ::= SEQUENCE {
                        referred-server-realm[0]  KERB-REALM
                        referred-name[1]         PrincipalName OPTIONAL
                }


   In order to facilitate cross-realm interoperability, a client SHOULD
   NOT send short names in TGS requests to the KDC. A short name is
   defined as a Kerberos name that includes a DNS name that is not
   fully qualified. The client MAY use forward DNS lookups to obtain
   the long name that corresponds to the user entered short name (the
   short name will be a prefix of the corresponding long name).

   The client may use the referred-name field to tell if it already has
   a ticket to the target server in its ticket cache.

   The client can use this 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.

7. 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). This requires more configurations on the client.
   Instead, the client should be able to request a TGT to the target
   realm from each realm on the route. The KDC will determine the best
   path for the client and return a cross-realm TGT. The client has to
   be aware that a request for a cross-realm TGT may return a TGT for a
   realm different from the one requested.



Swift                 Category - Standards Track                     6








                            KDC Referrals               February 2001


   For compatability, the client MUST use the canonicalize KDCoption if
   it is able to use cross-realm routing from the KDC.

8. Security Considerations

   The original Kerberos specification stated that the server principal
   name in the KDC reply was the same as the server name in the
   request. These protocol changes break that assumption, so the client
   may be vulnerable to a denial of service attack by an attacker that
   replays replies from previous requests. It can verify that the
   request was one of its own by checking the client-address field or
   authtime field, though, so the damage is limited and detectable.

   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.

9. Discussion

   This section contains issues and suggestions that need to be
   incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]:

   1) No means to do name canonicalization if you're not
      authenticating. Is it okay to require credentials in order to do
      canonicalization? If so, how about this: Send a TGS_REQ for the
      service name you have.  If you get back a TGS_REP for a service,
      great; pull out the name and throw out the credentials.  If you
      get back a TGS_REP for a TGT service, ask again in the specified
      realm.  If you get back a KRB_ERROR because policy prohibits you
      from authenticating to that service, we can add to the
      specification that the {realm,sname} in the KRB_ERROR must be the
      canonical name, and the checksum must be used.  As long as the
      checksum is present, it's still a secure exchange with the KDC.

      If we have to be able to do name canonicalization without any
      sort of credentials, either client-side (tickets) or server-side
      (tickets automatically acquired via service key), I think we just
      lose. But maybe GSSAPI should be changed if that's the case.

      There are cases where GSSAPI is not able to know of a canonical


Swift                 Category - Standards Track                     7








                            KDC Referrals               February 2001


      name even without the client name canonicalization proposed in
      this draft.

   2) Secure canonicalization of service name in AS_REQ. If the
      response is an AS_REP, we need a way to tell that the altered
      server name wasn't a result of a MITM attack on the AS_REQ
      message.  Again, the KDC-REP extensible fields could have a new
      required value added when name canonicalization happens,
      indicating what the original principal name (in the AS_REQ
      message) was, and signed using the same key as protects the
      AS_REP.  If it doesn't match what the client requested, the
      messages were altered in transit.

   3) Client name needs referral to another realm, and server name
      needs canonicalization of some sort. The above fixes wouldn't
      work for this case, and I'm not even sure which KDC should be
      doing the canonicalization anyways.


   The other-principal-name datum would probably look something like:

       PrincipalAndNonce ::= SEQUENCE {
                    name[0]     PrincipalName,
                    nonce[1]    INTEGER         -- copied from KDC_REQ
       }
       SignedPrincipal ::= SEQUENCE {
                    name-and-nonce[0]   PrincipalAndNonce,
                    cksum[1]    Checksum
       }
       {PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal
       {PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal

   with the checksum computed over the encoding of the 'name-and-nonce'
   field, and appropriate PA- or TE- numbers assigned.  I don't have a
   strong opinion on whether it'd be a pa-data or ticket extension;
   conceptually it seems like an abuse of either, but, well, I think
   I'd rather abuse them than leave the facility both in and
   inadequate.

   The nonce is needed because multiple exchanges may be made with the
   same key, and these extension fields aren't packed in with the other
   encrypted data in the same response, so a MITM could pick apart
   multiple messages and mix-and-match components.  (In a TGS_REQ
   exchange, a subsession key would help, but it's not required.)

   The extension field would be required to prevent a MITM from
   discarding the field from a response; a flag bit in a protected part
   of the message (probably in 'flags' in EncKDCRepPart) could also let
   us know of a cases where the information can be omitted, namely,
   when no name change is done.  Perhaps the bit should be set to
   indicate that a name change *was* done, and clear if it wasn't,
   making the no-change case more directly compatible with RFC1510.


Swift                 Category - Standards Track                     8








                            KDC Referrals               February 2001


10. References


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   3  Kohl, J., Neuman, C., "The Kerberos Network Authentication
      Service (V5)", RFC 1510, September 1993


11. Author's Addresses

   Michael Swift
   University of Washington
   Seattle, Washington
   Email: mikesw@cs.washington.edu

   John Brezak
   Microsoft
   One Microsoft Way
   Redmond, Washington
   Email: jbrezak@Microsoft.com

   Jonathan Trostle
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA 95134
   Email: jtrostle@cisco.com























Swift                 Category - Standards Track                     9








                            KDC Referrals               February 2001


   Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."



























Swift                 Category - Standards Track                    10