CVS shishi/doc/specifications

[shishi-commit]

Update of /home/cvs/shishi/doc/specifications
In directory dopio:/tmp/cvs-serv993

Added Files:
        draft-ietf-krb-wg-kerberos-referrals-05.txt 
Log Message:
Add.


--- 
/home/cvs/shishi/doc/specifications/draft-ietf-krb-wg-kerberos-referrals-05.txt 
    2004/10/28 20:42:21     NONE
+++ 
/home/cvs/shishi/doc/specifications/draft-ietf-krb-wg-kerberos-referrals-05.txt 
    2004/10/28 20:42:21     1.1


NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                             K. Jaganathan
Obsoletes: 2478 (if approved)                      Microsoft Corporation
Expires: April 25, 2005                                 October 25, 2004


           Generating KDC Referrals to locate Kerberos realms
                  draft-ietf-krb-wg-kerberos-referrals-05

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 April 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

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



Zhu & Jaganathan         Expires April 25, 2005                 [Page 1]

Internet-Draft               KDC Referrals                  October 2004


   then receive the ticket.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Conventions Used in This Document  . . . . . . . . . . . . .   5
   3.   Requesting a Referral  . . . . . . . . . . . . . . . . . . .   6
   4.   Realm Organization Model . . . . . . . . . . . . . . . . . .   7
   5.   Client Name Canonicalization . . . . . . . . . . . . . . . .   8
   6.   Client Referrals . . . . . . . . . . . . . . . . . . . . . .   9
   7.   Server Referrals . . . . . . . . . . . . . . . . . . . . . .  10
   8.   Cross Realm Routing  . . . . . . . . . . . . . . . . . . . .  12
   9.   Compatibility with Earlier Implementations of Name
        Canonicalization . . . . . . . . . . . . . . . . . . . . . .  13
   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  14
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  15
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  16
   12.1   Normative References . . . . . . . . . . . . . . . . . . .  16
   12.2   Informative References . . . . . . . . . . . . . . . . . .  16
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  16
        Intellectual Property and Copyright Statements . . . . . . .  17






























Zhu & Jaganathan         Expires April 25, 2005                 [Page 2]

Internet-Draft               KDC Referrals                  October 2004


1.  Introduction

   Current implementations of the Kerberos AS and TGS protocols, as
   defined in [KRBCLR], 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 [RFC822].  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.  In order for this to work on the client, each
   application canonicalizes the host name of the service, for example
   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



Zhu & Jaganathan         Expires April 25, 2005                 [Page 3]

Internet-Draft               KDC Referrals                  October 2004


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

   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.



















Zhu & Jaganathan         Expires April 25, 2005                 [Page 4]

Internet-Draft               KDC Referrals                  October 2004


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














































Zhu & Jaganathan         Expires April 25, 2005                 [Page 5]

Internet-Draft               KDC Referrals                  October 2004


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) [KRBCLR] 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)
                   -- 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 [KRBCLR].

































Zhu & Jaganathan         Expires April 25, 2005                 [Page 6]

Internet-Draft               KDC Referrals                  October 2004


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:

                        MS.COM
                      /        \
                     /          \
              OFFICE.MS.COM  NTDEV.MS.COM

   In this configuration, all users in the MS.COM enterprise could have
   a principal name such as address@hidden, 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
   principals reside in.




























Zhu & Jaganathan         Expires April 25, 2005                 [Page 7]

Internet-Draft               KDC Referrals                  October 2004


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 MS may have

[561 lines skipped]