2.2.2.13 Verification Trailer

Within exchanges in which the security provider in use does not provide integrity protection, as specified in [C706] section 13.2.5, these extensions specify an additional provision for providing integrity protection for certain portions of PDUs. The verification trailer encompasses several data structures. The data structures MUST only appear in a request PDU, and they SHOULD be placed in the PDU immediately after the stub data but before the authentication padding octets. Therefore, for security purposes, the verification trailer is considered part of the PDU body. For a fragmented request, only the last PDU of the request MUST have a verification trailer. As a general rule, implementations SHOULD<38> add the verification trailer on request PDUs that have portions of the PDU that cannot be protected by the security provider while in transit on the network.

The following diagram shows a PDU body within a PDU structure, with stub data, verification trailer, and authentication padding octets.

Figure 3: PDU structure with verification trailer

Client implementations MAY<39> send stub padding octets after the stub data. To maximize interoperability, server implementations SHOULD NOT assume that the verification trailer immediately follows the stub data but instead SHOULD search for a sequence of octets that matches the value of the signature, as specified in section 2.2.2.13.1, starting immediately after the end of the stub data and continuing until the end of the PDU.<40>

The verification trailer consists of a header and a body. The header MUST always contain an instance of the rpc_sec_verification_trailer structure that is specified in section 2.2.2.13.1. The beginning of the header MUST be 4-byte aligned with respect to the beginning of the PDU. If the stub data does not end on a 4-byte aligned boundary, padding octets MUST be added after the stub data. The padding bytes SHOULD be set to 0.

The verification trailer header MUST be immediately followed by the verification trailer body. The verification trailer body MUST consist of, at most, one instance from each of several data structures called verification trailer commands, which are specified in sections 2.2.2.13.2, 2.2.2.13.3, and 2.2.2.13.4.

Figure 4: Verification trailer header and commands

The verification trailer commands can come in any order after the header. If more than one command is present, the next command MUST be placed immediately after the previous one. Each command MUST start with a common command header defined as the following.

0	1	2	3	4	5	6	7	8	9	1 0	1	2	3	4	5	6	7	8	9	2 0	1	2	3	4	5	6	7	8	9	3 0	1
command																length

 typedef struct {
   USHORT command;
   USHORT length;
 } SEC_VT;

command: The commands MUST be encoded by using little-endian encoding for all fields.

Valid combinations are defined immediately after the table.

Value	Meaning
SEC_VT_COMMAND_BITMASK_1 0x0001	This is an rpc_sec_vt_bitmask command, as specified in section 2.2.2.13.2.
SEC_VT_COMMAND_PCONTEXT 0x0002	This is an rpc_sec_vt_pcontext command, as specified in section 2.2.2.13.4.
SEC_VT_COMMAND_HEADER2 0x0003	This is an rpc_sec_vt_header2 command, as specified in section 2.2.2.13.3.
SEC_VT_COMMAND_END 0x4000	This flag MUST be present in the last command in the verification trailer body.
SEC_VT_MUST_PROCESS_COMMAND 0x8000	Indicates that the server MUST process this command. If the server does not support the command, it MUST reject the request.

Least significant bits 0 through 13 (including 0 and 13) are used to hold the command type and MUST be considered a single field. Bits 14 and 15 are used to indicate command processing rules. If a server does not understand a command, it MUST ignore it unless the SEC_VT_MUST_PROCESS_COMMAND bit is set. If the server does not understand the command and the SEC_VT_MUST_PROCESS_COMMAND bit is set, it MUST treat the request as invalid, as if unmarshaling failure occurred, as specified in section 3.1.3.5.2, except that a status code of 5 SHOULD be used instead of the status code specified in section 3.1.3.5.2. Any combination of a value for the command type (bits 0 through 13) and command processing rules (bits 14 and 15) is valid.

length: The length field is in octets, MUST be a multiple of 4, and MUST NOT include the length of the command header. For fixed-size commands, the length field MUST be equal to the length of the fixed-size command.