5.3.1. Tickets

A ticket is a record that helps a client authenticate to a service. A Ticket contains the following information:

Ticket ::=                    [APPLICATION 1] SEQUENCE {
                              tkt-vno[0]                   INTEGER,
                              realm[1]                     Realm,
                              sname[2]                     PrincipalName,
                              enc-part[3]                  EncryptedData
}
-- Encrypted part of ticket
EncTicketPart ::=     [APPLICATION 3] SEQUENCE {
                      flags[0]             TicketFlags,
                      key[1]               EncryptionKey,
                      crealm[2]            Realm,
                      cname[3]             PrincipalName,
                      transited[4]         TransitedEncoding,
                      authtime[5]          KerberosTime,
                      starttime[6]         KerberosTime OPTIONAL,
                      endtime[7]           KerberosTime,
                      renew-till[8]        KerberosTime OPTIONAL,
                      caddr[9]             HostAddresses OPTIONAL,
                      authorization-data[10]   AuthorizationData OPTIONAL
}
-- encoded Transited field
TransitedEncoding ::=         SEQUENCE {
                              tr-type[0]  INTEGER, -- must be registered
                              contents[1]          OCTET STRING
}

The encoding of EncTicketPart is encrypted in the key shared by Kerberos and the end server (the server's secret key). See section 6 for the format of the ciphertext.

tkt-vno

This field specifies the version number for the ticket format. This document describes version number 5.

realm

This field specifies the realm that issued a ticket. It also serves to identify the realm part of the server's principal identifier. Since a Kerberos server can only issue tickets for servers within its realm, the two will always be identical.

sname

This field specifies the name part of the server's identity.

enc-part

This field holds the encrypted encoding of the EncTicketPart sequence.

flags

This field indicates which of various options were used or requested when the ticket was issued. It is a bit-field, where the selected options are indicated by the bit being set (1), and the unselected options and reserved fields being reset (0). Bit 0 is the most significant bit. The encoding of the bits is specified in section 5.2. The flags are described in more detail above in section 2. The meanings of the flags are:

  Bit(s)    Name        Description

  0         RESERVED    Reserved for future expansion of this
                        field.

  1         FORWARDABLE The FORWARDABLE flag is normally only
                        interpreted by the TGS, and can be
                        ignored by end servers.  When set,
                        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   When set, 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 is normally only
                        interpreted by the TGS, and can be
                        ignored by end servers. 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 The MAY-POSTDATE flag is normally
                        only interpreted by the TGS, and can
                        be ignored by end servers.  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.  The end-service
                        can check the authtime field to see
                        when the original authentication
                        occurred.

  7         INVALID     This flag indicates that a ticket is
                        invalid, and it must be validated by
                        the KDC before use.  Application
                        servers must reject tickets which
                        have this flag set.

  8         RENEWABLE   The RENEWABLE flag is normally only
                        interpreted by the TGS, and can
                        usually be ignored by end servers
                        (some particularly careful servers
                        may wish to disallow renewable
                        tickets).  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 AS 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 KDC before a
                        ticket was issued.  The strength of
                        the preauthentication method is not
                        indicated, but is acceptable to the
                        KDC.

  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.  The hardware authentication
                        method is selected by the KDC and the
                        strength of the method is not
                        indicated.

  12-31     RESERVED    Reserved for future use.

key

This field exists in the ticket and the KDC response and is used to pass the session key from Kerberos to the application server and the client. The field's encoding is described in section 6.2.

crealm

This field contains the name of the realm in which the client is registered and in which initial authentication took place.

cname

This field contains the name part of the client's principal identifier.

transited

This field lists the names of the Kerberos realms that took part in authenticating the user to whom this ticket was issued. It does not specify the order in which the realms were transited. See section 3.3.3.1 for details on how this field encodes the traversed realms.

authtime

This field indicates the time of initial authentication for the named principal. It is the time of issue for the original ticket on which this ticket is based. It is included in the ticket to provide additional information to the end service, and to provide the necessary information for implementation of a `hot list' service at the KDC. An end service that is particularly paranoid could refuse to accept tickets for which the initial authentication occurred "too far" in the past.

This field is also returned as part of the response from the KDC. When returned as part of the response to initial authentication (KRB_AS_REP), this is the current time on the Kerberos server (It is NOT recommended that this time value be used to adjust the workstation's clock since the workstation cannot reliably determine that such a KRB_AS_REP actually came from the proper KDC in a timely manner.).

starttime

This field in the ticket specifies the time after which the ticket is valid. Together with endtime, this field specifies the life of the ticket. If it is absent from the ticket, its value should be treated as that of the authtime field.

endtime

This field contains the time after which the ticket will not be honored (its expiration time). Note that individual services may place their own limits on the life of a ticket and may reject tickets which have not yet expired. As such, this is really an upper bound on the expiration time for the ticket.

renew-till

This field is only present in tickets that have the RENEWABLE flag set in the flags field. It indicates the maximum endtime that may be included in a renewal. It can be thought of as the absolute expiration time for the ticket, including all renewals.

caddr

This field in a ticket contains zero (if omitted) or more (if present) host addresses. These are the addresses from which the ticket can be used. If there are no addresses, the ticket can be used from any location. The decision by the KDC to issue or by the end server to accept zero- address tickets is a policy decision and is left to the Kerberos and end-service administrators; they may refuse to issue or accept such tickets. The suggested and default policy, however, is that such tickets will only be issued or accepted when additional information that can be used to restrict the use of the ticket is included in the authorization_data field. Such a ticket is a capability.

Network addresses are included in the ticket to make it harder for an attacker to use stolen credentials. Because the session key is not sent over the network in cleartext, credentials can't be stolen simply by listening to the network; an attacker has to gain access to the session key (perhaps through operating system security breaches or a careless user's unattended session) to make use of stolen tickets.

It is important to note that the network address from which a connection is received cannot be reliably determined. Even if it could be, an attacker who has compromised the client's workstation could use the credentials from there. Including the network addresses only makes it more difficult, not impossible, for an attacker to walk off with stolen credentials and then use them from a "safe" location.

authorization-data

The authorization-data field is used to pass authorization data from the principal on whose behalf a ticket was issued to the application service. If no authorization data is included, this field will be left out. The data in this field are specific to the end service. It is expected that the field will contain the names of service specific objects, and the rights to those objects. The format for this field is described in section 5.2. Although Kerberos is not concerned with the format of the contents of the subfields, it does carry type information (ad-type).

By using the authorization_data field, a principal is able to issue a proxy that is valid for a specific purpose. For example, a client wishing to print a file can obtain a file server proxy to be passed to the print server. By specifying the name of the file in the authorization_data field, the file server knows that the print server can only use the client's rights when accessing the particular file to be printed.

It is interesting to note that if one specifies the authorization-data field of a proxy and leaves the host addresses blank, the resulting ticket and session key can be treated as a capability. See [9] for some suggested uses of this field.

The authorization-data field is optional and does not have to be included in a ticket.