Previous | Table of Contents | Next |
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
Association Option |
target_supports |
target_requires |
|||
Integrity | Target supports integrity protected messages | Target requires integrity protected messages | |||
Confidentiality | Target supports privacy protected messages | Target requires privacy protected messages | |||
EstablishTrustInTarget | Target can authenticate to a client | Not applicable. This bit should never be set, and should be ignored by CSS | |||
EstablishTrustInClient | Target can authenticate a client | Target requires client authentication | |||
IdentityAssertion | Target accepts asserted caller identities based on trust in the authentication identity of the asserting entity. Target can evaluate trust based on trust rules of the target. If DelegationByClient is set, target can also evaluate trust when provided with a delegation token (that is, a proxy attribute contained in an authorization token).1 | Not applicable. This bit should never be set, and should be ignored by CSS | |||
DelegationByClient | When it occurs in conjunction with support for IdentityAssertion, this bit indicates that target can evaluate trust in an asserting entity based on a delegation token.2 | Target requires that CSS provide a delegation token that endorses the target as proxy for the client.3 |
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
Association Option |
target_supports |
target_requires |
|||
DetectReplay | Target can detect replay of requests (and request fragments) | Target requires security associations to detect replay | |||
DetectMisordering | Target can detect sequence errors of request (and request fragments) | Target requires security associations to detect message sequence errors |
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
Integrity |
Semantic |
||||
Not supported | None of the ciphersuites supported by the target designate a MAC algorithm | ||||
Supported | Target supports one or more ciphersuites that designate a MAC algorithm | ||||
Required | All the ciphersuites supported by the target designate a MAC algorithm |
Table 24-13Confidentiality Semantics
Confidentiality | Semantic | ||||
Not supported | None of the ciphersuites supported by the target designate a bulk encryption algorithm1 | ||||
Supported | Target supports one or more ciphersuites that designate a bulk encryption algorithm | ||||
Required | All the ciphersuites supported by the target designate a bulk encryption algorithm |
1. Bulk encryption algorithms include both block and stream ciphers.
Table 24-14EstablishTrustInTarget Semantics
EstablishTrustInTarget | Semantic | ||||
Not supported | None of the ciphersuites supported by the target designate a key exchange algorithm that will authenticate the target to the client | ||||
Supported | Target supports one or more ciphersuites that designate a key exchange algorithm that will authenticate the target to the client | ||||
Required | Not applicable. This bit should never be set, and should be ignored by CSS |
Table 24-15EstablishTrustInClient Semantics
EstablishTrustInClient | Semantic | ||||
Not supported | Target does not support client authentication during the handshake. Moreover, target provides no opportunity for client to authenticate in the handshake (that is, target does not send certificate request message). | ||||
Supported | Target provides client with an opportunity to authenticate in handshake. Target will accept connection if client does not authenticate. | ||||
Required | Target accepts connections only from clients who successfully authenticate in the handshake |
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
EstablishTrustInClient |
Semantic |
||||
1 | Not supported | Target does not support client authentication in service context (at this compound mechanism) | |||
2 | Supported | Target supports client authentication in service context. If a CSS does not send an initial context token (in an EstablishContext service context element), then the caller identity is obtained from the transport | |||
3 | Required | Target requires client authentication in service context. The CSS may have also authenticated in the transport, but the caller identity is obtained from the service context layer |
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
DelegationByClient |
IdentityAssertion |
Semantic |
|||
1 | Not supported | Not supported | Target does not support identity assertion (that is, identity tokens in the EstablishContext message of the SAS protocol). The caller identity will be obtained from the authentication layer(s). | ||
2 | Not supported | Supported | Target evaluates asserted caller identities based on trust rules of the target. In the absence of an asserted identity, the caller identity will be obtained from the authentication layer(s). | ||
3 | Supported | Not supported | Target accepts delegation tokens that indicate who has been endorsed to assert an identity. Target does not accept asserted caller identities. The caller identity will be obtained from the authentication layer(s). | ||
4 | Supported | Supported | Target accepts delegation tokens that indicate who has been endorsed to assert an identity. Target evaluates asserted caller identities based on trust rules of the target or based on endorsements in a delegation token. In the absence of an asserted identity, the caller identity will be obtained from the authentication layer(s). | ||
5 | Required | Not supported | Same as 3, with the addition that target requires a delegation token that endorses the target as proxy for the caller | ||
6 | Required | Supported | Same as 4, with the addition that target requires a delegation token that endorses the target as proxy for the caller |
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;