Internet Security Professional Reference:Kerberos

-->

KRB_SAFE Message Specification

This section specifies the format of a message that can be used by either side, client or server, of an application to send a tamperproof message to its peer. It presumes that a session key has previously been exchanged; for example, by using the KRB_AP_REQ/KRB_AP_REP messages.

KRB_SAFE Definition

The KRB_SAFE message contains user data along with a collision-proof checksum keyed with the session key. The message fields are as follows:

   KRB-SAFE = {
               pvno[0]               INTEGER,
               msg-type[1]           INTEGER,
               safe-body[2]          KRB-SAFE-BODY,
               cksum[3]              Checksum
              }

   KRB-SAFE-BODY = {
               user-data[0]          BYTE STRING,
               timestamp[1]          KerberosTime OPTIONAL,
               usec[2]               INTEGER OPTIONAL,
               seq-number[3]         INTEGER OPTIONAL,
               s-address[4]          HostAddress,
               r-address[5]          HostAddress OPTIONAL
                   }

The fields for this message are described in table 9.9.

**Table 9.9**
KRB_SAFE Message Fields

Field	Description

pvno and msg-type	Described earlier. msg-type is KRB_SAFE.
safe-body	Serves as a placeholder for the body of the KRB-SAFE message. It is to be encoded separately and then have the checksum computed over it, for use in the cksum field.
cksum	Contains the checksum of the application data. The checksum is computed over the encoding of the KRB-SAFE-BODY sequence.
user-data	Part of the KRB_SAFE and KRB_PRIV messages. It contains the application specific data that is being passed from the sender to the recipient.
timestamp	Part of the KRB_SAFE and KRB_PRIV messages. Its contents are the current time as known by the sender of the message. By checking the timestamp, the recipient of the message is able to make sure that it was recently generated, and is not a replay.
usec	Part of the KRB_SAFE and KRB_PRIV headers. It contains the microsecond part of the timestamp.
seq-number	Described earlier.
s-address	Specifies the address in use by the sender of the message.
r-address	Specifies the address in use by the recipient of the message. It can be omitted for some uses, such as broadcast protocols, but the recipient can arbitrarily reject such messages. This field, along with s-address, can be used to help detect messages that have been incorrectly or maliciously delivered to the wrong recipient.

The KRB_PRIV Exchange

The KRB_PRIV message provides clients confidentiality and the capability to detect modifications of exchanged messages by encrypting the messages and adding control information.

Generation of a KRB_PRIV Message

When an application needs to send a KRB_PRIV message, it collects its data and the appropriate control information and encrypts them under an encryption key, usually the last key negotiated via subkeys, or if no negotiation has occurred, the session key. As part of the control information, the client must choose to use a timestamp, a sequence number, or both. After the user data and control information are encrypted, the client transmits the ciphertext and some “envelope” information to the recipient.

Receipt of KRB_PRIV Message

When an application receives a KRB_PRIV 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_PRIV, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then decrypts the ciphertext and processes the resultant plaintext. If decryption shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY 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 if 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.

If all the checks succeed, the application can assume the message was generated by its peer, and was securely transmitted.

Table of Contents