Cross-realm operations in Kerberos allow users to access services offered by foreign realms. The cross-realm operations are based on inter-realm trust built using shared symmetric keys (aka. inter-realm keys) between the KDCs of the realms offering cross-realm services. The current cross-realm authentication model in Kerberos has some design properties that could be the origin of performance, scalability and security issues. The objective of this article is to overview these shortcomings.

The Kerberos protocol offers cross-realm authentication capabilities. This allows users to obtain service tickets to access resources in foreign realms. In order to access such services, the users first contact their home KDC asking for a TGT that will be used with the TGS of the foreign realm (message 1). If the home realm and the foreign realm share keys and have an established trust relationship, the home KDC delivers the requested TGT.

However, if the home realm does not share inter-realm keys with the foreign realm, the home KDC will provide a TGT that can be used with an intermediary foreign realm that is likely to be sharing inter- realm keys with the target realm (message 2). The client can use this 'intermediary TGT' to communicate with the intermediary KDC (message 3) which will iterate the actions taken by the home KDC: If the intermediary KDC does not share cross-realm keys with the target foreign realm it will point the user to another intermediary KDC (just as in the first exchange between the user and its home KDC). However, in the other case (when it shares inter- realm keys with the target realm), the intermediary KDC will issue a TGT that can be used with the KDC of the target realm (message 4).

After obtaining a TGT for the desired foreign realm, the client uses it to obtain service tickets from the TGS of the foreign realm (messages 5 and 6). Finally the user authenticates to the service using the service ticket.

The Figure below shows the exchanges between the different entities involved in a cross-realm authentication aiming at delivering a service ticket to a client when the service is deployed in a foreign realm.

                                +-------+
                                |       |
                    ST-SRV?  5  | KDC-T | 6  ST-SRV
          +-------------------->|       |---------------------+
          |                     +-------+                     |
          |                                                   |
          |                     +-------+                     |
          |         TGT-T?   3  |       | 4  TGT-T            |
          |      +------------->| KDC-I |--------------+      |
          |      |              |       |              |      |
          |      |              +-------+              |      |
          |      |                                     |      |
          |      |              +-------+              |      |
          |      |  TGT-T?   1  |       | 2  TGT-I     |      |
          |      |      +------>| KDC-H |-------+      |      |
          |      |      |       |       |       |      |      |
          |      |      |       +-------+       |      |      |
          |      |      |                       |      |      |
          |      |      |                       |      |      |
          |      |      +------ +--------+ <----+      |      |
          |      +------------- | Client | <-----------+      |
          +-------------------- +--------+ <------------------+






   H      : Home realm
   I      : Intermediary realm that shares inter-realm keys with H and T
   T      : Target realm
   KDC-X  : KDC of realm X (where X in {H,I,T})
   TGT-X ?: A TGS-REQ to request a TGT for realm X
   ST-SRV?: A TGS-REQ to request a service ticket for service SRV
   TGT-X  : A TGS-REP that contains a a TGT for realm X
   ST-SRV : A TGS-REP that contains a service ticket for service SRV

In Kerberos, the cross-realm operations are based on trust relationships between the Kerberos realms. There are two types of inter-realm trust relationships: Direct and Indirect trust relationship. A direct trust relationship means that the two realms involved in the cross-realm authentication share keys and their respective TGS principals are registered in each other's KDC. When only direct trust relationships are used, the KDC of each realm must maintain keys with all foreign realms. This can become a cumbersome task when the number of realms increase. The indirect trust relationship attempts to improve the direct trust relationship model by allowing two realms to perform cross-realm operations if there exist a chain of trust (also referred to as authentication path) that links the participating realms. However, the determination of the authentication path is an issue, there are no generic and scalable means by which the Kerberos KDC or client can dynamically discover possible authentication paths and chains of trusts between two realms.

When intermediary realms are involved, the success of the cross- realm authentication completely depends on the realms that are part of the authentication path. If any of the realms in the authentication path is not available, then the principals of the end-realms can not perform cross-realm operations. This constitutes a reliability issue that can fail Kerberos as a candidate authentication system for mission-critical deployments such as large factory automation and military applications. Moreover, during cross-realm authentication, any KDC in the authentication path can learn the session key that will be used between the client and the desired service, this means that any intermediary realm is able to spoof the identify of the service and the client as well as to eavesdrop on the communication between the client and the server. If an intermediary KDC is corrupted, all the authentication operations using the corrupted KDC as intermediary KDC will be corrupted. The forward secrecy issue in cross-realm operations is a serious problem, it makes the whole web of trust as vulnerable as the weakest KDC.

During cross-realm operations, Kerberos clients have to perform TGS exchanges with all the KDCs in the trust path, including the home KDC and the target KDC. In some cases where the client has limited computational capabilities, the overhead of these cross- realm exchanges may grow into unacceptable delays. Furthermore, if the number of intermediary realms increases, the delay introduced by the cross-realm messages can result in unacceptable delays due to network latency. This effect can be experienced even with devices with superior performance.

Within the IETF, some works started to target the issues above. At the time of this writing, the problem statement is currently in last call to become an informational RFC draft-ietf-krb-wg-cross-problem-statement.

As for solutions, two documents exist (both expired):

• draft-zrelli-krb-xtgsp
• draft-kamada-krb-client-friendly-cross

Labels: kerberos, security