Authentication
Authentication |
|
What is in a ticket, how ticket expiration times are calculated, and how much of a ticket's content is known by the client are important things to know when you want to configure Kerberos policy; therefore, they deserve a closer look.
Kerberos messages and tickets have a precise data structure and format. For more information about ticket fields and flags, see the Request for Comments (RFC) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Follow the links to RFC 1510.
Kerberos tickets have a start time and an expiration time. At any time after the start time but before the expiration time, a client holding a session ticket for a particular service can present the ticket and gain access to the service, no matter how many times the client has used the ticket previously. To reduce the risk of a ticket or its corresponding session key being compromised, administrators can set a maximum lifetime for tickets. This value is one element of Kerberos policy an administrator can set for the domain.
When a client asks the KDC for a session ticket to a service, it can request a specific start time. If this time is missing from a request or it is a time already past, the KDC sets the ticket's starttime field to the current time.
Whether or not clients specify a start time, their requests must include an expiration time. The KDC determines the value of a ticket's endtime field by adding the maximum ticket life fixed by Kerberos policy to the value of the ticket's starttime field. It then compares the result with the requested expiration time. Whichever of these times is earliest becomes the ticket's endtime.
Encryption keys wear out with frequent use. The more often an encryption key is used, the more examples of the key an attacker has available to study and the greater the temptation for this person to expend the effort necessary to break the code. The keys used most often in the Kerberos protocol are the session keys. Clients use the same key each time they connect to a server, for as long as the session ticket remains valid. When the ticket expires, the client gets a new ticket with a fresh session key, but until then, the key is not changed.
One way to limit the exposure of session keys to potential attackers is to force the session keys to change often. You can do this by setting Kerberos policy so that the maximum session ticket life is relatively short. Another strategy is to permit tickets to be renewed, which allows session keys to be refreshed periodically without having to issue a completely new ticket. If Kerberos policy permits renewable tickets, the KDC sets a RENEWABLE flag in every session ticket it issues and sets two expiration times in the ticket. One expiration time limits the life of the current instance of the ticket. The second expiration time sets a limit on the cumulative lifetime of all instances of the ticket.
The expiration time for the current instance of a session ticket is held in the endtime field. Just as for nonrenewable session tickets, endtime is the value of the starttime field plus the maximum ticket life specified by the Kerberos policy. A client holding a renewable ticket must present it to the KDC for renewal before the endtime is reached and present a fresh authenticator as well. When the KDC receives a session ticket for renewal, it checks a second expiration time held in the renew-till field. This time is set when the ticket is first issued; the value is the session ticket's starttime plus the maximum cumulative ticket life specified by the Kerberos policy. When the KDC renews the ticket, it checks to see that the renew-till time has not yet arrived. If it has not arrived, the KDC issues a new instance of the session ticket with a later endtime and a new session key.
This means that administrators can set Kerberos policy can so that session tickets must be renewed at relatively short intervals — every day, perhaps. When tickets are renewed, a new session key is issued, which minimizes the value of a compromised key. At the same time, administrators can also set the cumulative session ticket life for a relatively long period — one month, one year, or whatever. At the end of that time, the session ticket expires and is no longer valid for renewal.
When a session ticket expires, ongoing operations are not interrupted. Session tickets are used only to authenticate new connections with servers. After a connection has been set up, it no longer matters whether the session ticket is still valid. However, when a TGT expires, the Kerberos client might have to interrupt the activities of the user to ask for a password.
The KDC does not notify clients when their session tickets or TGTs are about to expire. In fact, it does not keep track of transactions with clients beyond the short-term records required to prevent replay attacks. If a client presents an outdated TGT to the KDC's ticket-granting service, the service responds with an error message. Network servers also return error messages when they receive expired tickets. All responsibility for renewing or replacing tickets rests with the client.
Clients have to know some of the information that is inside session tickets and TGTs in order to manage their credentials cache. When the KDC returns a ticket and session key as the result of an AS Exchange or TGS Exchange, it packages the client's copy of the session key in a data structure that includes the information in the ticket's flags, authtime, starttime, endtime, and renew-till fields. The entire structure is encrypted in the client's key and returned in a KRB_AS_REP or KRB_TGS_REP reply message.