KERBEROS: THE BASIC PROTOCOL
The following text explains the basic Kerberos protocol as it is defined in RFC 1510. Those not familiar with Kerberos may be bewildered by the need for numerous diverse keys to be transmitted around the network. In order to break down the complexity of the protocol we will approach it in five steps, as follows:
- Step 1: Kerberos authentication is based on symmetric key cryptography.
- Step 2: The Kerberos KDC provides scalability.
- Step 3: A Kerberos ticket provides secure transport of a session key.
- Step 4: The Kerberos KDC distributes the ticket by sending it via the client.
- Step 5: The Kerberos ticket-granting ticket limits the use of the entities’ master keys.
Before starting to explore how Kerberos works, we must explain the notations that will be used in the illustrations, as follows:
- u stands for user, s stands for resource server, k stands for KDC.
- S stands for session key; Sus means the session key shared between the user and the resource server.
- M stands for master key; Mu is the master key of the user.
- Illustration (1) in Figure 6 represents the session key shared between the user and resource server.
- Illustration (2) in Figure 6 represents the same session key, but this time encrypted.
- Illustration (3) in Figure 6 represents the same session key, encrypted using the master key of the user.
To ease reading we will talk about a client, Alice, and a resource server that authenticate using Kerberos. The identities used in this Kerberos authentication exchange are Alice’s SID and the SID of the service account that is used by the application or the service responsible for the resource. To be fully correct we should discuss the service account of the service, but this would not facilitate ease of reading. Also, when we discuss Alice, we really mean the LSA on Alice’s machine impersonating Alice and acting on her behalf. From now on the following words are synonyms: principal, security principal, and entity; domain and realm.
Step 1: Kerberos authentication is based on symmetric key cryptography
To authenticate entities Kerberos uses symmetric key cryptography. In symmetric key cryptography the communicating entities use the same key for both encryption and decryption. The basic mathematical formula behind this process is the following:
DK(EK(M)) = M
If the encryption (E) and decryption (D) processes are both using the same key (K), the decryption of the encrypted text (M) results in the readable text (M).
This is what happens when Alice wants to authenticate to a resource server using a symmetric key cipher (illustrated in Figure 7):
- Alice encrypts her name and the current time stamp using a symmetric key.
- The encrypted message and Alice’s name are sent to the resource server.
- The resource server decrypts the message.
- The resource server checks Alice’s name and the time stamp (this is the result of the decryption process). If they’re OK, Alice is authenticated to the server.
Why does this process authenticate Alice to the resource server? If the resource server can successfully decrypt the message, meaning if it results in Alice’s name and an acceptable time stamp, the resource server knows that only Alice could have encrypted this information, since she’s the only one, besides the resource server, who knows the symmetric key. An "acceptable time stamp" means that resource server compares the time stamp received in Alice’s encrypted packet against the local time. If the time skew between these two time stamps is too big, the resource service will reject the authentication attempt, since a hacker could have replayed Alice’s original authentication packet. Notice the differences and similarities with NTLM. Both Kerberos and NTLM use symmetric cryptography for authentication: "If you can prove you know your secret key, I believe you are who you say you are." In NTLM the knowledge of the secret key is proven using a challenge-response mechanism. Kerberos uses symmetric encryption of the time stamp and the user’s name to do the same thing. The encrypted packet containing Alice’s name and the time stamp is known in Kerberos as the authenticator, the symmetric key is called a session key. A session key exists between all Kerberos principals that want to authenticate to each other.
A critical element in the above exchange is the time stamp: it provides authenticator uniqueness and protects against replay attacks. Without the authenticator, a hacker could grab a ticket off the network and use it to impersonate Alice to a resource server. The time stamp explains the time sensitivity of Kerberos and of Windows 2000 in general. We will discuss extensively the importance of time for Windows 2000 authenticity in the section "Kerberos time sensitivity."
Remember from the introduction that Kerberos can provide mutual authentication. To provide this the Kerberos protocol includes an additional exchange that authenticates the server to the client. In the previous example, it means that, in turn, the server will encrypt its name and the current time stamp and send it to Alice.
A big problem when using a symmetric protocol is the distribution of the secret key: in practice the key is generated at one side of the communication channel and should be sent to the other side of the communication channel in a secure manner; secure means that the confidentiality of the key should be protected. If anybody could read the secret key when it’s sent across the network, the whole authentication system becomes worthless: the secrecy of the secret key is a vital part of a symmetric cipher.
Steps 2, 3, and 4 explain how the Kerberos developers have resolved the problem of secure session key distribution.
Step 2: The Kerberos KDC provides scalability
The Kerberos protocol always deals with three entities: two entities that want to authenticate to one another and one entity that mediates between these two entities for authentication: the Key Distribution Center (KDC). Why do we need a KDC? (See Figure 8.)
Suppose that Alice is part of a workgroup consisting of five entities, which all want to authenticate to one another using symmetric key cryptography. Since every entity needs to share a secret key with every other entity, we’ll need ten keys. The mathematical formula behind this is n (n — 1)/2. In a 50,000-employee company we would need about 1,500,000,000 keys. Not only would we have to deal with an enormous amount of keys, there would also be an enormous amount of small authentication databases: There would be one on every client, containing all the secret keys of the entities the client wants to authenticate. This solution is clearly not scalable at the level of a large company.
To make Kerberos more scalable the Kerberos developers included the concept of a Key Distribution Center (KDC). The Key Distribution Center (KDC) is a trusted third party with whom every entity shares a secret key. This key is called the entity’s master key. All entities trust the KDC to mediate in their mutual authentication. The KDC also maintains a centralized authentication database containing a copy of every user’s master key.
In Windows 2000 the KDC is a service that is installed on every DC as part of the DCPROMO Active Directory installation process. Every Windows 2000 DC runs a KDC service and hosts a portion of the Active Directory (AD), the centralized authentication database. The KDC itself is made up of two subservices: the Authentication Service (AS) and the Ticket-Granting Service (TGS); in other Kerberos implementations these two sub-services can run on different machines — this is not possible in Windows 2000.
An interesting note: A standard Kerberos domain is made up of a master KDC and one or more slave KDCs. The master KDC is collocated with a read/write copy of the authentication database (single-master model). In Windows 2000 every KDC server hosts a read/write copy of the domain portion of the Active Directory (multimaster model). Note that if a domain has multiple DCs, this feature can provide fault tolerance for the authentication process and the authentication database. If one DC is down, another one can automatically take over; also, the AD is replicated between DCs.
The concept of a master key is not new to Windows 2000 and Kerberos: It already existed in NT4. In both NT4 and Windows 2000, the master key is derived from an entity’s password. The password is a secret key shared between all the security principals and the KDC. (Note that we’re talking about symmetric key cryptography.) Both the entity and the KDC must know the master key before the actual Kerberos authentication process can take place. For obvious security reasons the AD never stores the plain password but a hashed version. The hash algorithm used for password hashing is MD4.
An entity’s master key is generated as part of the domain enrollment process — for example, when the administrator enrolls the user and enters a password. A machine’s master key is derived from the machine password that is automatically created when an administrator joins the machine into a domain.
Step 3: A Kerberos ticket provides secure transport of the session key
Figure 9 shows the three basic entities the Kerberos protocol deals with: a client (Alice), a resource server, and a Key Distribution Center (KDC). Figure 9 also shows the master keys shared between the entities participating in the authentication process and the KDC. Also note that the KDC consists of two subservices: an Authentication Service (AS) and a Ticket-Granting Service (TGS). We’ll discuss this difference later in this chapter.
Remember that in the first step we talked about the problem of distributing the secret key (the session key) when dealing with symmetric key ciphers. The following text explains how Kerberos resolves this problem.
Previously, we explained that every entity shares a master key with the KDC. We also said that all entities trust the KDC to mediate in their mutual authentication: trust in this context also means that every entity trusts the KDC to generate session keys. In the scenario shown in Figure 9, the resource server would never trust Alice to generate session keys, because Alice hasn’t yet authenticated to the resource server (the other way around wouldn’t work either).
So far so good: Alice needs to authenticate to the resource server and requests a session key from the KDC. The KDC will generate the session key and distribute it to both entities. The quality or the randomness of the session key is dependent on the quality of the random number generator of Windows 2000. Remember that the session key is the key introduced in step 1; it is the one used for authentication. The master key was introduced in step 2. The following text makes the link between the session key and the master key and explains why we need a master key.
After the KDC has generated the session key, it must communicate it to both Alice and the resource server. To secure the transport of the session key to a particular entity Kerberos encrypts it with the master key of that entity. As there are two entities, Alice and the resource server, two encrypted versions of the session key must be generated: one encrypted with Alice’s master key; one encrypted with the master key of the resource server.
In Kerberos terminology, the session key encrypted with the resource server’s master key is known as a ticket. A Kerberos ticket provides a way to transport a Kerberos session key securely across the network. Only the destination resource server and a Windows 2000 DC can decrypt it.
By securing the transport of the session key using the master key, Kerberos creates what is known as a key hierarchy. Figure 10 shows the Windows 2000 key hierarchy; it consists of the following entities:
- The session key (or short-term key). A session key is a secret key shared between two entities for authentication purposes. The session key is generated by the KDC. Since it is a critical part of the Kerberos authentication protocol, it is never sent in the clear over a communication channel: It is encrypted using the master key.
- The master key (or long-term key). The master key is a secret key shared between each entity and the KDC. It must be known to both the entity and the KDC before the actual Kerberos protocol communication can take place. The master key is generated as part of the domain enrollment process and is derived from a user’s, a machine’s, or a service’s password. The transport of the master key over a communication channel is secured using a secure channel.
- The secure channel. When Windows 2000 is using a secure channel, it is using a master key to secure the transport of another master key. The following example illustrates the secure channel concept. When you create a new user, the user’s password will be sent to the DC using a secure channel. The secure channel in this case is made up of the master key shared between the workstation you’re working on and the DC. In this case the master key is derived from the workstation’s machine account password. The concept of a secure channel was also explained in the previous chapter.
In the key hierarchy shown in Figure 10 the following are also true:
- Higher-level keys protect lower-level keys.
- Higher-level keying material has a longer lifetime than lower-level keying material.
- Lower-level keying material is used more frequently for sending encrypted packets across the network. As a consequence, there’s a higher risk for brute-force attacks on these packets; this means that the associated keys should be changed more often.
Step 4: The Kerberos KDC distributes the ticket by sending it via the client
The KDC can distribute the encrypted session keys to Alice and the resource server in the following two ways (remember that the session key is encrypted once with Alice’s master key and once with the resource server’s master key):
- Method 1: The KDC could send it directly to both Alice and the resource server (as shown in Figure 11).
- Method 2: The KDC could send the two encrypted session keys to Alice. Alice could send out the resource server’s encrypted session key later on in the Kerberos authentication sequence (as shown in Figure 12).
Method 1 has the following disadvantages:
- The resource server has to cache all the session keys: one session key for each client that wants to access a resource on the server. This would also impose a huge security risk on the server side.
- Synchronization problems could occur: The client could already be using the session key while the resource server hasn’t even received its copy yet.
Because of the disadvantages associated with Method 1, Kerberos uses the alternative shown in Method 2 (see Figure 12):
- Both the encrypted session keys (the one for Alice, encrypted with Alice’s master key, and the one for the resource server, encrypted with the resource server’s master key) are sent to Alice.
- Alice can decrypt the packet encrypted with her master key and get out the session key. Alice’s system can now cache both Alice’s copy of the session key and the server’s copy of the session key (contained in the ticket).
- When Alice needs to authenticate to the resource server, the client will send out the server’s copy of the session key.
The key advantage of Method 2 lies in its unique caching architecture. Alice’s machine can cache tickets and reuse them. Also, it takes away the need for the server to cache the tickets. It receives them from the client as needed. This architecture makes the Kerberos protocol stateless on the server side. This has obvious advantages if you want to implement some load balancing or redundancy solution on the server side: You will not need to bother about keeping the session keys synchronized between the different DCs.
On the client side tickets are kept in a special system memory area, which is never paged to disk. The reuse of the cached tickets is limited, because of a ticket’s limited lifetime and renewal time. Windows 2000 maintains a ticket cache for every logon session. The ticket cache is purged when the logon session ends; it is preserved when a system is in hibernation mode. The cache can be purged manually using the klist.exe or kerbtray.exe tools, explained later in this chapter.
|
Page:
1,
2,
3,
4,
5,
6,
7
|
next page  |
|
|
|
|
Windows IT Pro
Register
