Revisions to RFC 1510 - More on Checking Transited Field

["Douglas E. Engert" <[e-mail]>]

At 06:47 AM 4/8/97 -0700, Clifford Neuman wrote:
>
>If you have any additional issues that need to be resolved in this
>draft, please send me an e-mail message with the subject line:
>RFC1510 Revision - <short name of issue>.
>
>Clifford Neuman
>
>
Cliff, 
Here is some more thoughts on the checking of the transited field based on
the CAT meeting: 

I believe all current implementations of K5 check the transited field,
and that both the end-server checks and that the KDC checks when issuing 
tickets. There are 4 possibilities:

 (1) Neither the KDC nor the end-server checks. 
      Bad implementation which should not participate in cross-realm
                        authentication since this can be exploited. This
was the case prior to
      K5 beta 4(?). The old  DCE 1.0.3 was another example. 

 (2) The KDC and the end-server both check. I believe that this is the case
for
      all current implementations, but this needs to be checked. The KDCs
are also 
      checking all tickets, even cross-realm tickets for other realms. If the 
      TGS is considered a "end-service" since it is using a ticket, then
this is                   required by the RFC, but this does not appear to
have been the intent.  

 (3) The KDC checks and the end-server does not. I doubt that any
        implementations would have implemented this explicitly, but this is 
      the goal.

 (4) The KDC does not check, but the end-server does. This is what is closest
      to the current RFC 1510, but I doubt that any implementations do this.
  
I believe that if the end-server can trust the KDC to have checked, (3) then
this can simplify implementation, and maintenance. As Ted suggested this might
require a flag, if there are implementations like (4) which could not easily
comply or their KDC implementations are used with other end-service
implementations. (Since these implementations should already have the code
in the library for the end-servers to use to check the transited field, it
should be easy to use these routines in the KDC as well.)

The flag would be needed if there are type (3) end-servers using a (4) KDC.
Without the flag this combination is a type (1).

The proposal to require the KDC to check the transited field when issuing
tickets 
for its own realm, is a change to the RFC, but not the protocol. It does
not prevent the end-server from checking  nor does it  prevent KDCs from
checking the transited field when issuing cross-realm tickets.
  
Migration paths:
 (1) -> (2) or (3)
 (4) -> (2)  
 (2) -> (3)      
 
Doug Engert

----------------------------------
Text of original post which proposed two changes:
---------------------------------

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]