Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4120

The Kerberos Network Authentication Service (V5)

Pages: 138
Proposed Standard
Obsoletes:  1510
Updated by:  4537502158966111611261136649680677518062812984298553
Part 2 of 6 – Pages 16 to 42
First   Prev   Next

Top   ToC   RFC4120 - Page 16   prevText

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.
Top   ToC   RFC4120 - Page 17

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

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
Top   ToC   RFC4120 - Page 18
   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

   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

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
Top   ToC   RFC4120 - Page 19
   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
Top   ToC   RFC4120 - Page 20
   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
Top   ToC   RFC4120 - Page 21
   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

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.
Top   ToC   RFC4120 - Page 22


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)
Top   ToC   RFC4120 - Page 23
   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.
Top   ToC   RFC4120 - Page 24
   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
Top   ToC   RFC4120 - Page 25
   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

   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.
Top   ToC   RFC4120 - Page 26
   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

      *  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'
Top   ToC   RFC4120 - Page 27
   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

      *  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
   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
Top   ToC   RFC4120 - Page 28
   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

   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

   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.
Top   ToC   RFC4120 - Page 29

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.
Top   ToC   RFC4120 - Page 30
   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

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
Top   ToC   RFC4120 - Page 31
   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

   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

   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
Top   ToC   RFC4120 - Page 32
   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

   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

   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

   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
Top   ToC   RFC4120 - Page 33

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
Top   ToC   RFC4120 - Page 34
   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
Top   ToC   RFC4120 - Page 35
   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
Top   ToC   RFC4120 - Page 36
   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.
Top   ToC   RFC4120 - Page 37
   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

   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.
Top   ToC   RFC4120 - Page 38
   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

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
Top   ToC   RFC4120 - Page 39
   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
Top   ToC   RFC4120 - Page 40
   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. 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. 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
Top   ToC   RFC4120 - Page 41
   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

   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,


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


   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
Top   ToC   RFC4120 - Page 42

   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.

(page 42 continued on part 3)

Next Section