24.5.1 Target Security Configuration

   A target that supports unprotected IIOP invocations shall specify in the corresponding TAG_INTERNET_IOP profile a nonzero port number at which the target will accept unprotected invocations.9 A target that supports only protected IIOP invocations shall specify a port number of 0 (zero) in the corresponding TAG_INTERNET_IOP profile. A target may support both protected and unprotected IIOP invocations at the same port, but it is not required to do so.

   struct IOR { string type_id; sequence <TaggedProfile> profiles = {

   ProfileId tag = TAG_INTERNET_IOP;

   struct ProfileBody_1_1 profile_data = { Version iiop_version; string host; unsigned short port; sequence <octet> object_key; sequence <IOP::TaggedComponent> components;

   };};};

   9. The OMG has registered port numbers for IIOP (683) and IIOP/SSL (684) with IANA. Although the existence of these reservations does not prescribe their use, it may be useful to recognize these port numbers as defaults for the corresponding protocols.

   A target that supports protected invocations shall describe in a CompoundSecMech structure the characteristics of each of the alternative compound security mechanisms that it supports. The CompoundSecMech structure shall be included in a list of such structures in the body of a TAG_CSI_SEC_MECH_LIST tagged component.

   sequence <IOP::TaggedComponent> components = {

   IOP::TaggedComponent { ComponentId tag = TAG_CSI_SEC_MECH_LIST; sequence <octet> component_data = {

   CSIIOP::CompoundSecMechList = { boolean stateful; CompoundSecMechanisms mechanism_list = {

   CompoundSecMech;};};};};};

   The order of occurrence of the alternative compound mechanism definitions in a TAG_CSI_SEC_MECH_LIST component indicates the target’s mechanism preference. The target prefers mechanism definitions occurring earlier in the list. An IOR profile shall contain at most one TAG_CSI_SEC_MECH_LIST tagged component. An IOR profile that contains multiple TAG_CSI_SEC_MECH_LIST tagged components is malformed and should be rejected by a client implementation.

   24.5.1.1 AssociationOptions Type

   The AssociationOptions type is an unsigned short bit mask containing the logical OR of the configured options. The properties of security mechanisms are defined in an IOR in terms of the association options supported and required by the target. A CSS shall be able to interpret the association options defined in Table 24-10.

   Table 24-10Association Options

1. A target policy that accepts only identity assertions based on forward trust cannot be communicated in an IOR (although it can be enforced).

2. If an incoming request includes an identity token and a delegation token, the request shall be rejected if the delegation token does not endorse the asserting entity (see Section 24.3.1.1, “Context Validation,? on page 24-17)

3. A target with DelegationByClient set in target_requires shall also have this bit set in target_supports. As noted in the table, this has an impact on the target’ s identity assertion policy (if any).

   The representation of supported options is used by a client to determine if a mechanism is capable of supporting the client’s security requirements. The supported association options shall be a superset of those required by the target.

   When the IdentityAssertion bit is set in target_supports, it indicates that the target accepts asserted caller identities based on trust in the authentication identity of the asserting entity. When the DelegationByClient bit is not set, the target will evaluate trust based on rules of the target (that is, a backward trust evaluation). When the IdentityAssertion and DelegationByClient bits are set, they indicate that the target is also capable of evaluating trust in an asserting entity based on trust rules delivered in an authorization token (that is, a forward trust evaluation). A target that can perform a forward trust evaluation does so when trust rules are delivered in an authorization token. Otherwise a backward trust evaluation is performed.

   When the DelegationByClient bit is set in target_requires, it indicates that the target requires a delegation token to complete the processing of a request. Such circumstances will occur when a target, acting as an intermediate, attempts to issue a request as its caller and sanctioned by the delegation token delivered by its caller.

   The rules for interpreting asserted identities in the presence or absence of a delegation token (that is, a proxy attribute contained in an authorization token) are as defined in Section 24.3.1.1, “Context Validation,? on page 24-17.

   The security mechanism configuration in an IOR being used by a CSS may (as the result of target policy administration) no longer represent the actual security mechanism configuration of the target object.

   Alternative Transport Association Options

   Implementations that choose to employ the service context protocol defined in this specification to achieve interoperability over an alternative secure transport (one other than SSL/TLS) may also be required to support the message protection options defined in Table 24-11.

   Table 24-11Alternative Transport Association Options

   24.5.1.2 Transport Address

   The TransportAddress structure indicates an INTERNET address where the TSS is listening for connection requests.

   struct TransportAddress {string host_name;unsigned short port;

   };

   typedef sequence <TransportAddress> TransportAddressList;

   The host_name field identifies the Internet host to which connection requests will be made. The host_name field shall not contain an empty string. The host_name field shall contain a host name or an IP address in standard numerical address (e.g., dotted-decimal) form.

   The port field contains the TCP/IP port number (at the specified host) where the TSS is listening for connection requests. The port number shall not be zero.

   24.5.1.3 TAG_TLS_SEC_TRANS

   An instance of the TAG_TLS_SEC_TRANS component may occur in the transport_mech field within a CompoundSecMech structure in a TAG_CSI_SEC_MECH_LIST component.

   When an instance of the TAG_TLS_SEC_TRANS component occurs in the transport_mech field of the CompoundSecMech structure, it defines the sequence of transport addresses at which the target will be listening for SSL/TLS protected invocations. The supported (target_supports) and required (target_requires) association options defined in the component shall define the transport level security characteristics of the target at the given addresses.

   const IOP::ComponentId TAG_TLS_SEC_TRANS = 36;

   struct TLS_SEC_TRANS {

   AssociationOptions target_supports;

   AssociationOptions target_requires;

   TransportAddressList addresses; };

   The addresses field provides a shorthand for defining multiple security mechanisms that differ only in their transport addresses. The addresses field shall contain at least one address.

    Table 24-12, Table 24-13 on page 24-36, Table 24-14 on page 24-37, and Table 24-15 on page 24-37 describe the association option semantics relating to the TAG_TLS_SEC_TRANS tagged component that shall be interpreted by a CSS and enforced by a TSS. The IdentityAssertion and DelegationByClient association options shall not occur in an instance of this component.

   Table 24-12Integrity Semantics

   Table 24-13Confidentiality Semantics

   1. Bulk encryption algorithms include both block and stream ciphers.

   Table 24-14EstablishTrustInTarget Semantics

   Table 24-15EstablishTrustInClient Semantics

   24.5.1.4 TAG_SECIOP_SEC_TRANS

   A tagged component with the TAG_SECIOP_SEC_TRANS tag is a valid component for the transport_mech field of the CompoundSecMech structure. The presence of this component indicates the generic use of the SECIOP protocol as a secure transport underneath the CSI mechanisms. A component tagged with this value shall contain the CDR encoding of the SECIOP_SEC_TRANS structure.

   The SECIOP_SEC_TRANS structure defines the transport addresses for SECIOP messages, the association options pertaining to the particular GSS mechanism being supported, the GSS mechanism identifier, and the target's GSS exported name.

   const IOP::ComponentId TAG_SECIOP_SEC_TRANS = 35;

   struct SECIOP_SEC_TRANS {AssociationOptions target_supports;AssociationOptions target_requires;CSI::OID mech_oid;CSI::GSS_NT_ExportedName target_name;TransportAddressList addresses;

   };

   The addresses field provides a shorthand for defining multiple security mechanisms that differ only in their transport addresses. The addresses field shall contain at least one address.

    Table 24-12 on page 24-36, Table 24-13 on page 24-36, Table 24-14 on page 24-37, and Table 24-15 on page 24-37 also describe the association option semantics relating to the TAG_SECIOP_SEC_TRANS tagged component that shall be interpreted by a CSS and enforced by a TSS.

   24.5.1.5 TAG_CSI_SEC_MECH_LIST

   This new tagged component, TAG_CSI_SEC_MECH_LIST, is used to describe support in the target for a sequence of one or more compound security mechanisms represented in the mechanism_list field of a CompoundSecMechList structure. The mechanism descriptions in the mechanism_list occur in decreasing order of target preference.

   const IOP::ComponentId TAG_CSI_SEC_MECH_LIST = 33;

   struct CompoundSecMech {AssociationOptions target_requires;IOP::TaggedComponent transport_mech;AS_ContextSec as_context_mech;SAS_ContextSec sas_context_mech;

   };

   typedef sequence <CompoundSecMech> CompoundSecMechanisms;

   struct CompoundSecMechList {boolean stateful;CompoundSecMechanisms mechanism_list;

   };

   The CompoundSecMech structure is used to describe support in the target for a compound security mechanism that may include security functionality that is realized in the transport and/or security functionality realized above the transport in service context. Where a compound security mechanism implements security functionality in the transport layer, the transport functionality shall be represented in a transport-specific component (for example, TAG_TLS_SEC_TRANS) contained in the transport_mech field of the CompoundSecMech structure. Where a compound security mechanism implements client authentication functionality in service context, the mechanism shall be represented in an AS_ContextSec structure contained in the as_context_mech field of the CompoundSecMech structure. Where a compound security mechanism supports identity assertion or supports authorization attributes delivered in service context, the mechanism shall be represented in a SAS_ContextSec structure contained in the sas_context_mech field of the CompoundSecMech structure.

   At least one of the transport_mech, as_context_mech, or sas_context_mech fields shall be configured. The TAG_NULL_TAG component shall be used in the transport_mech field to indicate that a mechanism does not implement security functionality at the transport layer. A value of “no bits set? in the target_supports field of either the as_context_mech or sas_context_mech fields shall be used to indicate that the mechanism does not implement security functionality at the corresponding layer.

   The target_requires field of the CompoundSecMech structure is used to designate a required outcome that shall be satisfied by one or more supporting (but not requiring) layers. The target_requires field also represents all the options required independently by the various layers as defined within the mechanism.

   Each compound mechanism defines a combination of layer-specific functionality that is supported by the target. A target’s mechanism configuration is the sum of the combinations defined in the individual mechanisms.

   A value of TRUE in the stateful field of the CompoundSecMechList structure indicates that the target supports the establishment of stateful or reusable SAS contexts. This field is provided to assist clients in their selection of a target that supports stateful contexts. It is also provided to sustain implementations that serialize stateful context establishment on the client side as a means to conserve precious server-side authentication capacity.10

   A TSS shall set the stateful bit to FALSE in the CompoundSecMechList structure of IORs corresponding to target objects at which it will not accept reusable security contexts.

   struct AS_ContextSec

   The AS_ContextSec structure is used in the as_context_mech field within a CompoundSecMech structure in a TAG_CSI_SEC_MECH_LIST component to describe the client authentication functionality that the target expects to be layered above the transport in service context by means of the client_authentication_token of the EstablishContext element of the SAS protocol.

   struct AS_ContextSec{

   AssociationOptions target_supports;

   AssociationOptions target_requires;

   CSI::OID client_authentication_mech;

   CSI::GSS_NT_ExportedName target_name; };

   A value of “no bits set? in the target_supports field indicates that the mechanism does not implement client authentication functionality above the transport in service context. In this case, the values present in any of the other fields in this structure are irrelevant.

   If the target_supports field indicates that the mechanism supports client authentication in service context, then the client_authentication_mech field shall contain a GSS OID that identifies the GSS mechanism that the compound mechanism supports for client authentication above the transport.

   The target uses the target_name field to make its security name and or authentication domain available to clients. This information may be required by the client to obtain or construct (depending on the mechanism) a suitable initial context token.

   10.This serialization is only done when an attempt is being made to establish a stateful context.

    Table 24-16 describes the association options that are supported by conforming implementations.

   Table 24-16EstablishTrustInClient Semantics

   When a compound mechanism that implements client authentication functionality above the transport also contains a transport mechanism (in the transport_mech field), any required association options configured in the transport component shall be interpreted as a prerequisite to satisfying the requirements of the client authentication mechanism.

   struct SAS_ContextSec

   The SAS_ContextSec structure is used in the sas_context_mech field within a CompoundSecMech structure in a TAG_CSI_SEC_MECH_LIST component to describe the security functionality that the target expects to be layered above the transport in service context by means of the identity_token and authorization_token of the EstablishContext element of the SAS service context protocol. The security functionality represented by this structure is configured as association options in the target_supports and target_requires fields.

   // The high order 20-bits of each ServiceConfigurationSyntax // constant shall contain the Vendor Minor Codeset ID (VMCID) of // the organization that defined the syntax. The low order 12 bits // shall contain the organization-scoped syntax identifier. The // high-order 20 bits of all syntaxes defined by the OMG shall // contain the VMCID allocated to the OMG (that is, 0x4F4D0).

   typedef unsigned long ServiceConfigurationSyntax;

   const ServiceConfigurationSyntax SCS_GeneralNames = CSI::OMGVMCID | 0; const ServiceConfigurationSyntax SCS_GSSExportedName = CSI::OMGVMCID | 1;

   typedef sequence <octet> ServiceSpecificName;

   // The name field of the ServiceConfiguration structure identifies // a privilege authority in the format identified in the syntax // field. If the syntax is SCS_GeneralNames, the name field // contains an ASN.1 (BER) SEQUENCE[1..MAX] OF GeneralName, as // defined by the type GeneralNames in [IETF RFC 2459]. If the // syntax is SCS_GSSExportedName, the name field contains a GSS // exported name encoded according to the rules in [IETF RFC 2743] // Section 3.2, "Mechanism-Independent Exported Name Object // Format," p. 84.

   struct ServiceConfiguration {

   ServiceConfigurationSyntax syntax;

   ServiceSpecificName name; };

   typedef sequence <ServiceConfiguration> ServiceConfigurationList;

   struct SAS_ContextSec{

   AssociationOptions target_supports;

   AssociationOptions target_requires;

   ServiceConfigurationList privilege_authorities;

   CSI::OIDList supported_naming_mechanisms;

   CSI::IdentityTokenType supported_identity_types; };

   The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. A CSS shall not be required to look beyond the first element of this sequence unless required by the first element.

   The syntax field within the ServiceConfiguration element identifies the format used to represent the authority. Two alternative formats are currently defined: an ASN.1 encoding of the GeneralNames (as defined in [IETF RFC 2459]) which identify a privilege authority, or a GSS exported name (as defined in [IETF RFC 2743] Section 3.2) encoding of the name of a privilege authority.

   The high order 20-bits of each ServiceConfigurationSyntax constant shall contain the Vendor Minor Codeset ID (VMCID) of the organization that defined the syntax. The low order 12 bits shall contain the organization-scoped syntax identifier. The high-order 20 bits of all syntaxes defined by the OMG shall contain the VMCID allocated to the OMG (that is, 0x4F4D0).

   Organizations must register their VMCIDs with the OMG before using them to define a ServiceConfigurationSyntax.

   The supported_naming_mechanisms field contains a list of GSS mechanism OIDs. A TSS shall set the value of this field to contain the GSS mechanism OIDs for which the target supports identity assertions using an identity token of type ITTPrincipalName . The Identity token types are defined in Section 24.2.5, “Identity Token Format,? on page 24-14.

   The value of the supported_identity_types field shall be the bitmapped representation of the set of identity token types supported by the target. A target always supports ITTAbsent.

   The value in supported_identity_types shall be non-zero if and only if the IdentityAssertion bit is non-zero in target_supports. The bit corresponding to the ITTPrincipalName identity token type shall be non-zero in supported_identity_types if and only if the value in supported_naming_mechanisms contains at least one element.

    Table 24-17 describes the combinations of association options that are supported by conforming implementations. Each combination in the table describes the attribute layer functionality of a target that may be defined in a mechanism definition. A target that defines multiple mechanisms may support multiple combinations.

   A compound mechanism definition with the DelegationByClient bit set shall include the name of at least one authority in the privilege_authorities field.

   When a compound mechanism configuration that defines SAS attribute layer functionality also defines client authentication layer or transport layer functionality, any required association options configured in these other layers shall be interpreted as a prerequisite to satisfying the requirements of the functionality defined in the attribute layer

   Table 24-17Attribute Layer Association Option Combinations

   24.5.1.6 TAG_NULL_TAG

   This new tagged component is used in the transport_mech field of a CompoundSecMech structure to indicate that the compound mechanism does not implement security functionality at the transport layer.

   // The body of the TAG_NULL_TAG component is a sequence of octets of// length 0.const IOP::ComponentId TAG_NULL_TAG = 34;