4 Architectural features

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

The overall architectural feature of Security Services is specified in 3GPP TS 32.372 [5]. This clause specifies features that are specific to the CORBA Solution.

4.1 Principles of IRP Security Services

As shown in figure 4.1, the Security Services are between IRP Application layer and Transport layer. Security Attributes which are attached to network management information are transferred between IRPManager and IRPAgent to address Authentication, Authorization, Activity Log and file integrity requirements.

Figure 4.1: Principles of IRP Security Services

The basic idea of these Security Services is as follows:

Security Services on IRPManager side and Security Services on IRPAgent side cooperate to secure the Itf-N.

When IRPManager and IRPAgent exchange network management information in a secured manner, the sender Security Service attaches Security Attributes to the network management information. The receiver analyses the received Security Attributes to determine if the received network management information is authentic and authorized.

The present document specifies two alternative CORBA solutions for attaching Security Attributes over Itf-N.
They use different CORBA mechanisms to transfer the Security Attributes. One uses The CORBA Request Interceptor while the other uses the CORBA Security Attributes Service (SAS) protocol. Both solutions need to define their respective Security Attributes.

The Security Attributes used by the Interceptor mechanism and the mechanism itself are defined by the present document.
The ones used by the CORBA SAS protocol are defined in CORBA SAS [7].

In addition to the above two alternate mechanisms, the present document also specify a third alternative called Virtual Private Network (VPN) to secure the network management information exchanged between IRPManager and IRPAgent.
Such mechanism is defined in annex A of 3GPP TS 32.371 [4].

Table 4.1 identifies the use of the three alternatives to realize the Security Service such as Authentication Security Service, Authorization Security Service, Activity Log Security Service and File Integrity Security Service.

Table 4.1: Alternate solutions and Security Service relationship

Authentication Security Service

Authorization Security Service

Activity Log Security Service

File Integrity Security Service

Request Interceptor solution

X

X

X

SAS solution

X

X

X

VPN

X

X

X

X

NOTE: "X" means that "The Security Service identified by the column name is realised by the use of Security Attributes in the solution identified by the row name.

IRPManager and IRPAgent should decide to use one of the two alternative solutions to provide Authentication, Authorization and Activity Log Security Service at configuration/deployment time, and it is not changeable at run time.

IRP Manager and IRP Agents should both support VPN.

In case CORBA-based security services are used to provide Authentication, Authorization and Activity Log Security Service, IRP Managers shall support SAS Solution and Request Interceptor Solution, while IRP Agents may support either SAS Solution or Request Interceptor Solution (it shall be noted that usage is determined at configuration/deployment time, and it is not changeable at run time).

4.2 Request Interceptor

This clause introduces concept of Request Interceptor, definitions and details are addressed in clause 21.3 of OMG CORBA Specification [7]. This CORBA mechanism can be used to transfer Credential over Itf-N.

Request Interceptor (RI) is designed to intercept the flow of a request/reply sequence through the ORB at specific points so that services can query the request information and manipulate the service contexts that are propagated between clients and servers.

In Itf-N scenario, the service context includes Credential as Security Attributes to be exchanged between IRPManager side Security Service and IRPAgent side Security Service to address Authentication, Authorization, and Activity Log requirements. There are two types of Request Interceptors: Client-side and Server-side Interceptor. Both Client-side and Server-side request Interceptors are registered with an ORB (see section 21.7, "Registering Interceptors" in [7]). Each request Interceptor is called at a number of interception points.

As shown in figure 4.2, Client-side Request Interceptor is between Client Application layer and CORBA ORB layer; it comprises 5 kinds of Interception Points described in clause 4.2.1. Server-side Request Interceptor is between Server Application layer and CORBA ORB layer; it comprises 5 kinds of Interception Points described in clause 4.2.2. Information related to request and corresponding result exchanged between Client and Server can be intercepted at these Interception points by Client-side Request Interceptor and/or Server-side Request Interceptor.

Figure 4.2: Interception points of Request Interceptor

4.2.1 Client-side Interceptor

After Client-side Interceptor is registered with ORB, Client-side Interceptor can be called at the following 5 Interception Points.

1. send_request Interception point:

  • When request is sent to the server, this interception point can be invoked by ORB to query request information and modify the service context.

2. send_poll Interception point:

  • This interception point allows an Interceptor to query information during a Time-Independent Invocation (TII) polling get reply sequence.

3. receive_reply Interception point:

  • When a reply is returned from the server and before control is returned to the client, this interception point can be invoked by ORB to query the information on the reply.

4. receive_exception Interception point:

  • When an exception occurs and before control is returned to the client, this interception point can be called by ORB to query the exception’s information before it is raised to the client.

5. receive_other Interception point:

  • This interception point allows an Interceptor to query the information available when a request results in something other than a normal reply or an exception.

4.2.2 Server-side Interceptor

After Server-side Interceptor is registered with ORB, Server-side Interceptor can be called at the following 5 Interception Points.

1. receive_request_service_contexts Interception point:

  • After all the information regarding the request are available and before the request has been invoked by the server, this interception point can be invoked by ORB to query request information.

2. receive_request Interception point:

  • After the target operation has been invoked and before the reply is returned to the client, this interception point can be invoked by ORB to query reply information and modify the reply service context.

3. send_reply Interception point:

  • After the target operation has been invoked and before the reply is returned to the client, this interception point can be invoked by ORB to query reply information and modify the reply service context.

4. send_exception Interception point:

  • When an exception occurs, this interception point can be called by ORB.

5. send_other Interception point:

  • This interception point allows an Interceptor to query the information available when a request results in something other than a normal reply or an exception.

4.2.3 Request Interceptor Security Attributes

ServiceContext is defined in CORBA specification [7], it is composed of context_id and context_data.

Credential which is contained in SecurityContext as context data is used for IRPAgent to extract authentication token and authorization token.

4.3 Security Attributes Service Protocol

This clause introduces concept of Security Attributes Service Protocol, definitions and details are addressed in clause 24.3 of OMG CORBA Specification [6]. This CORBA mechanism can be used to transfer Credential over Itf-N.

The SAS protocol is designed to exchange its protocol elements in the service context of General Inter-ORB Protocol (GIOP) request and reply messages that are communicated over a connection-based transport. The protocol is intended to be used in environments where transport layer security exists.

Two security interceptors are used by ORB to exchange Security Attribute, but neither is available on application layer:

1. Secure Invocation Interceptor. This is a message-level interceptor, which is able to check and protect messages (requests and replies) for both integrity and confidentiality.

2. Access Control Interceptor. This is a request-level interceptor, which determines whether an invocation should be permitted.

The protocol provides client authentication, delegation, and privilege functionality that may be applied to overcome corresponding deficiencies in an underlying transport.

The SAS protocol is divided into two layers:

1. The authentication layer is used to perform client authentication where sufficient authentication could not be accomplished in the transport.

2. The attribute layer may be used by a client to push (that is, deliver) security attributes (identity and privilege) to a target where they may be applied in access control decisions.

4.3.1 Security Attribute Service context element

The Security Attribute Service (SAS) context element is used to associate security related service contexts with GIOP request and reply messages.

Four message types comprise the security attribute service context management protocol. Each security attribute service context element contains a context id and a message data that carries one of the following message body types:

1. EstablishContext: Sent by a Client Security Service (CSS) to establish a security attribute service context.

2. ContextError: Sent by a Target Security Service (TSS) to indicate errors that were encountered in context creation, in the message protocol, or in use of a context.

3. CompleteEstablishContext: Sent by a Target Security Service (TSS) to indicate the outcome of a successful request to establish a security attribute service context.

4. MessageInContext: Sent by a Client Security Service (CSS) to associate request messages with an existing stateful security attribute service context. This message may also be used to indicate that the context should be discarded after processing the request. Stateful contexts, also known as reusable contexts, endure until they are discarded, and can be referenced for use with subsequent requests.

4.3.2 CORBA Security Service

Note that the OMG security service [8] has a status indicating it is being replaced by a security protocol (SECP) specification.. SECP is a work in progress.

Should an operator and vendor agree to deploy the OMG security service they should be aware of the following cautions.

  • The status of the OMG security service indicates that changes are deemed necessary due to the development of a replacement specification in SECP [9].
  • The OMG security service is known to require more processing power. This may impact the processing platform and memory requirements, leading to higher cost solutions.

IRPManager and IRPAgent access Security Attributes via CORBA Security Service.

Editor Note: OMG is defining a new OMG CORBA Security Service to replace [8].

IRPManager side CORBA Security Service authenticates IRPManager explicitly or implicitly, and returns a credential as a warrant to the IRPManager. Since then, when the authenticated IRPManager sends a request to a IRPAgent, IRPManager side CORBA Security Service will transfer the IRPManager’s credential to the target IRPAgent.
The target IRPAgent side CORBA Security Service validates the transferred Credential to accomplish IRPManager authentication. Similarly, IRPManager side CORBA Security Service may authenticate IRPAgent if required.

CORBA Security Service provides authentication service on transport layer and maybe also on application layer.