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.
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.
the application client MUST present the ticket to the KDC to be validated before use.
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.
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.
Section 3.3.3 for specific details. 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. 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.
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. Section 5.9.1.
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.
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. 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'.
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. 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.
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. 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.
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.
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. 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.
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.