2.4. Postdated Tickets
Purpose
Applications may occasionally need to obtain tickets for use much later. For example, a batch submission system would need tickets to be valid at the time the batch job is serviced.
Problem and Solution
The Problem
It is dangerous to hold valid tickets in a batch queue, since they will be:
- On-line longer
- More prone to theft
The Solution
Postdated tickets provide a way to:
- Obtain tickets from the KDC at job submission time
- Leave them "dormant" until activated and validated by a further request of the KDC
- If ticket theft were reported in the interim, KDC would refuse to validate the ticket
MAY-POSTDATE Flag
The MAY-POSTDATE flag in a ticket:
- Is normally only interpreted by the ticket-granting service
- Can be ignored by application servers
- MUST be set in a TGT in order to issue a postdated ticket based on the presented ticket
- Is reset by default
- A client MAY request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message
Restrictions
- This flag does not allow a client to obtain a postdated TGT
- Postdated TGTs can only be obtained by requesting the postdating in the KRB_AS_REQ message
Lifetime Rules
The life (endtime-starttime) of a postdated ticket will be:
- The remaining life of the TGT at the time of the request
- Unless the RENEWABLE option is also set, in which case it can be the full life (endtime-starttime) of the TGT
- The KDC MAY limit how far in the future a ticket may be postdated
POSTDATED Flag
The POSTDATED flag indicates that a ticket has been postdated.
Usage by Application Servers
- Application server can check the authtime field in the ticket to see when the original authentication occurred
- Some services MAY choose to reject postdated tickets
- Or they may only accept them within a certain period after the original authentication
Special Behavior
When the KDC issues a POSTDATED ticket, it will also be marked as INVALID, so that the application client MUST present the ticket to the KDC to be validated before use.