Having received both SK_x,y and T_y from the TGS, X now can start the dialogue with Y as before. One detail that needs to be mentioned is that the initial message X sends to Y includes T_y and an authenticator. An authenticator is used for X and Y to prove that they are who they claim to be. Principal Y decrypts T_y and obtains the session key SK_x,y. The authenticator was encrypted by X using this session key and therefore can be decrypted by Y only through using the same session key. The authenticator includes the sending principal’s name X and the current timestamp. Y verifies the identify of X by comparing the decrypted timestamp with its own synchronized timestamp. Because the timestamp only can be decrypted with the same session key used for encryption, Y verifies X.

If bilateral authentication is required, X can request this of Y. To meet this requirement, Y takes the timestamp from the authenticator, increments the timestamp by one, encrypts this value with the session key, and sends the result back to X. The incremented timestamp can be decrypted and verified by X using the session key. Figure 2.4 provides a graphical simplification of how two parties use a KDC to begin a secure session.

Figure 2.4  Interacting with a Kerberos KDC to initiate a secure communications session.

To summarize, Kerberos provides for two-way, third-party authentication. The key points are as follows:

•  A KDC shares a secret with each principal.

•  Each principal authenticates to the KDC using this shared secret or password-derived value.

•  When an originating principal wants to securely communicate with a receiving principal, the originating principal obtains a new random session key from the KDC.

•  The KDC also sends the originator a ticket that is the session key encrypted with the secret of the receiving principal.

•  The originating principal sends the ticket and an authenticator to the receiving principal.

•  The receiving principal decrypts the ticket and obtains the session key. This key is used to decrypt the authenticator and to verify the identity of the originator.

•  If bilateral authentication is required, the receiver can demonstrate knowledge of the shared session key by encrypting a modified timestamp from the authenticator and returning this value to the originator.

Integrating Kerberos and UNIX Login

This login process identifies and authenticates the user X into the Kerberos environment, but what does this have to do with a login session on UNIX or NT? Recall from the previous discussions that in UNIX, for example, your UID and GIDs determine who you are on the system and what you can do. In the Kerberos login described, your identity is based on your principal name and your Kerberos password. Environments that integrate UNIX or NT with Kerberos can be confusing because you can have two identities. Because both Kerberos and UNIX implement their own security models, a separate identity is used in both security domains depending on the situation.

Consider the following scenario. If you have a personal UNIX workstation, you will have an account on that system. When you login and start running programs, the UID and GIDs assigned to you form your credentials. All of the programs on that system look at your UID and GIDs to decide what you are permitted to do on the system. Kerberos is a completely different environment. In order for a program to take advantage of the features in Kerberos, that program must be instrumented to or enabled for Kerberos. For you to interact with a Kerberos enabled program, you must have a Kerberos credential. The only way to obtain a credential is to authenticate to the Kerberos server. None of the programs delivered with your UNIX system will by default be able to do anything with your Kerberos credential unless they have been modified to do so. Although, Solaris provides some UNIX network applications that are enhanced to work with Kerberos.

Because the operating system security kernel does not make decisions based on Kerberos credentials, think of Kerberos as an application level framework. Applications are written specifically to work with Kerberos, and these applications sit on top of the operating system. Many of these applications are servers that run with root or special privileges on the operating system. To show you how confusing this can be, the Kerberos enabled application understands and interacts with Kerberos security internally, but the application itself is running within the security context of the UNIX operating system! When you remember that Kerberos is made of several different programs running on various operating systems, this concept does not seem so hard to grasp. Still, it’s an interesting dichotomy that surfaces with security products. Using terminology from Chapter 1, Kerberos augments the security of most operating systems, rather than replacing operating system components. Because Kerberos was designed to improve distributed systems security, it’s not surprising that this is the case.

Operating systems that have been integrated with Kerberos rely on modified login programs or procedures. If the change is transparent to the user, then login will create a shell with your credentials and obtain your Kerberos credentials from the server. In this way, programs that make access control decisions based on your UID and GIDs will work as usual, and any programs needing your Kerberos credentials can obtain these where they are stored on the local system. If integrated properly, the authentication step will not rely on finding your password in /etc/password (or the shadow file), but will use the Kerberos server to verify identity. In this way, the integrated system is taking advantage of a centralized store for user passwords. A word of caution is needed, though. Unless all login paths to the operating system have been modified to query the Kerberos server for authentication, leftover entry points into the system will exist. These leftover paths will use the information in /etc/passwd and might introduce weaknesses into your system.