2.  Ticket Flag Uses and Requests

   Each Kerberos ticket contains a set of flags that are used to
   indicate attributes of that ticket.  Most flags may be requested by a
   client when the ticket is obtained; some are automatically turned on
   and off by a Kerberos server as required.  The following sections
   explain what the various flags mean and give examples of reasons to
   use them.  With the exception of the INVALID flag, clients MUST
   ignore ticket flags that are not recognized.  KDCs MUST ignore KDC
   options that are not recognized.  Some implementations of RFC 1510
   are known to reject unknown KDC options, so clients may need to
   resend a request without new KDC options if the request was rejected
   when sent with options added since RFC 1510.  Because new KDCs will
   ignore unknown options, clients MUST confirm that the ticket returned
   by the KDC meets their needs.

   Note that it is not, in general, possible to determine whether an
   option was not honored because it was not understood or because it
   was rejected through either configuration or policy.  When adding a
   new option to the Kerberos protocol, designers should consider
   whether the distinction is important for their option.  If it is, a
   mechanism for the KDC to return an indication that the option was
   understood but rejected needs to be provided in the specification of
   the option.  Often in such cases, the mechanism needs to be broad
   enough to permit an error or reason to be returned.

2.1.  Initial, Pre-authenticated, and Hardware-Authenticated Tickets

   The INITIAL flag indicates that a ticket was issued using the AS
   protocol, rather than issued based on a TGT.  Application servers
   that want to require the demonstrated knowledge of a client's secret
   key (e.g., a password-changing program) can insist that this flag be
   set in any tickets they accept, and can thus be assured that the
   client's key was recently presented to the authentication server.

   The PRE-AUTHENT and HW-AUTHENT flags provide additional information
   about the initial authentication, regardless of whether the current
   ticket was issued directly (in which case INITIAL will also be set)
   or issued on the basis of a TGT (in which case the INITIAL flag is
   clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward
   from the TGT).

2.2.  Invalid Tickets

   The INVALID flag indicates that a ticket is invalid.  Application
   servers MUST reject tickets that have this flag set.  A postdated
   ticket will be issued in this form.  Invalid tickets MUST be
   validated by the KDC before use, by being presented to the KDC in a
   TGS request with the VALIDATE option specified.  The KDC will only
   validate tickets after their starttime has passed.  The validation is
   required so that postdated tickets that have been stolen before their
   starttime can be rendered permanently invalid (through a hot-list
   mechanism) (see Section 3.3.3.1).

2.3.  Renewable Tickets

   Applications may desire to hold tickets that can be valid for long
   periods of time.  However, 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.  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 periodically
   (i.e., before it expires) present a renewable ticket to the KDC, with
   the RENEW option set in the KDC request.  The KDC will issue 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 KDC MAY consult a hot-list
   to determine whether the ticket had been reported stolen since its

   last renewal; it will refuse to renew stolen tickets, and thus the
   usable lifetime of stolen tickets is reduced.

   The RENEWABLE flag in a ticket is normally only interpreted by the
   ticket-granting service (discussed below in Section 3.3).  It can
   usually be ignored by application servers.  However, some
   particularly careful application servers MAY disallow renewable
   tickets.

   If a renewable ticket is not renewed by its expiration time, the KDC
   will not renew the ticket.  The RENEWABLE flag is reset by default,
   but a client MAY 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.

2.4.  Postdated Tickets

   Applications may occasionally need to obtain tickets for use much
   later; e.g., a batch submission system would need tickets to be valid
   at the time the batch job is serviced.  However, it is dangerous to
   hold valid tickets in a batch queue, since they will be on-line
   longer and more prone to theft.  Postdated tickets provide a way to
   obtain these tickets from the KDC at job submission time, but to
   leave them "dormant" until they are activated and validated by a
   further request of the KDC.  If a ticket theft were reported in the
   interim, the KDC would refuse to validate the ticket, and the thief
   would be foiled.

   The MAY-POSTDATE flag in a ticket is normally only interpreted by the
   ticket-granting service.  It can be ignored by application servers.
   This flag MUST be set in a TGT in order to issue a postdated ticket
   based on the presented ticket.  It is reset by default; a client MAY
   request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ
   message.  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.  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.

   The POSTDATED flag indicates that a ticket has been postdated.  The
   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.  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.

2.5.  Proxiable and Proxy Tickets

   At times it may be necessary for a principal to allow a service to
   perform an operation on its behalf.  The service must be able to take
   on the identity of the client, but only for a particular purpose.  A
   principal can allow a service to do this by granting it a proxy.

   The process of granting a proxy by using the proxy and proxiable
   flags is used to provide credentials for use with specific services.
   Though conceptually also a proxy, users wishing to delegate their
   identity in a form usable for all purposes MUST use the ticket
   forwarding mechanism described in the next section to forward a TGT.

   The PROXIABLE flag in a ticket is normally only interpreted by the
   ticket-granting service.  It can be ignored by application servers.
   When set, this flag tells the ticket-granting server that it is OK to
   issue a new ticket (but not a TGT) with a different network address
   based on this ticket.  This flag is set if requested by the client on
   initial authentication.  By default, the client will request that it
   be set when requesting a TGT, and that it be reset when requesting
   any other ticket.

   This flag allows a client to pass a proxy to a server to perform a
   remote request on its behalf (e.g., a print service client can give
   the print server a proxy to access the client's files on a particular
   file server in order to satisfy a print request).

   In order to complicate the use of stolen credentials, Kerberos
   tickets are often valid only from those network addresses
   specifically included in the ticket, but it is permissible as a
   policy option to allow requests and to issue tickets with no network
   addresses specified.  When granting a proxy, the client MUST specify
   the new network address from which the proxy is to be used or
   indicate that the proxy is to be issued for use from any address.

   The PROXY flag is set in a ticket by the TGS when it issues a proxy
   ticket.  Application servers MAY check this flag; and at their option
   they MAY require additional authentication from the agent presenting
   the proxy in order to provide an audit trail.

2.6.  Forwardable Tickets

   Authentication forwarding is an instance of a proxy where the service
   that is granted is complete use of the client's identity.  An example
   of where it might be used is when a user logs in to a remote system

   and wants authentication to work from that system as if the login
   were local.

   The FORWARDABLE flag in a ticket is normally only interpreted by the
   ticket-granting service.  It can be ignored by application servers.
   The FORWARDABLE flag has an interpretation similar to that of the
   PROXIABLE flag, except TGTs may also be issued with different network
   addresses.  This flag is reset by default, but users MAY request that
   it be set by setting the FORWARDABLE option in the AS request when
   they request their initial TGT.

   This flag allows for authentication forwarding without requiring the
   user to enter a password again.  If the flag is not set, then
   authentication forwarding is not permitted, but the same result can
   still be achieved if the user engages in the AS exchange, specifies
   the requested network addresses, and supplies a password.

   The FORWARDED flag is set by the TGS when a client presents a ticket
   with the FORWARDABLE flag set and requests a forwarded ticket by
   specifying the FORWARDED KDC option and supplying a set of addresses
   for the new ticket.  It is also set in all tickets issued based on
   tickets with the FORWARDED flag set.  Application servers may choose
   to process FORWARDED tickets differently than non-FORWARDED tickets.

   If addressless tickets are forwarded from one system to another,
   clients SHOULD still use this option to obtain a new TGT in order to
   have different session keys on the different systems.

2.7.  Transited Policy Checking

   In Kerberos, the application server is ultimately responsible for
   accepting or rejecting authentication, and it SHOULD check that only
   suitably trusted KDCs are relied upon to authenticate a principal.
   The transited field in the ticket identifies which realms (and thus
   which KDCs) were involved in the authentication process, and an
   application server would normally check this field.  If any of these
   are untrusted to authenticate the indicated client principal
   (probably determined by a realm-based policy), the authentication
   attempt MUST be rejected.  The presence of trusted KDCs in this list
   does not provide any guarantee; an untrusted KDC may have fabricated
   the list.

   Although the end server ultimately decides whether authentication is
   valid, the KDC for the end server's realm MAY apply a realm-specific
   policy for validating the transited field and accepting credentials
   for cross-realm authentication.  When the KDC applies such checks and
   accepts such cross-realm authentication, it will set the
   TRANSITED-POLICY-CHECKED flag in the service tickets it issues based

   on the cross-realm TGT.  A client MAY request that the KDCs not check
   the transited field by setting the DISABLE-TRANSITED-CHECK flag.
   KDCs are encouraged but not required to honor this flag.

   Application servers MUST either do the transited-realm checks
   themselves or reject cross-realm tickets without
   TRANSITED-POLICY-CHECKED set.

2.8.  OK as Delegate

   For some applications, a client may need to delegate authority to a
   server to act on its behalf in contacting other services.  This
   requires that the client forward credentials to an intermediate
   server.  The ability for a client to obtain a service ticket to a
   server conveys no information to the client about whether the server
   should be trusted to accept delegated credentials.  The
   OK-AS-DELEGATE provides a way for a KDC to communicate local realm
   policy to a client regarding whether an intermediate server is
   trusted to accept such credentials.

   The copy of the ticket flags in the encrypted part of the KDC reply
   may have the OK-AS-DELEGATE flag set to indicate to the client that
   the server specified in the ticket has been determined by the policy
   of the realm to be a suitable recipient of delegation.  A client can
   use the presence of this flag to help it decide whether to delegate
   credentials (grant either a proxy or a forwarded TGT) to this server.
   It is acceptable to ignore the value of this flag.  When setting this
   flag, an administrator should consider the security and placement of
   the server on which the service will run, as well as whether the
   service requires the use of delegated credentials.

2.9.  Other KDC Options

   There are three additional options that MAY be set in a client's
   request of the KDC.

2.9.1.  Renewable-OK

   The RENEWABLE-OK option indicates that the client will accept a
   renewable ticket if a ticket with the requested life cannot otherwise
   be provided.  If a ticket with the requested life cannot be provided,
   then the KDC MAY issue a renewable ticket with a renew-till equal to
   the requested endtime.  The value of the renew-till field MAY still
   be adjusted by site-determined limits or limits imposed by the
   individual principal or server.

2.9.2.  ENC-TKT-IN-SKEY

   In its basic form, the Kerberos protocol supports authentication in a
   client-server setting and is not well suited to authentication in a
   peer-to-peer environment because the long-term key of the user does
   not remain on the workstation after initial login.  Authentication of
   such peers may be supported by Kerberos in its user-to-user variant.
   The ENC-TKT-IN-SKEY option supports user-to-user authentication by
   allowing the KDC to issue a service ticket encrypted using the
   session key from another TGT issued to another user.  The
   ENC-TKT-IN-SKEY option is honored only by the ticket-granting
   service.  It indicates that the ticket to be issued for the end
   server is to be encrypted in the session key from the additional
   second TGT provided with the request.  See Section 3.3.3 for specific
   details.

2.9.3.  Passwordless Hardware Authentication

   The OPT-HARDWARE-AUTH option indicates that the client wishes to use
   some form of hardware authentication instead of or in addition to the
   client's password or other long-lived encryption key.
   OPT-HARDWARE-AUTH is honored only by the authentication service.  If
   supported and allowed by policy, the KDC will return an error code of
   KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to
   perform such authentication.

3.  Message Exchanges

   The following sections describe the interactions between network
   clients and servers and the messages involved in those exchanges.

3.1.  The Authentication Service Exchange

                             Summary

         Message direction       Message type    Section
         1. Client to Kerberos   KRB_AS_REQ      5.4.1
         2. Kerberos to client   KRB_AS_REP or   5.4.2
                                 KRB_ERROR       5.9.1

   The Authentication Service (AS) Exchange between the client and the
   Kerberos Authentication Server is initiated by a client when it
   wishes to obtain authentication credentials for a given server but
   currently holds no credentials.  In its basic form, the client's
   secret key is used for encryption and decryption.  This exchange is
   typically used at the initiation of a login session to obtain
   credentials for a Ticket-Granting Server, which will subsequently be
   used to obtain credentials for other servers (see Section 3.3)

   without requiring further use of the client's secret key.  This
   exchange is also used to request credentials for services that must
   not be mediated through the Ticket-Granting Service, but rather
   require knowledge of a principal's secret key, such as the password-
   changing service (the password-changing service denies requests
   unless the requester can demonstrate knowledge of the user's old
   password; requiring this knowledge prevents unauthorized password
   changes by someone walking up to an unattended session).

   This exchange does not by itself provide any assurance of the
   identity of the user.  To authenticate a user logging on to a local
   system, the credentials obtained in the AS exchange may first be used
   in a TGS exchange to obtain credentials for a local server; those
   credentials must then be verified by a local server through
   successful completion of the Client/Server exchange.

   The AS exchange consists of two messages: KRB_AS_REQ from the client
   to Kerberos, and KRB_AS_REP or KRB_ERROR in reply.  The formats for
   these messages are described in Sections 5.4.1, 5.4.2, and 5.9.1.

   In the request, the client sends (in cleartext) its own identity and
   the identity of the server for which it is requesting credentials,
   other information about the credentials it is requesting, and a
   randomly generated nonce, which can be used to detect replays and to
   associate replies with the matching requests.  This nonce MUST be
   generated randomly by the client and remembered for checking against
   the nonce in the expected reply.  The response, KRB_AS_REP, contains
   a ticket for the client to present to the server, and a session key
   that will be shared by the client and the server.  The session key
   and additional information are encrypted in the client's secret key.
   The encrypted part of the KRB_AS_REP message also contains the nonce
   that MUST be matched with the nonce from the KRB_AS_REQ message.

   Without pre-authentication, the authentication server does not know
   whether the client is actually the principal named in the request.
   It simply sends a reply without knowing or caring whether they are
   the same.  This is acceptable because nobody but the principal whose
   identity was given in the request will be able to use the reply.  Its
   critical information is encrypted in that principal's key.  However,
   an attacker can send a KRB_AS_REQ message to get known plaintext in
   order to attack the principal's key.  Especially if the key is based
   on a password, this may create a security exposure.  So the initial
   request supports an optional field that can be used to pass
   additional information that might be needed for the initial exchange.
   This field SHOULD be used for pre-authentication as described in
   sections 3.1.1 and 5.2.7.

   Various errors can occur; these are indicated by an error response
   (KRB_ERROR) instead of the KRB_AS_REP response.  The error message is
   not encrypted.  The KRB_ERROR message contains information that can
   be used to associate it with the message to which it replies.  The
   contents of the KRB_ERROR message are not integrity-protected.  As
   such, the client cannot detect replays, fabrications, or
   modifications.  A solution to this problem will be included in a
   future version of the protocol.

3.1.1.  Generation of KRB_AS_REQ Message

   The client may specify a number of options in the initial request.
   Among these options are whether pre-authentication is to be
   performed; whether the requested ticket is to be renewable,
   proxiable, or forwardable; whether it should be postdated or allow
   postdating of derivative tickets; and whether a renewable ticket will
   be accepted in lieu of a non-renewable ticket if the requested ticket
   expiration date cannot be satisfied by a non-renewable ticket (due to
   configuration constraints).

   The client prepares the KRB_AS_REQ message and sends it to the KDC.

3.1.2.  Receipt of KRB_AS_REQ Message

   If all goes well, processing the KRB_AS_REQ message will result in
   the creation of a ticket for the client to present to the server.
   The format for the ticket is described in Section 5.3.

   Because Kerberos can run over unreliable transports such as UDP, the
   KDC MUST be prepared to retransmit responses in case they are lost.
   If a KDC receives a request identical to one it has recently
   processed successfully, the KDC MUST respond with a KRB_AS_REP
   message rather than a replay error.  In order to reduce ciphertext
   given to a potential attacker, KDCs MAY send the same response
   generated when the request was first handled.  KDCs MUST obey this
   replay behavior even if the actual transport in use is reliable.

3.1.3.  Generation of KRB_AS_REP Message

   The authentication server looks up the client and server principals
   named in the KRB_AS_REQ in its database, extracting their respective
   keys.  If the requested client principal named in the request is
   unknown because it doesn't exist in the KDC's principal database,
   then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.

   If required to do so, the server pre-authenticates the request, and
   if the pre-authentication check fails, an error message with the code
   KDC_ERR_PREAUTH_FAILED is returned.  If pre-authentication is

   required, but was not present in the request, an error message with
   the code KDC_ERR_PREAUTH_REQUIRED is returned, and a METHOD-DATA
   object will be stored in the e-data field of the KRB-ERROR message to
   specify which pre-authentication mechanisms are acceptable.  Usually
   this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as
   described below.  If the server cannot accommodate any encryption
   type requested by the client, an error message with code
   KDC_ERR_ETYPE_NOSUPP is returned.  Otherwise, the KDC generates a
   'random' session key, meaning that, among other things, it should be
   impossible to guess the next session key based on knowledge of past
   session keys.  Although this can be achieved in a pseudo-random
   number generator if it is based on cryptographic principles, it is
   more desirable to use a truly random number generator, such as one
   based on measurements of random physical phenomena.  See [RFC4086]
   for an in-depth discussion of randomness.

   In response to an AS request, if there are multiple encryption keys
   registered for a client in the Kerberos database, then the etype
   field from the AS request is used by the KDC to select the encryption
   method to be used to protect the encrypted part of the KRB_AS_REP
   message that is sent to the client.  If there is more than one
   supported strong encryption type in the etype list, the KDC SHOULD
   use the first valid strong etype for which an encryption key is
   available.

   When the user's key is generated from a password or pass phrase, the
   string-to-key function for the particular encryption key type is
   used, as specified in [RFC3961].  The salt value and additional
   parameters for the string-to-key function have default values
   (specified by Section 4 and by the encryption mechanism
   specification, respectively) that may be overridden by
   pre-authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO,
   PA-ETYPE-INFO2, etc).  Since the KDC is presumed to store a copy of
   the resulting key only, these values should not be changed for
   password-based keys except when changing the principal's key.

   When the AS server is to include pre-authentication data in a
   KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-
   INFO, if the etype field of the client's AS-REQ lists at least one
   "newer" encryption type.  Otherwise (when the etype field of the
   client's AS-REQ does not list any "newer" encryption types), it MUST
   send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for
   each enctype).  A "newer" enctype is any enctype first officially
   specified concurrently with or subsequent to the issue of this RFC.
   The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not
   "newer" enctypes.

   It is not possible to generate a user's key reliably given a pass
   phrase without contacting the KDC, since it will not be known whether
   alternate salt or parameter values are required.

   The KDC will attempt to assign the type of the random session key
   from the list of methods in the etype field.  The KDC will select the
   appropriate type using the list of methods provided and information
   from the Kerberos database indicating acceptable encryption methods
   for the application server.  The KDC will not issue tickets with a
   weak session key encryption type.

   If the requested starttime is absent, indicates a time in the past,
   or is within the window of acceptable clock skew for the KDC and the
   POSTDATE option has not been specified, then the starttime of the
   ticket is set to the authentication server's current time.  If it
   indicates a time in the future beyond the acceptable clock skew, but
   the POSTDATED option has not been specified, then the error
   KDC_ERR_CANNOT_POSTDATE is returned.  Otherwise the requested
   starttime is checked against the policy of the local realm (the
   administrator might decide to prohibit certain types or ranges of
   postdated tickets), and if the ticket's starttime is acceptable, it
   is set as requested, and the INVALID flag is set in the new ticket.
   The postdated ticket MUST be validated before use by presenting it to
   the KDC after the starttime has been reached.

   The expiration time of the ticket will be set to the earlier of the
   requested endtime and a time determined by local policy, possibly by
   using realm- or principal-specific factors.  For example, the
   expiration time MAY be set to the earliest of the following:

      *  The expiration time (endtime) requested in the KRB_AS_REQ
         message.

      *  The ticket's starttime plus the maximum allowable lifetime
         associated with the client principal from the authentication
         server's database.

      *  The ticket's starttime plus the maximum allowable lifetime
         associated with the server principal.

      *  The ticket's starttime plus the maximum lifetime set by the
         policy of the local realm.

   If the requested expiration time minus the starttime (as determined
   above) is less than a site-determined minimum lifetime, an error
   message with code KDC_ERR_NEVER_VALID is returned.  If the requested
   expiration time for the ticket exceeds what was determined as above,
   and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE'

   flag is set in the new ticket, and the renew-till value is set as if
   the 'RENEWABLE' option were requested (the field and option names are
   described fully in Section 5.4.1).

   If the RENEWABLE option has been requested or if the RENEWABLE-OK
   option has been set and a renewable ticket is to be issued, then the
   renew-till field MAY be set to the earliest of:

      *  Its requested value.

      *  The starttime of the ticket plus the minimum of the two maximum
         renewable lifetimes associated with the principals' database
         entries.

      *  The starttime of the ticket plus the maximum renewable lifetime
         set by the policy of the local realm.

   The flags field of the new ticket will have the following options set
   if they have been requested and if the policy of the local realm
   allows:  FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
   If the new ticket is postdated (the starttime is in the future), its
   INVALID flag will also be set.

   If all of the above succeed, the server will encrypt the ciphertext
   part of the ticket using the encryption key extracted from the server
   principal's record in the Kerberos database using the encryption type
   associated with the server principal's key.  (This choice is NOT
   affected by the etype field in the request.)  It then formats a
   KRB_AS_REP message (see Section 5.4.2), copying the addresses in the
   request into the caddr of the response, placing any required pre-
   authentication data into the padata of the response, and encrypts the
   ciphertext part in the client's key using an acceptable encryption
   method requested in the etype field of the request, or in some key
   specified by pre-authentication mechanisms being used.

3.1.4.  Generation of KRB_ERROR Message

   Several errors can occur, and the Authentication Server responds by
   returning an error message, KRB_ERROR, to the client, with the
   error-code and e-text fields set to appropriate values.  The error
   message contents and details are described in Section 5.9.1.

3.1.5.  Receipt of KRB_AS_REP Message

   If the reply message type is KRB_AS_REP, then the client verifies
   that the cname and crealm fields in the cleartext portion of the
   reply match what it requested.  If any padata fields are present,
   they may be used to derive the proper secret key to decrypt the

   message.  The client decrypts the encrypted part of the response
   using its secret key and verifies that the nonce in the encrypted
   part matches the nonce it supplied in its request (to detect
   replays).  It also verifies that the sname and srealm in the response
   match those in the request (or are otherwise expected values), and
   that the host address field is also correct.  It then stores the
   ticket, session key, start and expiration times, and other
   information for later use.  The last-req field (and the deprecated
   key-expiration field) from the encrypted part of the response MAY be
   checked to notify the user of impending key expiration.  This enables
   the client program to suggest remedial action, such as a password
   change.

   Upon validation of the KRB_AS_REP message (by checking the returned
   nonce against that sent in the KRB_AS_REQ message), the client knows
   that the current time on the KDC is that read from the authtime field
   of the encrypted part of the reply.  The client can optionally use
   this value for clock synchronization in subsequent messages by
   recording with the ticket the difference (offset) between the
   authtime value and the local clock.  This offset can then be used by
   the same user to adjust the time read from the system clock when
   generating messages [DGT96].

   This technique MUST be used when adjusting for clock skew instead of
   directly changing the system clock, because the KDC reply is only
   authenticated to the user whose secret key was used, but not to the
   system or workstation.  If the clock were adjusted, an attacker
   colluding with a user logging into a workstation could agree on a
   password, resulting in a KDC reply that would be correctly validated
   even though it did not originate from a KDC trusted by the
   workstation.

   Proper decryption of the KRB_AS_REP message is not sufficient for the
   host to verify the identity of the user; the user and an attacker
   could cooperate to generate a KRB_AS_REP format message that decrypts
   properly but is not from the proper KDC.  If the host wishes to
   verify the identity of the user, it MUST require the user to present
   application credentials that can be verified using a securely-stored
   secret key for the host.  If those credentials can be verified, then
   the identity of the user can be assured.

3.1.6.  Receipt of KRB_ERROR Message

   If the reply message type is KRB_ERROR, then the client interprets it
   as an error and performs whatever application-specific tasks are
   necessary for recovery.

3.2.  The Client/Server Authentication Exchange

                                Summary

   Message direction                         Message type    Section
   Client to Application server              KRB_AP_REQ      5.5.1
   [optional] Application server to client   KRB_AP_REP or   5.5.2
                                             KRB_ERROR       5.9.1

   The client/server authentication (CS) exchange is used by network
   applications to authenticate the client to the server and vice versa.
   The client MUST have already acquired credentials for the server
   using the AS or TGS exchange.

3.2.1.  The KRB_AP_REQ Message

   The KRB_AP_REQ contains authentication information that SHOULD be
   part of the first message in an authenticated transaction.  It
   contains a ticket, an authenticator, and some additional bookkeeping
   information (see Section 5.5.1 for the exact format).  The ticket by
   itself is insufficient to authenticate a client, since tickets are
   passed across the network in cleartext (tickets contain both an
   encrypted and unencrypted portion, so cleartext here refers to the
   entire unit, which can be copied from one message and replayed in
   another without any cryptographic skill).  The authenticator is used
   to prevent invalid replay of tickets by proving to the server that
   the client knows the session key of the ticket and thus is entitled
   to use the ticket.  The KRB_AP_REQ message is referred to elsewhere
   as the 'authentication header'.

3.2.2.  Generation of a KRB_AP_REQ Message

   When a client wishes to initiate authentication to a server, it
   obtains (either through a credentials cache, the AS exchange, or the
   TGS exchange) a ticket and session key for the desired service.  The
   client MAY re-use any tickets it holds until they expire.  To use a
   ticket, the client constructs a new Authenticator from the system
   time and its name, and optionally from an application-specific
   checksum, an initial sequence number to be used in KRB_SAFE or
   KRB_PRIV messages, and/or a session subkey to be used in negotiations
   for a session key unique to this particular session.  Authenticators
   MUST NOT be re-used and SHOULD be rejected if replayed to a server.
   Note that this can make applications based on unreliable transports
   difficult to code correctly.  If the transport might deliver
   duplicated messages, either a new authenticator MUST be generated for
   each retry, or the application server MUST match requests and replies
   and replay the first reply in response to a detected duplicate.

   If a sequence number is to be included, it SHOULD be randomly chosen
   so that even after many messages have been exchanged it is not likely
   to collide with other sequence numbers in use.

   The client MAY indicate a requirement of mutual authentication or the
   use of a session-key based ticket (for user-to-user authentication,
   see section 3.7) by setting the appropriate flag(s) in the ap-options
   field of the message.

   The Authenticator is encrypted in the session key and combined with
   the ticket to form the KRB_AP_REQ message, which is then sent to the
   end server along with any additional application-specific
   information.

3.2.3.  Receipt of KRB_AP_REQ Message

   Authentication is based on the server's current time of day (clocks
   MUST be loosely synchronized), the authenticator, and the ticket.
   Several errors are possible.  If an error occurs, the server is
   expected to reply to the client with a KRB_ERROR message.  This
   message MAY be encapsulated in the application protocol if its raw
   form is not acceptable to the protocol.  The format of error messages
   is described in Section 5.9.1.

   The algorithm for verifying authentication information is as follows.
   If the message type is not KRB_AP_REQ, the server returns the
   KRB_AP_ERR_MSG_TYPE error.  If the key version indicated by the
   Ticket in the KRB_AP_REQ is not one the server can use (e.g., it
   indicates an old key, and the server no longer possesses a copy of
   the old key), the KRB_AP_ERR_BADKEYVER error is returned.  If the
   USE-SESSION-KEY flag is set in the ap-options field, it indicates to
   the server that user-to-user authentication is in use, and that the
   ticket is encrypted in the session key from the server's TGT rather
   than in the server's secret key.  See Section 3.7 for a more complete
   description of the effect of user-to-user authentication on all
   messages in the Kerberos protocol.

   Because it is possible for the server to be registered in multiple
   realms, with different keys in each, the srealm field in the
   unencrypted portion of the ticket in the KRB_AP_REQ is used to
   specify which secret key the server should use to decrypt that
   ticket.  The KRB_AP_ERR_NOKEY error code is returned if the server
   doesn't have the proper key to decipher the ticket.

   The ticket is decrypted using the version of the server's key
   specified by the ticket.  If the decryption routines detect a
   modification of the ticket (each encryption system MUST provide
   safeguards to detect modified ciphertext), the

   KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that
   different keys were used to encrypt and decrypt).

   The authenticator is decrypted using the session key extracted from
   the decrypted ticket.  If decryption shows that is has been modified,
   the KRB_AP_ERR_BAD_INTEGRITY error is returned.  The name and realm
   of the client from the ticket are compared against the same fields in
   the authenticator.  If they don't match, the KRB_AP_ERR_BADMATCH
   error is returned; normally this is caused by a client error or an
   attempted attack.  The addresses in the ticket (if any) are then
   searched for an address matching the operating-system reported
   address of the client.  If no match is found or the server insists on
   ticket addresses but none are present in the ticket, the
   KRB_AP_ERR_BADADDR error is returned.  If the local (server) time and
   the client time in the authenticator differ by more than the
   allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is
   returned.

   Unless the application server provides its own suitable means to
   protect against replay (for example, a challenge-response sequence
   initiated by the server after authentication, or use of a server-
   generated encryption subkey), the server MUST utilize a replay cache
   to remember any authenticator presented within the allowable clock
   skew.  Careful analysis of the application protocol and
   implementation is recommended before eliminating this cache.  The
   replay cache will store at least the server name, along with the
   client name, time, and microsecond fields from the recently-seen
   authenticators, and if a matching tuple is found, the
   KRB_AP_ERR_REPEAT error is returned.  Note that the rejection here is
   restricted to authenticators from the same principal to the same
   server.  Other client principals communicating with the same server
   principal should not have their authenticators rejected if the time
   and microsecond fields happen to match some other client's
   authenticator.

   If a server loses track of authenticators presented within the
   allowable clock skew, it MUST reject all requests until the clock
   skew interval has passed, providing assurance that any lost or
   replayed authenticators will fall outside the allowable clock skew
   and can no longer be successfully replayed.  If this were not done,
   an attacker could subvert the authentication by recording the ticket
   and authenticator sent over the network to a server and replaying
   them following an event that caused the server to lose track of
   recently seen authenticators.

   Implementation note: If a client generates multiple requests to the
   KDC with the same timestamp, including the microsecond field, all but
   the first of the requests received will be rejected as replays.  This

   might happen, for example, if the resolution of the client's clock is
   too coarse.  Client implementations SHOULD ensure that the timestamps
   are not reused, possibly by incrementing the microseconds field in
   the time stamp when the clock returns the same time for multiple
   requests.

   If multiple servers (for example, different services on one machine,
   or a single service implemented on multiple machines) share a service
   principal (a practice that we do not recommend in general, but that
   we acknowledge will be used in some cases), either they MUST share
   this replay cache, or the application protocol MUST be designed so as
   to eliminate the need for it.  Note that this applies to all of the
   services.  If any of the application protocols does not have replay
   protection built in, an authenticator used with such a service could
   later be replayed to a different service with the same service
   principal but no replay protection, if the former doesn't record the
   authenticator information in the common replay cache.

   If a sequence number is provided in the authenticator, the server
   saves it for later use in processing KRB_SAFE and/or KRB_PRIV
   messages.  If a subkey is present, the server either saves it for
   later use or uses it to help generate its own choice for a subkey to
   be returned in a KRB_AP_REP message.

   The server computes the age of the ticket: local (server) time minus
   the starttime inside the Ticket.  If the starttime is later than the
   current time by more than the allowable clock skew, or if the INVALID
   flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned.
   Otherwise, if the current time is later than end time by more than
   the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is
   returned.

   If all these checks succeed without an error, the server is assured
   that the client possesses the credentials of the principal named in
   the ticket, and thus, that the client has been authenticated to the
   server.

   Passing these checks provides only authentication of the named
   principal; it does not imply authorization to use the named service.
   Applications MUST make a separate authorization decision based upon
   the authenticated name of the user, the requested operation, local
   access control information such as that contained in a .k5login or
   .k5users file, and possibly a separate distributed authorization
   service.

3.2.4.  Generation of a KRB_AP_REP Message

   Typically, a client's request will include both the authentication
   information and its initial request in the same message, and the
   server need not explicitly reply to the KRB_AP_REQ.  However, if
   mutual authentication (authenticating not only the client to the
   server, but also the server to the client) is being performed, the
   KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options
   field, and a KRB_AP_REP message is required in response.  As with the
   error message, this message MAY be encapsulated in the application
   protocol if its "raw" form is not acceptable to the application's
   protocol.  The timestamp and microsecond field used in the reply MUST
   be the client's timestamp and microsecond field (as provided in the
   authenticator).  If a sequence number is to be included, it SHOULD be
   randomly chosen as described above for the authenticator.  A subkey
   MAY be included if the server desires to negotiate a different
   subkey.  The KRB_AP_REP message is encrypted in the session key
   extracted from the ticket.

   Note that in the Kerberos Version 4 protocol, the timestamp in the
   reply was the client's timestamp plus one.  This is not necessary in
   Version 5 because Version 5 messages are formatted in such a way that
   it is not possible to create the reply by judicious message surgery
   (even in encrypted form) without knowledge of the appropriate
   encryption keys.

3.2.5.  Receipt of KRB_AP_REP Message

   If a KRB_AP_REP message is returned, the client uses the session key
   from the credentials obtained for the server to decrypt the message
   and verifies that the timestamp and microsecond fields match those in
   the Authenticator it sent to the server.  If they match, then the
   client is assured that the server is genuine.  The sequence number
   and subkey (if present) are retained for later use.  (Note that for
   encrypting the KRB_AP_REP message, the sub-session key is not used,
   even if it is present in the Authentication.)

3.2.6.  Using the Encryption Key

   After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and
   server share an encryption key that can be used by the application.
   In some cases, the use of this session key will be implicit in the
   protocol; in others the method of use must be chosen from several
   alternatives.  The application MAY choose the actual encryption key
   to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses
   based on the session key from the ticket and subkeys in the
   KRB_AP_REP message and the authenticator.  Implementations of the
   protocol MAY provide routines to choose subkeys based on session keys

   and random numbers and to generate a negotiated key to be returned in
   the KRB_AP_REP message.

   To mitigate the effect of failures in random number generation on the
   client, it is strongly encouraged that any key derived by an
   application for subsequent use include the full key entropy derived
   from the KDC-generated session key carried in the ticket.  We leave
   the protocol negotiations of how to use the key (e.g., for selecting
   an encryption or checksum type) to the application programmer.  The
   Kerberos protocol does not constrain the implementation options, but
   an example of how this might be done follows.

   One way that an application may choose to negotiate a key to be used
   for subsequent integrity and privacy protection is for the client to
   propose a key in the subkey field of the authenticator.  The server
   can then choose a key using the key proposed by the client as input,
   returning the new subkey in the subkey field of the application
   reply.  This key could then be used for subsequent communication.

   With both the one-way and mutual authentication exchanges, the peers
   should take care not to send sensitive information to each other
   without proper assurances.  In particular, applications that require
   privacy or integrity SHOULD use the KRB_AP_REP response from the
   server to the client to assure both client and server of their peer's
   identity.  If an application protocol requires privacy of its
   messages, it can use the KRB_PRIV message (section 3.5).  The
   KRB_SAFE message (Section 3.4) can be used to ensure integrity.

3.3.  The Ticket-Granting Service (TGS) Exchange

                             Summary

         Message direction       Message type     Section
         1. Client to Kerberos   KRB_TGS_REQ      5.4.1
         2. Kerberos to client   KRB_TGS_REP or   5.4.2
                                 KRB_ERROR        5.9.1

   The TGS exchange between a client and the Kerberos TGS is initiated
   by a client when it seeks to obtain authentication credentials for a
   given server (which might be registered in a remote realm), when it
   seeks to renew or validate an existing ticket, or when it seeks to
   obtain a proxy ticket.  In the first case, the client must already
   have acquired a ticket for the Ticket-Granting Service using the AS
   exchange (the TGT is usually obtained when a client initially
   authenticates to the system, such as when a user logs in).  The
   message format for the TGS exchange is almost identical to that for
   the AS exchange.  The primary difference is that encryption and
   decryption in the TGS exchange does not take place under the client's

   key.  Instead, the session key from the TGT or renewable ticket, or
   sub-session key from an Authenticator is used.  As is the case for
   all application servers, expired tickets are not accepted by the TGS,
   so once a renewable or TGT expires, the client must use a separate
   exchange to obtain valid tickets.

   The TGS exchange consists of two messages: a request (KRB_TGS_REQ)
   from the client to the Kerberos Ticket-Granting Server, and a reply
   (KRB_TGS_REP or KRB_ERROR).  The KRB_TGS_REQ message includes
   information authenticating the client plus a request for credentials.
   The authentication information consists of the authentication header
   (KRB_AP_REQ), which includes the client's previously obtained
   ticket-granting, renewable, or invalid ticket.  In the TGT and proxy
   cases, the request MAY include one or more of the following: a list
   of network addresses, a collection of typed authorization data to be
   sealed in the ticket for authorization use by the application server,
   or additional tickets (the use of which are described later).  The
   TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted
   in the session key from the TGT or renewable ticket, or, if present,
   in the sub-session key from the Authenticator (part of the
   authentication header).  The KRB_ERROR message contains an error code
   and text explaining what went wrong.  The KRB_ERROR message is not
   encrypted.  The KRB_TGS_REP message contains information that can be
   used to detect replays, and to associate it with the message to which
   it replies.  The KRB_ERROR message also contains information that can
   be used to associate it with the message to which it replies.  The
   same comments about integrity protection of KRB_ERROR messages
   mentioned in Section 3.1 apply to the TGS exchange.

3.3.1.  Generation of KRB_TGS_REQ Message

   Before sending a request to the ticket-granting service, the client
   MUST determine in which realm the application server is believed to
   be registered.  This can be accomplished in several ways.  It might
   be known beforehand (since the realm is part of the principal
   identifier), it might be stored in a nameserver, or it might be
   obtained from a configuration file.  If the realm to be used is
   obtained from a nameserver, there is a danger of being spoofed if the
   nameservice providing the realm name is not authenticated.  This
   might result in the use of a realm that has been compromised, which
   would result in an attacker's ability to compromise the
   authentication of the application server to the client.

   If the client knows the service principal name and realm and it does
   not already possess a TGT for the appropriate realm, then one must be
   obtained.  This is first attempted by requesting a TGT for the
   destination realm from a Kerberos server for which the client
   possesses a TGT (by using the KRB_TGS_REQ message recursively).  The

   Kerberos server MAY return a TGT for the desired realm, in which case
   one can proceed.  Alternatively, the Kerberos server MAY return a TGT
   for a realm that is 'closer' to the desired realm (further along the
   standard hierarchical path between the client's realm and the
   requested realm server's realm).  Note that in this case
   misconfiguration of the Kerberos servers may cause loops in the
   resulting authentication path, which the client should be careful to
   detect and avoid.

   If the Kerberos server returns a TGT for a realm 'closer' than the
   desired realm, the client MAY use local policy configuration to
   verify that the authentication path used is an acceptable one.
   Alternatively, a client MAY choose its own authentication path,
   rather than rely on the Kerberos server to select one.  In either
   case, any policy or configuration information used to choose or
   validate authentication paths, whether by the Kerberos server or by
   the client, MUST be obtained from a trusted source.

   When a client obtains a TGT that is 'closer' to the destination
   realm, the client MAY cache this ticket and reuse it in future
   KRB-TGS exchanges with services in the 'closer' realm.  However, if
   the client were to obtain a TGT for the 'closer' realm by starting at
   the initial KDC rather than as part of obtaining another ticket, then
   a shorter path to the 'closer' realm might be used.  This shorter
   path may be desirable because fewer intermediate KDCs would know the
   session key of the ticket involved.  For this reason, clients SHOULD
   evaluate whether they trust the realms transited in obtaining the
   'closer' ticket when making a decision to use the ticket in future.

   Once the client obtains a TGT for the appropriate realm, it
   determines which Kerberos servers serve that realm and contacts one
   of them.  The list might be obtained through a configuration file or
   network service, or it MAY be generated from the name of the realm.
   As long as the secret keys exchanged by realms are kept secret, only
   denial of service results from using a false Kerberos server.

   As in the AS exchange, the client MAY specify a number of options in
   the KRB_TGS_REQ message.  One of these options is the ENC-TKT-IN-SKEY
   option used for user-to-user authentication.  An overview of user-
   to-user authentication can be found in Section 3.7.  When generating
   the KRB_TGS_REQ message, this option indicates that the client is
   including a TGT obtained from the application server in the
   additional tickets field of the request and that the KDC SHOULD
   encrypt the ticket for the application server using the session key
   from this additional ticket, instead of a server key from the
   principal database.

   The client prepares the KRB_TGS_REQ message, providing an
   authentication header as an element of the padata field, and
   including the same fields as used in the KRB_AS_REQ message along
   with several optional fields: the enc-authorizatfion-data field for
   application server use and additional tickets required by some
   options.

   In preparing the authentication header, the client can select a sub-
   session key under which the response from the Kerberos server will be
   encrypted.  If the client selects a sub-session key, care must be
   taken to ensure the randomness of the selected sub-session key.

   If the sub-session key is not specified, the session key from the TGT
   will be used.  If the enc-authorization-data is present, it MUST be
   encrypted in the sub-session key, if present, from the authenticator
   portion of the authentication header, or, if not present, by using
   the session key from the TGT.

   Once prepared, the message is sent to a Kerberos server for the
   destination realm.

3.3.2.  Receipt of KRB_TGS_REQ Message

   The KRB_TGS_REQ message is processed in a manner similar to the
   KRB_AS_REQ message, but there are many additional checks to be
   performed.  First, the Kerberos server MUST determine which server
   the accompanying ticket is for, and it MUST select the appropriate
   key to decrypt it.  For a normal KRB_TGS_REQ message, it will be for
   the ticket-granting service, and the TGS's key will be used.  If the
   TGT was issued by another realm, then the appropriate inter-realm key
   MUST be used.  If (a) the accompanying ticket is not a TGT for the
   current realm, but is for an application server in the current realm,
   (b) the RENEW, VALIDATE, or PROXY options are specified in the
   request, and (c) the server for which a ticket is requested is the
   server named in the accompanying ticket, then the KDC will decrypt
   the ticket in the authentication header using the key of the server
   for which it was issued.  If no ticket can be found in the padata
   field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.

   Once the accompanying ticket has been decrypted, the user-supplied
   checksum in the Authenticator MUST be verified against the contents
   of the request, and the message MUST be rejected if the checksums do
   not match (with an error code of KRB_AP_ERR_MODIFIED) or if the
   checksum is not collision-proof (with an error code of
   KRB_AP_ERR_INAPP_CKSUM).  If the checksum type is not supported, the
   KDC_ERR_SUMTYPE_NOSUPP error is returned.  If the authorization-data
   are present, they are decrypted using the sub-session key from the
   Authenticator.

   If any of the decryptions indicate failed integrity checks, the
   KRB_AP_ERR_BAD_INTEGRITY error is returned.

   As discussed in Section 3.1.2, the KDC MUST send a valid KRB_TGS_REP
   message if it receives a KRB_TGS_REQ message identical to one it has
   recently processed.  However, if the authenticator is a replay, but
   the rest of the request is not identical, then the KDC SHOULD return
   KRB_AP_ERR_REPEAT.

3.3.3.  Generation of KRB_TGS_REP Message

   The KRB_TGS_REP message shares its format with the KRB_AS_REP
   (KRB_KDC_REP), but with its type field set to KRB_TGS_REP.  The
   detailed specification is in Section 5.4.2.

   The response will include a ticket for the requested server or for a
   ticket granting server of an intermediate KDC to be contacted to
   obtain the requested ticket.  The Kerberos database is queried to
   retrieve the record for the appropriate server (including the key
   with which the ticket will be encrypted).  If the request is for a
   TGT for a remote realm, and if no key is shared with the requested
   realm, then the Kerberos server will select the realm 'closest' to
   the requested realm with which it does share a key and use that realm
   instead.  This is the only case where the response for the KDC will
   be for a different server than that requested by the client.

   By default, the address field, the client's name and realm, the list
   of transited realms, the time of initial authentication, the
   expiration time, and the authorization data of the newly-issued
   ticket will be copied from the TGT or renewable ticket.  If the
   transited field needs to be updated, but the transited type is not
   supported, the KDC_ERR_TRTYPE_NOSUPP error is returned.

   If the request specifies an endtime, then the endtime of the new
   ticket is set to the minimum of (a) that request, (b) the endtime
   from the TGT, and (c) the starttime of the TGT plus the minimum of
   the maximum life for the application server and the maximum life for
   the local realm (the maximum life for the requesting principal was
   already applied when the TGT was issued).  If the new ticket is to be
   a renewal, then the endtime above is replaced by the minimum of (a)
   the value of the renew_till field of the ticket and (b) the starttime
   for the new ticket plus the life (endtime-starttime) of the old
   ticket.

   If the FORWARDED option has been requested, then the resulting ticket
   will contain the addresses specified by the client.  This option will
   only be honored if the FORWARDABLE flag is set in the TGT.  The PROXY
   option is similar; the resulting ticket will contain the addresses

   specified by the client.  It will be honored only if the PROXIABLE
   flag in the TGT is set.  The PROXY option will not be honored on
   requests for additional TGTs.

   If the requested starttime is absent, indicates a time in the past,
   or is within the window of acceptable clock skew for the KDC and the
   POSTDATE option has not been specified, then the starttime of the
   ticket is set to the authentication server's current time.  If it
   indicates a time in the future beyond the acceptable clock skew, but
   the POSTDATED option has not been specified or the MAY-POSTDATE flag
   is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is
   returned.  Otherwise, if the TGT has the MAY-POSTDATE flag set, then
   the resulting ticket will be postdated, and the requested starttime
   is checked against the policy of the local realm.  If acceptable, the
   ticket's starttime is set as requested, and the INVALID flag is set.
   The postdated ticket MUST be validated before use by presenting it to
   the KDC after the starttime has been reached.  However, in no case
   may the starttime, endtime, or renew-till time of a newly-issued
   postdated ticket extend beyond the renew-till time of the TGT.

   If the ENC-TKT-IN-SKEY option has been specified and an additional
   ticket has been included in the request, it indicates that the client
   is using user-to-user authentication to prove its identity to a
   server that does not have access to a persistent key.  Section 3.7
   describes the effect of this option on the entire Kerberos protocol.
   When generating the KRB_TGS_REP message, this option in the
   KRB_TGS_REQ message tells the KDC to decrypt the additional ticket
   using the key for the server to which the additional ticket was
   issued and to verify that it is a TGT.  If the name of the requested
   server is missing from the request, the name of the client in the
   additional ticket will be used.  Otherwise, the name of the requested
   server will be compared to the name of the client in the additional
   ticket.  If it is different, the request will be rejected.  If the
   request succeeds, the session key from the additional ticket will be
   used to encrypt the new ticket that is issued instead of using the
   key of the server for which the new ticket will be used.

   If (a) the name of the server in the ticket that is presented to the
   KDC as part of the authentication header is not that of the TGS
   itself, (b) the server is registered in the realm of the KDC, and (c)
   the RENEW option is requested, then the KDC will verify that the
   RENEWABLE flag is set in the ticket, that the INVALID flag is not set
   in the ticket, and that the renew_till time is still in the future.
   If the VALIDATE option is requested, the KDC will check that the
   starttime has passed and that the INVALID flag is set.  If the PROXY
   option is requested, then the KDC will check that the PROXIABLE flag

   is set in the ticket.  If the tests succeed and the ticket passes the
   hotlist check described in the next section, the KDC will issue the
   appropriate new ticket.

   The ciphertext part of the response in the KRB_TGS_REP message is
   encrypted in the sub-session key from the Authenticator, if present,
   or in the session key from the TGT.  It is not encrypted using the
   client's secret key.  Furthermore, the client's key's expiration date
   and the key version number fields are left out since these values are
   stored along with the client's database record, and that record is
   not needed to satisfy a request based on a TGT.

3.3.3.1.  Checking for Revoked Tickets

   Whenever a request is made to the ticket-granting server, the
   presented ticket(s) is (are) checked against a hot-list of tickets
   that have been canceled.  This hot-list might be implemented by
   storing a range of issue timestamps for 'suspect tickets'; if a
   presented ticket had an authtime in that range, it would be rejected.
   In this way, a stolen TGT or renewable ticket cannot be used to gain
   additional tickets (renewals or otherwise) once the theft has been
   reported to the KDC for the realm in which the server resides.  Any
   normal ticket obtained before it was reported stolen will still be
   valid (because tickets require no interaction with the KDC), but only
   until its normal expiration time.  If TGTs have been issued for
   cross-realm authentication, use of the cross-realm TGT will not be
   affected unless the hot-list is propagated to the KDCs for the realms
   for which such cross-realm tickets were issued.

3.3.3.2.  Encoding the Transited Field

   If the identity of the server in the TGT that is presented to the KDC
   as part of the authentication header is that of the ticket-granting
   service, but the TGT was issued from another realm, the KDC will look
   up the inter-realm key shared with that realm and use that key to
   decrypt the ticket.  If the ticket is valid, then the KDC will honor
   the request, subject to the constraints outlined above in the section
   describing the AS exchange.  The realm part of the client's identity
   will be taken from the TGT.  The name of the realm that issued the
   TGT, if it is not the realm of the client principal, will be added to
   the transited field of the ticket to be issued.  This is accomplished
   by reading the transited field from the TGT (which is treated as an
   unordered set of realm names), adding the new realm to the set, and
   then constructing and writing out its encoded (shorthand) form (this
   may involve a rearrangement of the existing encoding).

   Note that the ticket-granting service does not add the name of its
   own realm.  Instead, its responsibility is to add the name of the

   previous realm.  This prevents a malicious Kerberos server from
   intentionally leaving out its own name (it could, however, omit other
   realms' names).

   The names of neither the local realm nor the principal's realm are to
   be included in the transited field.  They appear elsewhere in the
   ticket and both are known to have taken part in authenticating the
   principal.  Because the endpoints are not included, both local and
   single-hop inter-realm authentication result in a transited field
   that is empty.

   Because this field has the name of each transited realm added to it,
   it might potentially be very long.  To decrease the length of this
   field, its contents are encoded.  The initially supported encoding is
   optimized for the normal case of inter-realm communication: a
   hierarchical arrangement of realms using either domain or X.500 style
   realm names.  This encoding (called DOMAIN-X500-COMPRESS) is now
   described.

   Realm names in the transited field are separated by a ",".  The ",",
   "\", trailing "."s, and leading spaces (" ") are special characters,
   and if they are part of a realm name, they MUST be quoted in the
   transited field by preceding them with a "\".

   A realm name ending with a "." is interpreted as being prepended to
   the previous realm.  For example, we can encode traversal of EDU,
   MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:

      "EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".

   Note that if either ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were
   endpoints, they would not be included in this field, and we would
   have:

      "EDU,MIT.,WASHINGTON.EDU"

   A realm name beginning with a "/" is interpreted as being appended to
   the previous realm.  For the purpose of appending, the realm
   preceding the first listed realm is considered the null realm ("").
   If a realm name beginning with a "/" is to stand by itself, then it
   SHOULD be preceded by a space (" ").  For example, we can encode
   traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as:

      "/COM,/HP,/APOLLO, /COM/DEC".

   As in the example above, if /COM/HP/APOLLO and /COM/DEC were
   endpoints, they would not be included in this field, and we would
   have:

      "/COM,/HP"

   A null subfield preceding or following a "," indicates that all
   realms between the previous realm and the next realm have been
   traversed.  For the purpose of interpreting null subfields, the
   client's realm is considered to precede those in the transited field,
   and the server's realm is considered to follow them.  Thus, "," means
   that all realms along the path between the client and the server have
   been traversed.  ",EDU, /COM," means that all realms from the
   client's realm up to EDU (in a domain style hierarchy) have been
   traversed, and that everything from /COM down to the server's realm
   in an X.500 style has also been traversed.  This could occur if the
   EDU realm in one hierarchy shares an inter-realm key directly with
   the /COM realm in another hierarchy.

3.3.4.  Receipt of KRB_TGS_REP Message

   When the KRB_TGS_REP is received by the client, it is processed in
   the same manner as the KRB_AS_REP processing described above.  The
   primary difference is that the ciphertext part of the response must
   be decrypted using the sub-session key from the Authenticator, if it
   was specified in the request, or the session key from the TGT, rather
   than the client's secret key.  The server name returned in the reply
   is the true principal name of the service.