Extending TINA with Secure On-Line Accounting Services
Carlos Becker Westphall,1,3Abderrahim Sekkaki,2
Luis Marco C´aceres Alvarez,1and Wagner Tatsuya Watanabe1
Concepts and principles of TINA (Telecommunications Information Networking Ar- chitecture) are introduced with the objective of correcting problems of the current cen- tralized service control and service data model in an IN (Intelligent Network). It is becoming increasingly clear that the future sophisticated telecommunication services, e.g., multimedia, and multi-party conferencing, breaking away from the traditional tele- phony call model will need the solutions for rapid and efficient introduction, deployment, operations, and management.
In this paper, we discuss accounting features and requirements, as well as security services in the TINA management context. We will introduce and present an implemen- tation of a model for a security management, based on secure objects, cryptography and certificate distribution. In order to provide secure services, secure objects that have security functionality, such as authentication and access control, have been defined. Se- cure objects in our model are CORBA objects. The security domain is also called SBS (Security Base Server), provides security services and has an SMIB (Security Manage- ment Information Base) that contains security policies, cryptographic algorithms, and other relevant information. A prototype has been implemented and some experimental results are presented.
KEY WORDS: TINA; accounting management; security of accounting; CORBA;
SBS; SMIB.
1. INTRODUCTION
Telecommunications Information Networking Architecture (TINA) is one of the most comprehensive information networking architecture that is used as a
1Network and Management Laboratory. Post-Graduate Program in Computer Science. Technological Center. Federal University of Santa Catarina. Caixa Postal 476. 88040-970, Florian´opolis, SC – Brazil.
E-mail:{westphal,caceres,wagner}@lrg.ufsc.br
2Department of Mathematics and Computer Science, Faculty of Science – Ain Chock, Hassan II University, Casablanca, Marocco. E-mail: sekakki@facsc-achok.ac.ma
3To whom correspondence should be addressed.
379
1064-7570/03/1200-0379/0°C2003 Plenum Publishing Corporation
foundation for building various telecommunication service infrastructures. This is mainly due to one of the TINAs assumptions which is based on the presence of the DPE (Distributed Processing Environment) and CORBA (Common Object Request Broker Architecture) as the signaling infrastructure. Services in TINA are carried out as distributed applications and are provided within a distributed computing environment.
TINA has defined the Network Resource Architecture (NRA) [1] that cov- ers the areas of connection, configuration, fault, and accounting management.
Some management areas have been defined in great detail, e.g., connection man- agement [2], while some other areas have only started to be. For example, fault management and accounting management architecture [3]; and some are not yet defined at all, e.g., performance management. Security management is also not yet fully addressed in TINA. Hence, we have been working on the framework of the TINA accounting management architecture as one of service management areas that is an indispensable part of all the TINA services. We also discuss the relevance of accounting management security and how to protect the accounting information.
This paper is organized as follows: Section 2 presents a TINA overview, including service architecture, service management, and TINA accounting archi- tecture. Section 3 describes the main components of TINA accounting manage- ment and their features. Section 4 discusses security services and mechanisms, and presents security considerations associated with accounting. Section 5 proposes a security model and describes the development of a prototype based on the pro- posed security model and the TINA accounting management architecture. Finally, the conclusions and suggested future work are given in Section 6.
2. TINA OVERVIEW
2.1. TINA Service Architecture
TINA defines a flexible architecture that consists of several modeling con- cepts and specifications. Besides the service architecture [4], the main specifica- tions involve the business model [5], the computational model, and the service component [6]. Figure 1 shows a simplified view of the business model and the computational model based on the TINA specification.
In the business model, the participants (stakeholders) in a service are catego- rized in five groups according to the roles they play in the service. The roles defined within TINA are Consumer, Retailer, Third Party Service Provider, Connectivity Provider, and Broker (not shown in Fig. 1). The Broker and the Third Party Service Provider roles have not been described in detail in TINA. The Consumer, Retailer, and Connectivity Provider roles, however, have been specified in TINA with suf- ficient detail, including the interface between them, defined as Reference Points.
Fig. 1. Overview of TINA Service Architecture.
The most important reference point for service management is the Ret-Reference Point [7] defined between the Consumer and the Retailer.
The TINA service architecture also defines two types of sessions: the access and the service sessions. The access session is responsible for the identification and authentication of the user. It is also used to search for available services and to execute the services by creating a service session. The service session is responsible for managing the service condition. It also creates and controls stream bindings, which are an abstract representation of end-to-end connection among applications.
The functionality of the service session is defined by a number of functional groups called Feature Sets. The Feature Sets carry out various functions, such as: joining a service, inviting parties in the service session, establishing stream connectivity requirements, issuing voting, etc. These functions are grouped into the Feature Sets, such as ‘basic,’ ‘multi-party,’ ‘stream-binding,’ ‘voting,’ etc.
A subscription subsystem and a subscription information model defined in TINA enable a user to discover new services and eventually subscribe to them.
This is independent of the used access technology, because end-users require more and more flexibility, and must have the ability to activate and deactivate a service subscription for themselves, and to alter the related profiles [8].
2.2. TINA Service Management
Service management is a very broad discipline and it is also an important part of the TINA service architecture. It involves management functions in TINA ser- vice architecture. It controls end-to-end transactions for TINA services to provide FCAPS properties dictated by binding management contexts [9]. There are four conceptual axes associated with TINA service management:
r Partitioning axis: TINA is partitioned into three layers (service, resource, and DPE).
r Functional axis: is represented most notably by FCAPS (Fault, Config- uration, Accounting, Performance, Security “management”) functions to support the FCAPS integrity of a service session. Constructs such as man- agement context and service transaction are provided.
r Computational axis: represents computational support for management needs.
r Life cycle axis: represents the life cycle issues, including service life cycle management and user (consumer) life cycle management.
To develop the management functions on a DPE (Distributed Processing Environment) platform, referring to the existing standards such ITU-T/TMN and ISO/ODP (Open Distributed Processing), TINA uses a common object interface description language (IDL or ODL). It uses also the Network Resource Information Model (NRIM), that enables us to describe systematically the network management information using unified abstract models of network resources [10].
2.3. TINA Accounting Architecture
In addition to the existing standards such as X.742 [11] and of the different works achieved on enriching the OSIMIS (OSI Management Information Service) platform with a structure supporting the developments of accounting applications [12], TINA dedicated one document to this topic [3]. Hellemans et al. [13] have also presented an “Accounting Management in a TINA-Based Service and Network Environment.” But on-line charging is still unresolved problem. This paper will present a solution for TINA on-line billing.
TINA accounting management consists of four cycles, namely: Metering, Classification, Tariffing, and Billing. It introduces a concept of Accounting Man- agement Context (AcctMgmtCtxt) associated with a Service Transaction (ST). The purpose ofAcctMgmtCtxtis to guarantee that accountability can be preserved through a set of activities of distributed objects, which constitute the service. We want to emphasize that accountability is not a property or an attribute of a single object. It is rather a set of quantities measured or calculated over a set of activities of the distributed objects throughout the service. When a ST is activated by a Service
Session Manager (SSM), itsAcctMgmtCtxtis interpreted in accordance with its Session Component description (unit of service to be accounted for) with the tar- iff structure within the SSM component. Then, the SSM passes the control and necessary parameters to the resource or computational level mechanism such as Communication Session Manager (CSM), notification server, metering managers and service management.
A Session Component (SC) is not necessarily an object, but rather a compo- nent that constitutes a session covered by a Service Transaction, and the SC itself is divided into various events. It is introduced in order to respond to dynamic and distributed accounting needs.
The Service Transaction (ST) process consists of three phases:
r Set-up phase: This is a phase of negotiation between the user and the provider (e.g., Tariff structure, etc.). The agreed scheme is submitted as AcctMgmtCtxtof the ST.
r Execution phase: The service is being offered to the user, as it was specified in the first phase. The description of information of the service session is specified as a part ofAcctMgmtCtxt.
r Wrap-up phase: The service is concluded. Account record or charging information may be sent to the user at the conclusion of the transaction, if specified inAcctMgmtCtxt.
3. TINA ACCOUNTING MANAGEMENT ARCHITECTURE
An extension to the OSIMIS management platform through implementing the OSIs Usage Metering Function has been developed and validated [12]. This function specifies generic managed objects, that are supporting the construction of OSI applications involving accounting activities. The work presented in this paper continues activities performed in the Network and Management Laboratory of the Federal University of Santa Catarina, on TINA and on-line billing.
3.1. Architectural Model
Figure 2 shows the architectural model of TINA accounting management with the interactions between the main components of the TINA services. The TINAAcctMgmtCtxtconsists of a set of components, covering different aspects of service and network control and management. These components are briefly described here.
3.1.1. The Accountable Event Collecting Component
The Accountable Events Collecting component receives, collects and collates the accounting events associated with the Session Components’ status and state changes, and the events associated with the billing information generated by the SSM. It is divided into two modules: EventManagememt and SessionComponent.
Fig. 2. Architectural Model.
3.1.2. The Tariffing Component
Two different modules represent the Tariffing component in TINA AcctMgmtCtxt:
r Recovery Module gives a charging-rate as a function of the current Session State. It also converts the collected accountable events into a charging record and stores it in the charging record database. In addition, it allows the restoration of the data when a failure occurs in the service.
r Tariff Module gives accumulated current charges. It calculates the tariff using the charging formula according to the contract and stores it in the billing record.
3.1.3. The Billing Component
The billing component may be automatically performed at the end of a billing period as negotiated and defined in the customer contract. It generates a bill based on the charging information contained in the billing records. There are four billing configurations: On-line charging, Shared billing, Third-party billing, and Credit- debit billing. The implementation of the billing application in the discussed pro- totype is configured based on on-line charging.
3.1.4. The Usage Metering Component
During the lifetime of the connection, the usage-metering component collects and controls data acquisition concerned with the utilization of network resources generated by the LNC (Layer Network Coordinator). It also registers the collected data for future processing, like fault and performance management.
Fig. 3. Definition theAcctMgmtCtxtComponents [16].
3.2. Implementation of theAcctMgmtCtxtComponents
The presented implementation uses the CORBA objects of Visibroker 3.04 [14]. The objects are defined as interfaces in IDL, so that they can access and be accessed by any other CORBA object regardless of the programming language [15]. The definitions of theAccMgmtCtxtcomponents in IDL are presented in Fig. 3.
Building of IDL specifications enables the creation of the inter-object inter- face. There are three data-bases that store defined IDLs: TheSubscripInfo.mdb data-base that defines the subscription user; TheTariffInfo.mdbdata-base that registers the events of the Tariffing component while the service is carried out; and TheBillingInfo.mdbdata-base that defines the charging-billing of the user.
TheAcctMgmtCtxtis the most important component of the accounting ser- vice. It is generated in the set-up phase of the ST and it is destroyed when the Service Transaction is concluded. The interface SessionComponent is used for controlling and managing the SC (Session Component), as also for starting and terminating metering actions in the accounting object. The SC refers to a service rendered to the specified user. The EventManagement component implements the event management functions, e.g., event delivery.
In order to test the proposed accounting service architecture we implemented in our prototype a pilot “digital-video-audio conference” session between the users and a provider. The components, forming part of the session are extended to generate accountable events for theAcctMgmtCtxtcomponents, and allow each consumer to retrieve on-line billing information concerning an ongoing shared service session. The pilot session is supported by a graphical interface (see Fig. 4),
Fig. 4. Graphical Interface.
which is subdivided into the following modules:
– Subscription: login as a known user, authentication and verification of the user credentials, and display of the user information.
– Up-date Subscription: up-dating of user information (Insert, Modify, Delete, etc).
– Monitoring service: display the video conference session for each user.
– Error messages: show the errors.
4. SECURITY DOMAIN IN TINA
In TINA, security requirements are defined for four areas: Security of Telecom- munications Systems and Services, Security of the Management System, DPE Security (Distributed Processing Environment) and DPE Security Services, and Security Management [17].
Security of Telecommunications Systems and Services involves the protec- tion of the network elements, network traffic, signaling network, and network services. Security mechanisms in network and services ensure against toll fraud, information disclosure and a denial of services. Security management involves the protection of processes that are part of the management systems to provide ad- ministration, telecommunications operations, and maintenance functionality. The
security system protects the management systems against attacks and ensures safe information transferring between management systems and the network elements.
DPE security involves the protection of the object deployment interoperability functionality provided by DPE. It includes protection of object interfaces, interac- tion, life cycle operations, persistence, and QoS. It can be implemented on several layers, namely on the application, network, and transport layers. Security manage- ment is concerned with the management of security services and mechanisms for these above areas. It involves authentication of the information, reporting, audit- ing, and recovery mechanisms. In order to provide the required security, several securities related services and mechanisms must be defined.
4.1. Security Services and Mechanisms
In order to provide security, it is necessary to specify security services and mechanisms. The following security services are required [18]:
r Identification and authentication of principals (human user or another ap- plication) to verify whether they are who they claim to be.
r Authorization and access control to decide whether a principal can access an object.
r Security communication between objects, requires the establishment of security associations, integrity, and confidentiality of messages.
r Nonrepudiation to provide evidence of action such as proof of origin or receipt of data.
r Security auditing to make principals accountable for their security-related actions.
r Key distribution to support security services using special security mech- anisms.
These security services may be implemented by a combination of security mechanisms, such as cryptography that provides confidentiality of other data or traffic flow information, digital signature mechanism to prevent the denial of ser- vice or to authenticate the principal. Access controls mechanisms can be used to determine and enforce the access rights of the principal using an access control information base, a data integrity mechanism that can determine the integrity by comparing the data unit generated by the sending party with the data unit gen- erated by the receiving party. The goal is to present a new model for security management.
4.2. Security of TINA Accounting Management
Security is an essential and natural part of distributed systems, and of course, accounting is no exception. Security of accounting implies the following: guaranteed accountability, reliable accounting, and integrity of the
accounting information.
r Guaranteed accountability refers to the service 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.”
r Reliable accounting means that accounting information should be assured.
The requirement comes from the openness of TINA. Openness is not nec- essarily a good thing unless both the user and the service provider are properly protected. Accounting information must be reliable and there must be a way of recording it on both sides in an unmodifiable and ir- refutable manner.
Integrity of accounting information implies that such integrity is to be preserved over network failures and over disruption of services.
4.3. The Proposed and Implemented Security Model 4.3.1. Security Components
In our system, the security functions are performed by the SBS (Security Base Server) [19], see Fig. 5. It provides an authentication service, a ticket distribution, an access control, and a SMIB (Security Management Information Base). These services are implemented via CORBA objects [22]. When a principal invokes a service on a server object, there is a request and a reply interacted between them.
This provides a security service, so those secure objects have security functionality using the Security Interceptor (SI) module to intercept the request and the reply.
The mechanism is transparent to the principal. The Security Base Server during the invocation of the target object performs most of the security functions. Figure 5 presents the general architecture of the model with components of the Security Base Server.
The authentication service provides identification and authentication of the principal, along with the authentication information provided by the user
Fig. 5. Architecture of the Security Base Server.
Fig. 6. Information Flow for the Authentication, Authorization and Ticket Distribution.
application and the SMIB (Security Management Information Base). The infor- mation is encrypted with a key that is generated by the client SBS and SI (Security Interceptor). The user is then mapped into the SMIB. An encrypted ticket is gen- erated and sent to the user.
The access control service is performed by the SBS, and provides authoriza- tion and access control functions in order to decide whether a principal can access an object or not. The process is based on the client’s capability (principal security attributes, target control attributes, services and other relevant information that principal can access).
Figure 6 shows a view of the security processes and the information flow for the authentication, authorization, and distributed ticket. It also shows where interactions occur.
The scenario of secure communications among the security components are described here:
1. Initially, the user domain requests the Authentication Object to identify and authenticate the principal. Then encrypted information, such as identity and password of the principal is sent to the user.
2. The Authentication Object decrypts the information received and then accesses SMIB to obtain data about the principal.
3. The data of the principal recorded in the SMIB is sent to the Authentication Object.
4. The Authentication Object compares information received from the User domain with the data of the principal recorded in the SMIB. If they are identical, then the principal is who it claims to be. In this case, the Authentication Object contacts the Distributed Ticket Object.
5. A transaction ticket is generated by the Distributed Ticket Object and sent to the principal. The ticket is the main identity encrypted with a key known by the principal.
6. The principal uses the ticket as identity to call for service implemented by the target object. To perform any transactions, the principal needs this ticket, and the request is always encrypted.
7. In the retailer domain, the principal’s request is intercepted. Then the Inter- ceptor sends one copy of the request to the Access Control Object.
8. The Access Control Object decrypts the received information and accesses the SMIB to obtain data about the principal.
9. The data of the principal recorded in the SMIB is sent to the Access Control Object.
10. The Access Control Object verifies whether the principal has rights to invoke the target object service; if so, it sends an acknowledgment to the Interceptor.
11. The Interceptor delivers the principal’s request to the target object.
12. The target object processes the request and sends an encrypted response to the Interceptor.
13. Finally, the Interceptor delivers the highly encrypted response to the principal.
In the presented model, the SBS acts as a Security Manager. It controls and manages the security context of the interactions between the consumer and the retailer. The Security Interceptor (SI) is a security agent factory that helps the access control of the service in the retailer domain, including theAcctMgmtCtxt.
4.3.2. Overview of the Security Base Server
All requests destined to the provider are transparently intercepted by the Security Interceptor (SI) that redirects it to the SBS, in order to check the principal authorization by verifying the principal identity in the SMIB. Data exchanged by the provider and the principal will be encrypted to guarantee security in DPE. The SBS has five principal modules:
a. Authentication Management (AuthMgmt)
In this module the first phase is to decrypt the principal information sent from the user application. During the second phase by checking the attributes (identity and password) the principal is authenticated 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).
In all future transactions between the principal and the provider, the principal uses this ticket as its identity. The ticket and some user-relevant information are recorded in the SMIB for a future check. The following squares show the interfaces
of SBS and the implementation of the authentication service. We use IDL (Interface Language Definition) to define these interfaces.
b. Access Control Management (AccessContMgmt)
The Security Interceptor module intercepts all transactions between the prin- cipal and the provider. It redirects principal requests to the Access Control Manage- ment module and the provider responses to the principal. To take these interactions in a security context, all data exchanged are encrypted to guarantee confidentiality.
In the first phase, the AccesContMgmt decrypts the ticket, checks its valida- tion along with the SMIB and verifies whether the principal has the right to invoke the target object service. If so, an acknowledgment is returned to the SecInterceptor and the provider executes the service. The following shows the IDL specifications of the Access Control Management Object.
c. Ticket Distribution (TicketDistrib)
This module basically generates a dynamic transaction ticket to identify a principal. This ticket is encrypted with the common key using advanced cipher
methods [18, 19].
d. Security Management Information Base (SMIB)
This module represents the database for the SBS. It contains access polices and the principal’s attributes, such as identity and capabilities, i.e., objects and services that a principal can access.
e. Security Interceptor (SecInterceptor)
A Security Interceptor (SI) object resides in the retailer domain and inter- cepts all transactions between the principal and the provider. It gets the reference of the SBS, redirects the principal request to the Access Control Management (AccContMgmt) module for validation and waits for an acknowledgment. The SI then sends the request to be executed by the provider, intercepts the response, encrypts it and sends it to the principal.
5. THE DESCRIPTION AND VISUALIZATION OF THE PROTOTYPE 5.1. Description Mechanism
The prototype is divided into two phases: subscription phase and monitoring phase [16].
a. The Subscription Phase
r The prototype begins a service when requested by the user (module Ser- vice, click button “Start” in Fig. 4) who logs in, entering his/her Id and password (module Subscription in Fig. 4).
r A verification (access to database “SubscripInfo.mdb”) and an authenti- cation are immediately carried out through the security management (SBS in Fig. 5). The authorized user presents himself/herself under one of two types:
1. The user client who has a contract with the provider utilizes the full service uses, i.e., audio (speaking-listening), and video (vision-image), or “ A+V ”.
2. The user who does not have a contract with the provider utilizes only a partial service and is seen as an Audio participant. The new user will be registered in the database (module Up-Date: “Add New User” in Fig.
4) to assure that his/her amount of available credit is enough to make use of the service. If not, the system will deny the use of the service, and will log the user out.
Notice that the security mechanism is present during a session process- ing. All requests destined to the provider are transparently intercepted by the Security Interceptor (SI) that redirects it to SBS (see Fig. 5), making possible the principal authorization by checking its (his/her) identity and rights in SMIB [17].
b. The Monitoring Phase
r For each user authorized, the properAcctMgmtCtxtis created, starting the service (module Service, click button “Enter” in Fig. 4).
r Automatically theAcctMgmtCtxtcreates the objects (interface Session- Component and interface EventManagement) that identify the manage- ment events during the execution.
At the same time, a Session State Vector is generated (SSVec) where each position registers the information relating the service events:
(1) Initial time (it);
(2) Final time (ft);
(3) Accumulated time “full service use” A+V (fs) or “partial service use” (ps); and
(4) Accumulated time “shared service use” of the users (ts).
r Click on button “Enter”, the “it” is initialized while activating “fs” or “ps”.
The vector is seen as a dynamic and volatile structure that enables any failure that occurs during the service to be registered as information in the database. The backup is necessary to store the information (events) in the database (“TariffInfo.mdb”) because its interaction with module Tariffing (interface Tariff) is periodic.
r During the service period, the provider must make sure that the time spent by the user does not exceed 80% of the available limit. If this occurs, the provider must notify the user and ask him/her if he/she wishes to
modify his/her available quota (module Up-Date: “Change Max Amount”
in Fig. 4), or to log-out of the service (activate the interface Billing for its charging).
r The user who makes use of the service can leave the session (module Service, click button “Leave” in Fig. 4). At this moment, the user is in the auditing (A) state. He/she also has the option of starting the service again (module Service, click button “Enter” in Fig. 4) or of ending of session (module Service, click button “Stop” in Fig. 4).
r The option also exists for several users to share the service at the same time. This takes place when the button “Enter” is activated and it, in turn, activates “ts” and stop “fs”. To leave the shared state, click button “Leave”
to active “fs”, or click the button “Stop” to quit.
r If the user is in the state “Stop,” the timers are deactivated, and “ft” is reg- istered. Finally, on-line charging (interface Billing) is activated for the service supplied to the user and the information is stored in database (“BillingInfo.mdb”). See Fig. 7.
r An important part of the service takes place when there is a failure. For example, events are lost during the session owing to the loss of timer synchronization, when accounting SC state is interrupted for failed node, due to loss of energy, etc. At such a time, interface Recovery stores and saves the information in a database (“TariffInfo.mdb”).
r If it occurs (in the case of the user), the session restarts and the timers continue with the accounting of the events, or the session stops (to quit a failure window, click “X”, and “Start” to continue in Fig. 4).
5.2. Scenario of Execution
In Fig. 7 we consider three users who share the same session of “multi-party conferencing service” provided by the Retailer. Each user has his/her own graphical interface “Client”, that defines the Accounting Management Context, allowing the
Fig. 7. Example Scenario.
management of the available resources in the session to start, as described in Section 5.1.
When the session is finished, the graphical interface “Billing” is displayed, showing the on-line charging of the service supplied to the Retailer.
The users have three options of access to the service according to their con- tracts: V (Video+Audio), A (Audio) and S (Video+Audio Shared). The use of the “V option” costs 3$/unit, the “A option” costs 1$/unit and the “S option” costs 2$/unit.
6. CONCLUSIONS
CORBA facilities and services offer an interface set that makes possible the construction of TINA service management. This paper has provided an overview of the TINA concepts, specifying the accounting management context. We described
accounting features, requirements, and some accounting issues. Then, we have proposed an integration between the accounting management architecture and the security of TINA accounting management. In order to execute our model, we described the accounting components and their roles and interactions to accomplish the accounting functionality. We described a prototype in TINA-based service environment that uses on-line billing.
The contribution of our work through the prototype shows that the available resources of the service could be assured, safely and efficiently. Our work in the reference [23] presents the formal description and verification of the Accounting Model of TINA architecture, complementing this paper.
In the future it will be necessary to implement a model that includes fault and performance management, in addition to management accounting and security.
The security model considering authorization could be improved using RBAC (Role-Based Access Control) [24].
REFERENCES
1. F. Steegmans, TINA network resource architecture, TINA-C, http://www.tinac.com, 1997.
2. G. Pavlou and D. Griffin, Realizing TMN-like management services in TINA, Journal of Network and Systems Management, Vol. 5, No. 4, pp. 437–457, December 1997.
3. T. Hamada, Accounting management architecture, TINA-C, http://www.tinac.com, 1996.
4. L. Kristiansen, TINA service architecture 5.0, TINA-C, http://www.tinac.com, 1997.
5. M. Yates, W. Takita, L. Demoudem, R. Jansson, and H. Mulder, TINA business model and reference points, TINA-C, http://www.tinac.com, 1997.
6. P. Farley, TINA retailer reference point specification, Version 1.0, TINA-C, http://www.tinac.com, 1998.
7. C. Abarca, TINA service component specification, Version 1.0b, TINA-C, http://www.tinac.com, 1998.
8. M. Pampaey and A. Couturier, Using TINA concepts for IN evolution, IEEE Communication Magazine, June 2000.
9. Journal of Network and Systems Management, Special Issue on Telecommunications Information Networking Architecture (TINA), Leith Campbell, Harm Mulder, and Juan Pavon, Guest Eds. Vol.
5. No. 4, December 1997.
10. N. Natarajan, H. Flinck, and R. Rosli, TINA network resource information model specification, TINA-C, http://www.tinac.com, 1997.
11. ITU-T Recommendation X.742, Information Technology—Open Systems Interconnection—
Systems management: Accounting meter function, July 1994.
12. L. F. Kormann, C. B. Westphall, and A. Coser, OSI usage metering function for OSIMIS manage- ment platform, Journal of Network and Systems Management, Vol. 4, No. 3, 1996.
13. P. Hellemans, K. Daenen, C. Redmond, and D. Lewis, Accounting management in a TINA-based service and network environment, Sixth International Conference on Intelligence in Services and Networks, (IS&N’99), Barcelona, April 1999.
14. Visibroker 3.04 http://www.inprise.com.
15. Object Management Group. The Common Object Request Broker Architecture 2.0/IIOP—
Specification Revision 2.0—OMG Document, August 1996.
16. A. Sekkaki, L. C. Alvarez, W. T. Watanabe, and C. B. Westphall, Accounting management based service in a TINA architecture, IFIP/IEEE International Symposium on Integrated Network Man- agement, Seattle, Washington, May 14–18, 2001.
17. J. H. Hahn, K. H. Lee, and J. C. Ryou, A model of secutity platform within TINA based management system, APNOMs, 1998.
18. A. Sekkaki, D. Nguessan, M. D. M¨uller, and C. B. Westphall, Security within TINA accounting ar- chitecture management, ICC2001, IEEE International Conference on Communications, Helsinki, Finlˆandia, June 2001.
19. W. Stallings, Cryptography and Networks Security. Principals and Practices, Second Edition.
20. R. Brennan, B. Jennings, C. McArdle, and T. Curran, Teletec Ireland, Evolutionary trends in intelligent networks, IEEE Communications Magazine, June 2000.
21. P. A. Loscocco, D. S. Stephen, A. M. Patrick, C. T. Ruth, S. Jeff, and J. F. Farrell, The inevitable of failure: The flawed assumption of security in modern computing environments, 21stNational Information Systems Security Conference, Cristal City, Virginia, October 1998. National Security Agency, NISSC, htttp://www.jya.com/paperF1.htm.
22. C. M. Westphall, J. S. Fraga, C. B. Westphall, and S. C. S. Bianchi, Mandatory security policies for CORBA security model, IFIP/SEC2002 XVII International Conference on Information Security.
pp. 251–262. Cairo, Egypt, May 7–9, 2002.
23. A. Sekkaki, C. B. Westphall, L. L. Rossi, and I. V. Souza, Formal specification and verification of the accounting model of TINA architecture, GRES’2001. Marocco, Marrakech, 2001.
24. R. S. Sandhu, D. Ferraiolo, and R. Kuhn, The NIST model for role-based access control:
Towards a unified standard, Proc. of the Fifth ACM/RBAC Conference, 2000. (http://www.acm.
org/sigsac/rbac2000.html).
Carlos Becker Westphall obtained an M.Sc. degree in Electrical Engineering in 1988 from the Federal University of Rio Grande do Sul, Brazil, and a D.Sc. in Computer Science (Network Management) at the Paul Sabatier University, France, in 1991. At present, he is Professor in the Department of Computer Science at the Federal University of Santa Catarina, Brazil, where he heads the Network and Management Laboratory.
Abderrahim Sekkaki received a D.Sc. in Network Management domain from the Paul Sabatier University, France, in 1991: and a Dr. of State Degree from Hassan II University, Marocco, in 2002.
He does research on distributed systems and application management. Presently, he is a Professor in Computer Science at the Hassan II University, Casablanca, Morocco.
Luis Marco C´aceres Alvarez graduated in 1995 in Computer Science at the Tarapac´a of Arica, Chile, and received an M.Sc. degree in Mechanical Engineering at the Federal University of Santa Catarina, Brazil in 1999. He is currently undertaking a research program leading to a D.Sc. at the Federal University of Santa Catarina, and works in the Network and Management Laboratory.
Wagner Tatsuya Watanabe graduated in 1999 in Computer Science at the State University of Maring´a, Brazil, and received an M.Sc. degree in Computer Science at the Federal University of Santa Catarina, in 2002. He is currently undertaking a research program leading to a D.Sc. at the Federal University of Santa Catarina, and works in the Network and Management Laboratory.
