Security Protocols

[Previous] [Next]

You probably won't be surprised to find out that protocols have been defined to initiate and implement secure communication. Different protocols can be used to meet different needs, and we will discuss three such protocols in this chapter: Kerberos, NTLM, and SSL. I selected these protocols because of the exceptional support Windows 2000 provides for them and their significance in existing environments such as the Internet.

Security protocols are primarily designed to use encryption techniques as well as network communication techniques, in a defined manner, with the objective of implementing one or more of the three goals mentioned earlier in this chapter: privacy, authentication, and integrity. All three protocols that we will cover achieve these goals to varying degrees. Additional features of some of the protocols are delegation and mutual authentication.

The Kerberos and NTLM security protocols are an integral part of security in Windows 2000. As such, these protocols can be used to directly authenticate a user in a domain. Said another way, a server can retrieve an access token for a client by using the Kerberos and NTLM security protocols. (Tokens are discussed in detail in Chapter 11.)

SSL is a security protocol that is not as tightly integrated with the Windows security model as are the other protocols. SSL is a certificate-based protocol, and Windows must do a mapping of certificate information before a server can impersonate. (Impersonation is discussed in detail in Chapter 11.)

NTLM

NTLM is the existing security protocol of the Windows family. It is understood by Windows 2000, Windows NT, and Windows 95/98. Although Kerberos offers some noteworthy improvements over NTLM, you need to understand NTLM.

The NTLM protocol is fairly straightforward and is based on what is known as a challenge/response sequence. The sequence, illustrated in Figure 12-1, works like this:

• Step 1 The client sends its username and its domain name to the server.
• Step 2 The server forwards this information to the domain controller (DC).
• Step 3 The DC creates a challenge, which is randomly generated and created with the client's password (known only by the client and the DC).
• Step 4 The DC sends the challenge to the server.
• Step 5 The server forwards the challenge to the client.
• Step 6 The client examines the challenge using its password, and performs a known modification to the challenge, creating a response. The known modification is defined by the NTLM protocol.
• Step 7 The client sends the response back to the server.
• Step 8 The server forwards the response to the DC.
• Step 9 The DC examines the response and verifies that it is the original challenge modified using the known modification. The client is now authenticated.
• Step 10 The DC informs the server that the client is authenticated.

Figure 12-1. NTLM authentication

As you can see from Figure 12-1, the network traffic generated by the NTLM protocol is significant, and the server bears a great deal of the responsibility even though it is largely acting as a proxy between the client and the domain controller (DC). But this protocol does get the job done.

Kerberos

As I mentioned in the last section, NTLM is the only security protocol supported on all of Microsoft's desktop operating systems. For this reason, it still plays a very important role in server development in an enterprise. However, Kerberos is the shining star of Windows 2000 and offers a lot of great features:

• Mutual authentication Kerberos offers a mechanism by which a client can be sure of the server's identity, in addition to the more common client authentication by the service. This authentication is achieved efficiently by Kerberos without requiring a second authentication by the client.
• Delegation With Kerberos, a server can use its client's credentials to contact a second-tier server on behalf of the client. Through delegation, the second-tier server authenticates the server as though its user context were that of the client's.
• Efficient authentication Kerberos authentication requires minimal communication legs in its journey, and only a single leg of communication must be performed by the server (or two communication legs, if the client is mutually authenticating). This efficiency removes a great deal of the load from the server, shifting the responsibility to the client.
• Kerberos is a standard The Kerberos authentication system was designed at MIT as part of project Athena. Windows 2000 implements Kerberos V5.0 as defined in RFC 1510. As such, Windows 2000 can interoperate with other operating systems that are capable of communicating with Kerberos.

Kerberos is the name of the three-headed dog in Greek mythology that guarded the entrance to the underworld. The Kerberos protocol was named after this mythical animal because it too has three components:

• Client This is the entity or principal that is initiating an authenticated conversation.
• Server This is the entity or principal with which the client wishes to communicate.
• Key Distribution Center (KDC) An entity, trusted by both the client and the server, that manages authentication for them.

Each of these entities plays an important role in the Kerberos specification. The following description of Kerberos will define some important terms and concepts for you, but you don't need a complete understanding of Kerberos before you can use it in your applications.

Kerberos Authentication

Kerberos relies on symmetric key encryption. A server using Kerberos to authenticate a client decrypts a packet known as an authenticator, which is sent by the client and contains an encrypted copy of the client's identification and a timestamp (which is used to avoid authenticator duplication and reuse across the wire). Only the client and the server can encrypt or decrypt the authenticator with this key, which is guaranteed to be a secret known only by them. This secret key is a session key. This session key is also the key that the client and server use to encrypt data as they continue to communicate for the duration of the session.

Kerberos authentication is pretty simple so far, but as you can imagine, the real magic of Kerberos is in the negotiation of the session key. The session key must be unique and is a secret known only by the communicating entities—the client and the server. The open questions are as follows:

• Who creates the session key?
• How is it communicated to the client and the server in a secure manner?

I will go through the process that answers these questions one step at a time, but first it is important that you understand the Kerberos protocol's concept of a ticket.

The ticket A ticket is a packet of information whose contents are held by a client, and that contains information that allows a server to authenticate the client. This packet was given the name ticket because its information is the client's "ticket" to "use" the server. Here are some important items contained within a ticket:

• The identification of the client holding the ticket. This is username and domain information for Windows 2000.
• A session key that is encrypted in the server's password. This is the secret key that is used to encrypt and decrypt any data communicated between the client and the server.
• A creation time and an expiration time.
• Additional information and flags.

Tickets are generated by the Key Distribution Center or KDC. The secret session key found inside the ticket is encrypted with the server's password. Only the KDC and the server know this password. Although the KDC grants tickets to clients, the encrypted portions of a ticket are opaque to a client and will be used only by the requested server.

The client requests tickets for use with specific servers, and the KDC grants these tickets. A ticket can be used and reused for authenticated communication with a server until the expiration time has passed, at which time the client must be granted a new ticket from the KDC.

Because the session key is encrypted using the server's password, the key can be used only by the server. Additionally, encrypted and clear-text versions of the ticket holder's identification are included on the ticket. This allows anybody to know the holder of the ticket, but the encrypted copy allows the server to ensure that the ticket holder has not been changed since the creation of the ticket.

The duration of a ticket's usefulness defines a session with a server. This session continues until the ticket expires or until the client discards the ticket. The server does not store the ticket, so authentication (from the server's point of view) is stateless.

Now I would like to describe a very important session. This is the client's session with the KDC. This is also the first of three phases that a client must go through to authenticate itself with a server. Figure 12-2 shows the entire authentication process using the Kerberos protocol from start to finish.

Figure 12-2. Kerberos protocol authentication process

The ticket-granting ticket (First Phase) As I mentioned before, the KDC creates tickets and communicates them to a requesting client. The KDC itself is a server, however, and the client must maintain a ticket for use with the KDC. Because the client will be using the KDC to retrieve tickets for use with other servers in the system, the ticket that the client holds for use with the KDC is called a ticket-granting ticket, or TGT. This is the very first ticket that a client requests from the KDC, and it defines a session with the KDC. Here are the steps in acquiring a TGT:

• Step 1 The client sends a request for a ticket-granting ticket to the KDC. (Microsoft has defined extra data that accompanies this request to preauthenticate the user to the KDC. This information is not part of the Kerberos definition, and it is not important for our discussion.)
• Step 2 The KDC sends a ticket-granting ticket to the client along with a secret key encrypted with the client's password. This secret key is a session key for future communication with the KDC.

Now the client holds a session key and a ticket that can be used with the KDC in requests for future tickets. The session key returned to the client is encrypted with the client's password. If the client has lied about its identity, it will not be able to decrypt the session key, and the ticket-granting ticket will be useless to it. This is because the session key is used in all future communication with the KDC.

The ticket-granting ticket, like all tickets, has a session key encrypted with the server's password and expiration information. As long as the client holds an unexpired TGT for the KDC, it is participating in a session with the server.

Requesting a ticket (Second Phase) When a client wishes to initiate an authenticated session with a server, it must first request a ticket for this session from the KDC. Before it can do this, it must hold a ticket-granting ticket for use with the KDC. This was established in the first phase. Here are the steps the client takes to request a ticket for use with a server:

• Step 1 The client sends a request to the KDC for a ticket. The request includes the following information:

• An authenticator (the client's identity and a timestamp), which is encrypted with the session key that the client holds for communication with the KDC
• The ticket-granting ticket
• The server for which the client is requesting a ticket

• Step 2 The KDC opens the TGT by decrypting the session key held within (using its own secret password). The KDC decrypts the authenticator with this session key. If the decryption succeeds, the client is authenticated to the KDC, and the KDC builds the requested ticket for the client.
• Step 3 The KDC sends the requested ticket back to the client. (Remember that the ticket contains a copy of the session key encrypted in the server's password known only by the KDC and the server.) The KDC also communicates the session key (for use with the server) to the client, encrypted in the secret session key associated with the client's TGT.

At this point, the client holds a ticket for authenticating with the requested server. The client also holds its own copy of the session key used when communicating with the server.

Authenticating with a server (Third Phase) Finally, the client begins its communication with the server, which can happen only if the client holds a ticket for authenticating with the server. The ticket is granted in the second phase. Here are the steps that the client takes to authenticate with a server:

• Step 1 The client sends a request for authentication to the server. This request includes the following information:

• An authenticator (the client's identity and a timestamp), which is encrypted with the secret key that the client holds for this session
• The ticket that the client holds for the session

• Step 2 The server opens the ticket by decrypting, using its secret password, the session key held within. The server then uses the session key to decrypt the authenticator included with the request. If the decryption works, the client has been authenticated to the server.
• Step 3 If the client has requested mutual authentication, the server sends an authenticator to the client, encrypted using the session key. The server could not have encrypted the authenticator unless it held the session key, proving that the server is the requested server.

At this point, the client and the server can communicate using their shared session key to encrypt data as it crosses the network.

Like the KDC, the server does not save its ticket, and in this way uses what is known as stateless authentication. This means that the third phase is necessary each successive time the client wishes to communicate with the server.

Notice in Figure 12-2 that communication with the server does not begin until the third phase. Notice also that the server and the KDC never communicate. These are noteworthy scalability improvements over the authentication scheme presented by NTLM.

As I mentioned before, this coverage of the Kerberos protocol does not cover every detail of the protocol. However, this description provides some perspective, which you will find useful when we begin our discussion of programming using security protocols.