Usage of the Kerberos 5 Transited Field

[Doug Engert <[e-mail]>]

I have a concern about the use of the Transited field of the
Kerberos 5 ticket. "draft-ietf-cat-kerberos-pk-cross-00.txt" and
"draft-ietf-cat-kerberos-pk-init-02.txt" both propose to add the names
of the certifiers in the certification path to the transited field of
the ticket. This is all well and good, but imposes additions
problems on current implementations.   

RFC-1510 states in section 1.1: "...the hierarchical organization
allows an authentication path to be easily constructed. If a
hierarchical organization is not used, it may be necessary to consult
some database to construct an authentication path between realms."

And it also states: "It is important for the end-service to
know which realms were transited when deciding how much faith to place
in the authentication process". Thus the end-service will enforce some
policy based on its knowledge of which realms should be listed in the
transited field. 

Most implementations of Kerberos use a default hierarchy defined by
the realm names of the client and end-service. This is used by the
client to obtain the necessary tickets, and is used by the
end-service to define the policy to be used for checking for an acceptable
authentication.   

Here are my concerns:

 o RFC-1510 does not state how a hierarchy is to be generated, and
   there are a number of ways to do this. Most kerberos implementations
   use the client and end-service realm names, and parse them in DNS
   style. OSF/DCE uses the client and end-service realm names, but uses a
   different separator character, and parses in the other direction. Thus
   both are within the RFC specifications, but cross-realm authentication
   is possible only when the two realms share an inter-realm
   key. i.e. the transited field is null, and there is no problem with
   determining the hierarchy between the two realms.

 o When "pk-cross" and/or "pk-init" are implemented, most current
   implementations of Kerberos will fail to function unless they are
   modified to recognize a new policy, and not rely on the hierarchy
   based on the realm names. In fact, even when the client and
   end-service are with in the same realm, the transited field may
   contain an entry if "pk-init" was used, and current end-services may
   not accept this. 

 o RFC-1510 implies that the end-service should check the transited
   field. But in most implementations, the intermediate TGSs also check
   the transited field. When using the hierarchical approach this is
   trivial, since it is easy to generate the same hierarchy from the
   client and end-service realm names. But if "pk-init" and/or "pk-cross"
   add additional entries to the transited filed, then each intermediate
   KDC must know what policies are valid between the client and end-service. 

 o RFC-1510 does not require a TGS to check the transited field, it
   only says an end-service should. 

Here is what I would like to see changed:

 o RFC-1510 or "pk-init" state that a TGS will always check the
   transited field against the realm's policy before issuing a ticket
   for an end-service in its realm. 

This relieves the end service of having to check the policy itself if
it is willing to live with the realm's policy, although it is still
free to check it. This will simplify the the end-service processing,
and maintenance of any policy information which is now localized to the
TGSs. 
 
This also says the the TGS does not need to check the transited field
when issuing a ticket for another realm. The only tickets issued for
another realm are for the other realm's TGS when doing cross-realm
authentication. This relieves the intermediate realm's TGS of having
to know (and enforce) the policy of the end-service's realm. It is
still free to do so, but unless the policy database is kept up to
date, it might interfere in some situations.

 o The KRB_TGS_REP message be extended to allow for the client's TGS
   to return, in addition to a ticket for the "closest" realm, an
   authentication path which should be used to obtain the tickets to get
   to the end-service's realm. (See RFC-1510 Section 3.3.3.) 

Without this, either the client has to (1) rely on a hierarchy path
model of authentication, (2) maintain a configurable authentication
path table, or (3) rely on each of the intermediate TGS's to know the
path to the end-service's realm.

(1) Has the problem as stated above that different implementations of
kerberos have implemented the notion of a hierarchy differently. (2)
Has the maintenance problem of having this table on the client. (3)
Has the problem of the intermediate TGS's having to know the path to
the end-server's TGS. 

Conclusion

The MIT Kerberos V5-1.0 release has the configurable authentication
path code which implements non-hierarchical authentication paths which
can be used to solve the above problems, but it suffers from a
maintenance view-point, and requires intermediate realms to also
maintain the authentication paths to all the other realms.
   
These two changes as outlined above, remove the responsibility of the
client, end-service and intermediate TGS's of having to know or to
check authentication paths. They place the responsibility on the
client's TGS to supply the path to the end-service's realm, and for
the end-service's TGS to check the authentication path. The changes
also streamline the processing, reduce the maintenance and allow for
the handling of the additional information being proposed by "pk-init"
and "pk-cross".


-- 
 
 Douglas E. Engert  <[e-mail]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 [phone]