|
|
| Previous | Table of Contents | Next |
Each Kerberos ticket contains a set of bit flags that are used to indicate attributes of that ticket. Most flags can be requested by a client when the ticket is obtained. Some are turned on and off automatically by a Kerberos server as required. The following sections explain what the various flags mean, and give examples of reasons to use such a flag.
Table 9.1 describes the ticket flags.
| Bit(s) | Name | Description |
|---|---|---|
| 0 | RESERVED | Reserved for future expansion. |
| 1 | FORWARDABLE | This flag tells the Ticket Granting Server that it is OK to issue a new Ticket Granting Ticket with a different network address based on the presented ticket. |
| 2 | FORWARDED | This flag indicates that the ticket has either been forwarded or was issued based on authentication involving a forwarded Ticket Granting Ticket. |
| 3 | PROXIABLE | The PROXIABLE flag has an interpretation identical to that of the FORWARDABLE flag, except that the PROXIABLE flag tells the Ticket Granting Server that only non-Ticket Granting Tickets may be issued with different network addresses. |
| 4 | PROXY | When set, this flag indicates that a ticket is a proxy. |
| 5 | MAY-POSTDATE | This flag tells the Ticket Granting Server that a post-dated ticket may be issued based on this Ticket Granting Ticket. |
| 6 | POSTDATED | This flag indicates that this ticket has been postdated. |
| 7 | INVALID | This flag indicates that a ticket must be validated before use. |
| 8 | RENEWABLE | A renewable ticket can be used to obtain a replacement ticket that expires at a later date. |
| 9 | INITIAL | This flag indicates that this ticket was issued using the Authentication Server protocol, and not issued based on a Ticket Granting Ticket. |
| 10 | PRE-AUTHENT | This flag indicates that during initial authentication, the client was authenticated by the Key Distribution Center before a ticket was issued. |
| 11 | HW-AUTHENT | This flag indicates that the protocol employed for initial authentication required the use of hardware expected to be possessed solely by the named client. |
| 12–31 | RESERVED | Reserved for future use. |
The INITIAL flag indicates that a ticket was issued using the Authentication Server protocol and not issued based on a Ticket Granting Ticket. Application servers that want to require the knowledge of a client’s secret key (for example, a password changing program) can insist that this flag be set in any tickets they accept. Thus, they are assured that the client’s key was recently presented to the application client.
The INVALID flag indicates that a ticket is invalid. Application servers must reject tickets that have this flag set. A postdated ticket usually is issued in this form. Invalid tickets must be validated by the Key Distribution Center before use, by presenting them to the Key Distribution Center in a Ticket Granting Server request with the VALIDATE option specified. The Key Distribution Center will validate tickets only after their start time has passed. Thus, the validation is required so that postdated tickets that have been stolen before their start time can be rendered permanently invalid using a hot-list mechanism.
Applications might want to hold tickets that can be valid for long periods of time. This can expose their credentials to potential theft for equally long periods and those stolen credentials would be valid until the expiration time of the ticket(s). Simply using short-lived tickets and obtaining new ones periodically would require the client to have long-term access to its secret key, an even greater risk.
The solution to this problem is a renewable ticket. Renewable tickets can be used to mitigate the consequences of theft. Renewable tickets have two expiration times. The first is when the current instance of the ticket expires and the second is the latest permissible value for an individual expiration time. An application client must present a renewable ticket to the Key Distribution Center before it expires. The ticket is presented with the RENEW option set in the Key Distribution Center request. The Key Distribution Center issues a new ticket with a new session key and a later expiration time. All other fields of the ticket are left unmodified by the renewal process. When the latest permissible expiration time arrives, the ticket expires permanently. At each renewal, the Key Distribution Center can consult a hot-list to determine if the ticket had been reported stolen since its last renewal. It refuses to renew such stolen tickets, thereby reducing the usable lifetime of stolen tickets.
The RENEWABLE flag in a ticket normally is interpreted only by the Tick et Granting Service. Application servers usually can ignore it. Some particularly careful application servers, however, might want to disallow renewable tickets.
If a renewable ticket is not renewed by its expiration time, the Key Distribution Center will not renew the ticket. The RENEWABLE flag is reset by default, but a client can request it be set by setting the RENEWABLE option in the KRB_AS_REQ message. If it is set, then the renew-till field in the ticket contains the time after which the ticket may not be renewed.
A renewable ticket will be used when a user wants to run a particularly long process. Because the application will run for longer than the local policy allows a single ticket to live, the application will request a renewable ticket. As the simulation is running, the application will occasionally request the Key Distribution Center to renew the ticket. This verifies that the workstation controlling the simulation has not been listed as compromised.
| Previous | Table of Contents | Next |