KRB_AP_REP Definition

The KRB_AP_REP message contains the Kerberos protocol version number, the message type, and an encrypted timestamp. The message is sent in response to an application request (KRB_AP_REQ) in which the mutual authentication option has been selected in the ap-options field.

   AP-REP = {
             pvno[0]                   INTEGER,
             msg-type[1]               INTEGER,
             enc-part[2]               EncryptedData
            }

   EncAPRepPart = {
             ctime[0]                  KerberosTime,
             cusec[1]                  INTEGER,
             subkey[2]                 EncryptionKey OPTIONAL,
             seq-number[3]             INTEGER OPTIONAL
                  }

Table 9.8 describes the fields in this message.

Error Message Reply

If an error occurs while processing the application request, the KRB_ERROR message is sent in response. The cname and crealm fields can be left out if the server cannot determine their appropriate values from the corresponding KRB_AP_REQ message. If the Authenticator was decipherable, the ctime and cusec fields contain the values from it.

The KRB_SAFE Exchange

The KRB_SAFE message may be used by clients that require the capability to detect modifications of messages they exchange. It achieves this by including a keyed, collision-proof checksum of the user data and some control information. The checksum is keyed with an encryption key. Kerberos usually uses the last key negotiated via subkeys, or the session key if no negotiation has occurred.

Generation of a KRB_SAFE Message

When an application needs to send a KRB_SAFE message, it collects its data and the appropriate control information and computes a checksum over them. The checksum algorithm should be some sort of keyed one-way function such as the RSA-MD5-DES, or the DES-MAC, generated using the subsession key if present, or otherwise the session key. Different algorithms can be selected by changing the checksum type in the message. Unkeyed or non-collision-proof checksums are not suitable for this use.

Next, a decision must be made about the appropriate control information to use. The control information for the KRB_SAFE message includes a timestamp and a sequence number. Designers of applications that use the KRB_SAFE message must choose at least one of the two mechanisms based on the needs of the application protocol.

Sequence numbers are useful when all messages sent will be received by one’s peer. Connection state presently is required to maintain the session key, so maintaining the next sequence number should not present an additional problem.

If the application protocol is expected to tolerate lost messages without them being resent, the use of the timestamp is the appropriate replay detection mechanism. Using timestamps also is the appropriate mechanism for multicast protocols in which all one’s peers share a common subsession key, but some messages are sent to a subset of one’s peers.

After computing the checksum, the client then transmits the information and checksum to the recipient.

Receipt of KRB_SAFE Message

When an application receives a KRB_SAFE message, it verifies it as follows. If any error occurs, an error code is reported for use by the application.

The message is first checked by verifying that the protocol version and type fields match the current version and KRB_SAFE, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error.

The application verifies that the checksum used is a collision-proof keyed checksum, and if it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. The recipient verifies that the operating system’s report of the sender’s address matches the sender’s address in the message. If a recipient address is specified or the recipient requires an address, then it checks that one of the recipient’s addresses appears as the recipient’s address in the message. A failed match for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the sequence number fields are checked.

If timestamp and usec are expected and not present, or they are present but not current, the KRB_AP_ERR_SKEW error is generated. If the server name along with the client name, time, and microsecond fields from the Authenticator match any recently seen such tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is included, or a sequence number is expected but not present, the KRB_AP_ERR_BADORDER error is generated. If neither a timestamp and usec nor a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.

Finally, the checksum is computed over the data and control information, and if it doesn’t match the received checksum, a KRB_AP_ERR_MODIFIED error is generated.

If all the checks succeed, the application is assured that the message was generated by its peer and not modified in transit.