Connected: An Internet Encyclopedia
RFC 1510 - 5.3.1. Tickets

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1510
Up: 5. Message Specifications
Up: 5.3. Tickets and Authenticators
Prev: 5.3. Tickets and Authenticators
Next: 5.3.2. Authenticators

### 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.

Next: 5.3.2. Authenticators

Connected: An Internet Encyclopedia
RFC 1510 - 5.3.1. Tickets