As shown in Table 3.2, flags for the TGT can be requested in the KDC Options field of the KRB_AS_REQ message.This same field exists in the KRB_TGS_REQ message.The field length is 32 bits, and each option corre- sponds to one of these bits.Table 3.6 lists the options available in the KDC Options table for the KRB_AS_REQ and KRB_TGS_REQ messages.
Table 3.6Flags Available in the KDC Options Field
Flag Bit Flag Value Remarks
0 Reserved
1 Forwardable The ticket can be forwarded to other addresses. The allowed addresses are specified in the address field of the message.
2 Forwarded The ticket is a forwarded ticket.
3 Proxiable The ticket can be proxied. This means that the ticket can be valid from other specified addresses instead of the client’s address.
4 Proxy The ticket is a proxy ticket. 5 Allow Postdate The ticket can be postdated. 6 Postdated The ticket is postdated. 7 Reserved
8 Renewable The ticket can be renewed. Tickets are valid only for the time specified in the Kerberos realm policy. If this bit is set, tickets can be renewed when the maximum time for the Kerberos realm has been reached.
9–13 Reserved
14 Request Creates a ticket authenticating that the user is Anonymous actually anonymous.
15–25 Reserved
26 Disable Disables tracking the realms through which a Transited ticket has passed.
Check
27 Renewable OK On the basis of this ticket, renewable tickets can be created.
28 ENC-TKT-INSKEY Encrypts the ticket in the session key. Used in user-to-user authentication.
29 Reserved
30 Renew Used by the KRB_TGS_REQ message and sent with the ticket that needs to be renewed.
31 Validate Used to validate a postdated ticket based on the start time located in the ticket.
Tickets
Tickets are at the heart of the Kerberos authentication system. A variety of mes- sages are used to request and send tickets between principals.The components that make up a ticket are similar to those in the message tables discussed earlier in the chapter.Table 3.7 shows the contents of Kerberos tickets.
Table 3.6Continued
Table 3.7Contents of a Kerberos Ticket
Name of Field Contents of Field
Ticket Version 5
Realm Name The realm’s name.
Server Name The target server’s name. Flags The options for the ticket. Key The session key.
Client Realm The initial realm that performed the authentication. Client Name The client’s name.
Transited The names of the realm that have been crossed. Authentication Time The time the ticket was created.
Start Time The time the ticket starts being valid. End Time The time the ticket is no longer valid. Renew Till Time The time the ticket absolutely expires. Client Address The valid address(es) for the client. Authorization Data The authorization data for the client.
Extensions An optional field for the use of application-specific data. Tickets contain a flag field that is 32 bits wide, just as KRB_AS_REQ and KRB_TGS_REQ messages do. Some of the fields are identical to those for the messages; others are different.Table 3.8 shows the complete list of flags available for Kerberos tickets.
Table 3.8Flags Available in Kerberos Tickets
Flag Bit Flag Value Remarks
0 Reserved
1 Forwardable The ticket can be forwarded. This flag is applicable only to TGTs.
2 Forwarded The ticket has been forwarded. 3 Proxiable The ticket can be proxied. 4 Proxy The ticket has been proxied.
5 May Postdate In a TGT, successive tickets can be postdated. 6 Postdated The ticket is postdated.
7 Invalid Set for a postdated ticket and cleared by the TGS when the start time for the ticket has been validated.
8 Renewable The ticket is renewable.
9 Initial The ticket is the result of a KRB_AS_REQ message and not based on a TGT.
10 Preauthenticated Specifies that preauthentication was required before the ticket was created.
11 HW-authenticated A hardware device was used to complete preauthentication.
12 Transited Policy The KDC completed a check of all realms that Checked the ticket has crossed to ensure that the
realms were trusted.
13 OK As Delegate The server specified in the ticket can act as a delegate for proxy or forwarded tickets. 14 Anonymous The principal is a generic account used to
distribute a session key. 15–31 Reserved
Tickets can be used by the principal holding the ticket as many times as nec- essary, as long as it is within the inclusive period shown between the start time and the end time.The KDC sets the time for a ticket based on the current time, unless the client has requested a different start time. Clients do not have to request a start time, but they do include the time they want the ticket to expire. The KDC consults the Kerberos realm policy and adds the time indicated in the policy to the start time. If the client has requested a specific end time, the KDC adds the requested end time to the start time.Whichever time is shorter—the time calculated using the Kerberos policy or the time calculated using the client requested time—is the time used for the end time.
If a client sends an expired session ticket to a server, the server rejects it. It is then up to the client to go back to the KDC and request a new session ticket. However, if the client is already communicating with the server and the session ticket expires, communication continues to take place. Session tickets are used to authenticate the connection to the server. After the authentication has taken place, the session ticket can expire, but the connection will not be dropped.
Table 3.8Continued
Ticket-granting tickets also expire on the basis of the time set in the Kerberos realm policy. If a client attempts to use an expired TGT with the KDC, the KDC rejects it. At that point, the client must request a new TGT from the KDC, using the user’s long-term key.
It is possible to renew tickets as well as flag settings.The Kerberos realm policy dictates whether tickets are renewable or not. If the policy allows tickets to be renewed, the renewable flag is set in every ticket issued by the KDC. In this situation, the KDC places a time in the End Time field and another time in the Renew Till Time field of tickets.The time set in the Renew Till Time field is equivalent to the time set in the Start Time field added to the maximum cumula- tive ticket life set in the Kerberos realm policy.The client must submit the ticket to the KDC prior to the original expiration time shown in the End Time field. Every time the client sends a ticket back to the KDC, it must also send a new authenticator.When the KDC receives the ticket from the client, it checks the time set in the Renew Till Time field. If the time has not already passed, the KDC creates a new copy of the ticket that has a new time set in the End Time field as well as a new session key. By issuing a new session key, the KDC helps alleviate the possibility of compromised keys.