Generation of KRB_AS_REQ Message

The client can specify a number of options in the initial request. Among these options are the following:

•  Whether to perform preauthentication

•  Whether the requested ticket is to be renewable, proxiable, or forwardable

•  Whether the ticket should be postdated or permit postdating of derivative tickets, and whether a renewable ticket can be accepted in lieu of a nonrenewable ticket if the requested ticket expiration date cannot be satisfied by a nonrenewable ticket (due to configuration constraints)

The client prepares the KRB_AS_REQ message and sends it to the Key Distribution Center.

Receipt of a KRB_AS_REQ Message

If all goes well, processing the KRB_AS_REQ message results in the creation of a ticket for the client to present to the server.

Generation of a 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 required, the server preauthenticates the request, and if the preauthentication check fails, an error message with the code KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate the requested encryption type, an error message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise, it generates a random session key.

Random means that, among other things, guessing the next session key based on knowledge of past session keys should be impossible. This can only be achieved in a pseudo-random number generator if it is based on cryptographic principles. Using a truly random number generator, such as one based on measurements of randomly physical phenomena, is preferred.

If the requested start time is absent or indicates a time in the past, then the start time of the ticket is set to the authentication server’s current time. If it indicates a time in the future, but the POSTDATED option has not been specified, then the error KDC_ERR_CANNOT_POSTDATE is returned; otherwise, the requested start time is checked against the policy of the local realm. The administrator might decide to prohibit certain types or ranges of postdated tickets. If acceptable, the ticket’s start time 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 Key Distribution Center after the start time has been reached.

The expiration time of the ticket will be set to the minimum of the following:

•  The expiration time (endtime) requested in the KRB_AS_REQ message

•  The ticket’s start time plus the maximum allowable lifetime associated with the client principal (the authentication server’s database includes a maximum ticket lifetime field in each principal’s record)

•  The ticket’s start time plus the maximum allowable lifetime associated with the server principal

•  The ticket’s start time plus the maximum lifetime set by the policy of the local realm

If the requested expiration time minus the start time (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 earlier, 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. 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 is set to the minimum of one of the following:

•  Its requested value

•  The start time of the ticket plus the minimum of the two maximum renewable lifetimes associated with the principals’ database entries

•  The start time 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 permits: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new ticket is postdated (the start time is in the future), its INVALID flag also will be set.

If all of the preceding succeed, the server formats a KRB_AS_REP message. It copies the addresses in the request into the caddr of the response, placing any required preauthentication data into the padata of the response. Finally it uses the requested encryption method to encrypt the ciphertext part in the client’s key and sends it to the client.

Receipt of a 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 can be used to derive the proper secret key to decrypt the message.

The client uses its secret key to decrypt the encrypted part of the response 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, and that the host address field also is correct. It then stores the ticket, session key, start and expiration times, and other information for later use. The key-expiration field from the encrypted part of the response can be checked to notify the user of impending key expiration. The client program could then suggest remedial action, such as a password change.

Proper decryption of the KRB_AS_REP message is not sufficient 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 Key Distribution Center. If the host wants 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. If those credentials can be verified, then the identity of the user can be assured.

Generation of a 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.

Receipt of a 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 to recover.