7.6 Security Management

32.1013GPPPrinciples and high level requirementsRelease 17Telecommunication managementTS

7.6.1 Overview

This clause describes an architecture for security management of the TMN that is divided into two layers, as shown in figure 7. No individual layer is dependent on any specific technology in the other one.

Figure 7: Security Management architecture

7.6.1.1 Layer B – OAM&P Transport IP Network

Some Service Providers might build their OAM&P transport network as a completely private, trusted network. In the normal case though, the OAM&P transport network should be regarded as partly insecure due to its size, complexity, limited physical security and possible remote access from dial-up connections or from the Internet. The only security service provided then is that the OAM&P transport network when based on IP is logically separated from the Internet. For IP based transports infrastructure aspects on security are handled to the extent possible utilizing IP classic features (addressing schemes, DNS, DHCP, BOOTP, protection with firewalls etc.).

Additionally, a trusted IP-environment to the application level might be provided, e.g. an environment with no masquerading IP-hosts and where potential intruders cannot communicate. One way to accomplish such a secure DCN is to use IP security mechanisms (IPSec; see IETF RFC 2401 [7]) to achieve authentication of IP hosts (servers, gateways, Network Elements) and optional encryption of OAM&P traffic. Note however that the secure DCN does not authenticate users.

7.6.1.2 Layer A – Application Layer

On this layer we find Telecom Management applications performing their tasks in the normal management functional areas. Managed objects residing in the network resources are often accessed or manipulated.

Layer A provides authentication of users ensuring that every party involved in OAM&P traffic is securely authenticated against every other party. The implementation of the authentication service supports "single log-on" (a user only has to log-on once to get access to all OAM&P applications in the network) and "single point of administration" (an administrator only needs to maintain a user and his/her profile in one place).

Layer A also provides authorization (access control) – to verify if a user is authorized to perform a certain operation upon a specified target object at a given time. In addition, it addresses the use of signing and logging of events. Logging of events here means "logging of actions" (not necessarily logging of ALL actions) to be able to check "who did what". At least all "critical" actions (configurations etc.) should be logged.

Interface definitions addressing authentication and authorization are needed. Also note that layer A requires confidentiality. Layer B may provide this service. If not, layer A instead has to provide it itself.

7.6.1.3 Common Services

In common services we find the security infrastructure components:

– Directory (for storage of user information, certificates, etc.);

– PKI (Certificate Authority, Registration Authority, Public Key Certificate, etc.).

Layer A relies on, and interacts with, the Common Services through distribution of certificates and keys, authentication of users, authorization, utilities for security administration (setting access rights), etc.

NOTE: Layer B does not necessarily interact with Common Services for security management purposes.
The arrows in figure 7 simply indicate the possible use of common services for Configuration Management.