Kerberos Overview

As mentioned previously, one of the strengths of the Kerberos protocol is that it provides mutual authentication-that is, it provides authentication of a client's identity to a server or network resource and also provides authentication of the server's or network resources' identity back to the client. This makes it extremely difficult for unauthorized users or rogue servers to be placed on the network and to gain access to resources. The mutual authentication is performed before the network connection is even established. Kerberos assumes that this initial mutual authentication is taking place across an open untrusted network, such as the Internet, where the packets are subject to capture and possible modification. Kerberos takes steps to prevent attacks such as these from successfully bypassing its security mechanisms (discussed later in this chapter).

Test Day Tip 

The material that follows in this section may or may not be on the exam, but it provides a critical foundation for understanding how Kerberos operates and how it is managed. It is necessary to cover this background information before examining the Kerberos implementation in Windows 2000. It is also good knowledge to have as an administrator dealing with Kerberos authentication in a Windows 2000 network.

The Kerberos protocol provides two services to a network:

  • Authentication Service (AS)  The AS of the KDC is responsible for authenticating users and issuing them their Ticket-Granting Ticket (TGT).

  • Ticket Granting Service (TGS)  The TGS is responsible for issuing individual session tickets that allow for network resource access by user based on their TGT.

We will examine how these two services are used in the following sections.

Kerberos Concepts

Kerberos relies extensively on the shared key concept. In shared key encryption, the encryption is symmetric meaning the same key can be used to both encrypt and decrypt the data being transmitted. Each side of the communication can verify the identity of the other due to the other having the secret key. This approach to validating traffic is much more secure than sharing a password.

Consider the following example: Two users want to communicate over the network. It is required that the receiving user be assured of the sender's identity. How can the sender prove their identity to the recipient? One possible method would be for them to send a shared secret in the message, thus proving that they know something only the two users know. The message containing the shared secret proves to the recipient that the sender is who they claim to be. Identity has been assured and communications can begin. There is, however, a flaw in this method. The sending of a shared secret in a message brings up the possibility of data capture and modification. Someone capturing packets between the two users could capture the shared secret and be able to impersonate one or both users. Clearly a better solution is required.

The trick here is to prove identity without revealing the shared secret in the process. Simply exchanging the shared secret cannot do this, so the solution is using the Kerberos protocol. Rather than sharing a secret in Kerberos, users can share a cryptographic key (see Chapter 4) and use it to safely verify each other's identity. Now, instead of sending a shared secret over the network, one user can encrypt a piece of data and send it to the other. If the receiving user successfully decrypts the data, it is assumed to be authentic and verifies the senders' identity. Remember that Kerberos makes use of a symmetric encryption key meaning that the same key is used both for encryption and decryption.

The Authenticator

As seen in the previous example, a user attempting to prove their authentication to another user or computer presented a piece of encrypted data. By presenting this data, which was encrypted with the shared encryption key, they proved that they know the shared secret. However, what is to prevent an attacker from capturing these packets and using them for their own purposes? The authenticator provides this protection. The authenticator also provides for mutual authentication, which is one of the foundations of the Kerberos protocol.

An authenticator is a piece of unique information encrypted using the shared encryption key. Each authenticator must be different than the previously issued authenticators, otherwise an attacker could simply replay back a captured authenticator and use it to gain access to resources they would otherwise be denied. To this end, each authenticator is time-stamped with the time on the sender's computer. Upon receipt of the authenticator, the receiver decrypts it and knows by examining the data contained within if the decryption was successful. If the decryption was successful, the receiver knows that the user who sent the authenticator has the correct shared encryption key. Since only authorized users have access to this key, the recipient safely assumes that the sender is who they claim to be.

To prove to the sender that the authorized recipient received the message, the recipient can initiate the process in reverse. The recipient extracts a small portion of the original message, encrypts it into a new authenticator, and sends it back to the sender. By decrypting and comparing the contents of this second authenticator to the data contained in the first authenticator, the sender can verify the recipient's identity. Again, only the authorized recipient would be able to successfully decrypt the original authenticator, so they must have the correct shared key. Mutual authentication has been assured.

The last issue that must be addressed is how to prevent replay attacks from occurring-wherein an attacker captures an authenticator and replays it later to trick the recipient into believing they are an authorized user. This protection is provided by time synchronization. After the original authenticator has been decrypted and the data extracted, the recipient examines the time stamp in the authenticator and compares it to the time on his own system. The times should match closely; within five minutes or less. If they match, the recipient can assume that the authenticator is valid. If the times are too far apart, the authenticator is rejected and no access is granted to the sender. However, one last check must be performed to further ensure that the time stamp is truly indicative of a valid authenticator. The recipient compares the time stamp in the offered authenticator to those contained in his memory. If the time stamp on the currently offered authenticator is the same as or earlier than any previously offered authenticator, the authenticator is invalid and is rejected. Through this time stamp comparison process, Kerberos prevents replay attacks from successfully gaining access for an attacker.

The time stamp plays another important role in mutual authentication. The authenticator that is sent back to the sender by recipient contains only the time stamp that was contained in the original authenticator. By providing only this one piece of information that is unique to the sending computer, the sender can be assured completely that the recipient has successfully received and decrypted the message. If the entire authenticator contents were sent back to the sender, the sender would not be able to tell the difference between a valid authenticator from the recipient or an attacker who just copied back the entire authenticator. This conclusively proves to the sender that the recipient is who they say they are.

start sidebar
Damage & Defense…
No Replay Here

When Kerberos v4 was released to the public it was almost the same as the v5 release, but with two notable changes. One change was the addition of the cache on the KDC that keeps track of authenticators sent to it, as shown in Figure 8.1. It became apparent to the design team at MIT that just having the five-minute time skew rule between the client's system time and the KDC's system time was not going to provide protection against an attacker who would simply capture the authenticator as it traveled across the network and then immediately send it out to the KDC to launch a replay attack. The solution was to include a "replay cache" in v5 that keeps track of recently seen authenticators. Now if an attacker tried to capture an authenticator and replay it, it would be rejected because the legitimate authenticator would have already been received by the KDC and its time stamp recorded in the cache. The cache flushes automatically as time stamps exceed the configured time skew, which is typically five minutes.

end sidebar

click to expand
Figure 8.1: The Authenticator Process

Figure 8.1 provides a graphic illustration of the authenticator process.

The KDC

Kerberos provides the optimum solution for ensuring mutual authentication of both clients and servers on a network. But one problem remains that needs to be addressed: how to get the secret key to those users who should have it.

In cases where there are just a few clients who need access to a secret key, distributing is made easy by gathering everyone together at one time and in one location and then handing out the secret key at that time. Unfortunately, production networks do not work this way. Clients may want to access resources from anywhere on the network and those resources may not be anywhere near them. Another problem with this approach is that it is likely that clients will want to communicate with more than one server and a service may communicate with multiple clients. If the secret key is handed out manually, they would need to ensure that every client had every server's key and vice versa. As this is obviously not a good solution, they will need to implement an automatic trusted intermediary to store and disburse keys to both users and servers as required. Also, storing so many keys on each server and computer presents a large security risk that is better avoided.

This problem is solved by the KDC, which forms the third part of the Kerberos system. In Greek mythology, there existed a fierce three-headed dog named Cerberus (Kerberos) that guarded the gates of the underworld. Like Cerberus, Kerberos uses three parts to guard access to networks: the client, the server, and a trusted intermediary-the KDC. The KDC sits between the client and the server, running as a service on a secure server on the network. It maintains the database of all account information for all security principals within its realm. A Kerberos realm is the equivalent of a Windows 2000 domain and is thus referred to as a domain for the remainder of this discussion. Included in the information the KDC stores about each security principal is a secret cryptographic key known only to the KDC and the security principal-be it a user, computer, or network service. This secret key, which is typically derived from a client's logon password, is used in exchanges between the KDC and the client and is referred to as the long-term key.

When a client requests access to a network resource, the KDC receives the request and creates a short-term key called the session key. This session key is used when the client and the server authenticate each other. The server's copy of the session key is encrypted in its long-term key and the client's copy of the session key is encrypted in its long-term key. This, however, still does not provide an efficient method for network clients to communicate with network servers and services. Key management would be a task that consumed massive amounts of resources from the KDC and a server would need to maintain a copy of every client's session key in memory while it waited for them to request access. Also, network traffic could cause a client's request for service to reach the intended server before the message from the KDC, thus causing the server to wait for a reply until the KDC's message has been received. This would force the server to commit more memory to holding the session state data. Fortunately, all of these problems are avoided by using session tickets.

The Session Ticket (ST)

When a client requests access to a service, this request is first sent to the KDC. Using the session ticket, however, results in both copies of the session key being sent back to the client. The client's copy of the session key is sent back to the client encrypted with the secret key that both the KDC and the client share (remember this is based on the client's network password). The server's copy of the session key is used to create what is called a session ticket (ST) that also contains information about the client. The session ticket is encrypted with a secret key that the KDC shares with the server. The session ticket contains the server's session key and can then be used to gain access to the requested service or resource without the client ever learning the server's secret key. Figure 8.2 illustrates the first two steps of a client requesting access to a network server.

click to expand
Figure 8.2: Client Requests Access to the Server

The KDC does not keep track of its messages to ensure that they have been properly received. While this may seem like a security problem, in reality it is not. Remember that only the authorized client can open the client's copy of the session key (knowledge of the client's secret key is required) and only the authorized server can open the session ticket (knowledge of the server's secret key is required). When the client receives the client's copy of the session key and the session ticket, it places them into a secure location which is located in a secure portion of volatile memory (RAM); not on the hard disk. This provides assurance that this information cannot be retrieved from the computer by an attacker.

When the client wants access to the server, it presents the server with both the session ticket and an authenticator, as previously discussed. Together, these two items prove the client's identity to the server. The server using its secret key decrypts the session ticket, and the session key is extracted. Using the extracted session key, the server decrypts the client's authenticator. If the authenticator is verified, the server is assured that a trusted authority-the KDC, has verified the identity of the client. The server can then use its copy of the session key to encrypt the time stamp from the client's authenticator and return it to the client as the server's authenticator, as discussed previously. The process of the client requesting access to the server continues is shown in Figure 8.3.

click to expand
Figure 8.3: Client Sends the Session Ticket to the Server

The server does not store a copy of the session ticket-it is the responsibility of the client to present this ticket to the server each and every time it wants to initiate a connection. The session ticket is decrypted each time using the server's secret key, which yields the session key. When the server no longer needs the session key, it is discarded, freeing up memory and resources on the server. Also, the client has no need to visit the KDC each time it needs to access the same server again, as it still has the session ticket in its volatile memory. Session tickets can be used and reused until they have expired. The expiration time serves as a form of protection against session ticket theft, as they are only valid for the length of time specified (10 hours by default in Windows 2000). This is designed to last the length of a typically user session-a workday-and then be flushed from volatile memory, destroying all session tickets and session keys at logoff or workstation shutdown.

The TGT

As discussed previously, a hash of the client's network password is used to create the long-term key. When a user logs into the network, the Kerberos client service on their workstation passes it through a one-way hashing algorithm to derive the secret cryptographic key. The resulting hash becomes the long-term key.

Note 

By default, all implementations of the Kerberos protocol are required to support the Data Encryption Standard (DES)/CBC/Message Digest 5 (MD5) hash, although other algorithms may be added as desired.

After the workstation Kerberos client has performed the hash, it requests that the Kerberos service on the KDC compare the results to those that are stored in the user's account properties. If the hashes match, the user is authenticated by the KDC. The Kerberos client on the user's workstation then requests a session ticket and session key from the KDC that can be used for all future transactions involving the KDC during this particular login session. In response, the KDC provides the client with a special session ticket called the ticket-granting ticket (TGT).

Although it may seem like extra work, the creation and use of the TGT saves the KDC a small amount of time and resources every time a client requests access to a service or server that they do not already have an existing session ticket for. This savings comes as a result of the client not having to authenticate to the KDC each time-it simply presents its request for a new session ticket by sending the TGT and an authenticator to the KDC. The KDC replies with a new session key and session ticket for the newly requested access. The TGT can continue to be used and reused in this fashion just like a ST until the TGT expires, which is 10 hours by default in Windows 2000. At client logoff or workstation shutdown, the TGT, all STs, and all session keys are flushed from volatile memory.

The complete Kerberos process, from client logon to resource access is illustrated in Figure 8.4.

click to expand
Figure 8.4: The Kerberos AS and TGS Processes

Kerberos Authentication across Domain Boundaries

Up to this point we have examined the operations of the Kerberos protocol contained on one domain. What happens when the resource the client has requested access to actually resides on another domain? Kerberos supports this situation through the use of a referral ticket. One additional thing must exist for cross-domain authentication to occur: the domains must share an inter-domain key.Once a trust has been established between domains (the sharing of this inter-domain key), the TGS of domain 1's KDC is registered as a security principal in domain 2 and vice versa. As a result of this, the TGS in each domain can now treat the TGS in the other domain as just another network service that it can issue session tickets for. Figure 8.5 illustrates the process of cross-domain authentication where a client in domain 1 requests access to a network resource in domain 2.

click to expand
Figure 8.5: Cross-realm Authentication

Exam Warning 

Do not let the term's realm or domain throw you. They mean the same thing in Windows 2000, although to be absolutely correct, realm is the correct term to use when discussing an implementation of Kerberos outside of Windows 2000.

Delegation of Authentication

In the example domains discussed so far, the client is authenticated to directly access resources. But what happens when a multitiered arrangement exists where a client connects to a front-end server that must actually connect to a back-end server to process the access request and supply the requested information? The front-end server must have a ticket to access the back-end server. This ticket must limit the front-end server's access on the back-end server to what the client is authorized to do, not what the front-end server is authorized to do. In cases like this, some form of delegation of authentication must occur.

Delegation is fairly simple in concept: the client delegates authentication to a server by telling the KDC that the server is now authorized to represent the client. Thus, the front-end server can now represent the client in obtaining the session ticket for the back-end server. The client accesses the requested resource as if nothing special happened. There are two forms of delegation in Kerberos:

  • Proxy Tickets  The client obtains a ticket for the back-end server and then presents it to the front-end server. The front-end server then presents this ticket to the back-end server. This method is difficult to use because the client must know the name of the back-end server ahead of time.

  • Forwarded Tickets  In this method, the client issues the front-end server a TGT that it can then use to request tickets for the client as requested.

Proxy Tickets

The client obtains a proxy ticket by presenting a TGT to the TGS on the KDC, asking it for a ticket to the back-end server. In this request is a flag signaling that the client desires to receive a proxy ticket and includes the name of the front-end server who will be representing the client. If Kerberos policy permits proxy tickets, the KDC creates the ticket for the back-end server, marks it as a proxy ticket by using the PROXY flag, and sends it back to the client. The client sends the proxy ticket to the front-end server, which then uses the ticket to access the back-end server in the client's name. The client can now gain access to the back-end server. Figure 8.6 illustrates the proxy ticket process.

click to expand
Figure 8.6: Using Proxy Tickets

Forwarded Tickets

If the client wants to delegate the task of obtaining the ticket to access the back-end server to the front-end server, it must request a forwardable TGT from the KDC. This done by sending a request to the KDC indicating the name of the front-end server that will be acting as the proxy for the client. If Kerberos policy permits proxy tickets, the KDC creates a TGT for the front-end server to use in the client's name by marking it with the FORWARDABLE flag, and sends it back to the client. The client then forwards this TGT to the front-end server. Now when the front-end server requests a ticket on behalf of the client for the back-end server, it presents the client's forwardable TGT to the KDC. The KDC makes note of the FORWARDABLE flag in the TGT, flags the session ticket with the FORWARDABLE flag, and sends it back to the front-end server. The client can now gain access to the back-end server. Figure 8.7 illustrates the forwarded ticket process.

click to expand
Figure 8.7: Using Forwarded Tickets

Note 

For a look at the Kerberos protocol's creation, see Designing an Authentication System: a Dialogue in Four Scenes at http://web.mit.edu/kerberos/www/dialogue.html. The Kerberos main page at MIT can be found at http://web.mit.edu/kerberos/www/.



MCSE. MCSA Implementing & Administering Security in a Windows 2000 Network Study Guide Exam 70-214
MCSE/MCSA Implementing and Administering Security in a Windows 2000 Network: Study Guide and DVD Training System (Exam 70-214)
ISBN: 1931836841
EAN: 2147483647
Year: 2003
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net