|
Previous | Table of Contents | Next |
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, -- senders addr r-address[5] HostAddress OPTIONAL -- recips addr }
Table 9.10 describes the fields for this message.
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 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 systems report of the senders address matches the senders address in the message.
Next it checks that one of the recipients addresses appears as the recipients 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.
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 |