The Kerberos protocol relies heavily on an authentication technique involving shared-secret keys. The basic shared-secret concept is quite simple: If a secret is known by only two people, then either person can verify the identity of the other by confirming that the other person knows the secret.

For example, suppose that Alice often sends messages to Bob, and that Bob needs to ensure that a message from Alice really has come from Alice before he acts on its information. They decide to solve their problem by selecting a password and agreeing to share the secret password between the two of them, but not with anyone else. If a message purported to be from Alice can somehow demonstrate that the sender knows the password, Bob can verify that the sender is indeed Alice.

The only question left for Alice and Bob to resolve is how Alice will show that she knows the password. She could include it somewhere in her messages, perhaps in a signature block at the end—Alice, Our$ecret. This would be simple and efficient and would be effective if Alice and Bob could be sure that no one else is reading their mail. Unfortunately, their messages pass over a network used by people like Carol, who uses a network analyzer to scan traffic in hope that one day she might spot a password. Thus, Alice must not prove that she knows the secret by including it in her message. To keep the password secret, she must show that she knows it without revealing it.

The Kerberos protocol solves this problem with secret key cryptography. Instead of sharing a password, communication partners share a cryptographic key, and they use knowledge of this key to verify one another's identity. In order for the technique to work, the shared key must be symmetric—that is, a single key must be capable of both encryption and decryption. One party proves knowledge of the key by encrypting a piece of information; the other proves knowledge of the key by decrypting the information.

Kerberos authentication relies on several keys and key types for encryption. Key types can include long-term symmetric keys, long-term asymmetric keys, and short-term symmetric keys. The authentication protocol was designed to use symmetric encryption, meaning that the same shared key is used by the sender and the recipient for encryption and decryption.

User keys

System keys

Service keys

Inter-realm keys

Kerberos SSP supports different encryption types and key lengths depending on the task to be completed and the options specified. Although the size of the key determines the degree of protection the key provides, key size does not significantly impact the size of the ticket. The following table lists the key lengths that Kerberos SSP supports for the various types of encryption.

Key Lengths for Encryption Types

The server does not have to store the session key that it uses in communicating with clients. It is the client's responsibility to hold a ticket for the server in its credentials cache and present the ticket each time it wants access to the server. Whenever the server receives a service ticket from a client, the server can use its secret key to decrypt the ticket and extract the session key. When the server no longer needs the session key, it can discard it.

The client does not need to go back to the KDC each time it wants access to this particular server. Service tickets can be reused. To guard against the possibility that someone might steal a copy of a ticket, service tickets have an expiration time that is specified by the KDC in the ticket's data structure.

How long a ticket is valid depends on the policy for the realm. Although the RFC recommends a maximum ticket lifetime of one day, in both MIT Kerberos 5 Release 1.3.1 and the Windows 2000 or Windows Server 2003 implementations of the Kerberos protocol, tickets are good for no longer than 10 hours by default, about the length of a normal logon session. When the user logs off, the credentials cache is flushed and all service tickets—as well as all session keys—are destroyed.

A client needs to have some information about what is inside tickets and TGTs in order to manage its credentials cache. When the KDC returns a ticket and session key as the result of an authentication service (AS) or ticket-granting service (TGS) exchange, it packages the client's copy of the session key in a data structure that includes the information in the following ticket fields: Authentication Time, Start Time, End Time, and Renew Till. The entire structure is encrypted in the client's key and returned with the KRB_AS_REP or KRB_TGS_REP messages.

The Kerberos protocol describes a number of fields to be used in the authentication exchange. One of these, the optional authorization data field, is intended to be specific to the end service, in this case, Microsoft authorization. The Microsoft implementation follows the Kerberos specification (RFC 1510) by using the authorization field to store information about user identity and group membership. This information is stored in Microsoft authorization data that is generated by a domain controller during an AS or TGS request. The Microsoft authorization data includes the following groups of information:

• Credential information. Information about the ticket and the client, such as Group IDs, which list relative IDs (RIDs) that belong to the client for his or her domain and groups.
  
• Client information. Ensures that the ticket belongs to the client who is submitting it.
  
• Supplemental credentials. Returned by the KDC service to enable PKINIT.
  
• Signatures. The Microsoft authorization data contains two digital signatures, one for the domain controller and one for the server offering the service. These signatures are used to prevent clients or untrusted services from generating their own forged Microsoft authorization data.
  
• PAC-request pre-authentication data. Normally, the Microsoft authorization data is included in every pre-authenticated ticket received from an AS request. However, a client can also explicitly request — with the privilege attribute certificate (PAC)-request pre-authentication data field — to include or not include SIDs. If the field is present, the account SIDs will be included. If the field is not present, SIDs will not be included.
  

For more information about Microsoft authorization data present in Kerberos tickets issued by Windows domain controllers, see "Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources," a Windows Development (General) topic on MSDN.

Each ticket has a start time and an expiration time. At any time after the start time but before the expiration time, a client holding a ticket for a service can present the ticket and gain access to the service, no matter how many times the client has used the ticket before. In order to reduce the risk that a ticket or the corresponding session key might be compromised, administrators can set the maximum lifetime for tickets. The maximum lifetime for tickets setting is an element of Kerberos policy.

When a client asks the KDC for a ticket to a service, the client can request a specific start time. If this time is missing from the request or is a time in the past, the KDC sets the ticket's start time field to the current time.

Whether or not a client specifies a start time, its request must include a desired expiration time. The KDC determines the value in a ticket's End Time field by adding the maximum ticket life fixed by Kerberos policy to the value in the ticket's Start Time field. It then compares the result with the requested expiration time. Whichever time is sooner becomes the ticket's end time.

The KDC does not notify clients when service tickets or TGTs are about to expire. Furthermore, other than keeping short-term records needed to prevent replay attacks, it does not keep track of transactions with clients.

If a client presents an expired service ticket when requesting a connection to a server, the server returns an error message. The client must request a new service ticket from the KDC. After a connection is authenticated, however, it no longer matters whether the service ticket remains valid. Service tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the service ticket used to authenticate the connection expires during the connection.

If a client presents an expired TGT when requesting a service ticket from the KDC, the KDC responds with an error message. The client must request a new TGT, and to do that it needs the user's long-term key. If the client did not cache the user's long-term key during the initial logon process, the client might have to ask the user for a password and derive the long-term key.

The target server can trust the contents of the ticket because the ticket is encrypted with the target server's secret key. However, the target server cannot trust that the ticket was really sent by the client specified in the ticket. The ticket could have been stolen and is now being included in an imposter's message.

• The authenticator is encrypted with the session key created by the KDC to be used between the client and the target server. Only the client and the target server can access the session key.
  
• The target server uses its secret key to decrypt the ticket, finds the session key inside the ticket, and uses it to decrypt the authenticator.
  
• If the target server can successfully decrypt the authenticator and if the authenticator's data is accurate, then the target server will trust the source of the ticket.
  

The timestamp is perhaps the most important piece of data in the authenticator. A domain's Kerberos policy and policies established by applications typically require that the timestamp be within minutes of the time on the target server. Otherwise, the authenticator and the ticket will be rejected. This helps prevent message replay.

Although no authenticator is included in the initial authentication service request message (explained later in this document), the message does include the client's timestamp in the pre-authentication field.

The following table lists and describes authenticator fields. The exact data structures for authenticators as well as messages can be found in RFC 1510.

Authenticator Fields

Authentication service (AS)

Ticket-granting service (TGS)

SPNs can only be registered by a domain administrator, with one exception—a system account can register an SPN for its computer account.

In Windows 2000, SPNs were canonicalized to the SAM account name—for example, Server1, Server1$. This caused issues when clients requested tickets for a service with a non-canonical name. The system was unable to detect the existing cached service ticket and would request a new service ticket for the service. In Windows Server 2003, on the other hand, the SPN requested is used without canonicalization.

SPNs are unique identifiers for services running on servers. Every service that will use Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network. If an SPN is not set for a service, then clients will have no way of locating that service. Without properly set SPNs, Kerberos authentication is not possible.

An SPN is registered in Active Directory under a user account as an attribute called Service-Principal-Name. The SPN is assigned to the account under which the service the SPN identifies is running. Any service can look up the SPN for another service. When a service wants to authenticate to another service, it uses that service's SPN to differentiate it from all of the other services running on that computer.

This is why SPNs are so crucial to constrained delegation (discussed later). When you set up a computer for delegation, one step of the process is to list the services on other computers that the computer is allowed to delegate to. This list forms a type of ACL. The services running on the other computers are identified by the SPNs that are issued to those services.

Additionally, in Windows Server 2003, KDCs will not issue a service ticket for an account that does not have an SPN. If a service account were simply a user account with a human-generated password, then that account would be more vulnerable to an offline dictionary attack. For an account without an SPN, the KDC will return KDC_ERR_S_PRINCIPAL_UNKNOWN. However, the context of the error will be KRB_ERR_MUST_USE_USER2USER, which has the description of "Server principal valid for user-to-user only."

In general, SPNs should be set at the time of account creation. Setting an SPN on an account is as important—from a security standpoint—as creating that account. Special accounts that were created for services are useless until an SPN is set on those accounts for whatever service will be running under them.

The following table lists, in alphabetical order, the built-in SPNs that are recognized for computer accounts.

Built-in SPNs Recognized for Computer Accounts

These SPNs are recognized for computer accounts if the computer has a host SPN. Unless they are explicitly placed on objects, a host SPN can substitute for any of the above SPNs.

Because multiple services can run simultaneously under the same account, setting an SPN requires four unique pieces of information. These four pieces of information uniquely identify any service running on a network and can be used to mutually authenticate to any service.

For each SPN that is set, the following information is required:

• The type of service, formally called a service class. This enables you to differentiate between multiple services running under the same account.
  
• The account under which the service is running.
  
• The computer on which the service is running, including any aliases that point to that computer.
  
• The port on which the service is running (optional if the default port for the service of that type is used such as port 80 for HTTP).
  

The syntax of an SPN itself is service/hostname:port, where:

• Service is the service class of the SPN.
  
• Hostname is the computer to which the SPN belongs.
  
• Port is the port on which the service that the SPN is registered to runs.
  

Users can change their passwords, and therefore their keys, at any time. This poses a problem for all existing credentials that are encrypted with the older key, because the credentials would no longer be usable if the user expected to use the new key. Although this is merely inconvenient to users—who can simply get new tickets—long-running services such as batch jobs would be interrupted if there was no one available to get a new ticket with the new key for the job. To address this problem, clients keep a copy of their older key for a period of time after switching to a new password.

When parties exchange encrypted communications, they need a way to determine which keys to use to decrypt the data they have received. If there is only one key, this is easy. However, when there are many keys, some of which correspond to the same account—such as when passwords are changed—then this task becomes difficult. One way to find the right key is to try all available keys, but this wastes time and computing resources, particularly if the client has many keys to try.

To streamline this process, encrypted data includes a header that has information including a sort of serial number that is associated with the key and the encryption type used to encrypt the data. When a client receives an encrypted communication, it includes information about whose key set to use, as well as which particular key version to use to decrypt the data. This way, even if a ticket is encrypted with an older key, the recipient can still decrypt it by looking at the key version number, finding the correct key version, and decrypting the ticket. Eventually, tickets with outdated keys expire, and the system gradually shifts to using the new key in all cases, creating no problems for the user.

New to Windows Server 2003 is the read-only attribute ms-DS-KeyVersionNumber. When a password is changed, the key version number is incremented and the current value can be queried using ms-DS-KeyVersionNumber. Windows 2000 KDCs will always issue tickets with a key version number equal to 1. Windows Server 2003 KDCs only keep track of the latest key version number for a principal account because there is no reason for the KDC to use outdated keys.

Key version numbers also enable Windows Server 2003 to provide more informative errors when a message cannot be decrypted. In general cases, when information can not be decrypted, the system provides the error KRB_AP_ERR_MODIFIED, meaning that the encrypted information is not accessible, but with no further information. For example, the data could have been modified in transit, the data could have been malformed initially, or there could be no available key. Each of these possible causes requires troubleshooting at different locations and using different techniques.

On the other hand, using key version numbers can enable the system to communicate the source of the failure. For example, if the client has no key to match the key version number included in the header, the system responds with the error KRB_AP_ERR_BADKEYVER. This error message specifically informs the client that the appropriate key version is not available. The client can then resolve the failure by resetting the password, which resets the keys.

The key version number is generated each time a password is changed on long-lived keys—such as the key that results from a user password, the keys for computer accounts, or the keys for domain trusts. Key version numbers also are provided because they are required for compliance with the Kerberos RFC (1510).

Key version numbers are constructed from the update logon timestamp attribute which is updated in the SAM when a password is changed. The update logon timestamp is a 32-bit value that identifies the version of the keys generated from the password. Key version number functionality based on update logon timestamps is only available in domains that have Windows Server 2003 domain functionality.

The client contacts the Key Distribution Center's authentication service for a short-lived ticket (a message containing the client's identity and—for Windows clients—SIDs) called a ticket-granting ticket (TGT). This happens at logon.

The authentication service (AS) constructs the TGT and creates a session key the client can use to encrypt communication with the ticket-granting service (TGS). The TGT has a limited lifetime. At the point that the client has received the TGT, the client has not been granted access to any resources, even to resources on the local computer.

Why use a TGT? Could the AS simply issue a ticket for the target server? Yes, but if the AS issued tickets directly, the user would have to enter a password for every new server/service connection. Issuing a TGT with a short lifespan (typically 10 hours) gives the user a valid ticket for the ticket-granting service, which in turn issues target-server tickets. The TGT's main benefit is that the user only has to enter a password once, at logon.

The client wants access to local and network resources. To gain access, the client sends a request to the TGS for a ticket for the local computer or some network server or service. This ticket is referred to as the service ticket or service ticket. To get the ticket, the client presents the TGT, an authenticator, and the name of the target server (the Server Principal Name or SPN).

The TGS examines the TGT and the authenticator. If these are acceptable, the TGS creates a service ticket. The client's identity is taken from the TGT and copied to the service ticket. Then the ticket is sent to the client.

Note

• The TGS cannot determine if the user will be able to get access to the target server. It simply returns a valid ticket. Authentication does not imply authorization.
  

After the client has the service ticket, the client sends the ticket and a new authenticator to the target server, requesting access. The server will decrypt the ticket, validate the authenticator, and for Windows services, create an access token for the user based on the SIDs in the ticket.

Optionally, the client might request that the target server verify its own identity. This is called mutual authentication. If mutual authentication is requested, the target server will take the client computer's timestamp from the authenticator, encrypt it with the session key the TGS provided for client-target server messages, and send it to the client.

Message 1: Authentication Service Request

The Kerberos client on the workstation sends the message KRB_AS_REQ to the KDC in tailspintoys.com.

The message includes:

• The user principal name.
  
• The name of the account domain.
  
• Pre-authentication data encrypted with the user's key derived from the user's password.
  

The KDC gets its copy of the user key from the user's record in its account database. When it receives a request from the Kerberos client on the user's workstation, the KDC searches its database for the user, pulls up the account record, and takes the user key from a field in the record.

This process—computing one copy of the key from a password, fetching another copy of the key from a database—actually takes place only once, when a user initially logs on to the network. Immediately after accepting the user's password and deriving the user's long-term key, the Kerberos client on the workstation requests a service ticket and TGS session key that it can use in subsequent transactions with the KDC during this logon session.

The KDC decrypts the pre-authentication data and evaluates the timestamp inside. If the timestamp passes the test, the KDC can be assured that the pre-authentication data was encrypted with the user key and thus verify that the user is genuine.

After it has verified the user's identity, the KDC creates credentials that the Kerberos client on the workstation can present to the ticket-granting service. For more information about how domain controllers create credentials in a Windows environment, see "How Access Tokens Work" in the Access Tokens Technical Reference.

Message 2: Authentication Service Reply

The KDC replies with KRB_AS_REP containing a service ticket for itself. This special service ticket is called a ticket-granting ticket (TGT). Like an ordinary service ticket, a TGT contains a copy of the session key that the service (in this case the KDC) will use in communicating with the user. The message that returns the TGT to the user also includes a copy of the session key that the user can use in communicating with the KDC. The TGT is encrypted in the KDC's long-term key. The user's copy of the session key is encrypted in the user's long-term key.

KRB_AS_REP Message Contents

The message includes:

• A TGS session key for the user to use with the TGS, encrypted with the user key derived from the user's password.
  
• A TGT for the KDC in tailspintoys.com, encrypted with the TGS key.
  The TGT includes:
  
  • A TGS session key for the KDC to use with the user.
    
  • Authorization data for the user.
    
  The authorization data includes:
  
  • The SID for the user's account.
    
  • SIDs for security groups which the user is a member of in the domain tailspintoys.com.
    
  • SIDs for universal groups in the enterprise that include either the user or one of the domain groups the user is a member of.
    

When the client receives the KDC's reply to its initial request, the client uses its cached copy of the user key to decrypt its copy of the session key. It can then discard the user key derived from the user's password, for it is no longer needed. In all subsequent exchanges with the KDC, the client uses the TGS session key. Like any other session key, this key is temporary, valid only until the TGT expires or the user logs off. For that reason, the TGS session key is often called a logon session key.

From the client's point of view, a TGT is just another ticket. Before the client attempts to connect to any service, the client first checks the user credentials cache for a service ticket to that service. If it does not have one, it checks the cache again for a TGT. If it finds a TGT, the LSA fetches the corresponding logon session key from the cache, uses this key to prepare an authenticator, and sends both the authenticator and the TGT to the KDC, along with a request for a service ticket for the service. In other words, gaining admission to the KDC is no different from gaining admission to any other service in the domain—it requires a session key, an authenticator, and a ticket (in this case, a TGT).

From the KDC's point of view, TGTs enable the KDC to avoid the performance penalties of looking up a user's long term key every time the user requests a service. The KDC looks up the user key only once, when it grants an initial TGT. For all other exchanges with this user, the KDC can decrypt the TGT with its own long-term key, extract the logon session key, and use that to validate the user's authenticator.

Message 3: Ticket-Granting Service Request

The Kerberos client sends the message KRB_TGS_REQ to the KDC in tailspintoys.com.

The message includes:

• The name of the target computer.
  
• The name of the target computer's domain.
  
• The user's TGT.
  
• An authenticator encrypted with the session key the user shares with the KDC.
  

Message 4: Ticket-Granting Service Reply

The KDC responds to the user's request to connect to a server by sending both copies of the session key to the user. The user's copy of the session key is encrypted with the key that the KDC shares with the user. The workstation's copy of the session key is embedded, along with information about the user, in a data structure called a service ticket. The entire structure is then encrypted with the key that the KDC shares with the user. The ticket—with the user's copy of the session key safely inside—becomes the workstation's responsibility to manage.

KRB_TGS_REP Message Contents

The KRB_TGS_REP message includes:

• A session key for the user to share with the computer encrypted with the session key the user shares with the KDC.
  
• The user's service ticket to the computer, encrypted with the computer's secret key.
  The service ticket includes:
  
  • A session key for the computer to share with the user.
    
  • Authorization data copied from the user's TGT.
    

When the Kerberos client receives the KDC's reply, it extracts the ticket and the user's copy of the session key, putting both in the user credentials cache (located in volatile memory, not on disk).

Note

• The KDC is simply providing a ticket-granting service. It does not keep track of its messages to make sure they reach the intended address. No harm will be done if the KDC's messages fall into the wrong hands. Only someone who knows the user's secret key can decrypt the user's copy of the session key. Only someone who knows the client's secret key can read what is inside the ticket.
  

Getting the User's Credentials to Winlogon

After credentials reach the workstation, the Windows Server 2003 access token creation process is the same as that of Windows NT versions. The LSA on the workstation receives the user's service ticket, decrypts the service ticket with the system key stored in its credentials cache, and then extracts the authorization data. The privilege attribute certificate (PAC) is taken from the service ticket and used to create the user's access token. The LSA then queries the local SAM database to discover whether the user is a member of any security groups local to the computer, and whether memberships in those groups grant the user any special rights on the local computer. It adds any SIDs returned by this query to the list taken from the ticket's authorization data. The entire list is then used to build an access token, and a handle to the access token is returned to Winlogon, along with an identifier for the user's logon session and confirmation that the logon information was valid.

Winlogon creates a window station and several desktop objects for the user, attaches the user's access token, and starts the shell process the user will use to interact with the computer. The user's access token is subsequently inherited by any application process that the user starts during the logon session.

When the user logs off, the credentials cache is flushed and all service tickets—as well as all session keys—are destroyed.

After credentials reach the server, the Windows Server 2003 token creation process is the same as that of earlier Windows versions. After the server authenticates the client using Kerberos authentication, the PAC is taken from the service ticket and used to create the user's access token.

After the service has an access token for the user, it still needs to verify that the user is authorized to do what the user wants to do. Except for the Kerberos authentication, security access checks are nearly identical with those of Windows NT 4.0 and earlier versions:

1. The client redirector sends an SMB message requesting file access.
   
2. Server security compares file permissions with the user's credentials and grants or denies access.
   
3. If access is granted, the connection proceeds.
   

During the connection, the session key can be used to encrypt application data, or the client and server can share another key for this purpose.