C.5 Quotation from OMG CORBA CSIv2 3 Conformance Levels of Security

32.3733GPPCommon Object Request Broker Architecture (CORBA) solutionSecurity services for Integration Reference Point (IRP)Telecommunication managementTS

This part is quoted from section 24.6 "Conformance Levels" of [8].

"

24.6.1 Conformance Level 0

Level 0 defines the base level of secure interoperability that all implementations are required to support. Level 0 requires support for SSL/TLS protected connections.

Level 0 implementations are also required to support username/password client authentication and identity assertion by using the service context protocol defined in this specification.

24.6.1.1 Transport-Layer Requirements

Implementations shall support the Security Attribute Service (SAS) protocol within the service context lists of GIOP request and reply messages exchanged over SSL 3.0 and TLS 1.0 protected connections.

Implementations shall also support the SAS protocol within the service context lists of GIOP request and reply messages over unprotected transports defined within IIOP. (SAS protocol elements should only be sent over unprotected transports within trusted environments.)

Required Ciphersuites

Conforming implementations are required to support both SSL 3.0 and TLS 1.0 and the mandatory TLS 1.0 ciphersuites identified in [IETF RFC 2246]. Conforming implementations are also required to support the SSL 3.0 ciphersuites corresponding to the mandatory TLS 1.0 ciphersuites. An additional set of recommended ciphersuites is identified in Section 24.4.2.1, "Recommended SSL/TLS Ciphersuites," on page 24-31.

24.6.1.2 Service Context Protocol Requirements

All implementations shall support the Security Attribute Service (SAS) context element protocol in the manner described in the following sections.

Stateless Mode

All implementations shall support the stateless CSS and stateless TSS modes of operation as defined in Section 24.3.2, "Session Semantics," on page 24-21, and in the protocol message definitions appearing in Section 24.2.2, "SAS context_data Message Body Types," on page 24-5.

Client Authentication Tokens and Mechanisms

All implementations shall support the username password (GSSUP) mechanism for client authentication as defined in Section 24.2.4.1, "Username Password GSS Mechanism (GSSUP)," on page 24-12.

Identity Tokens and Identity Assertion

All implementations shall support the identity assertion functionality defined in Section 24.3.1.1, "Context Validation," on page 24-17 and the identity token formats and functionality defined in Section 24.2.5, "Identity Token Format," on page 24-14.

All implementations shall support GSSUP mechanism specific identity tokens of type ITTPrincipalName.

Authorization Tokens (not required)

At this level of conformance, implementations are not required to be capable of including an authorization token in the SAS protocol elements they send or of interpreting such tokens if they are included in received SAS protocol elements.

The format of authorization tokens is defined in Section 24.2.3, "Authorization Token

Format," on page 24-10.

24.6.1.3 Interoperable Object References (IORs)

The security mechanism configuration of CSIv2 target objects, shall be as defined in Section 24.5.1, "Target Security Configuration," on page 24-32, with the exception that Level 0 implementations are not required to support the DelegationByClient functionality described in Section 24.5.1.1, "AssociationOptions Type," on page 24-33.

24.6.2 Conformance Level 1

Level 1 adds the following additional requirements to those of Level 0.

24.6.2.1 Authorization Tokens

Level 1 implementations shall support the push model for privilege attributes. Level 1 requires that a CSS provide clients with an ability to include an authorization token, as defined in Section 24.2.3, "Authorization Token Format," on page 24-10, in SAS EstablishContext protocol messages.

Level 1 requires that a TSS be capable of evaluating its support for a received authorization token according to the rules defined in Section 24.2.3.1, "Extensions of the IETF AC Profile for CSIv2," on page 24-11. A Level 1 TSS shall recognize the standard attributes and extensions defined in the attribute certificate profile defined in [IETF ID PKIXAC].

Level 1 requires that a target object that supports pushed privilege attributes include in its IORs the names of the privilege authorities trusted by the target object (as defined in "struct SAS_ContextSec" on page 24-40).

24.6.3 Conformance Level 2

Level 2 adds to Level 1 the following additional requirements.

24.6.3.1 Authorization-Token-Based Delegation

Level 2 adds to Level 1 a requirement that implementations support the authorizationtoken-based delegation mechanism implemented by the SAS protocol. A Level 2 TSS shall be capable of evaluating proxy rules arriving in an authorization token to determine whether an asserting entity has been endorsed (by the authority which vouched for the privilege attributes in the authorization token) to assert the identity to which the privilege attributes pertain. The semantics of the relationship between the identity token and authorization token shall be as defined in Section 24.3.1.1, "Context Validation," on page 24-17.

A Level 2 TSS shall recognize the Section 24.2.3.1, "Extensions of the IETF AC Profile for CSIv2," on page 24-11" (that is, the Proxy Info extension) as defined on that page.

Level 2 requires that a target object that accepts identity assertions based on endorsements in authorization tokens represent this support in its IORs as defined in Table 24-17 on page 24-42.

Level 2 requires that a target object that requires an endorsement to act as proxy for its callers represent this requirement in its IORs as defined in Table 24-17 on page 24-42.

24.6.4 Stateful Conformance

Implementations are differentiated not only by the conformance levels described in the preceding sections but also by whether or not they support stateful security contexts.

For an implementation to claim stateful conformance, it shall implement the stateless and stateful functionality as defined in Section 24.3.2, "Session Semantics," on page 24-21 and in Section 24.2.2, "SAS context_data Message Body Types," on page 24-5.

"

Annex D (informative):
Change history

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Cat

Old

New

Sep 2006

SA_33

SP-060556

Submitted to TSG SA#33 for Information

1.0.0

Mar 2007

SA_35

SP-070057

Submitted to TSG SA#35 for Approval

2.0.0

7.0.0

Dec 2008

SA_42

Upgrade to Release 8

7.0.0

8.0.0

Dec 2009

Update to Rel-9 version (MCC)

8.0.0

9.0.0