2.2.2.11 sec_trailer Structure
These extensions define the sec_trailer structure to have syntax equivalent to the auth_verifier_co_t structure as specified in [C706] section 12.6. The two structures have the same layout when sent on the network, but they name their fields differently and, in some cases, interpret their fields differently.
A nonzero value for the auth_length field indicates the presence of authentication information provided by the security provider. When the auth_length field is nonzero, the sec_trailer structure MUST be present.
For request and response PDUs, where the request and response PDUs are part of a fragmented request or response and authentication is requested (nonzero auth_length), the sec_trailer structure MUST be present in every fragment of the request or response.
The sec_trailer structure MUST be placed at the end of the PDU, including past stub data, when present. The sec_trailer structure MUST be 16-byte aligned with respect to the beginning of the PDU Body. Padding octets MUST be used to align the sec_trailer structure if its natural beginning is not already 16-byte aligned.
All PDUs that carry sec_trailer information share certain common fields: frag_length and auth_length. The beginning of the sec_trailer structure for each PDU MUST be calculated to start from offset (frag_length – auth_length – 8) from the beginning of the PDU.
The structure is defined as follows.
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
auth_type |
auth_level |
auth_pad_length |
auth_reserved |
||||||||||||||||||||||||||||
|
auth_context_id |
|||||||||||||||||||||||||||||||
auth_type (1 byte): MUST contain an authentication type. For information on how this is used, see sections 3.1.1.1.1, 3.3.1.5.2, and 3.1.3.1.1. If a request or response is fragmented, all PDUs from that request or response MUST have the same auth_type.
auth_level (1 byte): MUST contain one of the authentication levels as specified in section 2.2.1.1.8. The value serves a dual purpose. The first purpose is to specify what security protection is applied to what segment of the PDU, as specified in section 3.3.1.5.2. The second purpose is to serve as a parameter to the security provider that it SHOULD use to determine how to provide protection for the respective PDU segment. For information on how security providers use that, see the documentation for the respective security provider. If a request or response is fragmented, all PDUs from that request or response MUST have the same auth_level.
auth_pad_length (1 byte): The number of padding octets, used to 16-byte align the sec_trailer structure, as specified earlier in this section. In the figure "PDU structure with verification trailer" in section 2.2.2.13, these octets are referred to as the Authentication Padding Octets.
auth_reserved (1 byte): SHOULD be 0 on store, and SHOULD be ignored on read.
auth_context_id (4 bytes): Numeric identifier that uniquely identifies the security context that MUST be used for this PDU within the context of the current RPC connection. For information on security contexts, see section 3.3.1.5.4. An implementation MUST examine the drep field from the RPC PDU header to determine if this field is little-endian or big-endian, as specified in [C706] section 14.2.5. If a request or response is fragmented, all PDUs from that request or response MUST have the same auth_context_id.
Immediately after the sec_trailer structure, there MUST be a BLOB carrying the authentication information produced by the security provider. This BLOB is called the authentication token and MUST be of size auth_length. The size MUST also be equal to the length from the first octet immediately after the sec_trailer structure all the way to the end of the fragment; the two values MUST be the same. For more information on what the authentication token contains, see section 2.2.2.12.
A client or a server that (during composing of a PDU) has allocated more space for the authentication token than the security provider fills in SHOULD<37> fill in the rest of the allocated space with zero octets. These zero octets are still considered to belong to the authentication token part of the PDU.