Step 5: The Kerberos ticket-granting ticket limits the use of the entities’ master keys
There’s yet another important weakness in the protocol that we haven’t 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 13). This encrypted packet is sent over the network every time Alice needs a session key to authenticate to a resource server. This means that there are many opportunities for hackers to intercept the encrypted packet and to perform (offline) a brute-force attack to derive the user’s 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 the tools that were available in NT4 to do brute-force attacks on the SAM database or on authentication packets sent across the network, such as the L0phtcrack tool from the L0pht Heavy Industries (previously called Cult of the Dead Cow) hacker group.
There’s clearly a need here for a strong secret to replace Alice’s master key. This will be the role of the session key shared between each entity and the KDC. "Strong secret" in this context means less susceptible to brute-force attacks. To resist these attacks there are two possibilities. Use longer keys (longer keys create bigger key spaces and make it more difficult to guess the right key) or change the keys more often, which 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.
This new session key will replace Alice’s password to authenticate Alice to the KDC after the initial authentication. Although it has an identical function (authentication), the session key introduced in this step is not the same as the one used previously. This session key is shared between Alice and the KDC; the other session key is shared between Alice and the resource server. Just as with 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 principles as the ones described in steps 3 and 4, as follows:
- Step 3: Kerberos uses a ticket to provide secure transport of the session key: the special ticket used here is known as the Ticket-Granting Ticket (TGT).
- Step 4: Kerberos distributes the tickets by sending them out via Alice. The KDC sends the TGT to Alice; Alice caches the TGT and can send it to the KDC as needed. There’s no need for the KDC to cache the TGTs of every client.
Figure 14 shows how this new session key (S ku ) and the associated TGT are used in the basic Kerberos protocol exchange, as follows:
- Alice sends a logon message to the DC. This message is secured using Alice’s master key, derived from Alice’s password. The encryption of this request is not part of the basic Kerberos protocol as defined in RFC 1510; it’s based on the extension known as preauthentication data. Preauthentication data will be explained later on in the text.
- The KDC will then send out a secured copy of the session key to be used for authentication between Alice and the KDC for the rest of the logon session (this session key will replace the user’s master key). The copy of the session key encrypted with KDC’s master key is called the TGT.
- The session key and the TGT will be cached in Alice’s local Kerberos ticket cache.
- Later on, when Alice wants to access a resource on the resource server, the security process acting on Alice’s behalf will send out a request for a ticket to the KDC using the locally cached TGT. The request for the resource will be secured using the session key Sku.
- Finally, the KDC will send back a ticket and a new session key to Alice, which she can use later on to authenticate to the resource server. Notice that in Figure 14 the new session key is not encrypted using Alice’s master key, but using the newly created session key Sku.
The following are more thoughts on this basic Kerberos protocol Exchange:
- The TGT is reused to request tickets for other application or resource servers. The reuse of the TGT is limited by its lifetime. The lifetime of the TGT not only limits the use of the TGT itself but of all the tickets obtained using a particular TGT as well. For example, if I have a TGT that’s about to expire in a half hour, every new ticket I get will also expire at the same point in time (even though the default lifetime of a ticket may be one hour).
- Ticket requests don’t require further use of the client’s master key. This means that once you have a session key, 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 still caches the master key, because it needs it for NTLM authentication to down-level clients.
- During the logon session a weak secret (the master key derived from a client’s password) is exchanged for a strong secret (the session key contained within the TGT). In other words, at logon time and at each TGT renewal the user will authenticate to the KDC with his or her master key in subsequent ticket requests the user will authenticate using the session key, which is contained in the TGT.
- The newly created session key (S ku ) doesn’t need to be cached on the KDC: the KDC gets it from the client each time the client requests a new service ticket. S ku is encrypted using the KDC’s master key (remember: this is what they call the TGT). This feature makes Kerberos stateless on the KDC side, which has, as for resource servers, obvious advantages if some load balancing or redundancy technology has to be implemented on the KDC side. This is the case in Windows 2000; every DC has a KDC service.
Bringing It all together
In this section, we’ll bring together all the elements of the previous five steps to explain the complete Kerberos protocol. Figure 15 shows the complete Kerberos protocol, as it occurs when a user logs onto a domain and when he accesses a resource during his logon session.
Kerberos protocol consists of three subprotocols (or phases), each one made up of two steps. In the following listing, the cryptic names in parentheses are the names of the Kerberos protocol messages, as they are called in the Kerberos standard documents.
- Phase 1: Authentication Service Exchange (happens once per logon session).Bringing It all together
- Step 1: Authentication Server Request (KRB_AS_REQ). Alice logs onto the domain from her local machine. A TGT request is sent to a Windows 2000 KDC.
- Step 2: Authentication Server Reply (KRB_AS_REP). The Windows 2000 KDC returns a TGT and a session key to Alice.
- Phase 2: Ticket-Granting Service Exchange (happens once for each resource server)
- Step 1: TGS Request (KRB_TGS_REQ). Alice wants to access a resource on a server. A ticket request for the Resource Server is sent to the Windows 2000 KDC. This request consists of Alice’s TGT and an authenticator. Remember from step 1 that the authenticator is the basic entity used for Kerberos authentication: It contains the user’s ID and the current time stamp and is encrypted using the session key shared between the two entities that need to authenticate to one another.
- Step 2: TGS Reply (KRB_TGS_REP). The Windows 2000 DC returns a ticket and a session key to Alice.
- Phase 3: Client Server Authentication Exchange (happens once per server session)
- Step 1: Resource Server Request (KRB_AP_REQ). The ticket is sent to the resource server. Upon receiving the ticket and the authenticator, the server can authenticate Alice.
- Step 2: Resource Server Reply (KRB_AP_REP). The server replies to Alice with another authenticator. On receiving this authenticator, Alice can authenticate the server.
In this exchange, 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.
Kerberos data confidentiality, authentication, and integrity services
Windows 2000 includes the Kerberos extensions, which can be used to provide data confidentiality, authentication, and integrity for messages that are sent after the initial Kerberos subprotocol steps. These extensions are known as KRB_PRIV (data confidentiality) and KRB_SAFE (data authentication and integrity). They are based on the existence of a session key between two entities at the end of each Kerberos authentication protocol exchange, as follows:
- The session key can be used to sign a message (data authentication and integrity). A hash, the result of the application of a hash function on a message, can be encrypted using the session key. A hash encrypted with a session key is called a Message Authentication Code (MAC).
- The session key can be used to seal a message (data confidentiality) by encrypting a message using the session key.
A protocol that uses this session key to add signing functionality to its messages is the Server Message Block (SMB) protocol (currently known as the Common Internet File Sharing [CIFS] protocol). The use of digital signatures on SMB messages can be controlled using the EnableSecuritySignature and the RequireSecuritySignature registry values. On the server side these two values are located in HKLM\System\CurrentControlSet\Services\LanManServer\Parameters; on the client side in HKLM\System\Current-ControlSet\Services\Rdr\Parameters (as documented in Knowledge Base Article Q161372). Note that enabling SMB signing will have a significant impact on performance.
LOGGING ON TO WINDOWS 2000 USING KERBEROS
Now that we’ve explained the basic Kerberos protocol we can discuss some real-world Windows 2000 Kerberos logon examples. In this section we will look in detail at both local and network logon in a single- and a multiple-domain environment.
In the following text, we will also discuss the Authentication Service (AS) and Ticket-Granting Service (TGS) concepts. These are the two sub-services that make up the KDC service.
Single-domain logon
A single-domain logon occurs when the following takes place:
- Alice is logging on from a machine that is a member of the domain where Alice’s account has been defined (this is a local logon).
- Alice accesses a resource located on a machine that is a member of Alice’s logon domain (this is network logon).
Local logon
Figure 16 and the following list show what happens during a local logon in a single-domain environment:
- Alice presses <CTRL><ALT><DEL> and chooses to log on to the domain.
- The client software acting on behalf of Alice tries to locate a KDC service for the domain; this is done by querying DNS. The Kerberos package will retry up to three times to contact a KDC. It initially waits ten seconds for a reply and will wait an additional ten seconds on each retry. In most cases a KDC is already known; the discovery of a DC is also part of the secure channel setup that occurs before any local logon.
- Once the DC is found, Alice sends a Kerberos authentication request to the DC. This request authenticates Alice to the DC and contains a TGT request (KRB_AS_REQ).
- The Authentication Service authenticates Alice, generates a TGT, and sends it back to the client (KRB_AS_REP).
- The local machine where Alice logged on is, as with any other domain resource, a resource for which Alice needs a ticket. Alice sends a ticket request to the DC using her TGT (together with an authenticator) (KRB_TGS_REQ).
- The TGS of the DC checks the TGT and the authenticator, generates a ticket for the local machine, and sends it back to Alice (KRB_TGS_REP).
- On Alice’s machine, the ticket is presented to the Local Security Authority, which will create an access token for Alice. From then on, any process acting on behalf of Alice can access the local machine’s resources.
This first example showed how Kerberos uses DNS to locate a KDC service. Windows 2000 publishes two special Kerberos SRV records to DNS: _kerberos and _kpasswd.
Network logon
When Alice, who is already logged on to a domain, wants to access a resource located on a server within the same domain, a network logon happens. In this case, the logon sequence is the following (as illustrated in Figure 17):
- Alice sends a service ticket request to the DC using her TGT (together with an authenticator) (KRB_TGS_REQ).
- The TGS of the DC checks the authenticator, generates a service ticket, and sends it back to Alice (KRB_TGS_REP).
- Alice sends the ticket (together with an authenticator) to the resource server (KRB_AP_REQ).
- The resource server verifies the ticket and the authenticator. After the verification, it sends another authenticator to Alice for resource service authentication (KRB_AP_REP).
Multiple-domain logon
A multiple-domain logon occurs when the following takes place:
Alice is logging on from a machine member of a domain different from the one where Alice’s account has been defined (this is a logon logon).
Alice is accessing a resource located on a machine that is a member of a domain different from the one where Alice logged on (this is network logon).
In the following examples we will use the concepts referral ticket and interrealm key; they will be explained in a subsequent section.
Local logon
Figure 18 shows a typical multiple-domain environment, consisting of a parent domain, compaq.com, and two child domains, NA (North America), and Europe. In the local logon example, Alice’s account is defined in the Europe domain. Alice logs on from a workstation whose account is defined in the NA domain.
The local logon process can be subdivided into the four following steps:
- Step 1: AS exchange (KRB_AS_REQ and KRB_AS_REP):
- To log on, Alice sends a TGT request to a KDC in Europe.compaq.com. The AS request and reply are sent to the KDC of Europe.compaq.com. Only a KDC of Alice’s account domain can authenticate Alice (credentials are never replicated between DCs of different domains).
- Steps 2, 3, and 4: TGS exchanges (KRB_TGS_REQ and KRB_TGS_REP):
- To request a ticket for Alice to authenticate to the NA workstation, a TGS request is sent to the KDC of Europe.compaq.com.
- The KDC of Europe.compaq.com cannot issue a ticket that allows Alice to authenticate to the workstation in NA. Only a KDC of NA can return such a ticket. Therefore, the TGS reply contains a referral ticket to the domain closest to NA.compaq.com (from a DNS point of view) and with which NA.compaq.com has a real Kerberos trust. In this example, it is compaq.com. The concept of a "real trust relationship" will be explained in a later section, "Multiple domain logon: behind the scenes."
- To create trust relationships in a forest Windows 2000 calls on DNS; at run time, however, it calls on AD. If Windows 2000 would also use DNS at run time, it would be impossible to discover short-cut trust relationships.
- On receiving the referral ticket, Alice locates a KDC of the intermediary domain compaq.com and sends a TGS request, including the referral ticket to that KDC.
- The KDC in compaq.com decrypts the ticket using the interrealm key (shared between Europe.compaq.com and compaq.com) and detects it contains a ticket request for a workstation in NA. The KDC checks on the domain closest to NA.compaq.com from the compaq.com point of view, with which it has a real trust relationship, and sends Alice a referral ticket to this domain.
- Alice asks a KDC of NA.compaq.com for a ticket for the local workstation. Finally, a KDC of NA.compaq.com will send Alice a TGS reply with a valid ticket for the workstation.
The amount of interdomain authentication traffic occurring in this scenario should not be overestimated for two reasons: The size of Kerberos tickets is relatively small and the referral traffic does not occur at every resource access (tickets have a lifetime and are cached).
An interesting side note is to look at what happens if, at some point in the above exchange, the administrator of the Europe domain decides to disable Alice’s account. The answer to this question is pretty straightforward. The KDC of Europe will continue to issue tickets as long as the original TGT is valid; the same thing is true for the NA domain. The disabled account will only be detected when Alice gets a new TGT.
Network logon
Let’s look at what happens with a local logon in a multiple-domain environment. Again, we’re using the example of a parent domain and two child domains. In the network logon example, Alice is logged on to the NA domain (Alice and computer account are defined in the NA domain). Alice wants to access a resource hosted on a server in the Europe domain.
The network logon process can be subdivided into the following four steps (as illustrated in Figure 19):
Steps 1, 2, and 3: TGS exchanges:
- Before Alice can contact the KDC in realm Europe.compaq.com, she must have a valid referral ticket to talk to the KDC of that domain. Since there is no direct trust between Europe.compaq.com and NA.compaq.com, Alice must request the referral ticket via an intermediary domain.
- Alice first requests a referral ticket for the KDC of the domain closest to the Europe.compaq.com domain; this is compaq.com. Since there is a direct trust between NA.compaq.com and compaq.com, Alice can request this ticket from her own KDC. The KDC will return a referral ticket encrypted with the interrealm key shared with between NA.compaq.com and compaq.com.
- Armed with this referral ticket, Alice can send a TGS request to the KDC of realm compaq.com, requesting a referral ticket for the KDC of the Europe.compaq.com realm. Since there is a direct trust between compaq.com and Europe.compaq.com, the KDC of Europe.compaq.com can answer this request. The returned referral ticket will be encrypted with the interrealm key shared between compaq.com and Europe.compaq.com.
- With the above referral ticket, Alice finally can send a TGS request to a KDC of realm Europe.compaq.com to request a service ticket for the target file server.
Step 4: Application Server Exchange:
- With the service ticket received from the target server’s KDC, Alice sends an access request (consisting of the ticket and an authenticator) to the target server.
- During the last step, the target server will authenticate back to Alice.
|
Page:
1,
2,
3,
4,
5,
6,
7
|
next page  |
|
|
|
|
Windows IT Pro
Register
