24.3.1 Compound Mechanisms

   The SAS protocol combines common authorization (security attribute) functionality with client authentication functionality and is intended to be used in conjunction with a transport-layer security mechanism, so that there may be as many as three protocol layers of security functionality. This section describes the semantics of the compound security mechanisms that may be realized using this interoperability architecture.

   The three protocol layers build on top of each other. The transport layer is at the bottom. The client authentication functionality of the SAS protocol provides a way to layer additional client authentication functionality above the transport layer. The common authorization functionality provides a way to layer security attribute functionality above the authentication layers. Any or all of the layers may be absent.

   A target describes in its IORs the CSI compound security mechanisms it supports. Each mechanism defines a combination of layer-specific security functionality supported by the target, as defined in Section 24.5.1.5, “TAG_CSI_SEC_MECH_LIST,? on page 24-38.

   The mechanisms a client uses to interact with a target shall be compatible with the target’s capabilities and sufficient to satisfy its requirements.

   7. As defined in “IETF RFC 2743? on page 24-58, “Generic Security Service Application Program Interface Version 2, Update 1?, J. Linn, January 2000.

   24.3.1.1 Context Validation

   A target indicates its requirements for client authentication in its IORs. The layers at which a CSS authenticates to a TSS shall satisfy the requirements established by the target (see the description in Section 24.5.1, “Target Security Configuration,? on page 24-32). When a CSS attempts to authenticate with a TSS using the client authentication functionality of the SAS context layer protocol (by including a client_authentication_token in an EstablishContext message), the authentication context established in the TSS will reflect the result of the service context authentication (after having satisfied the target’s requirement for transport level authentication, if any).

   If the service context authentication fails, the following shall happen:

• The request shall be rejected, whether or not authentication is required by the target.

• An exception containing a ContextError service context element shall be returned to the CSS. The ContextError service context element shall contain major and minor status codes indicating that client authentication failed.

   If the request does not include a client_authentication_token, the client authentication identity is derived from the transport layer.

   When a request includes an identity token, the TSS shall determine if the identity established as the client authentication identity is trusted to assert the identity represented in the identity token.

    A TSS that does not support authorization-token-based delegation (see Section 24.6, “Conformance Levels,? on page 24-45) shall evaluate trust by applying the client authentication identity and the asserted identity to trust rules stored at the target. We call the evaluation of trust based on rules of the target a backward trust evaluation.

   When a TSS that supports authorization-token-based delegation receives a request that includes both an identity token and an authorization token with embedded proxy attributes, the TSS shall evaluate trust by determining whether the proxy attributes were established (that is, signed) by a privilege authority acceptable to the target and whether the client authentication identity is included in the identities named in the proxy attributes. We call the evaluation of trust based on rules provided by the caller a forward trust evaluation. A TSS shall not accept requests that failed a forward trust evaluation based on a backward trust evaluation.

   A TSS shall determine that a trusted identity established in the authentication layer(s) is trusted to assert exactly the same identity (in terms of identifier value and identification mechanism) in an identity token.

   In either case of forward or backward trust evaluation, if trust is established, the context is considered correctly formed. Otherwise, the TSS shall reject the request by returning an exception containing a ContextError service context element. The ContextError element shall contain major and minor status codes indicating that the evidence was invalid.

   If a request includes an authorization token but does not include an identity token, the TSS shall ensure that the access identity named in the authorization token is the same as the client authentication identity. If the request includes an identity token, the TSS shall ensure that the access identity is the same as the identity in the identity token. A TSS that supports authorization-token-based privilege attributes shall reject any request that does not satisfy this constraint and return an exception containing a ContextError service context element. The ContextError element shall contain major and minor status codes indicating that the evidence was invalid.

   When a request includes an authorization token, it is the responsibility of the TSS to determine if the target trusts the authorities that signed the privileges in the token. A TSS that supports authorization-token-based privilege attributes shall reject any request with an authorization token that contains privilege information signed by an authority that is not trusted by the target. In this case, the TSS shall return an exception containing a ContextError service context element. The ContextError element shall contain major and minor status codes indicating that the evidence was invalid.

   24.3.1.2 Legend for Request Principal Interpretations

    This section serves as a key to the invocation scenarios represented in Table 24-3 on page 24-19, Table 24-4 on page 24-20, and Table 24-5 on page 24-21. The three tables describe the interpretation of security context information arriving at a target object from a calling object, object 2, that may have been called by another object, object 1. The authentication identity of object 2, as seen by the target object, may have been established in the transport layer, or the SAS context layer, or both. If the authentication identity was established at the transport layer it is referred to as P2A. If the authentication identity was established at the SAS context layer it is referred to as P2B. The authentication identity seen by object 2 when it is called by another object (that is, object 1) is referred to as P1, the authentication identity of object 1. No distinction is made between the transport and SAS layer authentication identities of object 1 as seen by object 2. Object 1 may also call object 2 anonymously.

   P1 is also used to represent a non-anonymous identity that may be asserted by object 2 when it calls the target object. When object 2 calls the target object, it may include an asserted identity in the form of an identity token in its SAS layer context. The asserted identity may be the anonymous identity or, a non-anonymous identity (represented by P1). When object 2 asserts an identity to the target object, it may (or may not) establish proof of its own identity by authenticating at either or both of the transport (P2A), or SAS (P2B) layers. When the target object receives a request made with an asserted identity, the target object will determine if it trusts the client authentication identity (that of object 2, or P2) acting as proxy for the asserted identity (that of object 1, or P1).

   When object 2 asserts a non-anonymous identity to the target object, it may include with its request a SAS layer authorization token containing PACs. Each PAC may include an attribute that assigns proxy to a collection of identities that are endorsed by the authority that created the PAC to assert the identity to which the privileges in the PAC apply. When the target object receives a request made with an asserted identity and an authorization token containing proxy rules, the target object will use the proxy rules to determine if it may trust the client authentication identity (P2A or P2B) as proxy for the asserted identity(P1).

   Figure 24-2 Invocation Scenarios

   24.3.1.3 Anonymous Identity Assertion

   The anonymous identity is used to represent an unauthenticated entity. To assert an anonymous caller identity, a CSS (perhaps acting as an intermediate) shall include a SAS context element containing an EstablishContext message with an identity_token containing the anonymous IdentityTokenType in its request.

   24.3.1.4 Presumed Trust

   Presumed trust is a special case of the evaluation of identity assertions by a TSS. In presumed trust, a TSS accepts identity assertions based on the fact of their occurrence and without consideration of the authentication identity of the asserting entity. The presumption is that communications are constrained such that only trusted entities are capable of asserting an identity to the TSS.

   24.3.1.5 Failed Trust Evaluations

    Table 24-3 shows the circumstances under which the interpretation of caller credentials by a TSS results in a failed trust evaluation. None of these circumstances correspond to presumed trust, where trust evaluations are not performed (and therefore cannot fail).

   Table 24-3 Conditions under which Trust Evaluation Fails

   A failed trust evaluation shall result in the request being rejected with an indication that client authentication failed.

   July 2002 CORBA, v3.0: Security Attribute Service Protocol

   24.3.1.6 Request Principal Interpretations

    The entries in Table 24-4 describe the interpretation of client credentials by a TSS after an incoming call has satisfied the target’s security requirements and has been validated by the TSS.

   Table 24-4 TSS Interpretation of Client Credentials After Validation

1. Rule 1: TSS trusts P2A to use authenticator for P2B is implied by P2B having been authenticated.

2. Rule 2: TSS presumes trust in transport to accept None, P2A, or P2B speaking for P1.

3. Rule 3: TSS trusts P2A, or P2B to speak for P1.

4. Rule 4: TSS trusts None, P2A, or P2B to speak for Anonymous. A TSS shall support the configuration of rule 4, such that Anonymous identity assertions are accepted independent of authentication of the asserter.

    The entries in Table 24-5 describe additional TSS interpretation rules to support delegation. These rules have been separated from those in Table 24-4 on page 24-20, because they describe functionality required of implementations that conform to a higher level of secure interoperability as defined in Section 24.6.3, “Conformance Level 2,? on page 24-47. The entries in Table 24-5 correspond to invocations that carry an identity token and an authorization token with embedded delegation token (that is, a proxy endorsement attribute) in an EstablishContext service context element. Invocations that do not carry all of these tokens are represented in Table 24-4.

   An authorization token may contain authorization elements that contain proxy statements, which endorse principals to proxy for other entities. Table 24-5 describes delegation scenarios in which endorsements from the issuer of the authorization element authorize the authenticated identity, which is P2A or P2B, to proxy for the asserted identity. In this table, the column “Proxies Named in Authorization Element? defines the identities who are endorsed by the authorization element to proxy for P1, the asserted identity and the subject of the authorization element. The value “Any? indicates that the authorization element contains a blanket endorsement, such that as far as its issuer is concerned, any identity may proxy for P1. The outcomes described in Table 24-5 assume that the TSS trusts the issuer of the authorization element to endorse principals to proxy for others.

   Table 24-5 Additional TSS Rules to Support Delegation