HostedDB - Dedicated UNIX Servers

-->
Internet Security Professional Reference:Kerberos
Previous Table of Contents Next


KRB_PRIV 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, securely and privately, a message to its peer. It presumes that a session key has previously been exchanged.

KRB_PRIV Definition

The KRB_PRIV message contains user data encrypted in the Session Key. The message fields are as follows:

   KRB-PRIV = {
               pvno[0]              INTEGER,
               msg-type[1]          INTEGER,
               enc-part[3]          EncryptedData
              }

EncKrbPrivPart = {
               user-data[0]         BYTE STRING,
               timestamp[1]         KerberosTime OPTIONAL,
               usec[2]              INTEGER OPTIONAL,
               seq-number[3]        INTEGER OPTIONAL,
               s-address[4]         HostAddress, -- sender’s addr
               r-address[5]         HostAddress OPTIONAL
                                                 -- recip’s addr
                 }

Table 9.10 describes the fields for this message.

Table 9.10
KRB_PRIV Message Fields

Field Description

pvno and msg-type Described earlier. msg-type is KRB_PRIV.
enc-part Holds an encoding of the EncKrbPrivPart sequence encrypted under the session key. This encrypted encoding is used for the enc-part field of the KRB-PRIV message.
user-data, timestamp, usec, s-address, and r-address Described earlier.
seq-number Described earlier.

The KRB_CRED Exchange

The KRB_CRED message can be used by clients who require the capability to send Kerberos credentials from one host to another. It achieves this by sending the tickets together with encrypted data that contain the session keys and other information associated with the tickets.

Generation of a KRB_CRED Message

When an application needs to send a KRB_CRED message, it first obtains credentials to be sent to the remote host. Then it uses the ticket or tickets it obtains to construct a KRB_CRED message. It places the necessary session key to use each ticket in the key field of the corresponding KrbCredInfo sequence of the encrypted part of the KRB_CRED message.

Other information associated with each ticket and obtained during the KRB_TGS exchange also is placed in the corresponding KrbCredInfo sequence in the encrypted part of the KRB_CRED message. The current time and, if specifically required by the application, the nonce, s-address, and r-address fields are placed in the encrypted part of the KRB_CRED message. It is then encrypted under an encryption key previously exchanged in the KRB_AP exchange.

Receipt of KRB_CRED Message

When an application receives a KRB_CRED message, it verifies it. If any error occurs, an error code is reported for use by the application. The message is verified by checking that the protocol version and type fields match the current version and KRB_CRED, 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. If present or required, the recipient verifies that the operating system’s report of the sender’s address matches the sender’s address in the message.

Next 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. The timestamp and usec fields, and the nonce field if required, are checked next. If the timestamp and usec are not present, or if they are present but not current, the KRB_AP_ERR_SKEW error is generated.

If all the checks succeed, the application stores each of the new tickets in its ticket cache together with the session key and other information in the corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED message.

KRB_CRED Message Specification

This section specifies the format of a message that can be used to send Kerberos credentials from one principal to another. It presumes that a session key has already been exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.


Previous Table of Contents Next