Security within TINA accounting architecture management

(1)

Security within TINA Accounting Architecture Management

A. Sekkaki

1 , 2

D. Nguessan

'Department

of

Mathematics

&

Computer science University Hassan 11, Faculty ofsciences- Ain chok P .0 Box 5366, Maarif- Casablanca. Morocco

'sekkaki@jacsc-achok.ac.

ma 2sekkaki, desirk, morvan, westphal@lrg. ufsc. br

Abstract-

TINA has been designed with the goal to offer an universal vision of telecommunications services, it answers to the increasing needs of fast developments of news services (e.g., multimedia, multi-party conference, etc.) in heterogeneous networks environments (e.g., fixe, mobile and multimedia) with interaction of several actors.

However the management context functionality (FCAPS management functions) is still an initial state of research and development.

In this paper we discuss requirements and security services for TINA management context, in particularly for TINA accounting management architecture. We propose and implement a model of security management middleware architecture, based on secure objects, cryptography and ticket distributed. To provide security services, secure objects, which have security functionality like authentication and access control, have been defined in security domain. Secure objects in our model are CORBA objects. Security domain, also called SBS ,

provides security serGces and has SMIB that contains security policies, cryptographic algorithms and other relevant information.

Key- words

:

Security, Accounting, TINA and CORBA I. INTRODUCTION

In general, the systems which are based on distributed computing environment improve efficiency and reusability of components, but they are more vulnerable to security violation than traditional systems because information are open and distributed. Therefore, systems, which are running on distributed computing environment, require security frameworks or mechanism that takes the distributed nature into account [l]. Some types of security frameworks support the security of open and distributed computing system, for example, Kerberos, POSIX, ISO7498-2. However, they do not support distributed object-oriented computing systems like CORBA (Common Object Request Broker Architecture) and TINA system (Telecommunication Information Networking Architecture)[ 131.

CORBA, is a specification for a standard object-oriented architecture that is defined by OMG (Object Management

M. D. Muller C. B. Westphall

2Network and Management Laboratory Technological Center

Federal University

of

Santa Catarina PhoneCaixa Postal 4 76

88040-970,

Floriandpolis

^-

SC

^-

Brazil

Group). CORBA enables software object to interact with each other despite their location, type of host computer or programming language. It improves system scalability, increases software reuse, ease of distribution, implementation language independence, and combines the technology of distributed computing with object-oriented The advantages of existent off-the self CORBA services, such as security, naming, messaging notification can also help accelerate application development [8]. CORJ3A still has a shortcomings when expected to operate in highly fault-tolerant real time environment, as it is expected in telecommunication systems[4]. CORBA systems may be adapted to TINA Services Architecture. In this sense, we propose a model of security management middleware architecture based on CORBA objects and integrate it to TINA. We validated the model applying it to accounting management within TINA First we present the security requirements in TINA domain. We discuss about security services and mechanisms and present security considerations in accounting. We describe the model of security based on object and integrate it to accounting in TINA. Finally, we present the conclusion of this work.

[61.

SECURITY DOMAIN

IN

TINA

In TINA, security requirements are defined for four areas:

security of telecommunications systems and service, security of management system, DPE Security (Distributed Processing Environment) and DPE security services, and security management [2].

Security of telecommunications systems and services involves the protection of network elements, networks traffic, signaling, and services. Security mechanisms in network and services ensure against toll fraud, information disclosure, a denial of services. Security of management system involves the protection of processes that are parts of management systems to provide administration, telecommunications operations, and maintenance functionality. This ensures against attacks to management systems and information transferring between management systems and network elements. DPE security involves the protection of the object deployment interoperability functionality provided by DPE.

This includes protection of object interfaces, interaction, life

(2)

cycle operations, persistence, and QoS. This can be implemented at several layers that are application, network, and transport layer[ 121. Security management is concerned with the management of security services and mechanisms for the above areas. This involves the administration of authentication information, reporting, auditing, and recovery mechanisms.

IIL SECURITY SERVICES AND MECHANISM

To provide security, it is necessary to specify security services and mechanisms. The following security services are necessary [l]:

??

.~~

Identification and authentication of principals to verify if they are who they claim to be.

Authorization and access control to decide whether a principal can access an object.

Security communication between objects, which requires the establishment of security associations, integrity and confidentiality of messages.

Non-repudiation to provide evidence of action such as proof of origin or receipt of data

Security auditing to make principals accountable for their security related actions.

Key distribution to support security services using special security mechanisms [1][11].

These security services may be implemented by a combination of security mechanisms like cryptography that provides confidentiality of other data or traffic flow information, digital signature mechanism for prevention of the deny of service or authentication of principal, access controls mechanisms to determine and enforce the access rights of the principal using access control information base.

Data integrity mechanism can determine the integrity by comparing data unit generated by the send party with the data unit generated by the receive party.

Iv. SECURITY CONSIDERATION IN ACCOUNTING The security of accounting implies: guaranteed accountability, trustful %counting, integrity of accounting information and so on

[

141. 1) Guaranteed accountability refers to the services transaction that should ideally offer a mechanism to guarantee integrity of the service. This means that “you do not pay if you do not get the agreed service”.

2) Trustful accounting - means that accounting information should be trustful. The requirement comes from the openness of TINA. An user and a server provider which is totally unknown to each other can connect by using an on-line Yellow Page or by using a trader (situation where security mechanism is urgently needed). How can user trust in the service provider and how can service provider trust in

I Human user

or

another application

the user in reverse? The first question is related more to accounting management whereas the second is related more to security management. It is similar to the case where an unknown phone company sends you an expensive bill based on questionable service usage. Openness is not necessarily a good thing unless both the user and the service provider are properly protected. Accounting information should be trustful and should be able to be recorded on both sides in an unmodifiable and non-refutable manner.

3) Integrity of accounting information should be preserved over network failures, over disruption of services, considering the service crossing over different management domains.

V. SECURITY MODEL BASED ON CORJ3A OBJECT A. Security Components

In our system, the security functions are performed by the SBS (Security Base Server). It provides an authentication service, a ticket distribution, an access control and a SMIB (Security Management Information Base). These services are implemented by CORBA objects. When a principal invokes a service on a server object, there is a request and reply interacted between them. Thus providing security services, secure objects having security functionality (Interceptor) m.ust intercept the request and the reply. The mechanism is transparent to the principal. Most of the security functions are performed by the Security Base Server during the invocation of the target object. Figure 1 presents the general architecture of the model with components of the Security Base Server.

Authentication service provides identification and authentication of the principal along

with the

authentication information which is provided by the user application and the SMIB (Security Management Information Base).

Authentication information is encrypted with a key that is generated in the principal, SBS and SI (Security Interceptor).

The user is mapped in the SMIB. An encrypted ticket is generated and sent to the user.

-

....

-..

I I

i

I

^~

Consumer;

I I

1 Retailer i

I . I

Security Management Information Base

~l t

ITicket Distribution

I I

Access Control

I

! Security Interceptor

I

i 1

~

L

._-_..._-_..---.-.--.-.--,

j

I

1

Fig.

1.

Architecture of the Security Base Server

(3)

Access control service performed by the SBS provides authorization and access control to decide whether a principal can access an object. The process is based on the client capability (principal security attributes, target control attributes, services and other relevant information that the principal can access).

Figure 2 shows a view of processes and the information flow for the authentication, authorization and ticket distributed. It also shows where interactions occur.

Fig.

2 .

Information

^Flow

for the Authentication, Authorization and Ticket Distributed.

We describe below the mechanism scenario between the security components:

1.

2.

3.

4.

5.

Initially, the User domain requests the Authentication Object to identify and authenticate the principal. Then, encrypted information like the principal identity and password are sent to the Authentication Object.

The Authentication Object decrypts the information received and it accesses to SMIB to obtain data about the principal.

The data of the principal recorded in the SMIB is sent to the Authentication Object.

The Authentication Object compares information received from the User domain with the data of the principal recorded in the SMIB. If they are equal, then the principal is who it claims to be. In this case, the Authentication Object contacts the Distributed Ticket Object.

A transaction ticket is generated by the Distributed Ticket Object and it is sent to the principal. The ticket is

the principal identity encrypted with a key known by the principal.

The principal uses the ticket as its identity to invoke (service implemented by the target object) the target object. To do any transactions, the principal needs this ticket, and the request is always encrypted.

In the retailer domain, the request of the principal is intercepted. Then the Interceptor sent one copy of the request to the Access Control Object.

The Access Control Object decrypts the information received, and it accesses to SMIB to obtain data about the principal like capability of the principal.

The data of the principal recorded in the SMIB is sent to the Access Control Object.

10. The Access Control Object verifies if the principal has rights to invoke the target object service, if it is true then it sends to the Interceptor an acknowledgement.

1 1. The Interceptor delivers the request of principal to target object.

12. The target object processes the request, encrypts the response and sends to the Interceptor.

13. Finally, the Interceptor delivers the response highly encrypted to the principal.

In our model the SBS acts as Security Manager. It controls and manages the security context of the interactions between the consumer and the retailer. The SI is a security agent factory (contact points) that aids in the access control of the services in the retailer domain, inclusive the accounting management context (AcctMgmtCtxt).

B. SBS With Accounting

The AcctMgmtCtxt has the following components:

Accountable Event Collecting

^-

it receives and collects accounting events associated with session state. TarifJing

-

it gives charging-rate as a function of the current session state, and the accumulated current charges as a function of accounting events. Billing

^-

it issues at the end of the billing period as negotiated and defined in the consumer's contract.

Usage Metering

-

during the life time of the connection the usage metering component collects and controls the data acquisition concerned with the use of network resources [6].

These components are seen by the SBS as services objects.Then they need secure transactions. The SI present in the retailer domain will intercept invocation to AcctMgmtCtxt and provide security.

Figure 3 illustrates the relation between the model (SBS) TINA Service with AcctMgmtCtxt defined in [6] and the

architecture.

The description of each one of the components can be

found in TINA Service Component Specification [7].

(4)

Security Base

7 4

I

i' Ea

f:

i:

::

..C

-

^.^.¹^.¹ ^.^.^.^.^.^.^I^.^.^.^.

CC- Connection Coordinator

CSM - Communication Session Manager SI

- Security

Interceptor

LNC - Layer Network

Coordinator

PA - Provider Agent

SBS - Security Base Server SSM ^-Service Session Manager

SUB -

Subscription

Management Component UA

- User

Agent

UAP -

User

Application

Fig.

3.

Relation Between AcctMgmtCtxt and Security Base Server

VI. OVERVIEW OF THE SECURITY BASE SERVER (SBS) AI1 requests destined for the provider are transparently intercepted by the Security Interceptor (SI) that redirects it to the SBS, to proceed the principal authorization by checking his identity and rights in SMIB. Data exchanged by the provider and the principal will be encrypted, to guarantee security in the DPE (Distributed Processing environment) like TINA. The SBS has five principal modules:

??

Authentication Management (AuthMgmt)

??

Access Control Management (AccessContMgmt)

??

Ticket Distribution (TicketDistrib)

??

Security Interceptor (SecInterceptor)

??

are described below.

Security Management Information Base (SMIB)

Each one of these modules has specific functions. They

A . Authentication Management (AuthMgmt)

In this module the first phase is to decrypt the principal information sent from the user application. In the second phase, the principal is authenticated by checking its attributes (identity and password) along with the SMIB. After being authenticated, a transaction ticket is generated by the

TicketDistrib and sent to the principal. To increase the security level the ticket is encrypted by a key (common key) known initially by the three parts (Principal, SBS and SecInterceptor).

module SBS {

exception NotAuthenticated string Decrypt ( in string CryptText, string Encrypt ( in string Text,

exception NotAuthorized{};

interface Authmgmt( l4uthentication Sentic

typedef sequence< octet > Ticket;

in string CommonKey) in string CommonKey)

Ticket Authenticate(

in string userId, in string password

)

raises( NotAuthenticated

);

public byte[] Authenticate( String userIdEncryted,

3; ...

String passWordEncrypted ) throws NotAuthenticated {

userID = Decrypt (userIdEncryted, password = Decrypt (passWordEncrypted,

CommonKey)

if( userTa ble.containsKey( userId ) &&

userTable.get( userId ).equals( password ) ) {

..

return GenerateTicket( userID,,passWord) ; else {

1 >

throw new NotAuthenticatedO;

?

Fig. 4. SBS IDL Specifications and Authenticate Implementation In all future transactions between the principal and the provider the principal uses this ticket as his identity. The ticket and some user relevant information are recorded in the SMIB for a future check. Figure 4 presents the interfaces of SBS and the implementation of the authentication service. \Ye use IDL (Interface Language Definition) to define these interfaces.

B.

Access Control Management (AccessContMgmt)

The Security Interceptor module intercepts all transactions

between the principal and the provider. It redirects principal

requests to the Access Control Management module and the

provider responses to the principal. To become these

interactions in an security context, all data exchanged are

encrypted to guarantee the confidentiality.

(5)

~~ ~

module SBS {

.. interface AccessContMgmt

{

/ / Authorisation Sen void Authorize(

in Ticket clientTicket, in Object targetobject, in s a g operationName

)

raises( NotAuthorized

);

Interface TicketDistrib

3;

{// Ticket Distributed Service Ticket GenerateTicket( in string UserId,

in string Password );

>;

>

Interface SecurityBasicServer : Authmgmt,

AccessContMgmt

void Authorize( byte[] ticket, org.omg.CORBA.Object TicketDistrib {}

object, String operationName ) throws NotAuthorized {

String userId = Decrypt( ticket );

return;

if( accessControlList.containsKey( userId )) { (String) accessControlList.get( userId );

return;

regionMatches(O,objectId,O, objectId.length() ) ) { return;

1

String allowedObjects =

if( allowedObjects.regionMatches( 0,

“*”,

0, 1 ) ) {

1

if( allowed0bjects.

throw new NotAuthorized();

1

Fig.

5.

SBS IDL Specifications and Authorize Implementation.

In the first phase, the AccesContMgmt decrypts the ticket, check his validation along with the SMIB and verifies if the principal has rights to invoke the target object service. If it is true an acknowledgement is returned to the SecInterceptor and the service is executed by the provider. Figure 5 shows the IDL specifications.

C. Ticket Distribution (TicketDistrib)

This module generates a dynamic transaction ticket to identify a principal. This ticket is encrypted with the common key using advanced cipher methods [IO] (see figure 5 ) .

D.

Security Interceptor (SecInterceptor)

Security Interceptor (SI) object resides in the retailer domain and intercepts all transactions between the principal and the provider. It gets the reference of the SBS, redirects the principal request to the Access Control Management (AccessContMgmt) module for validation and wait for an

acknowledgement. SI in the following send the request to be executed by the provider, intercepts the response, encrypts it and sent to the principal.

E. Security Management Information Base (SMIB)

This module represents the data base for the SBS. It contains access policies and principal attributes like its identity and capabilities.

w.

CONCLUSION

We discuss about security issues and describe security requirements, security services and mechanisms. We propose and implement a model of security management middleware architecture, based on secure objects, authentication, authorization, cryptography and ticket distributed. This model can be adapted to the TINA-based system and has been validated in a prototype accounting management context. The integrity and non-repudiation issues are not treated in the model and can be object of future studies.

REFERENCES

D. Nguessan., “ A Model of Security Management f o r Distributed Object, ”Master Thesis. UFSC-CPGCC.

Florianopolis, April 2000.

J.H Hahn, K.H Lee and J.C Ryou, ‘&A Model of Securiw Platform within TINA-based Management System ,”APNOMS,

16-1 8 September 1998, Sendai, Japan.

OMG, Document Number, 98-1 2-09, Security Service Specification in CORBA Services, 1998.

R. Brennan, B. Jennings, C. McArdle, and T. Curran,

“Evolutionary Trends in Intelligent Networks,” IEEE Communications Magazine, June 2000.

M. Mampaey, A.Couturier, ‘Wsing TINA Concepts for Evolution,” IEEE Communications Magazine, June 2000.

A. Sekkaki, L.M.C Alvarez, W.T Watanabe and C. B.

Westphall, “Accounting management based service environment in a TINA architecture,” To appear in IEEE ICC2001. Helsinki

-

Finland, 11-15 June 2001.

TINA-C, Service Component Specification, Version 1 .Ob, January 19, 1998 http://www.tinac.com

OMG, Document Number 98-12-09, CorbaIIOP 2.2 Specification.

P. A. Loscocco, D.S Stephen, A.M Patrick, C.T Ruth, S. Jeff and John F. Farrell, “the Inevitable ofFailure: the Flawed Assumption of Securiv in Modem Computing Environments”, In 2 1 NISSC, Virginia, October 1998.

William Stallings, Cryptography and Networks Security.

Principals andpratices, second edition.

C.M Westphall et. al, “Authorization Schemes for L a r g e a e , Systems based on Java, Corba and Web Security Models,”

ICON99, September 28 to October 1, Bisbane , Australia.

Steegmans et al., TINA Network Resource Architecture 1997 http://www. tinac.com

G. Pavlou et al., %sues in Realizing the TINA Network Resource Architecture,” Interoperable Communication Networks Joumal, vol. 2, No.1, March 1999.

TINAC-C, Accounting Management Architecture, Version: 1.3, February 1996 httn://urww.tinac.com