[krbdev.mit.edu #2559] Replacement Text Explaining [capaths] for Admin Guide

["Jeffrey Altman [Kermit Project]" via RT]

[capaths]

In order to perform direct (non-hierarchical) cross-realm authentication,
a database is needed to specify the authentication paths between the
various source and destination realms. This section defines the database.

The database is used for different purposes by a Kerberos client and
a Kerberos server (kdc and application server).  The client uses the
capaths to determine the authentication path between the client principal
realm and the realm of the server,  The server verifies the the transited
field of the ticket received from the client against this database.

The database defines for each source and destination pair an ordered list
of intermediary realms which represent cross realm relationships.  The
authentication paths specified in the database are unidirectional.
Each direction of a bidirectional path must be specified separately.
 
The best way to explain how to construct the database is to show by example.
The realms ANL.GOV, PNL.GOV, and NERSC.GOV all wish to use the ES.NET realm
as an intermediate realm.  TEST.ANL.GOV is a sub realm of ANL.GOV which must
authenticate with NERSC.GOV but not PNL.GOV.


                                     NERSC.GOV
                                    /
                                   /
  TEST.ANL.GOV -- ANL.GOV -- ES.NET
                                   \
                                    \
                                     PNL.GOV


Enumerating the desired relationships results in the following table.


  Client                                   Service
 Principal      Intermediary              Principal
  Realm            Realms                   Realm
----------------------------------------------------------
  ANL.GOV                                 TEST.ANL.GOV
  ANL.GOV         ES.NET                  PNL.GOV
  ANL.GOV         ES.NET                  NERSC.GOV
  ANL.GOV                                 ES.NET
  TEST.ANL.GOV                            ANL.GOV
  TEST.ANL.GOV    ANL.GOV                 ES.NET
  TEST.ANL.GOV    ANL.GOV     ES.NET      NERSC.GOV
  PNL.GOV                                 ES.NET
  PNL.GOV         ES.NET                  ANL.GOV
  PNL.GOV         ES.NET                  NERSC.GOV
  NERSC.GOV                               ES.NET
  NERSC.GOV       ES.NET                  PNL.GOV
  NERSC.GOV       ES.NET                  ANL.GOV
  NERSC.GOV       ES.NET      ANL.GOV     TEST.ANL.GOV
  ES.NET                                  ANL.GOV   
  ES.NET          ANL.GOV                 TEST.ANL.GOV
  ES.NET                                  NERSC.GOV
  ES.NET                                  PNL.GOV


 From the table we can then produce the [capaths] sections for each of
the five realms.  The section consists of a separate subsection for each
client principal realm.  Within each subsection are one or more entries
for each destination realm specifying the intermediate realm(s) used
on the path.  A path with no intermediary realms is indicated by the
symbol "." (period).

The [capaths] section for ANL.GOV systems would look like this:

[capaths]
    ANL.GOV = {
        TEST.ANL.GOV = .
        PNL.GOV = ES.NET
        NERSC.GOV = ES.NET
        ES.NET = .
    }
    TEST.ANL.GOV = {
        ANL.GOV = .
    }
    PNL.GOV = {
        ANL.GOV = ES.NET
    }
    NERSC.GOV = {
        ANL.GOV = ES.NET
        TEST.ANL.GOV = ES.NET
    }
    ES.NET = {
        ANL.GOV = .
    }


The [capaths] section for NERSC.GOV systems:

[capaths]
    NERSC.GOV = {
        ANL.GOV = ES.NET
        TEST.ANL.GOV = ES.NET
        TEST.ANL.GOV = ANL.GOV
        PNL.GOV = ES.NET
        ES.NET = .
    }
    ANL.GOV = {
        NERSC.GOV = ES.NET
    }
    PNL.GOV = {
        NERSC.GOV = ES.NET
    }
    ES.NET = {
        NERSC.GOV = .
    }
    TEST.ANL.GOV = {
        NERSC.GOV = ANL.GOV
        NERSC.GOV = ES.NET
    }

The [capaths] section for ES.NET systems:
    ES.NET = {
        ANL.GOV = .
        TEST.ANL.GOV = ANL.GOV
        NERSC.GOV = .
        PNL.GOV = .
    }
    ANL.GOV = {
        ES.NET = .
        NERSC.GOV = ES.NET
        PNL.GOV = ES.NET
    }
    TEST.ANL.GOV = {
        ES.NET = ANL.GOV
        NERSC.GOV = ANL.GOV
    }
    PNL.GOV = {
        ES.NET = .
    }
    NERSC.GOV = {
        ES.NET = .
    }

The [capaths] section for PNL.GOV systems:
    PNL.GOV = {
        ANL.GOV = ES.NET
        NERSC.GOV = ES.NET
        ES.NET = .
    }
    ANL.GOV = {
        PNL.GOV = ES.NET
    }
    NERSC.GOV = {
        PNL.GOV = ES.NET
    }
    ES.NET = {
        PNL.GOV = .
    }

The [capaths] section for TEST.ANL.GOV systems:
    TEST.ANL.GOV = {
        ANL.GOV = .
        ES.NET = ANL.GOV
        NERSC.GOV = ANL.GOV
        NERSC.GOV = ES.NET
    }
    ANL.GOV = {
        TEST.ANL.GOV = .
    }
    ES.NET = {
        TEST.ANL.GOV = ANL.GOV
    }
    NERSC.GOV = {
        TEST.ANL.GOV = ES.NET
        TEST.ANL.GOV = ANL.GOV
    }  

In the above [capaths] sections, the ordering of the destination realm 
values
are not important except when the same destination realm is used more 
then once
to specify a sequence of intermediary realms.  (Ordering is never 
important to
the server since the transited realm field in the ticket is not ordered.)

Client systems from which client principals issued by multiple realms 
are used
must include the transited realm rules appropriate for each of the client
principals. 

The error message "Illegal cross-realm ticket" implies that a [capaths]
section for the authentication path must be added to the server machine.
The error message "KDC policy rejects request" implies that the [capaths]
section on the server specifies an authentication path which does not match
the authentication path that was actually used.

Cross realm authentication paths are not currently supported by DCE. DCE
security servers can be used with Kerberized clients and servers, but 
versions
prior to DCE 1.1 did not fill in the transited field, and should be used 
with
caution.