A SECURE SOLUTION FOR NETWORK MANAGEMENT IN HETEROGENEOUS NETWORKS
A THESIS
submitted by
NISHA P KURUR
for the award of the degree of
MASTER OF SCIENCE (by Research)
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING INDIAN INSTITUTE OF TECHNOLOGY MADRAS. January 2008
THESIS CERTIFICATE This is to certify that the thesis entitled A Secure Solution for Network Management in Heterogeneous Networks submitted by Nisha P Kurur to the Indian Institute of Technology Madras, for the award of the degree of Master of Science (by research) is a bonafide record of research work carried out by her under my supervision and guidance. The contents of this thesis, in full or in parts, have not been submitted to any other Institute or University for the award of any degree or diploma.
Dr. Timothy A. Gonsalves
Chennai-600036 Date:
ACKNOWLEDGEMENTS First, I would like to thank my advisor Prof. Timothy A Gonsalves for his continuous support and guidance. Prof. TAG is a perfectionist and has taught me lessons that will always be helpful. I had the freedom to disturb him with my doubts any time. I whole-heartedly thank him for the patience he showed to listen to my problems and solve them. No matter what the problem is, his problem solving skill is worth admiring. He taught me how to write academic papers, made me a better programmer, had confidence in me when I doubted myself, and brought out the good ideas in me. He enlightened me with his ideas about how to apply technology and make it useful to common man. Overall, it was a great learning experience for me. My heartfelt thanks to my co-advisor Dr. N Usha Rani for her encouragement. She was always there to correct my papers, and to ask me the right questions to help me think through my problems. With great interest, she found time in her hectic schedule to meet and discuss my ideas. Without her constant motivation, it would have been difficult to write this thesis. Apart from my advisors, I would like to thank Prof. Hema A Murthy whose advice inspired me to take up this MS programme. I would like to mention her confidence in me while handing over many responsible tasks. Hope that her expectations were met by me. I also thank her for her valuable suggestions while giving a technical presentation. A special thanks to Dr. Namita Jacob and Dr. Anil Prabhakar for giving us (Dinil, Deivapalan, Samuel and myself) an oppurtunity to work for a noble cause. It would
have been a great loss for me if I had not attended the AAC conference in December 2005. This made a great impact on my perspective of life. I extend my thanks to the Department of Computer Science and Engineering for providing me excellent facilities to complete my research work. I am grateful to all the faculty members of the department for their help in carrying out my work. I also express my thanks to the respected members of my General Test Committee, for spending their time in evaluating my work. I would also like to thank the staff and student community of this Department for their co-operation. Working in DON lab had been a pleasant experience. I have learnt a lot from this lab and have sweet memories which will remain with me forever. I am really thankful to all of them who helped me during my tenure here. I thank all of the staff members in the Computer Centre for their help they offered me whenever I approached them. My tenure in NMSWorks had been an exciting and challenging one. I thank all the employees in NMSWorks for providing me excellent support whenever I had a problem. I am also grateful to all at Sharavathi hostel for the facilities and comforts provided during the stay here at IIT. This hostel has given me memories which I treasure a lot. Words are not enough to express my thanks to my friends who were there with me always. Special mention to Dinil, Samuel, Vivek, Sandeep, Lakshmi, Jayasree, Neel, Sujit, Dean, Ranjani, Deivapalan, Aarthi Reddy, Madan, Ravinder, Swethalakshmi, Ramya, Ranbir, Vanchynathan, R Deepak, B Prashanth, Jyothi, and many more. I am truly grateful to Major Ishpal Singh Gill for his excellent co-operation. Without him, it would have been extremely difficult for me to understand the basics of network security. Thanks a lot Major for instilling confidence in me. I would also like to mention my gratitude to the unofficial research group which was helpful in solving problems that were faced at each juncture of the research.
iii
Last, but not the least, my family who have always understood my problems even before telling them. All what I have achieved is due to their constant motivation and without their support this would never have happened.
iv
ABSTRACT Keywords: Network management; Transit security; User-space VPN; Single SignOn; ITU-T Recommendation X.805; Security layers; Security dimensions; Security planes; Security threats
The increasing size and complexity of networks and the need to remotely manage them have resulted in wide-spread use of Network Management Systems (NMS). The NMS helps the administrator by providing a unified view of the entire network with regular feedback about the state of each element (node or link) in the managed network. This helps in simplifying various network administration tasks thereby reducing operational costs and improving performance. However, the introduction of NMS creates some security issues. This work discusses a generic secure framework proposal to solve the security issues caused by the installation of NMS along with the design and implementation a secure solution which confirms to the proposed framework. The solution addresses the security issues at three different levels - transport, access and storage. The aim of this solution is to provide maximum possible security while managing currently deployed networks. This thesis also discusses the various major security issues that have been noticed as part of the study conducted to come up with the framework for NMS scenario. To understand the security measures supported by various network elements, we conducted a survey and came up with a classification which divided these elements into four basic groups depending on their support for security. This classification helped in
developing the solution with different security measures for each class. The scope of this solution includes securing data in transit as well as in storage and access control at distinct levels. As part of the solution, we introduce the concept of user-space VPN (Virtual Private Network) to secure management data in transit. Moreover, we promote the idea of unified access control using single sign-on mechanism through this solution. We performed a compliance checking as per the ITU-T Recommendation X.805 ( provides a standard security framework for open systems providing end-to-end communications) and found that our solution covers most of the security dimensions mentioned in the recommedation. We also carried out a survey of popular NMS products in terms of supported security measures and compared our proposed solution with others. Our solution provides security at transport level and access control level irrespective of the features supported by the managed element.
vi
TABLE OF CONTENTS Thesis certificate
i
Acknowledgements
ii
Abstract
v
List of Tables
xi
List of Figures
xii
1 Introduction
1
1.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Security for Network Management Operations . . . . . . . . . . . . . .
5
1.3
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.4.1
Transport security . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.4.2
Access Control Mechanism . . . . . . . . . . . . . . . . . . . . .
10
1.4.3
Storage Security . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.5
Organization
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Current Trends in Secure Network Management 2.1
12 13
Product survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.1.1
Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3 Proposed Security Framework 3.1
Security Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21 22
3.2
3.3
3.1.1
NMS security . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.2
Transport security . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.3
Access control to NEs . . . . . . . . . . . . . . . . . . . . . . .
25
Solution description . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.1
Transport Security . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.2
Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2.3
Secure storage . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4 Design and Implementation 4.1
4.2
4.3
4.4
37
Transport Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.1.1
OpenVPN - User-space VPN . . . . . . . . . . . . . . . . . . . .
38
4.1.2
Improving key exchange in OpenVPN . . . . . . . . . . . . . . .
40
4.1.3
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.1
NMS level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.2
NE level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.3
Database level . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.2.4
Design of Single Sign-On . . . . . . . . . . . . . . . . . . . . . .
47
4.2.5
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Security of stored data . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.3.1
Collected data . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.3.2
Common measures . . . . . . . . . . . . . . . . . . . . . . . . .
53
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5 Performance Evaluation and Analysis 5.1
Experimental Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
55 55
5.1.1
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.1.2
Key exchange time measurement . . . . . . . . . . . . . . . . .
56
5.1.3
File transfer performance . . . . . . . . . . . . . . . . . . . . . .
57
Compliance of the solution . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.2.1
ITU-T Recommendation X.805 . . . . . . . . . . . . . . . . . .
58
5.2.2
Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.3
Framework Implementation Evaluation . . . . . . . . . . . . . . . . . .
61
5.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.2
6 Conclusions
63
6.1
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.2
Criticism of the work . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
6.3
Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
Appendix A
66
OpenSSL Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
A.2 Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
A.2.1 OpenSSL Engines - Introduction
. . . . . . . . . . . . . . . . .
66
A.2.2 Software Engine - Contribution . . . . . . . . . . . . . . . . . .
67
A.2.3 Further Enhancements . . . . . . . . . . . . . . . . . . . . . . .
68
Appendix B
69
OpenVPN Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
B.2 Merits of OpenVPN
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
B.3 OpenVPN - Available Features . . . . . . . . . . . . . . . . . . . . . .
71
Appendix C
73 ix
RSA-KEM and RSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
C.2 RSA-KEM Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
C.2.1 Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
C.2.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
C.2.3 Decapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
C.3 RSA-PSS Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
C.3.1 SignPSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
C.3.2 VerifyPSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
References
77
Curriculum Vitae
81
General Test Committee
82
x
LIST OF TABLES 2.1
Survey of Security Aspects in NMS Products . . . . . . . . . . . . . . .
16
2.2
Comparing different versions of SNMP (v1, v2c and v3) . . . . . . . . .
18
4.1
IPSec vs OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.1
Key exchange time comparison . . . . . . . . . . . . . . . . . . . . . .
57
5.2
Mapping of security dimensions to security threats . . . . . . . . . . . .
61
5.3
Features in the framework implementation . . . . . . . . . . . . . . . .
62
A.1 AES-128-CBC speed comparison, bytes/sec . . . . . . . . . . . . . . . .
67
A.2 AES-128-CBC table space and time taken comparison . . . . . . . . . .
68
LIST OF FIGURES 1.1
Manager-Agent Model . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2
Typical NMS deployment
. . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3
Proposed secure transport scheme . . . . . . . . . . . . . . . . . . . . .
10
1.4
Operators connect to NEs via NMS using SSO . . . . . . . . . . . . . .
10
3.1
NMS-NE-Administrator interaction block diagram . . . . . . . . . . . .
22
3.2
Security aspects - Framework block diagram . . . . . . . . . . . . . . .
23
3.3
Proposed security solution . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1
Proposed transport security . . . . . . . . . . . . . . . . . . . . . . . .
39
4.2
Design for secure transport . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.3
Secure Key Exchange protocol . . . . . . . . . . . . . . . . . . . . . . .
43
4.4
Tunnel Management protocol - newkey command . . . . . . . . . . . .
44
4.5
Multi-tier architecture for single sign-on . . . . . . . . . . . . . . . . .
45
5.1
Local and remote setup . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.2
Server side measurements (remote setup) . . . . . . . . . . . . . . . . .
57
5.3
Time taken for file transfer (remote setup) . . . . . . . . . . . . . . . .
58
5.4
Security framework for end-to-end network security . . . . . . . . . . .
60
C.1 The PSS scheme
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
CHAPTER 1
Introduction
1.1
Overview
The last decade has seen a tremendous expansion of IP network deployment [1]. This is mainly due to the increased usage of network services like Voice over IP (VoIP), peerto-peer systems, email and chatting, Internet gaming, on-line trading, etc by people across the globe [2]. These services demand a robust and liable network with very high uptime, typically 99.999%. Therefore, network management has become an integral part of such networks, without which reliability and availability can not be ensured. As most of the network management operations were, and to some extent still are, manual processes, the staffing requirements alone for these activities has created a crisis for many organizations. The growth of networks has also led to the development of large, heterogeneous networks. Heterogeneous networks are made up of various types of elements which support different operating systems (OS) and protocols. Most of the networks are heterogeneous as they perform many functions and different components or elements are used for the same. An example is the use of Broadband corDECT1 to provide 1
Broadband corDECT is the latest wireless local loop offering from Midas Communications [3]. With per user, always-on data speeds of up to 336 kbps, it is an ideal solution for rapid roll-out markets that need broadband data along with toll-quality voice at a very affordable per line cost [4].
1
Internet on wireless [5]. There are many other products like wireless routers by many vendors like Cisco, NetGear, DLink etc that provide the similar functionality (i.e., Internet on wireless). Many of these support proprietary softwares which adhere to the standard principles, but differ in their protocol implementations, and support for management. For example, Cisco devices run on the Cisco IOS while JunOS is used by Juniper devices. These OSes provide the same basic functionalities of switching/routing etc but through different implementations. Similarly, many systems support different protocols for management. While some use standard protocols like Simple Network Management Protocol (SNMP) [6, 7] [8, Part 2], others have proprietary management protocols. Managing various elements that support different technologies has become a challenge as it is tough to have manual expertise in all the technologies. Moreover, the increasing size of the networks has made it tougher. Thus, an urgent need has risen for automated network management, integrated across diverse environments. Network management is a service that employs a variety of tools, applications, and devices to assist human managers in monitoring and maintaining networks. A network management system (NMS) is designed to view the entire network as a unified architecture, with addresses and labels assigned to each point of interest. This point of interest may be a network element (router or switch) or a connection between two elements (link between two routers). Specific attributes of each element and link known to the NMS are monitored and managed either by polling2 or by notification3 methods [6, Chapter 1]. The manager-agent paradigm, depicted in Fig. 1.1, is the most commonly used 2 3
In polling, the manager requests for information from the elements. The active managed elements of the network send status information to the manager whenever an event occurs.
2
Fig. 1.1: Manager-Agent Model organizational model in network management. While the manager provides the interface between the human network manager and the management system, the agent interfaces between the manager and the physical device being managed. The management database at the agent contains information that reflects the configuration and behaviour of the managed objects. The database at the manager contains node specific information about the agents under its control [8, Chapter 4]. The capabilities of the network management software are usually based upon the functionalities supported by the network management protocol being used. Most systems use open protocols; however, some of them use vendor specific proprietary protocols. The two most commonly used standard management protocols are Simple Network Management Protocol (SNMP) and Common Management Information Protocol (CMIP). SNMP : This protocol was introduced as an interim solution for network management during the elaborate development of object oriented management protocols. The main goal while developing this protocol was hence to have a simple protocol which would reduce the complexity of network management and use minimal resources [6, Chapter 4] [8, Chapter 4]. However, SNMP became, and is still, one of the most commonly used management protocol as it provides centralized, robust, and inter-operable network
3
management. It has the flexibility to allow management of vendor-specific information. The protocol is based on a request-response architecture. Each managed object at the element’s side has a current value and is identified with a unique identifier (called the Object Identifier - OID). When the manager queries an agent, it sends the community string, which serves as a token for authentication between the agent and manager, and the OID of the managed object for which it requires the value. The agent checks the authenticity and authority of the manager and then provides the current value for that particular OID. SNMP has three versions namely SNMP v1, v2c and v3 out of which only v3 supports security measures like encryption and hashing. In the former versions, all the messages are passed through the network as plain text. CMIP : This is a well designed protocol that defines how network management information is exchanged between network management applications and management agents. It uses an ISO reliable connection-oriented transport mechanism and has a system with built-in facility that supports access control, authorization and security logs. The NMS application initiates transactions with agents using various operations and the information is exchanged through managed objects. This protocol also provides powerful capabilities that allow management applications to accomplish more with a single request and better reporting of unusual network conditions [9]. But, the inherent complexity and large resource requirement for implementation of CMIP when compared to SNMP, resulted in lesser usage of CMIP for management activities [8, Chapter 3]. Thus SNMP still remains the most widely used management protocol for IP networks.
4
1.2
Security for Network Management Operations
This section discusses about the security issues as per the standard network management model that has been widely deployed. The ISO functional model, termed as FCAPS in short, consists of five dimensions in management - fault management, configuration management, accounting management, performance management and security management. Every management function should be safe-guarded according to the confidentiality and importance of the information being handled. Fault management deals with the faults or errors in the network which should be known only to relevant managers. Configuration management deals with the remote configuration of devices and should be done securely to avoid unwanted access to the elements. Accounting management deals with the business returns generated by the network and should be safeguarded. Sometimes, leakage of performance parameters can be utilized by an attacker to learn about the network and break into it. Security management deals with the access control and management of security devices like firewall, intrusion detection systems (IDS) etc. It is hence evident that each sphere of network management requires security measures to safeguard the management data they deal with and have a secure path for all the legal access to and from the NMS. Thus, the security of entire network management operations is highly significant. A typical NMS deployment is shown in Fig. 1.2. The NMS has to manage various network elements by sending data to and receiving data from them. The network through which the data flows need not be a trusted network. Also, there are many users who login to the NMS to know more about the managed networks. At any level (NMS, user or transport network) attacks can be carried out to get information about the managed network. Hence, the security at every level is very important.
5
Fig. 1.2: Typical NMS deployment
1.3
Motivation
One of the biggest motivation behind the adoption of network management technologies is to improve the reliability and security. When an NMS is introduced into a network, protocol that is otherwise not used, come into picture. For example, SNMP is widely used for network management only. Even though being the most popular management protocol, many SNMP protocol designs have issues like allowing unauthorized privileged access, denial of service conditions or unstable behaviour [10]. Thus, the deployment of an NMS for managing networks has raised several important security issues. The goal of this work is to enhance the security and reliability of the managed network by implementing a secure solution to overcome issues raised by the induction of management systems into the network. One among the major security issues while managing network is security of data while in transit as well as in storage. Apart from the regular subscriber traffic, additional information regarding management activities flow through the network. This management traffic share the same data links as that of subscriber traffic in most of the networks, making it vulnerable to security threats. The data collection from devices and configuration of devices may be done using any standard protocol like SNMP
6
or FTP4 or some proprietary protocol supported by that particular device. Some of these protocols do not support any security mechanisms and thus the data traverses through the network as plain text. It is very important that this sensitive information about the network, used for management operations, should not be revealed to any unauthorized sources. Another major security factor in network management is easy but secure access to network elements (NEs) and NMS. When network management is introduced in an organization, human managers are appointed with an authorized set of tasks, thus leading to a hierarchy of authorities. If this structure of permissions is not properly maintained, severe security breaches can occur within the organization itself, and hence affect the business. For example, the management data provides information about the NEs and is a valuable asset which should be guarded against intruders. So only few users, privileged ones, should be allowed to access this data. In addition to the access control, the stored data should be kept confidential as it contains important details about the managed network. The managed network topology can be understood by accessing the NMS database which is an important information for attackers. Many of these issues have been identified earlier like for example, many implementations of management protocols do not support any security measures for transit data as well as access control. For example, SNMPv1 and v2c have community string based weak security. The data passes over the network as plain text which can be easily interpreted by the attacker [6, Chapter 15]. To evaluate how far these issues are taken care of by the popular NMS products, we conducted a survey of several NMS products. It has been found in our survey that no NMS product takes care of all these issues. Most of them support security 4
File Transfer Protocol is used by many devices to retrieve log files, and for bulk transfer of performance and configuration data
7
based on the NE’s support for security. Similarly, access to NEs through NMS has been provided but again this depends on the control mechanism supported by the NE (refer Table 2.1 in Page 16). In short, if the NE provides security then the NMS also manages the NE securely. But there are many NEs that are deployed in the network which do not have any support for security. We found that there was no generic secure solution for this purpose and decided to come up with one such solution for an NMS managing a heterogeneous network consisting of a mix of NEs with different levels of security.
1.4
Contributions
In this thesis, we identify the various threats raised due to the deployment of NMS for managing networks, and we propose a generic framework that should be followed to ensure secure network management. A secure solution adhering to the proposed generic framework is also discussed along with an evaluation of this solution with the ITU-T Recommendation X.805 (refer Section 5.2.1 in Page 58). The solution considers three different dimensions in order to provide enhancements to security while managing heterogeneous networks. We first studied the security concerns raised by the introduction of an NMS into a heterogeneous network for management. The major security issues identified are as given below: 1. Data Security • Protocol Dependent • Protocol Independent • Storage 2. Access Control • Network management application • Network element • Database 8
In order to evaluate the capabilities of current NMS products we conducted a survey of various NMS products (refer Section 2.1). This survey throws light on how these security concerns are being addressed by various NMS products. This led to the proposal of a generic framework for secure network management and a solution that confirms to this framework. As a part of security solution implementation, we carried out a survey of NEs based on their support for security. This study was to know about the security features supported by heterogeneous network components and resulted in a classification of NEs to four different classes based on the security criteria (refer Section 3.2 in Page 26). The security concerns that are raised while managing networks are categorized into three different areas and dealt accordingly. They are 1. Transport security 2. Access Control Mechanism 3. Storage Security
1.4.1
Transport security
We suggest a scheme which provides security for all types of NEs irrespective of its capability to support security (refer Fig.1.3). For those which support security, the same security mechanisms that are supported by elements are used. For those which do not support any security mechanisms we propose the establishment of protocol independent user-space tunnels to protect the data in the transit. As a part of tunnel establishment, we also devise a new key exchange protocol - Secure Key Exchange protocol (SKE protocol) based on RSA-KEM and RSA-PSS (refer Appendix C). This SKE protocol has been integrated with user-space VPN software (here Open VPN), thus making the key exchange more secure than the current scheme (Open VPN at
9
Fig. 1.3: Proposed secure transport scheme present uses Diffie-Hellman (DH) key exchange protocol). Although it has been integrated with Open VPN, we have developed a generic client-server architecture which makes it usable on any user-space VPN with slight modifications.
1.4.2
Access Control Mechanism
We propose a unified access control mechanism based on the Single Sign-On (SSO) concept. The NMS becomes the authority, only through which the network operators can access the NEs as well as the NMS database (refer Fig.1.4). Also, depending Secure Network A
NMS Server with LDAP lookup
Firewall
Secure transport mechanism
Managed NE
B LDAP information base
C NMS Client from remote locations using https
Fig. 1.4: Operators connect to NEs via NMS using SSO 10
on the user privileges, the NMS displays different customized views of the managed network. Since there can be large number of managed NEs and many operators, a huge database which consists of the mapping between each operator and his rights to each NE comes in to picture. This huge database is similar to a corporate database which stores information about their employees where the operations for retrieval of data is more than the update operations. For such queries directory access protocols are used which provide results efficiently. Here, we have used Lightweight Directory Access Protocol (LDAP) which is a subset of X.5005 . OpenLDAP, an open source implementation of LDAP, with Berkeley database (bdb) as back-end database, supplies the access control information to the NMS. As a part of implementation work, we have developed the access control layer at the NMS using SSO mechanism through which the NEs supporting telnet and ssh6 can be accessed.
1.4.3
Storage Security
Database security consists of various aspects like server security, data security and access to the database. The users can connect to the database, but only through the NMS (SSO based access control). The NMS itself is used for managing its database. An alarm is raised when any unauthorized connection is made to this managed database. The data to be protected is classified as high, medium and low depending on the safety requirements. After classification, data is placed in various tables and different levels of security are assigned by encrypting at multiple levels (refer Subsection 4.3.1). 5
X.500 is an ISO naming system designed to make identification of objects easier. It allows naming of an object by giving a set of attributes. For example, a person can be identified with a set of attributes like name, title, phone number, postal address and so on [11, Chapter 9].
6
telnet and ssh are the common protocols used for accessing NEs remotely
11
1.5
Organization
The rest of this thesis is organized as follows. Chapter 2 discusses the practices currently followed for network security management. It first gives an account of NMS product survey which provides insight to the current industrial trends in providing secure network management. It also presents an overview of related work done which comprises of different security mechanisms in an NMS scenario. Chapter 3 describes the generic framework and proposed security solution which is a specific implementation of the framework. This chapter also includes the classification of NEs based on the security mechanisms they support. The solution relies on this classification to provide maximum security at various levels. Chapter 4 gives an overview of the design and implementation of each phase of proposed solution. It gives a detailed comparison of user-space VPN with kernel-space VPN for securing transport and also explains the newly designed protocols to achieve a better secure key exchange mechanism. SSO implementation for unified access control is also discussed in this chapter. Chapter 5 describes various experiments conducted and presents performance analysis based on these experiments. Compliance analysis of the solution is done with respect to ITU-T Recommendation X.805. The research is summarized and pointers to future directions are given in Chapter 6.
12
CHAPTER 2
Current Trends in Secure Network Management Network management systems are mainly used to provide a single console for managing networks with diverse elements located at various places. The system can be deployed in a centralized manner depending on the cost and size of network. However, this single point of access poses a threat to the security of the network as well as the management environment. If an attacker breaks into the central management system, he is bestowed with immediate and complete control of the network. So the security of an NMS is very important in order to avoid such attacks. The introduction of NMS also increases the amount of information flowing through the network and thus adds more security concerns that affect the business. NMS related information can be stolen at any level including application, OS, during transit through network or from the stored database. Additionally, security weaknesses can be introduced by the various protocols used for management. There are many NMS products available in the market. In order to evaluate their performance with respect to the above mentioned security issues, we conducted a survey. In this chapter, we discuss the survey results based on the security mechanisms supported. We also describe other related work in this area.
13
2.1
Product survey
We conducted a product survey to study the market trends and evaluate the various security mechanisms provided by these products. The popular products included for the survey are TTI Telecom’s Secure Access [12], HP OpenView [13], CiscoWorks [14], CA TNG Unicenter [15], IBM Tivoli [16], AdventNet OpManager [17], OpenNMS [18], NMSWorks CygNet [19]. All these products were compared for the features they provide for enhancing the security while managing networks. TTI Telecom’s Secure Access is a plug-in module that works well with various other NMS products. As the name suggests, this protects from unauthorized access and allows to easily create and modify security permissions for different users. HPOpenView is a comprehensive family of NMS products and provides very fine grained access control mechanisms to the network resources as well as the resources within the NMS application. CiscoWorks supports almost all the security features required for an NMS. Identity management module provides mechanisms for user identification. It also supports access control to NEs using its module named Secure Access. Secure User Registration Tool partitions the traffic based on the user’s identity. Hence, different plug-in modules/products together provide the security aspects in CiscoWorks. CA TNG Unicenter provides a module called Network Security Option that filters all the packets and has the ability to track the session state information for connectionless protocols also. Its access management mechanism clearly defines who has access to what, logs all the operations and reports about the carried out operations. It also have threat monitoring and security monitoring modules. IBM Tivoli has separate modules for separate tasks. Identity Manager helps in the creation of user accounts. User Administration manages the user accounts on various platforms. Global sign-on is used in which a single user name and password can allow to login to distributed 14
resources. But here, the resources are the enterprise solutions provided by IBM themselves, not the network elements. Risk Manager eliminates false threats, identifies real threats, determines the severity of threats. AdventNet OpManager provides secure authentication and access control through both SSL and secure RMI. Fine grained and extensible authorization support for users, groups, roles, operations and object views. Also secure data communication from the NMS to NE is provided through a new feature called Secure Remote Monitoring. OpenNMS is an open source initiative and is a free software. It has user based authentication to enter the NMS server. Each user has restricted access according to his role. NMSWorks CygNet has a security manager which supports fine grained user access control. It also allows the NMS users to securely login to the server from a public network like Internet.
2.1.1
Comparison
It is interesting to note that almost all the NMS products support SNMPv3. For NEs that do not support SNMPv3, alternate mechanisms should be provided to secure management data. In such cases, if an end-to-end tunnel is established, then the products can claim to have secure data transmission. However, most of them assume NEs to have support for secure tunneling of data. Lesser importance is given to the security of NEs with no tunneling facility. Similarly, most of the NMS’ storage security is based on the vendor specific security mechanisms provided along with the database. Our survey (refer Table: 2.1) shows that the best product available, from the security point of view, is AdventNet OpManager, which takes care of all security issues. However, to realize secure transport for NEs with lesser/no security features, a custom software has to be installed at the NE which is not preferred by network administrators. The next best products are CiscoWorks and HP OpenView, which
15
Table 2.1: Survey of Security Aspects in NMS Products Products
Data Security
Access control
Protocol Dependent
Protocol Independent
Storage
NMS
NE
DB
TTI Secure Access
✖
✖
✖
✔
✔
✖
HP OpenView
✔
✚
✚
✔
✚
✚
CiscoWorks
✔
✚
✚
✔
✔
✚
CA TNG Unicenter
✔
✚
✚
✔
✚
✚
AdventNet OpManager
✔
✔a
✚
✔
✚
✚
IBM Tivoli
✔
✚
✚
✔
✚
✚
OpenNMS
✔
✚
✚
✔
✚
✚
NMSWorks CygNet
✔
✚
✖
✔
✚
✚
a
Custom software to be installed at the NE
✔ - Available, ✖ - Not available, ✚ - Partially available
takes care of all the security issues except secure transport mechanism for elements that do not support any tunneling mechanisms. Both relies on IPSec enabled routers for secure transport which need not be applicable in heterogeneous networks. IBM Tivoli and CA TNG Unicenter are good products but lack in secure and controlled access to NEs. Known for its modular architecture, TTI Telecom’s Secure Access provides excellent plug-ins for various products running on wide platforms but not a total solution. OpenNMS, being an open source initiative, can be customized as per needs. It also supports basic authentication and access control. CygNet is a highly customizable product tailored for telecom networks but the security measures are limited to fine grained access control and secure access from remote clients. However, it is evident that none of the NMS products take care of all the security issues that are present while managing networks. Also, we noticed that no generic 16
secure framework has been developed for an NMS product to provide secure network management. This has motivated us to conduct a detailed study on the various security threats that are present while managing networks and propose a generic framework that has to be adhered to while creating an NMS solution for heterogeneous networks. The detailed study and the framework is discussed in the following chapter (refer Chapter 3). In the section below, we discuss the current practices and research work done with respect to secure network management.
2.2
Related work
The most widely used IP network management protocol is SNMP [20] [8, Chapter 4] [6, Chapter 4]. It has three versions v1, v2c and v3. SNMP v1 and v2c provide community string based security. Every message from a management station to an agent includes a community string. This string functions as a password, and the message is assumed to be authentic if the sender knows the password. However, this is a weak form of security, as the community string traverses the network in plain text. SNMPv3 supports better security mechanisms and operates in three modes [21]. The different modes are as given below: 1. noAuthNoPriv - No authentication and no privacy. Same as insecure SNMP v1 and v2c. 2. authNoPriv - Authentication but no privacy. The hash of the whole protocol data unit (PDU) will be sent along with the PDU for authentication. There is no encryption at this level. Only authenticity and integrity of the data is taken into consideration here. 3. authPriv - Authentication as well as privacy. The PDU payload is encrypted and the hash of the whole PDU is placed in the SNMP packet. Here all the
17
Table 2.2: Comparing different versions of SNMP (v1, v2c and v3) SNMP
Standard request
Additional usage per variable
CPU time
Memory
Response
CPU time
Memory
Response
(in µs)
(in KB)
time(in µs)
(in µs)
(in KB)
time(in µs)
v1
609
322
605
2.3
21
92
v2c
618
324
612
2.3
21
89
v3
804
915
1030
2.3
30
106
Courtesy: Analysis and Design of an Embedded Management Agent, T Senthil Nathan [22]
three elements of security1 are taken care of. In order to have a secure transport mechanism, the authPriv mode should hence be considered. SNMPv3 requires higher CPU power and hence expensive to implement as an embedded agent (refer Table 2.2. The measurements in the table were taken on an Intel Celeron processor (466 MHz) machine with 16 MB RAM running Linux 2.4 kernel). Moreover, since these agents are only to support management, they should make use of minimal resources when compared to other modules with definite functionalities like the routing or switching engine. Due to these reasons, SNMP v1 and v2c remain the widely used protocols for IP network management despite their weak security. SNMP is mainly used for performance and fault management. While SNMP provides reasonable performance for the retrieval of a small amount of data from many devices, it becomes rather slow when retrieving large amounts of data (such as routing tables). SNMP does not support easy retrieval and restoration of previous configurations. This is because it is not easy to identify configuration objects and the naming system is very specific. Hence, it is very difficult to get back a previous configuration 1
Confidentiality, Integrity and Authenticity - CIA are the three elements of security
18
of a physical device using SNMP [23, 24]. Several other techniques have been developed for performing these functionalities, some of which do not support security mechanisms. For example, XML based techniques are being used for bulk data transfer related network management operations. XML is a machine readable format with relatively easy syntax rules and provides a document-oriented view of configuration data. It is easy to process and there are many good tools available for parsing XML files [24]. It is hence clear that achieving protocol dependent security for all the management related data is difficult, as a combination of protocols is used to perform the full spectrum of management activities. Many approaches have been made to find generic solutions and support end-toend security by establishing tunnels across the network and thus provide protocol independent security [25]. Mostly IP Security protocol, known popularly as IPSec, has been used for this approach as some NEs have built-in support for IPSec [26]. Access control mechanisms along with auditing are considered as the important feature of any secure system [27]. Almost all NMS products provide access control based on user authentication. Once a user has been logged in, he has a particular set of rights and permissions in the NMS. Normally for NMS application security, a role based access control is implemented as each NMS operator has a particular role in the organization [28]. For access control to NEs, it depends on the protocol being used to access the NE. This is also very important as it allows the NMS user to perform operations on the NE remotely. If a telnet/ssh/ftp based access is used, a login name and password is required to access the NE. In case of SNMP, a community string is required. Regarding access control to the NE, SNMPv3 provides view based access control which depends on the user as well as the location from where he manages it. For
19
example, a privileged user may become an ordinary operator once he leaves the secure subnet and accesses the element from a machine in the untrusted network [29]. For the database server security, specialists need to rely on network administrators implementing precautions such as firewalls to protect local data. Regarding data security, the database vendors themselves provide some securing mechanisms such as built-in encryption routines, table access control methods and database access restrictions [30].
2.3
Summary
In this chapter, we have first surveyed the popular NMS products in the market. This survey is to evaluate the security mechanisms that are currently being used in the industry for network management. The survey shows that there is no NMS product that provides security in all aspects. A detailed sketch of various existing techniques to overcome these security issues is also included in this chapter.
20
CHAPTER 3
Proposed Security Framework We have already discussed about the importance of NMS security and various measures to achieve this. In this chapter, we discuss about the security issues introduced while managing heterogeneous networks and propose a generic framework for secure network management. We also put forward a solution which adheres to this framework practices. To administer the network effectively and efficiently, NMS has to retrieve information from NEs. In ideal case, the network administrator should be able to retrieve all the necessary information about the network from the NMS itself. But there are scenarios as given in Fig. 3.11 , where the network administrator has to access the NMS for some information and managed elements for other information. This access depends on the protocols supported by the element as well as on the interfaces provided by the NMS application. There are NMS applications that provide remote NE access. It is merely a remote console login provided and NMS cannot control every action performed on the NE through this remote login. Thus, access to NEs through the NMS cannot be completely regulated. Moreover, access to NMS itself is crucial for network management security. Hence, access control mechanisms form an integral part in this security framework. The NMS application has to support protocols that are provided for management at the NE’s end. The data flowing in the network, between NMS, NE and network 1
This figure shows all the possible interactions between the elements that form the managed network
21
NE1 NE2
Transport security
NMS application
. .
Application security Database security
Transport security
.
Server security
NMS Server
NMS DB
NEn
Secure access to NMS Client Secure access to NMS DB
Secure access to NEs
Network Administrator
Fig. 3.1: NMS-NE-Administrator interaction block diagram administrator, should be authentic, untampered and confidential, independent of its direction of flow. Hence, transport security has a vital role in this framework. Similarly, the stored data, which includes data collected from various network elements, should also be secure. Thus, database security also becomes important as it contains valuable information about the managed network assets. For any system, access control is a useful technique to keep intruders out and thus enhance security. Here, there are two different aspects for access control - one to the NMS application and other to the NEs. NMS application should be developed in such a way that any organization’s set of network permissions can be shown and used as per need. Moreover, the access to the network assets through the NMS should be secure and controlled such that no unauthorized user can analyze or manipulate the operations performed. Based on these issues, we propose a framework that helps in providing secure management for heterogeneous networks.
3.1
Security Framework
The framework consists of the following important areas in which security has to be ensured - NMS, transport, and access to NEs. For ease of understanding different
22
NE1 NE2
Transport security
NMS application
. .
Application security Database security
Transport security
NMS DB
.
Server security
NMS Server
NEn Secure access to NMS Client, NMS DB and NEs
Network Administrator
Fig. 3.2: Security aspects - Framework block diagram aspects of security, we have used the same interaction diagram and labeled it with respective security concerns (refer Fig. 3.2). We have also made it more secure by allowing the administrator to manage the entire network just by accessing the NMS. NMS provides the required facilities to access NMS DB, and managed elements through it thus enhancing the privacy of the system. The framework mandates that these aspects of security should be considered in any NMS application to provide secure network management.
3.1.1
NMS security
The NMS security can be further subdivided as application security, server security, database security and transit security (between NMS server and NMS database). At application level, each NMS operator should be allowed to view, manage and monitor only particular sections of the network. If well-defined rules and regulations are not set, the operators can obtain inappropriate privileged access which can cause havoc. At the other extreme, improper rule definitions can restrict the operators from performing authorized tasks. There can also be conditions where the operator would like to access the NMS from a remote location (outside the subnet, say via Internet), 23
which poses serious security risks for the application. If the access information of a privileged user is leaked out, then the critical operations can be performed by an unauthorized, perhaps malicious, person. There can be unauthorized access to the NMS server either due to lapse in physical security or through hacking the OS of the server. The NMS application server can also face security threats and attacks that are common to other application servers. Denial of service (DoS) attack, domain name hijacking etc are few of the attacks common to any application server. While managing various parameters of the elements, NMS collects data and stores it for further usage. The NMS database is the source of this collected data, which is used for studying and analyzing the network conditions. Many business level decisions are made based on this analysis of stored data. Hence, the importance of database security is significant. The transport section between the NMS and database should be secure since the data exchanged consists of information relevant to either the managed elements or the application as such. Thus, transit security is very important especially when the NMS application and database run on different servers.
3.1.2
Transport security
To determine the exact status of NEs, the NMS has to collect data from them at regular intervals. Many devices support standard protocols (SNMP, FTP2 , ssh, telnet etc) for data collection and configuration of devices. There are devices that provide proprietary protocols for the above functionalities. However, some of these protocols do not support any security mechanisms and thus, the data traverses through the network as plain text without any encryption. This provides attackers good opportunity 2
FTP is used for uploading and downloading configuration files in many devices.
24
to learn about the devices . If a single router in the network gets compromised, the attacker could route all the traffic to an unauthorized destination, creating a major security breach. Hence, every other security measure taken becomes useless, once the network becomes compromised. Further, NMS is also used for configuration management, which allows to change the managed element configurations. If the configuration data gets altered during transit, the system will not be able to judge the real state of the device which can lead to many serious issues. Therefore, it is essential that the data in transit should adhere to the three fundamentals of security - confidentiality, integrity and authenticity (CIA). The information flowing from NMS server to its users should also be secure. The NMS server should provide access to an authorized user from any remote location. Adequate care should be taken in order to prevent launch of attacks and disclosure of details about the NMS user, application and the managed elements. Therefore, a secure mechanism for protecting the data between NMS and remote operator, is also important.
3.1.3
Access control to NEs
Almost all NMS products in the market support access to NEs by providing a console/terminal to the NMS user. This allows the user to access the NE, but the NMS cannot control the user operations. For example, if the NE supports only telnet and the NMS provides a remote telnet console, then the access to the NE through the NMS is neither secure nor controlled. Moreover, in a large network, the user has to remember many security credentials (login name/password, community strings etc.) which is a big challenge. The natural tendency is to have same password for all the elements in a subnet or even a group
25
Fig. 3.3: Proposed security solution of elements without any password. This can create security breaches in the NEs. Therefore, there should be some mechanisms in the NMS that allow the users to access NEs securely and easily, irrespective of the security mechanisms supported by the managed NEs.
3.2
Solution description
It is difficult to provide security for a network that is already being managed as the disruption of the service should be negligible and the network poses many constraints like devices supporting insecure protocols only, no proper access control mechanisms, insufficient support for security techniques etc. Hence, the solution is designed with an objective of providing maximum available security in an existing managed heterogeneous network. The solution is proposed referring to the framework (refer Section 3.1) for the security aspects and is divided into three separate security domains - transport security, access control and storage security. Special care has been taken to design a solution with minimal change and maximum security. Normally, an NMS is placed in a secure network in order to avoid attacks from outsiders. The firewall in the figure (refer Fig. 3.3) is to protect the NMS by placing it in a secure network. Users can login to the NMS either from within the secure
26
network or from remote insecure locations. We also require that the NMS is placed in a location where unauthorized physical access is restricted and installation is done on a hardened OS, which limits potential exposure. The solution is proposed keeping in mind the heterogeneity of a network. A survey of NEs, based on support for security was conducted to address various issues due to heterogeneous networks. This leads to a classification of elements into four groups as given below: Class 1 (Weakly secure): NEs that support very weak security mechanisms with access control credentials and data passing through the network as plain text. Protocols used by such NEs include telnet, insecure SNMP (v1 or v2c). Access control is done by user name-password pairs or community strings. Examples for such NEs are routers that connects a LAN to ISP, metro Ethernet switches, and many legacy systems which still form a part of modern networks. Class 2 (Partially secure): NEs that support secure protocols either for configuration or for management, but not for both. This class can be further subdivided into two - one which supports secure configuration only, and other which supports secure management only. Class 2(a) Many devices use SSH or other secure protocols for configuration and insecure SNMP (v1 or v2c) for management. Here, configuration is done securely but the insecurity problem exists for the management protocol, as SNMPv1 and SNMPv2c are not secure. Examples for this type of NEs include SAN (Storage Area Network) switches by various vendors. Class 2(b) The other extreme is to use SNMPv3 for management and telnet or other weakly secure protocols for configuration. Examples for this type are Nortel switches (Nortel Networks Baystack 325 switches) [31]. 27
Class 3 (Fully secure - Protocol dependent): NEs that support secure protocols for both configuration and management. The secure protocols include SSH/ SNMPv3/any secure proprietary protocol. High-end switches and routers manufactured by Cisco (MDS 9000 family), 3Com (7750, 8850 family) etc come under this category. Class 4 (Fully secure - Protocol independent): NEs that support protocol independent security by establishing tunnels from the source to destination. Here the tunnels are setup using IPSec, or other secure tunnel establishment techniques. Mostly backbone routers that are involved in setting up virtual private networks (VPN) support secure tunneling mechanisms. Hence, the challenge is to provide security for all the above defined classes of elements and ensure maximum security while managing such heterogeneous networks. Our mechanism relies on different security mechanisms for each class of NEs.
3.2.1
Transport Security
There are situations where the NMS data flows between the NMS server and the NEs through a network that need not be trusted. It is essential that this data is secure with respect to the three basic fundamentals of security - Confidentiality, Integrity and Authenticity (CIA). Thus, there is an imperative need for a secure transport channel. The secure transport can be either by securing each protocol that is being used between the NMS and NE, or by providing protocol independent security through end-to-end tunnel establishment. An important issue that needs to be addressed, as part of transport security, is secure access to the NMS by users. The administrator should be able to login to the NMS from anywhere in case of urgency. So, the access to the NMS should not be
28
restricted to the secure subnet alone. To achieve this, a secure web server that uses HTTPS3 protocol is provided for remote login users. Another significant part of securing transit data is between the NMS and the managed elements. Considering the problem of managing heterogeneous environments, various techniques are used for different elements based on the support they offer. Elements that support security protocols for management as well as configuration (Class 3 & Class 4) can use them for secure communication without any modification. For the rest, it is difficult to incorporate security at the NE level since hardware modification is required. Hence, this problem is solved by grouping such NEs and placing them in a secure subnet. We have designed a secure transport mechanism using VPN tunnels, which takes care of transit security. A secure tunnel is setup between the NMS and the secure gateway which serves as the entry point for the traffic to the secure LAN (Local Area Network), where the NEs are placed. The different VPN mechanisms and their comparisons are given below. VPN schemes A VPN allows information to be sent securely across an insecure media. This media may typically be Internet, but may include any other connection media such as an internal network or leased line as is used for a WAN (Wide Area Network). The required capabilities of a VPN are as given below. • Encrypted Tunnels - Data packets are encrypted, encapsulated into another protocol and transmitted between two locations. • Authentication - Users must be authenticated to be sure no unauthorized persons are using the VPN. A security policy server may be used for this function. Digital certificates are used for stronger authentication. 3
HTTP over SSL - SSL layer provides the security for HTTP protocol.
29
• Address Management - For clients, a separate address must be assigned and kept private. • Key Management - Encryption keys must be generated, securely distributed and managed according to the security policy. Secure VPN techniques There are many secure VPN techniques out of which the commonly used are MultiProtocol Label Switching (MPLS) based VPNs, kernel space VPNs and user-space VPNs [32]. MPLS based VPN does not use cryptographic tunneling. Instead, it relies on the security of a single provider’s network to protect the traffic. It assumes a trusted network for VPN establishment. In kernel-space VPN, the encryption/decryption routines are placed in the kernel space (i.e., the encryption is done at the network layer). IPSec is the most widely used kernel -space VPN protocol. The user-space VPN uses the routines for encryption in the user-space itself (i.e., the encryption is done at the application layer). It is similar to an application running on a machine. Various implementations of SSL VPNs come under this category.
Comparison of various VPN techniques MPLS based VPN cannot be considered as we have an untrusted heterogeneous network. All the elements may not be owned by the same provider and may also not support MPLS. So this technique is ruled out. Kernel space VPNs are tightly coupled with the kernel and offers security at the lower layers of the protocol stack. IPSec is an internationally accepted kernel-space VPN standard. User space VPN tunnels secure the end-to-end layers of the protocol stack. Moreover, they are kernel independent, simple and easy to use and configure, and give performance comparable to that of kernel-space VPNs. In comparison with user space VPN (SSL VPN), IPSec has the following disadvantages [33]: 30
• IPSec is difficult to use effectively due to its complexity. Also, it has many possible configurations, some of which produce insecure architectures. • The nature of IPSec requires it to be tightly coupled with the OS kernel. If the code can interfere with kernel space, its failure is usually catastrophic for the entire system. A compromise of a kernel-coupled component can lead to instant root access. IPSec VPNs are implemented in kernel space, but SSL VPNs do not have this requirement. • Though IPSec is very flexible, as it can be used for protecting both TCP and UDP based protocols, there is an increase of complexity and processing overhead, as it cannot rely on TCP to manage reliability and fragmentation. • The initial handshake takes a long time in IPSec and a retransmit timer should be maintained. Also, IPSec adds extra bytes to the original packet. Apart from these issues, IPSec is bound to specific ports whereas SSL is not [34]. There are several user-space VPNs available, and of these we chose OpenVPN [35,36]. This is because OpenVPN has been already accepted as a standard and is the most widely used SSL VPN. A description of OpenVPN is given in Appendix B.
3.2.2
Access Control
Access control is the mechanism for restricting unauthorized people from entering a particular building, room, property or software system. The main focus here is to have a centralized access control mechanism to the NMS server as well as to the managed elements. This increases the security of the system and makes the access management easier for the administrator. Access control can be at many levels like application level, database level, OS level, NE level etc. It is very difficult for the user to remember his rights and permissions at each level and provide proper secure credentials for authentication. Hence, the 31
mechanism used to control the access should have proper authentication mechanism, such that it is strong enough to secure the system. Also, the mechanism should be designed in such a way that it is user friendly and easy to use. A login based authentication mechanism is used to access the NMS application. Every authorized NMS user has a login and password to enter the NMS application. Once authenticated, they are provided with a set of privileges. Creating these privileges is very crucial, as it differentiates on who can do what in the system as well as in the network. We have given a new dimension to this set of permissions by including the access permissions to the NEs as well as the NMS database. The various permissions and access information stored in the unified mechanism include the following: • NMS Operations: Various NMS operations like alarm management, provisioning, log management, addition/modification/deletion of elements, report generation etc can be restricted/permitted according to the user’s privileges. Also, operators are restricted according to their current role. Some of them should be allowed only to monitor the network, whereas some should be able to monitor as well as manage the network. The map based views of the managed network even can be varied depending on the user privileges. • NE Security Credentials: Each NE has authentication mechanism depending on the protocol being used for accessing it. If telnet/ssh/ftp is being used, then the authentication mechanism is a login/password. If SNMP (v1 or v2c) is being used, then the authentication mechanism is community string. In order to provide a remote login and obtain a command line interface (CLI) to these NEs, proper authentication credentials should be provided. • Database User Credentials: To access the database, proper user authentication credentials are required. Each database user will be assigned a set of privileges depending on the role of the user. 32
For easy and effective access control, we propose the concept called Single Sign-On (SSO). SSO is a specialized form of software authentication that enables a user to get authenticated once and gain access to the resources of multiple software systems. Here, we have a slight variation for this. Once logged into the NMS, the user gains a set of permissions which refers to set of privileges stored in the unified access mechanism. The operator will be allowed only to perform the set of NMS operations permitted by this access mechanism. Apart from that, when a user tries to connect to a managed element the NMS will take care of the authentication part and provide the user with a restricted command line interface (CLI). This means that even the commands executed at the CLI are controlled by the NMS and the user is allowed only a set of authorized commands (as mentioned in the unified access control). Likewise, any other secure credential can be saved in this mechanism and hence can be made secure and private. Moreover, the users are restricted from accessing the elements by omitting the NMS, as they are unaware of the secure credentials for access. Thus, this access control system provides a unified access control mechanism for the whole system with a level of privacy guaranteed. The advantages of this approach are listed below. • The NMS user can perform the authorized tasks even without knowing about his rights, permissions and other security related information for any NE. Here, the security information is maintained by the NMS alone and is not known to anyone else. This enhances the privacy of the system. • The NMS can control the user operations performed by providing a restricted CLI of the remote NE. • The user need not remember many passwords. Also, as the passwords are generated and stored by the NMS, they can be randomly generated and changed frequently. • The administrator can provide proper rights and regulations for each user from 33
a centralized location.
3.2.3
Secure storage
Database security requirements arise from the need to protect data: first, from accidental loss and corruption, and second, from deliberate unauthorized attempts to access or alter that data. New technologies and practices continually provide new arenas for unauthorized exploitation, as well as new ways for accidental or deliberate misuse to affect even stable products and environments. Securing storage can be done in three steps. 1. Database server security: Security of the server where the DBMS application is hosted is very important. Attacks to the server can be reduced by placing the database behind a firewall with strict rules and allowing only the NMS server to establish connection to it. There can also be software vulnerabilities in the DBMS which can cause severe security mishaps. Updating the server with the latest DBMS patches should be done to avoid such a situation. 2. Confidentiality of data: Data confidentiality can be achieved by encrypting the stored data. The major bottleneck in this case is that the database should support encryption. Various levels of encryption are possible if encryption is supported by the database - field level, record level, column level, table level, database level. Depending on the criticality, the level of encryption can be chosen. There can also be various combinations of encryption. For example, the index fields alone can be encrypted, then while searching for a particular record, each record’s index should be decrypted, compared and then encrypted. In worst case scenario this can go up to the maximum number of records in the table. If the non-index fields alone are encrypted, then the search is easier as it does not involve any decryption. When the required records are obtained, decryption is 34
used to obtain the non-index field values. Although this is better method than the former one in case of encryption overheads, the indices may contain many important details about the NE which are stored unencrypted. So, while using this scheme the indices should be chosen in such a way that the critical fields do not form any part of the indices. If the whole record is encrypted (i.e., both index and non-index fields are encrypted), then the security is more but the search overheads are also more as the indices are encrypted. If database do not support encryption, then confidentiality can be ensured only by encrypting at the OS level. This means that there should be a layer in between the DBMS and the file system which translates the queries from the DBMS, decrypts the files in the file system, operates on the relevant records and provides the result to the DBMS, and encrypts back the files. There may be cases where a file contains more than a table or one large table can be stored in multiple files. In that case, to execute on a single record in a table, the file(s) have to be decrypted. There are databases where each table is stored as a file. In such situations, join queries become cumbersome as two or more tables are involved in a single query. There should be a proper consensus between the performance trade-off and security level. For example, if the database contains access control information which is very critical for the system, then encryption can be applied at the OS level itself. If the data is important but not very critical, then the encryption can be done at the DBMS level (field level to table level). If the data is very frequently accessed, then it is important to check whether the encryption/decryption causes severe performance overheads. 3. Access control: Most of the database systems themselves provide mechanisms to restrict access to various table spaces in the application. This is done by
35
having a login and password. Accessing the database can only be done through the NMS, as we have a unified access control mechanism. Besides this restriction, all the connections to the database can be monitored by the NMS itself. An alerting mechanism can be developed so that any inappropriate access gets reported through the fault module of the NMS. Moreover, common security techniques like strong passwords4 , strict rules for access control and restricted permissions to table spaces can be adopted to enhance the security.
3.3
Summary
In this chapter, a generic framework has been proposed. Also, a solution is provided which implements the security aspects discussed in the framework. The solution has three relevant dimensions - transport security, access control and storage security which protect the system from various threats at different levels. Each dimension has its own relevance and underestimating any one of them can cause serious weaknesses in the security of the management system.
4
Passwords that are difficult to detect by both humans and computer programs, effectively protecting data from unauthorized access.
36
CHAPTER 4
Design and Implementation This chapter gives a detailed description on the design and implementation of each aspect of the proposed solution. Here, we consider the various levels of security already existing in the network and try to enhance them so that maximum security can be provided. The different dimensions of security, as per our framework are: 1. Transport security 2. Access control 3. Security of the stored data
4.1
Transport Security
From the classification of NEs (refer Section 3.2, page 26), it is clear that there cannot be a unique method to secure data in transit because different NEs support different levels of security. To achieve the maximum security possible for a given heterogeneous network, it would be better to make use of existing secure mechanisms where feasible and provide protection only for those elements that are in need. Hence, the solution is to make use of the security mechanisms already available with class 3 and class 4 elements and to use external mechanisms to provide security for data in transit for class 1 and class 2 elements. As we look at class 1 and class 2 elements, it is evident that they do not support any security primitives. To incorporate security at the NE level, re-engineering of the hardware and software is required. This is obviously not feasible in most cases. 37
Moreover, the transit data should be secure along its path from source to destination. To secure data during transit, protocol independent techniques would be better as the data can be secured irrespective of the protocol used for transfer. We propose the use of user-space tunneling mechanism to protect the NMS traffic [37]. These tunnels provide security at the transport or higher layers and thus provide end-to-end security. Moreover, they are kernel independent, simple and easy to use and configure, and give performance comparable with that of kernel-space VPNs. We conducted a study of user space VPNs (also called as SSL VPNs) like OpenVPN, Crypto IP Encapsulation (CIPE) etc, that are commonly used. OpenVPN was chosen for our implementation as it has emerged as a standard for SSL VPNs in the industry [35, 36]. The insecure NE problem is solved by grouping such NEs and placing them in a secure subnet (Fig. 4.1). The data is secured, with the aid of VPN software, while it traverses the public network. A secure gateway acts as the entry point for traffic and protects the entire subnet. This architecture not only solves the problem of managing a heterogeneous network, but also has the advantage of being independent of traffic type.
4.1.1
OpenVPN - User-space VPN
OpenVPN is an open source, user-space tunneling package, that uses the OpenSSL library to provide encryption and authentication of both the data and control channels [38]. It is easy to understand and deploy this package since it is kernel independent with a performance comparable to that of its counter- part, kernel-space VPNs. The use of common network protocols (TCP and UDP) makes it a desirable alternative to IPSec in situations where an ISP may block specific VPN protocols in order to force users to subscribe to a higher-priced service tier. Refer Appendix A for more 38
Fig. 4.1: Proposed transport security details on the OpenSSL enhancement carried out and Appendix B for further details on OpenVPN. The comparison with IPSec is given in Table 4.1. OpenVPN has two modes of operation based on the key used for encryption. 1. Static key mode - A pre-shared secret key exists at both ends of the VPN tunnel. With this key, the selected symmetric encryption algorithm is used to encrypt all traffic. 2. TLS mode - The secret key is exchanged using the Diffie-Hellman (DH) key exchange mechanism with all messages being digitally signed by both ends [39]. This secret key is then used for tunnel encryption. As mentioned above, OpenVPN in TLS mode uses DH protocol for key exchange. We implement a new secure secret key exchange mechanism based on RSA-KEM [40] and RSA-PSS [41]. The algorithms are explained in Appendix C. Through this, we have improved the key exchange mechanism of OpenVPN with the newly implemented one overlaid on OpenVPN. The generic design developed for this can be used in any user-space VPN mechanism with minor modifications. Additional to the implementation, we have developed a full fledged public key infrastructure (PKI) solution with a key server. The details are discussed in Subsection 4.1.2. 39
Table 4.1: IPSec vs OpenVPN Function
IPSec
OpenVPN
Configuration
hard
easy
Client authentication
must
option
Handshake time
slow
fast
Preshared key
yes
yes
Interoperability problems
yes
no
TCP application support
yes
yes
UDP application support
yes
yes
Throughput rate
high
high
Compression support
yes
yes
Configuration of support for NAT
difficult
easy
Courtesy: A Technical Comparison of IPSec and SSL, A Alshamsi and T Saito [34]
4.1.2
Improving key exchange in OpenVPN
The new secure secret key exchange mechanism is based on the RSA-KEM and RSAPSS schemes which are considered more secure than DH as per NESSIE consortium [42]. This mechanism offers OpenVPN a new hybrid mode which uses the static key mode functionality of writing the secret key into the file, but also has the features of TLS mode like key exchange and tunnel management (Fig. 4.2). Thus, the hybrid mode enhances the static key mode of OpenVPN by providing similar features as that of default OpenVPN TLS mode, with computationally provable secure key exchange mechanism. The enhancements are implemented in such a way that they are generic and can be reused for any user-space VPN solution. This can further be used to improve the VPN solutions that do not support on-the-fly key exchange mechanisms.
40
Security Gateway
NMS Server
Tunnel Establishment Secure Key Exchange Protocol
Key Exchange Server Server
Client
symmetric key
Client
symmetric key
OpenVPN tunnel OpenSSL
OpenVPN
Client
Server
OpenVPN
OpenSSL
Tunnel Management Telnet server
cmd status
Tunnel Mgmt Process
Tunnel Management Protocol Server
Client
Tunnel Mgmt Listener
Fig. 4.2: Design for secure transport The following were done as part of the implementation of the hybrid mechanism for key exchange. • PKI implementation [43]. • A multi-threaded key exchange server. • Design and implementation of Secure Key Exchange (SKE) protocol and a protocol for tunnel management (Fig. 4.2). The PKI includes a public/private key pair generator and a certification authority (CA) which generates digital certificates and certifies them. Moreover, a multithreaded key exchange server to exchange symmetric keys with utmost security has been developed. This server uses a newly designed protocol, namely Secure Key Exchange (SKE), based on RSA-KEM hybrid key exchange scheme and RSA-PSS digital signature scheme. Added to these features, a tunnel management protocol has been implemented for managing the encrypted tunnels (Fig. 4.2).
41
4.1.3
Protocols
Secure Key Exchange (SKE) Protocol:
The key exchange is done when any
security gateway (client) connects to the NMS (server). The server listens at a specific port to which the client sends a key request. Both the ends first authenticate each other through exchange and verification of digital certificates. Thereafter, in response to a ”Key Request” from the client, the server uses the RSA-KEM scheme to generate and send the key across. All the exchange messages are digitally signed using the RSA-PSS scheme thus guarding against man-in-the-middle attack (Fig. 4.3). The exchanged key is used as the seed to a key scheduler algorithm (internally uses the AES key scheduling algorithm) that generates 16 different keys. This algorithm is run on both sides and the keys are written into a key file which is used for tunnel encryption. This step in the protocol is specific to OpenVPN as its key file contain 16 different keys, each used for a specific secure functionality like hashing, encrypting etc. The overheads due to this key exchange come in play only once i.e. when the tunnel is initially established. Thereafter, all the NMS traffic will flow with complete security through this tunnel with no overheads of key exchange or certification. The digital certificate exchange can be totally avoided in case the NMS server itself is assumed to be the CA, since the main aim of this exchange is to authenticate the public key of the other party. Tunnel Management Protocol:
When a secure gateway comes up initially, a
client management listener is also started that listens to the management requests coming from the server. Tunnel management is done from the NMS server by using the telnet protocol locally. This means that the tunnel management can only be done from the NMS server by connecting to a specific port. Also, using telnet from
42
Server (NMS Server)
Client (Security Gateway) tiation
Key Exchange Ini
cate
Send Client certifi Client certificate verification
Send Server certifi
cate Server certificate verification
gned)
Key Request (si RSA−KEM key generation
Cipher text with
key (signed) RSA−KEM key extraction
ned)
Key Received (sig
KEY SCHEDULER RUN LOCALLY AT BOTH ENDS TO GENERATE 16 DIFFERENT KEYS FROM THE EXCHANGED KEY WHICH ARE USED BY OPENVPN FOR VARIOUS PURPOSES.
Fig. 4.3: Secure Key Exchange protocol remote machines to the NMS server is not allowed. Therefore, to perform tunnel management the administrator has to physically come to the NMS server and execute these commands. Thus, the commands given in the telnet prompt are within the same machine (i.e NMS server) and creates no security issues. On providing the management command at the telnet prompt, the server sends appropriate requests to the client, management listener and coordinates various administrative functionalities provided for tunnel management. This protocol (Fig. 4.4) was developed mainly to enhance the static mode OpenVPN with the same features as provided by the TLS mode. In this protocol, the VPN client has a management process listening for the commands from the VPN server. These commands enable a single window tunnel management for multiple clients. The commands supported are: 1. status - current status of the tunnels. i.e., how many VPN tunnels are connected to the NMS server, what are the client’s real and virtual IPs, port number to 43
Mgmt Process (NMS Server)
Mgmt Listener (Security Gateway) Listens on port 10001. Interpret mgmt commands.
Telnet server on port 10000. Issue telnet command.
shutdown OpenVPN client instance successfully terminated. OK Server OpenVPN instance shutdown.
restart New OpenVPN client instance started. OK Display status and close socket.
Fig. 4.4: Tunnel Management protocol - newkey command which they are connected etc. 2. shutdown hclientIP i - shutdown the VPN client. 3. restart hclientIP i - restart the VPN client. 4. newkey hclientIP i - generate and exchange a new key with the VPN client. 5. quit - quit the management console. newkey command:
When a newkey command is given at the management prompt,
the server sends a request to the client management listener to shutdown the client instance of the OpenVPN. Once the client instance is successfully shutdown, the client management listener sends an ‘OK’ message to the server. As soon as the server receives this message, the server shuts down the OpenVPN server instance for that particular client and on successful completion sends a client restart message. The client receives the message and restarts the client. Whenever the client starts, first a new key is exchanged using the SKE protocol, thereby successfully completing the newkey command. In short, the newkey command comprises of both the commands shutdown and restart.
44
4.2
Access control Secure Network A
NMS Server with LDAP lookup
Firewall
Secure transport mechanism
Managed NE
B LDAP information base
C NMS Client from remote locations using https
Fig. 4.5: Multi-tier architecture for single sign-on The access control mechanism should take care of the various levels at which access restrictions can be employed (refer Fig. 4.5). The levels are explained in the following subsections.
4.2.1
NMS level
This indicates the set of permissions the NMS user has in the NMS application. There are various operations like alarm management, addition/modification/deletion of elements, provisioning, log management, report generation etc in an NMS application, which can be restricted/permitted according to the user’s privileges. For example, an operator need not have the rights to add/delete an element but he may be able to modify certain properties of that element.
4.2.2
NE level
Each NE has an authentication mechanism depending on the protocol being used for accessing it. If telnet/ssh/ftp is being used, then the authentication mechanism is a login-password pair. If SNMP is being used, then the authentication mechanism is a community string. In order to provide a remote login and receive a remote command line interface (CLI) of these NEs, proper authentication credentials should be provided. 45
Once a user logs into the NMS, he is provided with a set of authentication credentials to each element managed by him. Here on, whenever he tries to remotely login to this element, he need not provide the credentials. Instead, the NMS will take care of the same and provide him with a CLI. The interesting part is that from now on the NMS can even control the user operations through CLI. A layer is provided between the actual remote login prompt and user’s prompt so that only authorized set of commands can be executed by the user. Hence, a secure and restricted CLI is provided to the user which is a new concept. To promote the SSO based NE access control, whenever an element is added to the NMS (i.e., whenever an element becomes a managed one), the users and passwords of that element is also provided. This is for the initial addition phase. As part of element addition, the passwords are changed by the NMS and the changed ones are used for further operations. This makes sure that the user is unaware of the current NE password and hence prevents him from entering the element directly or through some alternate means other than the NMS.
4.2.3
Database level
The database can have many users with different set of regulations. This can be easily achieved by the access control mechanisms provided by the DBMS software. The database users should be mapped with the NMS users appropriately to achieve desired level of access control. From the above descriptions, it is clear that the access control mechanisms should be fine-grained. In an NMS scenario, there can be many users and having the controls at user level might be difficult to handle. We propose the usage of role based access control mechanism. Each user belongs to a group and these groups are given the permissions. There can be 100 operators who belong to a single group named operator. All these 46
users get the permissions of the group operator. This can be considered an appropriate mechanism since all the users of a particular group will be interested in the same set of operations.
4.2.4
Design of Single Sign-On
Single Sign-On (SSO) is a concept of authenticating a user once and allowing him to access multiple resources which otherwise require separate authentication. Although the concept of SSO appears simple, it has major implementation issues. The managed network may be huge and the number of users managing them can also be large. This creates problem of huge data management. The next issue is how to map each user to each managed element. The mapping should be flexible such that the granularity of access control can be changed at any point of time. The last, but not the least, problem is the time taken to retrieve access information. The large number of users and network assets pose a challenge to fast methods for retrieval. A directory is a set of objects with similar attributes organized in a logical and hierarchical manner. There should be some methods for querying and modifying the directory services. Lightweight Directory Access Protocol (LDAP) is an application protocol that allows to access the directory contents and make necessary changes. It is the protocol which is widely used for retrieving user details from large corporate directories. The earlier directory access protocol (DAP) required the Open Systems Interconnection (OSI) protocol stack. LDAP simplifies the interface by providing relatively simple API over TCP/IP and thus replacing the ASN.1 encoding with textual encoding [44, Chapter 9]. In this case, we have large number of permissions for each user in the NMS as well as in the managed elements. Hence, LDAP is a good choice for selecting the appropriate entry in the directory service of permissions. To solve the issue of mapping each user to managed element, a role based approach 47
has been adopted. An LDAP schema has been defined and object definitions have been created. These definitions are for managed elements, NMS operations, NMS users, NMS user groups, NMS user groups to element mappings and NE operations. A standard set of NE operations are already defined. While adding an element to the managed element list, the following steps are taken: • Step 1: The managed element object is added, which includes the managed element details like IP address, location, type of protocol supported etc. • Step 2: The managed element user details and security credentials like user name, current password, read/write community string etc are added. When this is done, internally NMS changes the security credentials and further access to the NE can be done only through the NMS. While adding an NMS user, details like NMS user name, password, group name, etc have to be given. If the group do not exist, then the group should be created first and then the user. NMS operations are also defined as separate objects with attributes defining the operation to be carried out. NMS user group addition has the following steps: • Step 1: Add the NMS user group with proper name and description. • Step 2: Create a mapping of NMS operations to the group. • Step 3: The NE details and NE operations are also mapped to the group. This defines the set of permissions for each group on each NE.
4.2.5
Implementation
As part of implementation, the above mentioned objects were defined using LDAP schema in OpenLDAP (ver 2.0.27), an open source LDAP implementation. To increase the retrieval speed, Berkeley database (bdb) was used as the backend for OpenLDAP. A Java Naming and Directory Interface (JNDI) (Java ver. 1.4.2 05) based LDAP client was developed which queries the LDAP server and finds the set of permissions for the 48
currently logged in user. This set of permissions were then used for all the operations that the user can perform through the NMS and hence provides the unified access control mechanism. The next issue is to provide a restricted CLI for remote NEs. This is achieved by providing a layer for filtering out the commands provided by the user. The user is provided by a terminal which sends the commands to a filter. The filter in turn checks whether the commands are authorized ones for this particular user. If yes, then these commands are sent to the actual remote terminal which gets executed and the output is shown in the terminal at the user’s end. In short, the user gets the feel of the actual terminal where he can execute a set of permitted commands. This restricted CLI is also implemented in Java (ver. 1.4.2 05) and integrated along with the unified access control mechanism. However, the complete access information has not yet been implemented into this unified mechanism. Only telnet and ssh based login permissions required by the restricted CLI has been incorporated to the unified access control mechanism at present.
4.3
Security of stored data
Database security has a significant role in securing the whole system. We propose monitoring and managing of the database by the NMS itself. By providing the SSO based access control, we allow only the NMS server to access the NMS database. The NMS can monitor for other access requests to the database and raise alerts as they are unauthorized requests. Added to this, a maximum number of connections that it can support simultaneously can be defined. This reduces the chances of DoS (Denial of Service) attack. The monitoring is based on the log files of the database. Hence, the NMS provides a post-facto auditing mechanism to figure out the unauthorized connection requests to the database. 49
Various other measures can also be implemented for securing the database. The database server can be safeguarded from the external security threats by placing it behind a firewall such that only NMS server can connect to the database server. Patch updation for the DBMS server helps in mitigating the application vulnerabilities. All the database users should have strong passwords and fine grained access control should be imposed for each user. To ensure data security, encryption is essential. Hence, the database should support encryption to provide confidentiality for stored data and this is vendor dependent. Oracle provides the most comprehensive set of security features among all DBMS vendors. With latest versions, it supports strong encryption algorithms and network encryption. However, it lacks support for pluggable crypto and support for hardware crypto accelerator. IBM DB2 supports label based access control (LBAC). Labels can be based on any criteria and once created, can be associated with individual columns and rows in a table to protect the data held there. MySQL, yet another popular open-source RDBMS, supports encryption and compression using in-built functions. It provides implementations for AES (Rijndael), DES, MD5 and SHA1 algorithms [45, Case Study: ORACLE, DB2]. Database-level encryption protects the data within the database management system (DBMS) and also protects against a wide range of threats, including storage media theft, well known storage attacks, database-level attacks, and malicious database administrators (DBA). This eliminates all changes required in the application-level model, and also addresses a growing trend towards embedding business logic within a DBMS through the use of stored procedures and triggers. Since encryption/decryption only occurs within the database, this solution does not require an enterprise to understand or discover the access characteristics of applications to the data that is encrypted.
50
While this type of solution can certainly secure data, it does require some integration work at the database level, including modifications of existing database schemas and the use of triggers and stored procedures to undertake encrypt and decrypt functions. Additionally, careful consideration has to be given to the performance impact of implementing a database encryption solution, First, enterprises must adopt an approach to encrypt only sensitive fields. Second, this level of encryption must consider leveraging hardware to increase the level of security and potentially to offload the cryptographic process in order to minimize any performance impact. Storage-level or file-system level encryption is well suited for encrypting files, directories, storage blocks, and tape media. In large storage environments, this type of encryption addresses a requirement to secure data without using logical unit number (LUN) masking or zoning. While this solution does provide the ability to segment workgroups and provides some security, it presents a couple of limitations. First, it only protects against a narrow range of threats, namely media theft and storage system attacks. However, storage-level encryption does not protect against most application or database-level attacks, which tend to be the most prominent type of threats to sensitive data. Second, current storage security mechanisms only provide block-level encryption; they do not give the enterprise the ability to encrypt data within an application or database at the field level. Consequently, one can encrypt an entire database, but not specific information housed within the database. As part of database monitoring, audit trails can also be maintained which keep track of all the major events in the database. Log files should be maintained for all the discrete events happening in the database. If required, a user interface that depicts the important fields from the log files can be included. Moreover, well-implemented backup mechanisms should be in place so that the data can be recovered in case it
51
gets lost or corrupted. The backed up files should be maintained securely by limiting the access to administrators only [45, Chapter 12].
4.3.1
Collected data
The database in the NMS contains various types of data. • Fault data - All the events including alarms. • Configuration data - Alarm configuration, poll configuration, SLA configuration and other such configuration data • Audit data - Event logs, operations log (all the operations done in the NMS) • Performance data - Polled data from various NEs • Security data - Access control, passwords, managed element secure credentials Levels of encryption for collected data The levels of security is decided by considering the performance and importance of the data. There are cases where the importance of the data has more priority than performance. For example, the passwords of NMS users should be stored as encrypted/hashed values as it is very important and the overhead due to this can be neglected. But at the other extreme, the performance of the NMS becomes very important in cases like report generation, trend analysis etc. In this case, if the performance data is encrypted for security reasons, the time taken for the NMS to show historical reports on some parameter of an element will be high. This cannot be ignored as it will affect the product’s market value. So a proper balance should be maintained between security and performance. High security: The most important part of the database is the data related to security and its allies. The data related to access control, user passwords, and other secure credentials should be shielded against threats. So this data can be kept in a separate 52
database. In the framework we have proposed a unified access control mechanism which uses bdb as back-end database to store all the access related information. This is further used by LDAP for enabling the proper levels of restriction. In this case, the whole bdb database can be encrypted and stored so that the security is maximum Medium security: The configuration data should be kept secure as it reveals the details about the configuration parameters being used. We can have DBMS level encryption. Even though the database level encryption can be done, performance of the NMS is also a major bottleneck. The audit data can also be placed in files that are encrypted and can have restricted viewer ship. For example, the log management module in the NMS should display the log files only to admin users. Low security: All the performance data and fault data should be secure. But on encrypting these data, the performance of the NMS can go down drastically. So there should be a proper consensus on whether performance or security should be given higher priority.
4.3.2
Common measures
Many sophisticated measures are usually in place to prevent unauthorized access at the network and OS levels and are incorporated in off-the-shelf or custom-built database application systems. A common strategy, known as defense-in-depth, is used to combat attacks and provide good security. This strategy uses multiple layers of security rather than trying to build an ultimate security layer. Now the attacker needs to get many things right and at the same time - something that is much harder to do. As part of this strategy, various steps are taken by the administrators out of which some are given below: • Place the database behind a firewall. If possible, provide with Intrusion Detection/Prevention Systems (IDS/IPS). 53
• Restrict the number of simultaneous connections with a maximum value. Allow only the NMS server to make connections to the database (Denial of service attack mitigation). • Harden the OS of the machine on which the database server resides. • Apply the relevant latest patches for the database server. • Fine grained access permissions should be applied to each user accessing the database. • Database users should have strong passwords and a password policy should be implemented.
4.4
Summary
In this chapter, we have discussed our solutions for each security dimension to mitigate the various security threats introduced by an NMS. The user-space VPN based secure transport and unified access control are new directions in providing security for network management. As stored data security depends highly on the database specific security mechanisms, we have proposed to store data by classifying them into groups and secure them using appropriate mechanisms. Also, common measures used for database security have been listed out.
54
CHAPTER 5
Performance Evaluation and Analysis Having described our security framework, we now analyze its performance and compliance with an ITU-T framework standard. Performance evaluation is done by measurement whereas, compliance evaluation is done by comparison with ITU-T Recommendation X.805 security framework. Additionally, our framework implementation is analyzed by comparing it with popular NMS products available in the market (as per the survey results in Table 2.1).
5.1
Experimental Analysis
The aim of these experiments are to estimate the overheads (if any) due to our implementation when compared with default OpenVPN. The parameters of interest are time taken for key exchange between the client and server, CPU utilization and memory utilization for the server machine. Key exchange time measurement and various size file transfers are the experiments done to measure the required parameters. The former experiment provided the key exchange time whereas the latter provided the CPU and memory utilization for the server machine.
5.1.1
Setup
Server - AMD Sempron 1.6 GHz processor, 512 MB RAM, 100 Mbps Ethernet card placed in one LAN.
55
Fig. 5.1: Local and remote setup Client - AMD Athlon 2.1 GHz processor, 512 MB RAM, 100 Mbps Ethernet card placed in another LAN. Link - 2Mbps link connecting the two different LANs. For key exchange time measurement, we made a local and a remote setup (refer Fig. 5.1). In the local setup, the server instance and client instance of OpenVPN (both default and enhanced) were running on the same machine. This was done to estimate the overheads due to implementation without considering the network delays. The remote setup had server and client running on different machines with specifications as given above.
5.1.2
Key exchange time measurement
This experiment was conducted with remote setup as well as local setup. The local setup as mentioned earlier considers an ideal situation with no network delays as both the server and client was in the same machine. The remote setup considers the real scenario. The experiment was repeated 10 times and the average values were calculated. The comparison between the OpenVPN (ver. 2.0.2) Diffie-Hellman (DH) key exchange and the OpenVPN with SKE is shown in Table 5.1. Analysis: The time for key exchange can be further reduced if the digital certificates need not be exchanged each time. Once the certificate exchange has been done, it can be ignored till it expires and then, the new certificate exchange has to be done. This 56
Table 5.1: Key exchange time comparison Key exchange mechanism
remote
local
OpenVPN-DH
0.157
0.126
OpenVPN-SKE
0.226
0.137
0.5
No Encryption OpenVPN-DH OpenVPN-SKE
4
% Memory Utilization
% CPU Utilization
5
Time taken (in seconds)
3 2 1 0
No Encryption OpenVPN-DH OpenVPN-SKE
0.4 0.3 0.2 0.1 0
10 100
500 File size (in MB)
1000
10
(a) % CPU utilization
20 100 500 1000 File size (in MB)
(b) % Memory utilization
Fig. 5.2: Server side measurements (remote setup) depends on the validity of the certificate which normally, is of the order of six months to an year as per the level of security desired.
5.1.3
File transfer performance
The measurements were carried out on the remote setup with file transfers of various sizes (10 MB, 20 MB, 100 MB, 500 MB and 1000 MB) through the VPN tunnel. The aim was to calculate the CPU utilization, memory utilization and the time taken for file transfer and estimate whether overheads are caused. The file transfer was conducted 10 times for each file size and the average values were calculated. The results are as shown in Fig. 5.2 and Fig. 5.3. Analysis: From the graph it is clear that the CPU utilization is not increased con-
57
Time taken (in minutes)
No Encryption OpenVPN-DH OpenVPN-SKE
6000 5000 4000 3000 2000 1000 0 10
20 100 500 1000 File size (in MB)
Fig. 5.3: Time taken for file transfer (remote setup) siderably. This means that the CPU utilized is almost the same for OpenVPN-DH and OpenVPN-SKE (Fig, 5.2(a)). Also, the time taken for file transfers through OpenVPN-DH and OpenVPN-SKE is almost the same (Fig. 5.3). Memory utilization is less in case of OpenVPN-SKE because it uses the static key mode, which requires less memory compared to the OpenVPN-DH (Fig. 5.2(b)).
5.2
Compliance of the solution
In this section we evaluate the proposed solution by analyzing the compliance with respect to ITU-T Recommendation X.805. An overview of the security framework standard is given below (refer Subsection 5.2.1).
5.2.1
ITU-T Recommendation X.805
This recommendation provides a standard security framework for open systems providing end-to-end communications. The framework components are • Security Dimensions: This comprises of a set of security measures designed to address a particular aspect of network security. The eight security dimensions are as given below: 1. Access control - restricts unauthorized usage of resources 2. Authentication - verifies the identities of entities
58
3. Non-repudiation - prevents an entity from denying the fact of having performed an action/operation 4. Data confidentiality - protects data from unauthorized disclosure 5. Communication security - information flows between authorized end points 6. Data integrity - ensures the correctness or accuracy of data 7. Availability - no denial of authorized access to network resources 8. Privacy - protection of information that might be derived from observation • Security Layers: They are a hierarchy of equipments and facility groupings. Each security layer has unique vulnerabilities, threats and mitigations. The three different security layers are 1. Application layer 2. Services layer 3. Infrastructure layer • Security Planes: These planes represent the types of activities that occur on a network. The three distinct planes identified are 1. Management plane 2. Control plane 3. End-user plane • Security Threats: The various security issues that are addressed by this framework architecture. The five major threats are 1. Destruction of information and/or other resources 2. Corruption or modification of information 3. Theft, removal or loss of information and/or other resources 4. Disclosure of information 5. Interruption of services Each security plane is applied to every security layer to yield nine security perspectives. Each security perspective has unique vulnerabilities and threats. All the eight security 59
Fig. 5.4: Security framework for end-to-end network security dimensions are applied to each security perspective (refer Fig. 5.4). In short the recommendation can be summarized as: The intersection of each security layer and each security plane provides a security perspective where security dimensions can be applied to counteract the security threats. The standard also give details about how the security dimensions map into the security threats (refer Table 5.2.1). Thus, it provides a systematic, organized way of performing network security assessments and planning.
5.2.2
Analysis
For analysis we consider only the management security plane as the solution is for a network management scenario. The secure tunneling mechanism provides data confidentiality, non-repudiation, transit data integrity, communication security and availability (security against passive attacks). The unified access control mechanism takes care of access control, authentication and privacy. Thus, the proposed solution covers all dimensions except availability due to active interruption attacks like DoS (Denial of Service) and stored data integrity. 60
Table 5.2: Mapping of security dimensions to security threats Dimensions
Threats Destruction
Corruption
Theft
Disclosure
Interruption
Access control
✔
✔
✔
✔
✖
Authentication
✖
✖
✔
✔
✖
Non-repudiation
✔
✔
✔
✔
✔
Data Confidentiality
✖
✖
✔
✔
✖
Communication security
✖
✖
✔
✔
✔
Data Integrity
✔
✔
✖
✖
✖
Availability
✔
✖
✖
✖
✔
Privacy
✖
✖
✖
✔
✖
✔ - Threat coverage, ✖ - No threat coverage
5.3
Framework Implementation Evaluation
In this section, we list down the features available in the implementation of the proposed framework and classify them according to the security dimensions mentioned in Chapter 2. This is done to evaluate the framework implementation along with the popular NMS products available in the market for which the survey was conducted. The table given below (Table 5.3) can be considered as a row in the survey results table (Table 2.1).
5.4
Summary
In this chapter different evaluations of the proposed solution have been done. First, a performance analysis of the secure tunneling mechanism is explained. Then, a compliance analysis of the total solution with respect to ITU-T Rec. X.805 is done. Finally,
61
Table 5.3: Features in the framework implementation Data Security Protocol Dependent
✔
Protocol Independent
Access control Storage
NMS
NE
✔ ✚ ✔ ✔ ✔ - Available, ✚ - Partially available
DB
✚
the implementation of the security framework is compared with its counter-parts popular in the market as per the security dimensions mentioned in Table 2.1.
62
CHAPTER 6
Conclusions 6.1
Summary
The goal of network management security is to control access to network resources according to local guidelines so that the network cannot be sabotaged (intentionally or unintentionally) and sensitive information cannot be accessed by those without appropriate authorization. The objectives of this thesis were to study the various security threats posed while managing a heterogeneous network and present a solution that can be used in securing an NMS and hence improve the management capabilities. To learn about the current state of NMS security, a survey on NEs as well as NMSs were carried out. The survey on NEs resulted in a classification of NEs to four different groups whereas the survey on NMSs helped in estimating the available NMS products and their security principles. Through this thesis, we propose a generic framework for secure network management. This thesis has resulted in the following: 1. Generic secure framework: This framework can be used while designing a secure solution for network management. All the aspects of security for network management has been listed out in this framework. 2. User-space VPN: To secure transport between the NMS and NEs, we have proposed to use user-space VPN in conditions where there is no security support at the NE’s end. 63
3. Secure Key Exchange protocol: This protocol has been developed to enhance the key exchange mechanism. The generic client-server architecture implementation of this protocol is done so as to provide easy integration with any user-space VPN software. 4. Single Sign-On mechanism: This mechanism is normally used to gain access to resources of multiple software systems. Here we have used the same principle to gain access to different NEs. This also provides a unified access control mechanism for the NMS application as well as to the NEs and the database, with LDAP as protocol for access information lookup. Since the user is not aware of the NE’s secure credentials, he can access the NE only through the NMS. This also restricts the user from accessing the NEs through some other insecure mechanisms and enhances the privacy of the system. 5. Restricted remote terminals: While logging in to the NE, the user need not provide the user name and password as it is a Single Sign-On system. Once logged in, the user is provided with a terminal on which he can execute a set of permitted commands. 6. Database monitoring: The database used for storing the NMS collected data can be monitored by the NMS itself and various security threats and illegal accesses can be reported to the administrator. ITU-T Recommendation X.805 covers the major security aspects for an opens system providing end to end communication. The proposed solution is compliant with the standard security framework proposed by the recommendation. Moreover, it provides security at the transport level and access control level as shown by in Table 5.3.
64
6.2
Criticism of the work
Although the solution covers most of the security dimensions, it fails to provide protection against active interruption attacks like DoS, and stored data integrity issues. The solution also depends on the security mechanisms available in the database and hence falls short in providing database security independent of vendor specifications.
6.3
Future work
The SKE protocol and tunnel management protocol have been developed in such a way that they can be applied to any user-space VPN package. For testing purposes, we have overlaid it on OpenVPN rather than integrating it. Integration of SKE protocol with OpenVPN might have an improvement in performance. The Single Sign-On concept has been used only to implement the restricted terminal provision. This can be expanded to include all the access control credentials used by an NMS. The solution is limited in case of active attack threats and stored data security issues. There is scope for future research work. Database security should be provided independent of the vendor. The complete solution has to be implemented in an NMS (here CygNet) and deployed in a real heterogeneous telecom network. Once deployed in a real scenario, the actual security problems can be studied in a broader perspective and approaches can be developed, thus enhancing the solution.
65
APPENDIX A OpenSSL Enhancements A.1
Introduction
OpenSSL is an open source cryptography toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) network protocols and related cryptography standards required by them. It provides a library in ANSI C library which helps in building applications that use SSL/TLS for secure functionalities [38]. The openssl program is a command line tool for using the various cryptography functions of OpenSSLs crypto library from the shell. It can be used for: 1. Creation of RSA, DH and DSA key parameters 2. Creation of X.509 certificates, CSRs and CRLs 3. Calculation of message digests 4. Encryption and decryption using ciphers 5. SSL/TLS client and server tests 6. Handling S/MIME signed or encrypted mail
A.2 A.2.1
Enhancements OpenSSL Engines - Introduction
ENGINE is a component that was added to support alternative cryptography implementations, most commonly for interfacing with external crypto devices (e.g., accelerator cards). These objects act as containers for implementations of cryptographic
Table A.1: AES-128-CBC speed comparison, bytes/sec Block size
16 byte 64 byte 256 byte 1024 byte
8192 byte
OpenSSL
29892
31772
32285
32692
32724
Our impl
22328
23612
23967
24025
23920
algorithms and support a reference-counted mechanism to allow them to be dynamically loaded in and out of the running application. The functionality that can be provided by an ENGINE implementation includes the following abstractions: • RSA METHOD - for providing alternative RSA implementations. • DSA METHOD, DH METHOD, RAND METHOD - alternative DSA, DH, and RAND. • EVP CIPHER - potentially multiple cipher algorithms (indexed by unique id). • EVP DIGEST - potentially multiple hash algorithms (indexed by unique id). • Key-loading - loading public and/or private EVP PKEY keys.
A.2.2
Software Engine - Contribution
A software engine was developed through which a self implemented AES (Rijndael) encryption algorithm (implemented in C) was integrated and tested [43]. This can be easily upgraded to integrate with any hardware based AES encryption also. Performance evaluation was carried out by plugging our own AES engine to OpenSSL0.9.7a. Comparison have been carried out with the default AES implementation of OpenSSL-0.9.7a and the results are as shown in Table A.1. The speed option in OpenSSL has been used for comparing the number of operations performed in a given time interval. In OpenSSL implementation, the lookup tables used by the AES algorithm are hard coded. In our implementation these tables are randomly generated. So the 67
Table A.2: AES-128-CBC table space and time taken comparison Time taken for generation of tables
0.2 milliseconds
Table space used by
OpenSSL
10 * 4 * 256 = 10240 bytes
AES implementations
Our own
4 * 256 + 4 * 2 * 256 = 3072 bytes
number of bytes processed per second reduces but this gives the flexibility of choosing the exponent value for the AES tables and also saves memory.
A.2.3
Further Enhancements
Apart from the engine implementation, the following crypto routines have been successfully integrated and tested with the OpenSSL crypto toolkit: 1. The SHA-256 hash algorithm 2. A Pseudo Random Byte Generator (PRBG) as per the NIST-Recommended Random Number Generator based on ANSI X9.31 3. RSA-PSS digital signature scheme 4. RSA-KEM-DEM hybrid encryption scheme The implementation of these above mentioned encryption schemes were done using GMP library, whereas OpenSSL uses BIGNUM library. These encryption schemes are only available as command line tools but not as APIs (Application Programming Interfaces). So the scope for future work includes the implementation of these schemes using BIGNUM library and integrating it with OpenSSL.
68
APPENDIX B OpenVPN Features B.1
Introduction
OpenVPN is a robust and highly flexible VPN daemon designed and implemented by James Yonan [35]. It supports SSL/TLS security, Ethernet bridging, TCP or UDP tunnel transport through proxies or NAT, support for dynamic IP addresses and DHCP, scalability to hundreds or thousands of users, and portability to most major OS platforms. It derives much of its crypto capabilities from OpenSSL, an open source crypto library in C. It supports conventional encryption using a pre-shared secret key (Static Key mode) or public key security (SSL/TLS mode) using client & server certificates. OpenVPN also supports non-encrypted TCP/UDP tunnels and is designed to work with the TUN/TAP virtual networking interface that exists on most platforms. Overall, OpenVPN aims to offer many of the key features of IPSec but with a relatively lightweight footprint.
B.2
Merits of OpenVPN
The principal strength as compared to other VPN solutions available is its crossplatform portability across most of the known computing universe, excellent stability, scalability to hundreds or thousands of clients, relatively easy installation, and support for dynamic IP addresses and NAT. OpenVPN runs on Linux, Solaris, OpenBSD, FreeBSD, NetBSD, Mac OS X, and Windows 2000/XP. Since it is written as a user-
space daemon rather than a kernel module or a complex modification to the IP layer, porting efforts are dramatically simplified. OpenVPN has been rigorously designed and tested to operate robustly on unreliable networks. A major design goal of OpenVPN is that it should be as responsive, in terms of both normal operations and error recovery, as the underlying IP layer that it is tunneling over. That means that if the IP layer goes down for 5 minutes, when it comes back up, tunnel traffic will immediately resume even if the outage interfered with a dynamic key exchange which was scheduled during that time. OpenVPN has been built with a strongly modular design. All of the crypto is handled by the OpenSSL library, and all of the IP tunneling functionality is provided through the TUN/TAP virtual network driver. The benefits of this modularity can be seen, for example, in the way that OpenVPN can be dynamically linked with a new version of the OpenSSL library and immediately have access to any new functionality provided in the new release. For example, when OpenVPN is built with the latest version of OpenSSL, it automatically has access to new ciphers such as AES-256 (Advanced Encryption Standard with 256 bit key) and the encryption engine capability of OpenSSL that allows utilization of special-purpose hardware accelerators to optimize encryption, decryption, and authentication performance. In the same way, OpenVPN’s user-space design allows straightforward porting to any OS which includes a TUN/TAP virtual network driver. OpenVPN is easy to use. In general, a tunnel can be created and configured with a single command (and without any required configuration files). OpenVPN’s documentation contain examples illustrative of its ease of use. Running Redhat 7.2 on a Pentium II 266MHz machine, using TLS-based session authentication, the Blowfish cipher, SHA1 authentication for the tunnel data, and tunneling an FTP session with
70
large, pre-compressed files, OpenVPN achieved a send/receive transfer rate of 1.455 megabytes per second of CPU time (combined kernel and user time). This shows that OpenVPN is fast. It uses an industrial-strength security model designed to protect against both passive and active attacks. OpenVPN’s security model is based on using SSL/TLS for session authentication and the IPSec ESP protocol for secure tunnel transport over UDP. OpenVPN supports the X.509 PKI or session authentication, the TLS protocol for key exchange, the OpenSSL cipher-independent EVP interface for encrypting tunnel data, and the HMAC-SHA1 algorithm for authenticating tunnel data. While OpenVPN provides many options for controlling the security parameters of the VPN tunnel, it also provides options for protecting the security of the server itself, such as –chroot for restricting the part of the file system the OpenVPN daemon has access to, –user and –group for downgrading daemon privileges after initialization, and –mlock to ensure that key material and tunnel data is never paged to disk where it might later be recovered. On Windows, OpenVPN can read certificates and private keys from smart cards which support the Windows Crypto API. OpenVPN gives an extensible VPN framework which has been designed to ease site-specific customization, such as providing the capability to distribute a customized installation package to clients, or supporting alternative authentication methods via OpenVPN’s plug-in module interface. OpenVPN also offers a management interface which can be used to remotely control or centrally manage an OpenVPN daemon. The management interface can also be used to develop a GUI or web-based front-end application for OpenVPN.
B.3
OpenVPN - Available Features
OpenVPN provides various types of tunneling capabilities. It allows to tunnel 71
1. any IP subnetwork or virtual Ethernet adapter over a single UDP or TCP port, 2. networks whose public endpoints are dynamic such as DHCP or dial-in clients, 3. networks through connection-oriented stateful firewalls without having to use explicit firewall rules, 4. networks over NAT. Additional to these tunneling mechanisms, it also creates secure Ethernet bridges using virtual tap devices. OpenVPN supports all of the encryption, authentication, and certification features of the OpenSSL library to protect the private network traffic as it transits the Internet. Also, it works with various ciphers, key sizes, or HMAC digest (for datagram integrity checking) supported by the OpenSSL library. OpenVPN helps in configuring a scalable, load-balanced VPN server farm using one or more machines which can handle thousands of dynamic connections from incoming VPN clients. It uses real-time link compression and traffic-shaping to manage link bandwidth utilization. It also supports various modes of operations - static, pre-shared keys and TLS-based dynamic key exchange, Moreover, OpenVPN can be controlled using a GUI on Windows or Mac OS X.
72
APPENDIX C RSA-KEM and RSA-PSS C.1
Introduction
The RSA based Key Encapsulation Mechanism (KEM) is one of the simplest mechanisms of this type. It uses the RSA trapdoor permutation as a security mechanism. It is included in the evaluation process as a de facto standard for a KEM-DEM based cryptosystem since it has been proposed for inclusion in the ISO/IEC standard 180332[489]. RSA-PSS, as submitted by RSA Labs, is based on the Probabilistic Signature Scheme (PSS) design and its security mainly relies on the intractability of the eth root problem.
C.2
RSA-KEM Algorithms
C.2.1
Key Generation
The RSA-KEM key generation algorithm is a probabilistic algorithm that takes the security parameter λ as input and runs as follows. 1. Generate a public exponent e, an odd integer greater than 1. 2. Randomly generate a prime p of length λ such that GCD(p − 1, e) = 1 where GCD is the function that calculates the greatest common divisor. 3. Similarly, generate a random prime number q of length λ such that,
GCD(q − 1, e) = 1. 4. Set n = pq 5. Set d to be the unique integer such that ed = 1modλ(n) where λ(n) = LCM 1 (p − 1, q − 1) 6. Set public key,pk = (n, e, λ) and secret key, sk = (d, pk). 7. Output the public-private key pair as (pk, sk).
C.2.2
Encapsulation
The encapsulation algorithm is a probabilistic algorithm that takes as input the public key, pk. It also uses a public key derivation function (KDF) that is available to all parties. It runs as follows: 1. Generate a random integer r ∈ 0, . . . , n − 1 2. Set C = r e mod n 3. Set K = KDF (r) 4. Output the encapsulated key pair (K,C) The cipher C, is then across to the receiver with whom a secret key has to be shared.
C.2.3
Decapsulation
The decapsulation algorithm is deterministic algorithm that takes an encapsulated C and the secret-key sk as input. It also uses the pre-agreed KDF and runs as follows: 1. Set r = C d modn 2. Set K = KDF (r) 3. Output K, the shared key
C.3
RSA-PSS Algorithms
The PSS scheme is shown diagrammatically in Fig. C.1. Signature scheme 1
LCM is the function that calculates the least common multiple
74
Message M
Random r of k0 bits
g1(w) h
Bit 0
g1
W of k bits
Masked seed
r*
g2(w)
g2
Fig. C.1: The PSS scheme P SS[k0, k1] = (GenP SS, SignP SS, V erif yP SS) is parameterized by k0 and k1 which are numbers between 1 and k satisfying k0 + k1 ≤ k − 1. To be concrete, an example is k = 1024, k0 = k1 = 128. The key generation GenP SS, is same as for RSA i.e., obtain (N,e,d) and output (pk, sk) where pk = (N, e) and sk = (N, d). The signing and verification algorithms make use of two hash functions. The first h is called the compressor and the second g is called the generator. Let g1 be the function which on input w returns the first k0 bits of g(w) and let g2 be the function which on input w returns the remaining k − k0 − k1 − 1 bits of g(w). The SignP SS and V erif yP SS are described below.
C.3.1
SignPSS
The signer picks up a random seed r of k0 bits. He then concatenates this seed to the message M , effectively ”randomizing” the message, and hashes this down, via the compressing function h to a k1 bit string w. Then the generator g is applied to w to
75
yield a k0 bit seed r, resulting in the masked seed r∗. Now, w||r∗ is pre-pended with a 0 bit and appended with g2(w) to create the image point y which is decrypted under the RSA function to define the signature. Notice that the new seed is chosen for each message. In particular, a given message has many possible signatures, depending on the value of r chosen by the signer.
C.3.2
VerifyPSS
Given (M, x), the verifier computes y = xe modN and recovers r∗, w and r. These are used to check that y was correctly constructed and the verifier only accepts if all checks succeed.
76
BIBLIOGRAPHY [1] “Internet Usage by World Region.” http://www.internetworldstats.com/stats.htm. [2] K. G. Coffman and Andrew Odlyzko, “The Size and Growth Rate of the Internet,” First Monday - Peer Reviewed Internet Journal, April 1998. [3] “Midas Communication Technologies.” http://www.midascomm.com/. [4] “Broadband corDECT - Wireless solution.” http://www.midascomm.com/products /bbcordect.html. [5] Ashok Jhunjhunwala, Bhaskar Ramamurthi, and Timothy A Gonsalves, “The role of technology in telecom expansion in India,” in IEEE Commn. Mag., Dec. 1998. [6] W. Stallings, SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. Addison-Wesley, 1998. [7] J. Case, M. Fedor, M. Schoffstall, and J. Davin, “RFC 1157 - A Simple Network Management Protocol (SNMP),” May 1990. [8] M. Subramaniam, Network Management - Principles and Practices. Addison-Wesley, 2000. [9] “Common Management Information Protocol.” http://www.sei.cmu.edu/str/descr iptions/cmip.html. [10] “CERT Advisory CA-2002-03 Multiple Vulnerabilities in many Implementations of the Simple Network Management Protocol (SNMP).” http://www.cert.org/advisories/CA2002-03.html, May 2005. [11] L. L. Peterson and Bruce S Davie, Computer Networks - A Systems Approach. Elsevier, third ed., 2003. [12] “TTI Telecom - Secure Access.” http://www.tti-telecom.com/index.php?id=637&pt =8&pid=636&level=3. [13] “HP OpenView - Network Node Manager.” http://h20229.www2.hp.com/solutions/az.html. [14] “CiscoWorks.” http://www.cisco.com/en/US/products/sw/netmgtsw/. [15] “CA TNG UniCenter.” http://www3.ca.com/Enterprise/Product.aspx. [16] “IBM Tivoli.” http://www-306.ibm.com/software/tivoli/sw-bycategory/index.html. [17] “AdventNet OpManager.” http://manageengine.adventnet.com/products. [18] “OpenNMS.” http://www.opennms.org/index.php. [19] “NMSWorks Software Ltd., ‘CygNet NMS’.” http://www.nmsworks.co.in/products /cygnet.php.
77
[20] U. D. Black, Network Management Standards SNMP, CMIP, TMN, MIBs and Object Libraries. McGraw Hill, second ed., 1995. [21] J. Case, R. Mundy, D. Partain, Ericsson, and B. Stewart, “RFC 3410 - Introduction and Applicability Statements for Internet Standard Management Framework,” Dec. 2002. [22] T. S. Nathan, “Analysis and Design of an Embedded Management agent,” Master’s thesis, Computer Science Dept., Indian Institute of Technology, Madras, 2006. [23] L. Sanchez, K. McCloghrie, and J. Saperia, “RFC 3139 - Requirements for Configuration Management of IP-based Networks,” June 2001. [24] J. Schoenwaelder, “RFC 3535 - Overview of the 2002 IAB Network Management Workshop,” May 2003. [25] J. Ioannidis and Matt Blaze, “The Architecture and Implementation of Network Layer Security Under UNIX,” in Proc. of 4th Usenix Security Symposium, Oct. 1993. [26] S. Kent and K. Seo, “RFC 4301 - Security Architecture for the Internet Protocol,” Dec. 2005. [27] Sandhu R S and Samarati P, “Access Control: principle and practice,” in IEEE Commn. Mag., pp. 40–48, Sept. 1994. [28] Sandhu R S, Coyne E J, Feinstein H L, and Youman C E, “Role-based access control,” in Computer, pp. 38–47, Feb. 1996. [29] B. Wijnen, R. Presuhn, and K. McCloghrie, “RFC 3415 - View Based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP),” Dec. 2002. [30] Sushil Jajodia, “Database security and privacy,” in ACM Computing Surveys, pp. 129– 131, Mar. 1996. [31] “Nortel Network Baystack 325 Switches.” http://www.productsandservices.bt.com/ btbusiness/btbusinessProducts/pdfs/BS325-24Tand24G.pdf. [32] “VPN Consortium.” http://www.vpnc.org/vpn-technologies.html, Mar. 2006. [33] C. Hosner, “SSL VPNs and OpenVPN: A lot of lies and a shred of truth.” http://software.newsforge.com/article.pl?sid=05/09/22/164231&from=rss, Sept. 2005. [34] AbdelNasir Alshamsi and Takamichi Saito, “A Technical Comparison of IPSec and SSL,” in Proc. of 19th Intl. Conf. on Advanced Information Networking and Applications (AINA’05), vol. 2, pp. 392–395, Mar. 2005. [35] C. Hosner, “OpenVPN and the SSL VPN Revolution.” http://www.sans.org/rr/ whitepapers/ vpns/1459.php, Aug. 2004. [36] M. D. Wilson, “VPN HOWTO,” http:// www.tldp.org/HOWTO/VPN-HOWTO, Dec. 1999. [37] J. Yonan, “VPN Solutions.” http://openvpn.net /papers, 2003. [38] V. Hegde, “Encryption using OpenSSL’s crypto libraries,” Linux Gazette Mag., vol. 87, 2003.
78
[39] W. Diffie and M. E. Hellman, “New directions in cryptography,” in IEEE Trans. on Information Theory 22, pp. 644–654, 1976. [40] A. W. Dent, “ACE-KEM and the general KEM-DEM structure,” NESSIE Internal report, 2002. [41] J. Jonsson, “Security proof for the RSA-PSS signature scheme,” in Proc. of 2nd NESSIE Workshop, 2001. [42] NESSIE, “The New European Schemes for Signature, Integrity, and Encryption.” http:// www.cryptonessie.org, Feb. 2000. [43] Ishpal Singh Gill, “An Encryption Schema for Army Networks,” tech. rep., (MTech), DON Lab, Computer Science Dept., Indian Institute of Technology Madras, 2006. [44] G. Coulouris, Jean Dollimore, and Tim Kindberg, Distributed Systems Concepts and Design. Pearson Education, third ed., 2002. [45] R. Ben Natan, Implementing Database Security and Auditing. Digital Press, first ed., 2005.
79
LIST OF PUBLICATIONS
Published
1 Nisha P. Kurur, Ishpal Singh Gill, N. Usha Rani and Timothy A. Gonsalves, “Transport Data Security in Network Management” 13th National Conference on Communications, NCC 2007, IIT Kanpur, Jan. 2007, pp 263-268
80
CURRICULUM VITAE 1. Name: Nisha Parameswaran Kurur 2. Date of Birth: 27th May, 1981 3. Educational Qualifications: • 2008 - Master of Science (M.S) • 2002 - Bachelor of Technology (B.Tech) 4. Permanent address: Kurur Mana, Kadalassery, P.O Vallachira, Thrissur - 680562, Kerala. Ph: 0480-2791599, email-id:
[email protected]
81
GENERAL TEST COMMITTEE 1 Chairperson: Dr. P Sreenivas Kumar 2 Guide: Prof. Timothy A. Gonsalves 3 Members: • Dr. Deepak Khemani • Prof. Srinivasan G
82
