8.3 Kerberos-based AAIs

Furthermore, the six steps can be grouped in three exchanges:

• The AS exchange between the client and the AS (steps 1 and 2);

• The TGS exchange between the client and the TGS (steps 3 and 4);

• The AP exchange between the client and the application server (steps 5 and 6).

Obviously, the AS exchange must be performed only once during the log-in process, whereas the TGS exchange and the AP exchange must be performed for each server the client wants to access (if the server requires authentication).

When a user U wants to sign on a Kerberos realm, he or she has a client C send a KRB_AS_REQ (Kerberos authentication server request) message to the AS of the Kerberos KDC in step 1. The message basically includes the principal identifier for U, the identifier for a TGS, a desired lifetime L ₁ for the TGT, and a randomly chosen nonce N ₁ .

After having received the KRB_AS_REQ message, the AS looks up and extracts the secret keys for both U and the TGS. If required, the AS preauthenticates the request, and if preauthentication fails, a corresponding error message is returned to C. Otherwise, the AS randomly selects a new session key K , and returns a KRB_AS_REP (Kerberos authentication server reply) message to C in step 2. The message includes U , a TGT T _c,tgs = { U; C; TGS; K; T _start , T _expire }K _tgs , and { TGS; K; T _start , T _expire , N ₁ } K _U . The TGT s start and expiration times T _start and T _expire are set in accordance with the realm s security policy in a way that fits the specified lifespan L ₁ of the KRB_AS_REQ message.

After having received the KRB_AS_REP message in step 2, C applies a well-known one-way hash function h to the user-provided password pwd _U to compute the user s master key K _U = h ( pwd _U ). ^[20] Equipped with this key, C can decrypt { TGS; K; T _start , T _expire } K _U , and extract TGS, K , T _start , and T _expire accordingly . C is now in the possession of a TGT that is valid from T _start to T _expire . It can use this TGT to request a service ticket from the TGS for every registered server S in the realm. Note that in a TGT, a lifetime is used like a password expiration time. Limiting the lifetime of a TGT thus limits the amount of damage that can be caused by a compromise of the TGT. In Kerberos, there is generally no possibility to revoke a TGT once it has been issued. Thus, limiting the TGT lifetime implicitly sets a deadline after which the TGT becomes obsolete.

Before initiating a TGS exchange, C must determine in which realm the application server he or she will request a ticket for has been registered. If C does not already possess a TGT for that realm, C must obtain one. This is first attempted by requesting a TGT for the destination realm from the local Kerberos server (using the KRB_TGS_REQ message recursively). The Kerberos server may return a TGT for the desired realm, in which case C can proceed. Alternatively, the Kerberos server may also return a TGT for a realm which is closer to the desired realm, in which case this step must be repeated with a Kerberos server in the realm specified in the returned TGT. If neither is returned, the request must be retried with a Kerberos server for a realm higher in the hierarchy. This request will itself require a TGT for the higher realm, which must be obtained by recursively applying these directions. Once the client obtains a TGT for the appropriate realm, it determines which Kerberos servers serve that realm, and contacts one. The list might be obtained through a configuration file or a corresponding network service.

In step 3, C sends a KRB_TGS_REQ (Kerberos ticket-granting server request) message to the TGS. The message includes the principal identifier S for the server, a requested lifetime L ₂ for the service ticket, a nonce N ₂ , the TGT T _c,tgs , and an authenticator A _c,tgs to prove legitimate ownership of the TGT. A _c,tgs can be regarded as the principal identifier of C and a time stamp, both of them encrypted with the session key K : A _c,tgs = { C , T } K . Note that T _c,tgs can have a comparably long lifetime, and could be eavesdropped upon and replayed. The purpose of the authenticator is thus to show that C holds the secret key, and to thwart this kind of attack. Also note that the use of authenticators generally requires that principals on the network keep reasonably synchronized time. The times can be off by some amount. The allowable time skew is independently set at each server, and therefore some servers may be configured to be fussier than others about times being close. The allowed time skew is usually set to be accurate within 5 minutes without undue administrative burden . In practice, that assumption has turned out to be more problematic than expected. Distributed time services, once deployed, make much tighter synchronization possible.

The KRB_TGS_REQ message is processed in a manner similar to that of the KRB_AS_REQ message, but there are some additional checks to be performed. In step 4, the TGS returns a KRB_TGS_REP message (Kerberos ticket-granting server reply) that shares its format with the KRB_AS_REP message. It includes the principal identifier for the user, a ticket T _c,s for the requested server S, and an expression (i.e., { S; K ; T _start , T _expire , N 2}) encrypted with K . Again, the client can use K to decrypt the expression and to extract the identifier for the server, the new session key K (which the client uses to talk to the server), a lifetime for the ticket, and the nonce N ₂ .

When the KRB_TGS_REP is received by C, it is processed in the same manner as the KRB_AS_REP processing described above. The primary difference is that the ciphertext part of the response must be decrypted with the session key that is shared with the TGS rather than with the user s master key.

It turns out that there is neither functionality nor security gained by having Kerberos require an authenticator as part of the KRB_TGS_REQ message. If someone who did not know the session key K transmitted Tc; tgs to the TGS, the TGS would return a message encrypted with K , which would be of no use to someone who did not know the session key. The reason the designers of Kerberos did it this way is to make the protocol for talking to the TGS be the same as for talking to the other servers. When talking to other servers, the authenticator does indeed provide security, because it authenticates the knowledge of the corresponding session key.

The AP exchange of the Kerberos V4 protocol is used by network applications either to authenticate a client to a server, or to mutually authenticate a client and a server to each other. The client must have already acquired credentials for the server using the AS or TGS exchange.

In step 5, C sends a KRB_AP_REQ (Kerberos application request) message to the server S. The message includes T _c,s , A _c,s = { C; T } K , and some additional bookkeeping information. Authentication is based on the server s current time of day, the ticket T _c,s , and the authenticator A _c,s .

To make sure that the KRB_AP_REQ message is not a replay of a request recent enough to look current given the time skew, S should keep all time stamps received within the maximum allowable time skew and check that each received time stamp is different from any of the stored values. Any authenticator older than the maximum allowable time skew would be rejected anyway, so there is no need to remember values older than the threshold value. Kerberos V4, however, does not bother saving time stamps. Saving time stamps does not help if S is a replicated service in which all the instances of the service use the same master key. The threat of an eavesdropper replaying the authenticator C sent to one instance of S to a different instance of S could have been avoided if Kerberos had done something like put the network layer of the instance of S in the authenticator, too.

If no error occurs, and if mutual authentication is required, S has to return a KRB_AP_REP (Kerberos application reply) message to C in step 6. Again, this message is encrypted with the session key K that is shared between C and S. Since this key was in the ticket encrypted with the server s secret key, possession of this key is proof that S is the intended principal. More accurately, S has to increment the time stamp included in the KRB_AP_REQ message authenticator and re-encrypt it with K .

As described thus far, Kerberos provides mutual authentication services for the client and server. However, a by-product of the Kerberos authentication protocol is the exchange of a session key K that is shared between the clients and the servers. This key can then be used by the application to protect the confidentiality and integrity of communications. Typically, communications between the client and server is transparently encrypted and decrypted using the DES and the session key K .

There are at least two problems that should be considered with care when it comes to large-scale deployment of the Kerberos system:

1. The fact that one part of the KRB_AS_REP message is encrypted with K _U can be used to launch a verifiable password guessing attack against the user s password. More accurately, it is possible to guess a password candidate, derive a candidate K _U from this value, and decrypt the relevant part of the KRB_AS_REP message with this key. It is then verifiable whether the password candidate was properly guessed. There are several strategies to protect against this type of attack, but unfortunately , all require the use of public key cryptography or similar constructs.

2. The fact that the Kerberos KDC shares a secret key with each principal in the realm allows the administrator of the KDC to spoof any principal. This is a consequence of the fact that the Kerberos system uses only secret key cryptography.

Furthermore, every network application must be modified to make use of the Kerberos system. The process of modifying a network application to make use of Kerberos is commonly referred to as ˜ ˜Kerberizing it. In general, Kerberizing network applications is the most difficult part of installing Kerberos. Fortunately, the MIT reference implementations of the Kerberos system include Kerberized versions of some popular network applications, such as Telnet and the Berkeley r-tools. Other applications have been Kerberized by vendors and are included in their supported products. The availability of Kerberized applications has improved with time, and is expected to further improve in the future. However, a site would still have to arrange itself to add Kerberos support to any application developed in-house.

One of the commonly agreed upon design principles for authentication and key distribution systems is the use of a standardized API, such as the Generic Security Services API (GSS-API) specified by the IETF Common Authentication Technology (CAT) WG. The use of the GSS-API for Kerberos V5 is specified in RFC 1964 [26]. Also, more work is needed to standardize and eventually simplify the GSS-API, such as demonstrated by GSS-API version 2 [27] or the Simple Public-Key GSS-API Mechanism [28].

Note that the Kerberos system provides authentication, data confidentiality, and data integrity services. By itself, it provides no information as to whether or not the client is authorized to access the server and to use the corresponding services. In general, there are three possibilities to address authorization within the Kerberos model:

1. The Kerberos KDC could maintain authorization information for each service and issue tickets to authorized users only.

2. A dedicated service could maintain authorization information by keeping access lists for each service and allowing the client to obtain sealed certification of list membership. The client would then present the sealed certification in addition to a Kerberos ticket to the requested service.

3. Each service could maintain its own authorization information, with the optional help of a service that stores access lists and provides certification of list membership.

The Kerberos model is based on the assumption that each service knows best who its users should be and what form of authorization is appropriate for them. Consequently, the third approach is employed in the Kerberos system. Next we will see that the main difference between Kerberos and Kerberos-based AAIs, such as SESAME and Windows 2000, is that the former employs the second approach to address authorization.

8.3.2    SESAME

The Secure European System for Applications in a multi-vendor Environment (SESAME) was a European research-and-development project aimed at developing an AAI and system for distributed computing and networking environments [29 “31]. It achieved this by including and combining an extended Kerberos V5 authentication service and a privilege attribute service that can be used to provide authorization and corresponding access control services.

Recall that in the Kerberos system a client requests a TGT from the AS, and that the client can use this TGT to request service tickets from the TGS. In the SESAME system, a similar approach is used for authorization and access control. If a client wants to use a service, he or she must not only be authenticated by the AS, but also have his or her other privilege attributes certified by an additional component, a so-called privilege attribute server (PAS). In SESAME, the term privilege attribute certificate (PAC) is used to refer to a certified set of privilege attributes. In principle, a PAC consists of both the user s privileges and corresponding control information. The user s privileges are data such as the user s identity, role, organizational group , and security clearance, whereas the control information says where and when the PAC can be used and whether it can be delegated or not. Note that a PAC is conceptually similar to an attribute certificate. In short, the client and the PAS must exchange KRB_PAS_REQ and KRB_PAS_REP messages between the AS exchange (using the KRB AS REQ and KRB_AS_REP messages) and the TGS exchange (using the KRB_TGS_REQ and KRB_TGS_REP messages). In these messages, the client is provided with a PAC that is relevant for the user on whose behalf it is acting.

Refer to Chapter 6 of [10] or [31] to get a more comprehensive overview and discussion of the SESAME system. With the deployment of similar mechanisms in Windows 2000, interest in SESAME and SESAME-enabled applications has disappeared in the past.

8.3.3    Windows 2000

More recently, Microsoft has implemented the Kerberos V5 authentication service with extensions for public key authentication ^[21] for the Windows 2000 operating system. The Kerberos KDC is integrated with other Windows 2000 security services running on the domain controller and uses the domain s active directory as its security account database. ^[22]

In addition to the functionality specified in [21], Windows 2000 implements an authorization mechanism in the Kerberos system in a specific and unique way. When the Kerberos protocol is used for authentication, a list of security identifiers (SID) identifying a principal and the principal s group memberships is transported to the client in the authorization data field of a ticket. Authorization data, in turn, are gathered in two steps:

1. The first step takes place when the KDC in a Windows 2000 domain prepares a TGT.

2. The second step is accomplished when the KDC prepares a service ticket for the server in the domain.

When a user requests a TGT, the KDC in the user s account domain queries the domain s active directory. The user s account record includes the user s SID as well as SIDs for any security group to which the user belongs. The list of SIDs returned by the KDC is placed in the authorization data field of the TGT. ^[23] In a multiple-domain environment, the KDC also queries the Global Catalog for any universal groups that include the user or one of the user s domain security groups. If any are found, their SIDs are also added to the list in the TGT s authorization data field.

When a user requests a service ticket, the KDC in the server s domain copies the contents of the TGT s authorization data field to the ticket s authorization data field. Furthermore, if the server s domain is different from the user s account domain, the KDC queries the active directory to find out whether any security groups in the local domain include the user or one of the user s security groups. If any are found, their SIDs are also added to the list in the service ticket s authorization data field.

^[15] In Greek mythology, Kerberos is the name of the three-headed watchdog of Hades, whose duty it was to guard the entrance of the underworld.

^[16] Outside the United States and Canada, the eBones distribution of Kerberos V4 is used and widely deployed. The eBones distribution is available at http://www.pdc.kth.se/kth-krb.

^[17] http://web.mit.edu/kerberos/www

^[18] http://nii.isi.edu/ info /kerberos

^[19] http://web.mit.edu/kerberos/www/dialogue.html

^[20] Kerberos V4 did not prompt the user to enter the password until after C has received the KRB_AS_REP message. This is because Kerberos V4 was serious in following the generally good security rule of having C know the user s password only for the minimum time possible. But waiting the few seconds to retrieve the KRB_AS_REP message before asking the user for the password really does not enhance security significantly, and in fact Kerberos V5 has the user enter the password before C sends the KRB_AS_REQ message. The reason for the designers of Kerberos V5 to change the order was that V5 requires C to prove that it knows the user s password before the AS sends the KRB_AS_REP message, which makes it less easy to obtain a quantity with which to launch an offline password guessing attack.

^[21] These extensions are specified by the IETF CAT WG under the acronym PKINT.

^[22] For consistency, the Microsoft documentation uses the term ˜ domain instead of ˜ realm . Furthermore, the distinction between an AS and a TGS is not made. Both components are collectively referred to as a KDC.