C.2 Authentication

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

The Secured Interface IRP shall be in conformance to OMG CSIv2 conformance Level 0. See clause C.5.

We recommend 3GPP to standardize two methods: the Transport Layer based method (2.1) and the Supplemental Client Authentication Layer based method (2.2). 3GPP should qualify each of them, in terms of support, in the following sense:

  • To support IRPManager authentication, a Secured Interface IRP instance shall support method 1 (2.1) or method 2 (2.2).
  • To support IRPAgent-to-IRPManager and IRPManager authentication (mutual authentication), a Secured Interface IRP instance shall support method 1.
  • The Secured Interface IRPs from a particular vendor supporting an Itf-N instance shall all have the same supported authentication method(s).

EXAMPLE: A vendor providing a secured IRPAgent including BulkCMIRP, NotificationIRP and AlarmIRP, shall implement the same set of authentication methods in the three IRPs involved.

C.2.1 Transport Layer based method

The IRPManager authentication and IRPAgent-to-IRPManager authentication shall be supported by this method. This method operates at the Transport Layer as shown in the following diagram (extracted, with modification specific for IRP context, from section 24.1.1 of [8].

In this mode, the supporting ORB and its related Transport Layer will implement the authentication method and provide the authentication security service to the IRPManager and IRPAgent applications.

Figure C.1: Protocol stack supporting CORBA secured IRP

Authentication should be accomplished by using the subject (e.g. IRPManager) identity inside a X.509 digital certificate provided to the object (e.g. the secured IRPAgent application) and vice versa.

The IRPManager must first obtain a credential (container for security attributes) containing the subject access identity only (see note 1) for use during future CORBA session in a secured IRP environment. How IRPManager can obtain a credential is outside the 3GPP standard scope.

The IRPAgent application can obtain the IRPManager’s credential at runtime by making appropriate authenticate call (non-3GPP standardized) to its local ORB interface.

Likewise, the IRPAgent application must also obtain a credential for use during future CORBA session. How IRPAgent can obtain its credential is outside the 3GPP standard scope.

The IRPManager application can obtain the IRPAgent’s credential at runtime by making appropriate authenticate call (non-3GPP standardized) to its local ORB interface.

To allow the IRPManager to authenticate received notifications, our preference is to use the following scheme.

  • The Notification IRPAgent should need another key pair (different key than one used for authentication mentioned above) for signing the notifications.
  • Notification IRPManager at notification subscription time can ask for secured (i.e. notification carries IRPAgent’s signature) or non-secured notifications (i.e. notification does not carry digital signature).
  • We would prefer the Notification IRPAgent to include its digital signature in the notifications, rather than to rely on SSL to provide authentication for notifications. This preference is to avoid the 3 or 4 protocol exchanges required at the SSL to achieve authentication for each notification sent. This preference also allows the IRPManager, if it considers the received notification is of no significance from security viewpoint, needs not spend its CPU cycles to authenticate the incoming signature.

NOTE 1: In general, credential can contain, in addition to access identity, the privilege attributes such as security role name. Our recommendation is not to use privilege attributes in credential because we propose the use of the widely supported CSIv2 conformance level 0. Unfortunately, privilege attributes are only supported in CSIv2 conformance level 1.

NOTE 2: The SSL v3.0/TLS 1.0 protocol specified by CSIv2 conformance level 0 provide strong authentication X.509 certificate based public key technology. This certificate-based authentication method operates at the transport (SSLIOP) layer and not at the higher levels of the CSIv2 stack. The PKI infrastructure and support needed for of distribution of public/private keys are limited given the small amount of participating IRPManagers and IRPAgents. One simple way to distribute keys is to store them in file, place them on disk and physically and securely shipped them to appropriate administrators for installing in their systems. Third party authorities or the operator’s own Certificate Authority (CA) can be used to certify the keys being distributed.

C.2.2 Client Authentication layer based method

To supplement IRPManager authentication offered by the Transport Layer, we recommend 3GPP to also standardize the use of the Client Authentication Tokens and Identity Tokens as defined in the CSIv2 (i.e. the so-called General Security Services Username Password (GSSUP)-based authentication method). These mechanisms operate at the Supplemental Client Authentication Layer and the Security Attribute Layer (see Figure C.1) There is no need to standardize the use of Authorization Tokens (which also operates at the Security Attribute Layer).

  • The Client Authentication Token, if used by IRPManager, is the client authentication token used by the username password (GSSUP) mechanism for client authentication. For 3GPP standard, all secured IRPAgent, supporting IRPManager authentication, shall support this method. IRPManager can choose to use or not to use it.
  • The Identity Token, if present, is an identity token used by the IRPAgent’s identity assertion functionality. It identifies the client of the request. For 3GPP standard, secured IRPAgent, may choose to use it or ignore it.

In this mode, similar to the other mode of 2.1, the supporting ORB and its related Transport Layer will implement the authentication method and provide the authentication security service to the IRPManager applications.