3.2.1.4.1.1 Using a Security Context
After a security context is built, the security context (referenced by the security context handle) can be used by the RPC runtime and higher-level protocols to perform authorization decisions. Besides using the security context for authorization decisions, the RPC runtime can also use the security context to create a logical stream of data that is protected from tampering and information disclosure on the network.
The amount of protection applied depends on the authentication level for the security context requested by the client when the security context is created. The authentication level is applied in two dimensions:
In the first dimension, the authentication level controls what capabilities the RPC runtime MUST request from the security provider when the security context is being built, as detailed in the first table that follows in this section. It is possible for a security provider to not be able to provide a certain capability. In this case, the lack of the capability MUST be considered by the RPC runtime as equivalent to the security provider returning an error and is handled as specified in the previous section.
In the second dimension, the authentication level controls how the RPC runtime MUST perform PDU protection for the different PDU segments using the security context as detailed in the second table that follows in this section.
The following table specifies the abstract capability that the RPC runtime MUST request from the security provider when the security context is being created. The capabilities are further specified in [RFC2743] section 1.2.1.2. The capabilities requested at each level include the ones requested at the previous level.
|
Authentication level |
Capability requested |
|---|---|
|
RPC_C_AUTHN_LEVEL_CONNECT |
None |
|
RPC_C_AUTHN_LEVEL_PKT |
Replay Detect |
|
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY |
Sequence Detect, Integrity |
|
RPC_C_AUTHN_LEVEL_PKT_PRIVACY |
Confidentiality |
As specified earlier in this section, once the security context is built, the RPC runtime MUST also use the authentication level to determine how the different PDU segments are protected.
Header signing is not supported in connectionless RPC.
|
Authentication level |
PDU header |
PDU body |
sec_trailer |
|---|---|---|---|
|
RPC_C_AUTHN_LEVEL_CONNECT |
None |
None |
None |
|
RPC_C_AUTHN_LEVEL_PKT |
None |
None |
None |
|
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY |
None |
Integrity |
None |
|
RPC_C_AUTHN_LEVEL_PKT_PRIVACY |
None |
Confidentiality |
None |
In the preceding table, "None" means no protection, "Integrity" means an integrity check per [RFC2743] section 2.3.1 MUST be applied, and "Confidentiality" means that the segment MUST be encrypted (conf_req_flag is TRUE per [RFC2743] section 2.3.3).
The above levels of protection can be applied through an implementation-specific equivalent of the abstract GSS_Wrap call, as specified in [RFC2743]. The receiver of a protected packed can verify the integrity of the packet or decrypted using an implementation-specific equivalent of the abstract GSS_Unwrap.
This protocol does not specify whether the authentication token itself is protected from tampering by the security provider. It also does not specify how the security provider applies integrity or confidentiality protection to a PDU segment. The algorithms for doing so are specific to the security provider. For information about a security provider, see the documentation for that security provider.