Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)

The following sections explain 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:

Before starting to explore how Kerberos works, we must explain the notations that will be used in the illustrations:

To ease reading we will talk about a “client,” Alice, and a “resource server” that authenticates 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 talk about the “service account of the service,” but this would not promote ease of reading. Also, when we talk about 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 and security principal and entity, and domain and realm.

5.2.1 Kerberos design assumptions

Before diving into the nuts and bolts of the protocol, let’s have a quick look at some of the design assumptions the Kerberos designers at MIT took. It is very important to keep these assumptions in mind as we run through the Kerberos internals.

5.2.2 Step 1: Kerberos authentication is based on symmetric key cryptography

To authenticate entities Kerberos uses symmetric key cryptography.[2] 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 5.2):

Figure 5.2: Kerberos authentication is based on symmetric key cryptography.

Why does this process authenticate Alice to the resource server? If the resource server can successfully decrypt the message, this means if the decryption process results in Alice’s name and an acceptable timestamp, the resource server knows that only Alice could have encrypted this information, because she is the only one, besides the resource server, who also knows the symmetric key. In this context acceptable means the following: Upon receipt of Alice’s encrypted packet, the resource server will compare the timestamp in Alice’s packet against the local time. If the time skew between these two timestamps is too big, the resource server will reject the authentication attempt, because a hacker could have replayed Alice’s original authentication packet.

In this explanation you may have noticed the differences and similarities with the NTLM authentication protocol. 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 timestamp and the user’s name to do the same thing.

The encrypted packet containing Alice’s name and the timestamp is known in Kerberos as the authenticator, and 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 this exchange is the timestamp: 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 timestamp explains the time sensitivity of the Kerberos protocol and of Windows 2000 and Windows Server 2003.

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 this example, it means that, in turn, the server will encrypt its name and the current timestamp and send it to Alice.

A big problem when using a symmetric protocol is the secure distribution of the secret key. The secret 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 way. Secure means that the confidentiality and integrity of the key should be protected. If anybody could read the secret key when it is 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.

5.2.3 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?

Suppose that Alice is part of a workgroup consisting of five entities that all want to authenticate to one another using symmetric key cryptography. Because every entity needs to share a secret key with every other entity, we will need 10 keys. The mathematical formula behind this is n (n – 1)/2. In a 50,000-employee company we would need about 1.5 billion keys. Not only would we have to deal with an enormous amount of keys, but there would also be an enormous amount of small authentication databases: On every client there would be one, containing all the secret keys of the entities with which the client wants to authenticate. This solution is clearly not scalable to the level of a big environment. Imagine having to use such a solution on the Internet.

To make Kerberos more scalable, the Kerberos developers included the concept of a KDC. KDC is a trusted third party with which 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.

Figure 5.3: A KDC provides scalability.

In Windows Server 2003 the KDC is a service that is installed on every domain controller as part of the dcpromo Active Directory installation process. Every Windows Server 2003 domain controller runs a KDC service[3] and hosts an Active Directory (AD) instance, the central authentication database.[4 ]As a consequence, a domain with multiple domain controllers provides fault tolerance for the authentication process and the authentication database. If one DC is down, another one can automatically take over. Also, the AD authentication database is replicated between domain controllers.

The concept of a master key is not new to Windows 2000, Windows Server 2003, and Kerberos: It already existed in NT4 and earlier Windows versions. In Windows the master key is derived from a security principal’s password.

The password is a secret key that is shared between each individual security principal and the central authentication authority (in the Kerberos case the KDC). 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 is MD4).

An entity’s master key is generated as part of the domain enrollment process (e.g, 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.

5.2.4 Step 3: The ticket provides secure transport of the session key

Figure 5.4 shows the three basic entities with which the Kerberos protocol deals: a client (Alice), a resource server, and a KDC. Figure 5.4 also shows the master keys that are shared between the entities participating in the authentication process and the KDC.

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. This section explains how Kerberos resolves this problem. It makes the link between the session key and the master key (introduced in step 2) and explains why we really need a master key in the Kerberos protocol.

Figure 5.4: Kerberos entities and master key concept.

In Section 5.2.3, 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 Figure5.4, the resource server would never trust Alice to generate session keys, because Alice has not authenticated yet to the resource server (the other way around would not 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[5] and distribute it to both entities. 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.

Because there are two entities, Alice and the resource server, two encrypted versions of the session key must be generated:

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 Server 2003 domain controller 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 5.5 shows the Windows Server 2003 key hierarchy, which consists of:

Figure 5.5: Windows Server 2003 key hierarchy.

In this key hierarchy the following are also true:

5.2.5 Step 4: The KDC distributes the session key by sending it to the client

The KDC can distribute the encrypted session keys to Alice and the resource server in two ways:

Alice. Alice could then send out the resource server’s encrypted copy of the session key later on in the Kerberos authentication sequence (as shown in Figure 5.7).

The first method has the following disadvantages:

Because of the disadvantages associated with Method 1, Kerberos uses the alternative explained next as Method 2 (see Figure 5.7):

Figure 5.7: Kerberos ticket distribution Method 2.

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 clients as needed. This architecture makes the Kerberos protocol stateless on the server side. This has obvious advantages if you want to implement a load balancing or redundancy solution on the server side: There is no need to bother about keeping the session keys synchronized between the different domain controllers.

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, XP, and Windows Server 2003 maintain a ticket cache for every security principal logon session. The ticket cache is purged when the logon session ends. The cache is preserved and written to disk when a system goes into hibernation mode.

5.2.6 Step 5: The Ticket Granting Ticket limits the use of the master keys

There is yet another important weakness in the protocol that we have not addressed so far: The session key that is sent back from the KDC to Alice is encrypted using Alice’s master key (as shown in Figure 5.8). This encrypted packet is sent over the network every time Alice needs a session key to authenticate to a resource server. This means that every time there is an opportunity for hackers to intercept the encrypted packet and to perform— possibly offline—a brute-force attack on the encrypted packet and derive the user’s master key.

Figure 5.8: The use of the master key.

In a brute-force attack, a hacker tries to guess the key that was used to encrypt a packet by trying out all the possible keys and looking at the result. Such attacks are not unrealistic: Remember some of the tools that were mentioned in Chapter 2 (L0phtcrack, John the Ripper…) to do brute-force attacks on the SAM or AD database or on the authentication packets sent across the network?

There is clearly a need here for a strong[6] secret to replace Alice’s master key: This will be the role of the session key that is shared between each entity and the KDC. This session key will replace Alice’s password, and it will be used to authenticate Alice to the KDC after the initial authentication.[7]

Although it has an identical function (authentication), the session key introduced in this step is not the same as the one used in the previous sections. This session key is shared between Alice and the KDC, and the other session key is shared between Alice and the resource server.

Just like Alice’s master key, both Alice and the KDC must know this session key. To securely transport this session key, we will use the same mechanism as the one described in steps 3 and 4:

Figure 5.9 shows how this new session key (Sku) and the associated TGT are used in the basic Kerberos protocol exchange:

This sequence shows how in the basic Kerberos exchange:

5.2.7 Bringing it all together

In this section we will bring together all the elements that were brought up in the previous five steps. Figure 5.10 shows the complete Kerberos protocol: It consists of three subprotocols (or phases), each one made up of two steps. In the following list, the cryptic names between parentheses are the names of the Kerberos protocol messages as they are called in the Kerberos standard documents.

Figure 5.10: The complete Kerberos protocol. Request Ticket + Auth

During these exchanges the following keys and tickets are cached on Alice’s computer: the TGT, the ticket used to authenticate to the resource server, and two session keys—one to authenticate to the KDC and one to authenticate to the resource server.

5.2.8 Kerberos data confidentiality, authentication, and integrity services

Windows 2000, XP, and Windows Server 2003 all include the Kerberos extensions that can be used to provide data confidentiality, authentication, and integrity for messages that are sent after the initial Kerberos exchange outlined in the previous sections. These extensions are known as the KRB_PRIV (providing data confidentiality) and the KRB_SAFE (providing data authentication and integrity) Kerberos extensions. They are based on the existence of a session key between two entities at the end of a Kerberos authentication protocol exchange:

[2]When the Kerberos design was started, public key cryptography was still patented (by RSA). This explains why the default Kerberos protocol (as defined in RFC 1510) relies on symmetric key cryptography.

[3]The KDC itself is made of two subservices: the Authentication Service (AS) and the Ticket Granting Service (TGS); in other Kerberos implementations these two subservices can run on different machines, but this is not possible in Windows 2000 and Windows Server 2003.

[4 ]On 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 and Windows Server 2003 every KDC server hosts a read-write copy of the domain portion of the Active Directory (multimaster model).

[5]The security quality of the session key depends on the quality of the random number generator used to generate the session key.

[6]Strong means less susceptible to brute-force attacks. To resist these attacks there are two possibilities: (1) Use longer keys—longer keys create bigger key spaces and make it more difficult to guess the right key; (2) change the keys more often—this limits the chance for brute-force attacks. In other words, limit the lifetime of the keys; this principle is often referred to as perfect forward secrecy (PFS). The Kerberos developers have chosen the latter solution.

[7]There are also other reasons why the concept of a session key shared between every Kerberos entity and the KDC is important: it allows for the KDC’s AS and TGS services to be hosted on different machines (this cannot be done in Windows, but is often done in UNIX Kerberos implementations), and it enables cross-domain authentication referrals (explained later).

[8]The encryption of this request is not a part of the basic Kerberos protocol as defined in RFC 1510; it is based on a Kerberos extension known as Kerberos preauthentication. It will be explained later on in this chapter.

[9]This also means that once you have a session key, in a standard Kerberos implementation there’s no more need to cache the master key on the client, which is very good from a security point of view. Microsoft Windows 2000, XP, and Windows Server 2003 still cache the master key because they need it to perform NTLM authentication to downlevel clients.

Related

Категории