Academia.edu no longer supports Internet Explorer.
To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to upgrade your browser.
Building a Dynamic Interoperable Security Architecture for Active Networks
Building a Dynamic Interoperable Security Architecture for Active Networks
Roy CampbellRelated Papers
1994 •
The continuous deployment of network services over the wide range of public and private networks has led to transactions and services that include personal, and sometimes quite sensitive, data. Examples of services include: pay-per-view, cable telephony, bill payments by phone, credit card charging, and Internet banking. Such services require significant effort not only to protect the sensitive data involved in the transactions and services but to ensure integrity and availability of network services as well. The requirement for employing heterogeneous networks and systems becomes increasingly important, and as the view of traditional distributed systems has changed to a network centric view in all types of application networks, therefore, the complexity of these systems has led to significant security flaws and problems. Existing conventional approaches for security service development over such complex and most often heterogeneous networks and systems are not satisfying and cannot...
AFRL-IF-RS-TR-2002-262
Final Technical Report
October 2002
BUILDING A DYNAMIC INTEROPERABLE
SECURITY ARCHITECTURE FOR ACTIVE
NETWORKS
University of Illinois
Sponsored by
Defense Advanced Research Projects Agency
DARPA Order No. G378
APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED.
The views and conclusions contained in this document are those of the authors and should not be
interpreted as necessarily representing the official policies, either expressed or implied, of the
Defense Advanced Research Projects Agency or the U.S. Government.
AIR FORCE RESEARCH LABORATORY
INFORMATION DIRECTORATE
ROME RESEARCH SITE
ROME, NEW YORK
This report has been reviewed by the Air Force Research Laboratory, Information
Directorate, Public Affairs Office (IFOIPA) and is releasable to the National Technical
Information Service (NTIS). At NTIS it will be releasable to the general public,
including foreign nations.
AFRL-IF-RS-TR-2002-262 has been reviewed and is approved for publication
APPROVED:
SCOTT S. SHYNE
Project Engineer
FOR THE DIRECTOR:
WARREN H. DEBANY, Technical Advisor
Information Grid Division
Information Directorate
Form Approved
OMB No. 074-0188
REPORT DOCUMENTATION PAGE
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing this collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including
suggestions for reducing this burden to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302,
and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503
1. AGENCY USE ONLY (Leave blank)
2. REPORT DATE
October 2002
3. REPORT TYPE AND DATES COVERED
Final May 98 – Jun 02
4. TITLE AND SUBTITLE
5. FUNDING NUMBERS
BUILDING A DYNAMIC INTEROPERABLE SECURITY ARCHITECTURE
FOR ACTIVE NETWORKS
C
PE
PR
TA
WU
6. AUTHOR(S)
Roy H. Campbell and M. Dennis Mickunas
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)
- F30602-98-1-0192
- 62301E
- G378
- 00
- 01
8. PERFORMING ORGANIZATION
REPORT NUMBER
University of Illinois
Grants and Contracts Office
109 Coble Hall – 801 South Wright Street
Champaign Illinois 61820-6242
9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES)
Defense Advanced Research Projects Agency AFRL/IFGA
3701 North Fairfax Drive
525 Brooks Road
Arlington Virginia 22203-1714
Rome New York 13441-4505
10. SPONSORING / MONITORING
AGENCY REPORT NUMBER
AFRL-IF-RS-TR-2002-262
11. SUPPLEMENTARY NOTES
AFRL Project Engineer: Scott S. Shyne/IFGA/(315) 330-4819/ Scott.Shyne@rl.af.mil
12a. DISTRIBUTION / AVAILABILITY STATEMENT
12b. DISTRIBUTION CODE
APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED.
13. ABSTRACT (Maximum 200 Words)
Security is viewed as one of the major obstacles to the widespread deployment active networks. A significant challenge
is to develop mechanisms to change software state on routers dynamically, without sacrificing protection guarantees.
The Seraphim projects leverages the inherent dynamism in the paradigm to build dynamic security mechanisms for
active networks. Seraphim's security architecture is component based, dynamically extensible, and reflective, and
supports a variety of policy strategies and enforcement mechanisms. This enabled the development of customizable,
interoperable, domain-specific, or task-specific security policies and mechanisms, to meet the security requirements of
active network entities. Administrators were able to develop security policies as active network capsules, called dynamic
policies, and enforce these policies by executing them in a suitable software context on active network routers. A suite
of confidentiality, integrity, authentication and access-control mechanisms was developed to secure the node of an
active network. This suite was based on standardized APIs and provided support for customized Quality of Protection
guarantees. Customized dynamic policies were created and installed at run-time, trading functionality for performance,
to implement low-overhead solutions that were able to successfully counter threats and attack, without sacrificing
protection guarantees.
14. SUBJECT TERMS
15. NUMBER OF PAGES
Active Networks, Security Mechanisms, Security Policies, Access-Control Mechanisms
90
16. PRICE CODE
17. SECURITY CLASSIFICATION
OF REPORT
18. SECURITY CLASSIFICATION
OF THIS PAGE
UNCLASSIFIED
UNCLASSIFIED
NSN 7540-01-280-5500
19. SECURITY CLASSIFICATION
OF ABSTRACT
UNCLASSIFIED
20. LIMITATION OF ABSTRACT
UL
Standard Form 298 (Rev. 2-89)
Prescribed by ANSI Std. Z39-18
298-102
Table of Contents
1. SUMMARY.................................................................................................................................................. 1
2. OVERVIEW OF CONTRIBUTIONS ....................................................................................................... 2
1.1
1.2
1.3
1.4
1.5
1.6
SECURITY ARCHITECTURE FOR DYNAMIC POLICY .................................................................................. 2
DYNAMIC ACCESS CONTROL POLICIES ................................................................................................... 3
SECURE NODE ARCHITECTURE AND SECURITY AS SERVICES .................................................................. 3
SECURE FLOW ANALYSIS ........................................................................................................................ 3
FORMAL SPECIFICATION AND VALIDATION OF DYNAMIC POLICIES ........................................................ 4
DENIAL OF SERVICE PROTECTION ........................................................................................................... 4
3. LIST OF ACCOMPLISHMENTS............................................................................................................ 5
4. REFERENCES ............................................................................................................................................ 8
APPENDICES ................................................................................................................................................ 10
APPENDIX A AN AGENT BASED ARCHITECTURE FOR SUPPORTING APPLICATION LEVEL SECURITY........ 11
APPENDIX B SERAPHIM: DYNAMIC INTEROPERABLE SECURITY ARCHITECTURE FOR ACTIVE NETWORKS
..................................................................................................................................................................... 23
APPENDIX C FLEXIBLE SECURE MULTICASTING IN ACTIVE NETWORKS .................................................. 33
APPENDIX D SECURE INFORMATION FLOW IN MOBILE BOOTSTRAPPING PROCESS. ................................. 41
APPENDIX E DYNAMIC, DISTRIBUTED, SECURE MULTICAST IN ACTIVE NETWORKS ............................... 49
APPENDIX F SECURING THE NODE OF AN ACTIVE NETWORK ................................................................... 55
APPENDIX G PLUGGABLE ACTIVE SECURITY FOR ACTIVE NETWORKS .................................................... 69
APPENDIX H DEVELOPING DYNAMIC SECURITY POLICIES ....................................................................... 75
i
1. SUMMARY
In an active network, new protocols and services can be injected into the network
using smart packets to carry customized software components. This technology increases
the degree and sophistication of the network architecture and enables fast deployment of
new protocols and services. However, allowing installation of arbitrary software
components on routers may cause undesirable side effects and impact the protection
guarantees of the software on the routers. Administrators of active network routers may
want to restrict the behavior of active capsules and preserve certain behavior guarantees at
all times. These guarantees may be specified as safety properties of component
mechanisms, noninterference properties of information flows, or timing guarantees in
availability policies. Traditional security mechanisms and network policy management
tools have limited support for changing and enforcing different types of policy strategies,
let alone policies, at run-time. The ability to specify, implement and enforce these policies
in a dynamic environment becomes crucial.
In Seraphim, we study the interoperability, extensibility, and configuration issues of
security policies for active networks. To address these issues, we introduce the notion of
dynamic policies that can be enforced by executing them on an active network node. These
policies are designed by formally modeling the behavior and interactions between different
components on active routers. Behavioral guarantees, expressed as temporal safety
properties, form an integral part of the specification of dynamic policies and can be
validated within the model framework. Policies are implemented by wrapping the
mechanisms to change operational parameters with suitable guards so as to preserve these
behavior guarantees. This combination of guards and commands are encapsulated in active
capsules and the policy they specify is enforced by instantiating and executing these
capsules in a suitable sandbox-like environment on the active router. Using our policy
framework, we can change policy strategies (e.g., between MAC and RBAC) at run-time,
in response to intrusions and other security violations, without sacrificing security
guarantees.
We also provide a suite of customizable security mechanisms to protect the
integrity, authenticity, and confidentiality of capsules exchanged between active routers.
These mechanisms to secure the node of an active network are implemented as services
based on standardized APIs. The services are carefully designed and analyzed to preserve
noninterference properties and prevent information leaks. The dynamism afforded by the
architecture also allows us to implement different Quality of Protection (QoP) levels to
provide customizable security for active flows. This enables us to implement minimal
security policies and deploy stronger mechanisms on a need to protect basis, and amortize
performance penalties. We believe that this support for dynamism in security is our major
contribution in the context of security for active networks.
1
2. OVERVIEW OF CONTRIBUTIONS
We believe that no single security architecture will be able to address the security
issues for active networks in general. Customizable security policies and extensible
security mechanisms will play an important part in addressing the security concerns with
the practical deployment of active network infrastructure on routers. We argue that
developing satisfactory security solutions in a dynamic environment requires support for
dynamic security. We provide a framework to develop reactive security solutions in this
context, on a need-to-protect basis with minimal overhead in terms of software and
performance. In this section, we summarize our major contributions, which include:
•
•
•
•
•
A dynamic security architecture for active networks that provides support for
dynamic policies that integrates seamlessly with proposed active network
architecture [Liu00-1, Liu00-2], along with a distributed secure multicast
application to demonstrate these policies [Var99, Var00, Liu00-3].
A componentized policy framework that implements different access control
strategies and allows administrators to change between policy strategies at run
time [Nal00].
A suite of customizable mechanisms to secure the node of an active network
along with a flow analysis to guarantee noninterference [Liu005, Liu00-6].
Formal specification and validation of dynamic policies [Nal02].
Investigation of denial of service prevention and implementation of certified
bandwidth mechanisms.
We describe each of these contributions in greater detail the following subsections.
1.1 SECURITY ARCHITECTURE FOR DYNAMIC POLICY
The Seraphim project developed dynamic and fully extensible security architecture
for active networks [Liu00-1, Liu00-2]. The architecture is based on the principles
underlying active networks rather than on existing static systems. Seraphim project adopts
ideas and technologies from previous Cherubim mobile agent based security architecture
research, including dynamic security policies that support interoperability among different
security domains, and active capabilities that provide application specific security
functions. In addition, Seraphim’s security architecture for active networks imposes only a
minimal set of security functions on the base active network architecture to support secure
deployment of new security services. More sophisticated and application specific security
functions may be recursively installed using a secure reconfigurable [Liu00-4] bootstrap
process. Seraphim’s architecture is not constrained to one specific security scheme for
securing smart packets and active nodes. This reflective design allows the maximum
flexibility for building a secure active network environment. Seraphim’s security
architecture fits transparently into the proposed Active Network and Active Network
Security Architecture. We have also integrated it with the ABone test-bed.
2
1.2 DYNAMIC ACCESS CONTROL POLICIES
Seraphim’s Dynamic Policy Management Framework, written in Java, implements
different access control strategies. In addition to DAC (Discretionary Access Control),
MAC (Mandatory Access Control) and RBAC (Role Based Access Control) we have also
incorporated the I-RBAC (Interoperable RBAC) [Kap00] and R2BAC models developed by
our group. The I-RBAC model allows us to interoperate between different RBAC domains,
providing us a dynamic mechanism to translate our dynamic access control policies across
different domains. The R2BAC model allows us to change between two different RBAC
instances in the same domain. This model is useful to deploy a restrictive access control
policy under an attack and change it back to the default when the threat has receded.
1.3 SECURE NODE ARCHITECTURE AND SECURITY AS SERVICES
The secure node architecture includes an active node operating system security API,
an active security guardian, and quality of protection (QoP) provisions [Liu00-5, Liu01,
Liu02]. The architecture supports highly customized and situational policies created by
users and applications dynamically. It permits active nodes to satisfy application-specific
dynamic security and protection requirements. The secure node architecture can provide a
fundamental base for securing the active network infrastructure. It provides a framework
that adapts and implements the Pluggable Authentication Module API, Generic Access and
Authorization API and Generic Security Services API for authentication, authorization, and
various security services. The implementation uses DES, IDEA, and Rijndael encryption
algorithms, whose keys are exchanged through RSA/X.509v3 algorithm, for dynamic
customized security services. The security configuration supports various encryption
algorithms and RSA key lengths. Applications can dynamically select the suitable security
configuration and services at each routing hop, based on their security and performance
requirements.
1.4 SECURE FLOW ANALYSIS
In addition to the secure node architecture, we also provide the analysis of secure
information flow using a type system [Liu01]. Information flow control is concerned with
the right of dissemination of information. Secure information flow properly restricts the
propagation of sensitive cryptographic data beyond the security API to untrusted
environments. The analysis demonstrates that the type system can ensure secure flow
enforcement efficiently and therefore provide additional security assurance for active
networks.
The type system guarantees that a well-typed program satisfies the
noninterference security property. This means that the program does not leak sensitive
data.
3
1.5 FORMAL SPECIFICATION AND VALIDATION OF DYNAMIC POLICIES
We introduce formal modeling and specification in our policy development life
cycle. In most existing systems, policies are implemented and enforced by changing the
operational parameters of shared system objects. These policies do not account the
behavior of the entire system, and enforcing these policies can have unexpected interactive
or concurrent behavior. We develop a policy specification, implementation, and
enforcement methodology based on formal models of interactive behavior and satisfiability
of system properties. We show that by carefully designing the code to change the
operational parameters our policy implementation entities, dynamically installing and
executing our policies does not affect the behavioral guarantees specified by the properties.
Our dynamic policy is a program consisting of a set of guards and actions, created by our
policy administrator. It encodes not only the logic to modify the system implementation to
change operational parameters, but also includes all the necessary guards to enforce good
behavior and prevent its misuse. For example, in the access control policy example, the
guard can include proofs of authorization, and the commands are programs to change
parameters of an access control rule. In our Seraphim active network prototype, these
programs map directly to active capsules, and can be viewed as in-line policies. We also
describe other types of dynamic policies for information flow and availability, based on
safety, liveness, fairness, and other properties. We believe that dynamic policies are
important building blocks of reactive security solutions for active networks.
1.6 DENIAL OF SERVICE PROTECTION
In addition to our work in dynamic policies, we have also developed a behavioral
model of network denial of service; especially Distributed Denial of Service attacks
(DDOS). Based on the behavior analysis, we argue that the trace of a DDOS victim’s
behavior cannot be made DDOS resistant by implementing a suitable mechanism on the
victim alone. Bandwidth agreements, similar in flavor to user agreements, are necessary to
prevent denial of service. We have implemented a lightweight mechanism that was
demonstrated at the December 2000 Demo meeting, to attach bandwidth certificates to
legitimate traffic. We call these certificates CABs or Credentials that Authorize
Bandwidth. A CAB is a small, fixed length identifier that cannot be forged easily. It
certifies that the packet it is attached to is legitimate. It can be used to mark legitimate
UDP or control packets for DDOS resistance. One of the ways to ensure that valid CABs
can only be created by trusted entities is to use cryptography and tie in a shared secret to the
CAB value. Certified bandwidth can be used to implement cooperative bandwidth
agreements required to prevent denial of service.
4
3. LIST OF ACCOMPLISHMENTS
June 1998 – June 1999:
1. Modified ANTS active network toolkit and built the SAINTS (Secure Active
Interoperable Network Toolkit System) to implement the Active network architecture with
explicit NodeOS and Execution Environment (EE) objects. This modified toolkit was the
test-bed for most of our experiments.
2. Designed and implemented a lean security guardian to provide access control from the
EE to the shared NodeOS resources. The security guardian is a colocated extension to the
NodeOS. Every node has a security guardian, through which all accesses to node resources
occur.
3. Completed implementation of the NodeOS proxy to support portability. The EEs direct
their requests for NodeOS resources to the NodeOS proxy that sits atop the NodeOS. The
proxy acts as a wrapper to the NodeOS API and redirects access control requests to the
security guardian.
4. Completed implementation of Role Based Access Control (RBAC) within the Seraphim
policy framework and integrated support for DAC and MAC from our previous project into
the Seraphim toolkit.
5. Demonstrated support for secure, flexible, and dynamic multicast, as an extension of the
original ANTS multicast scheme. Deposited a Master’s thesis titled “Dynamic Distributed
Secure Multicast in Active Networks”.
July 1999 - June 2000:
1. Designed a NodeOS security API to support authentication, authorization and integrity.
The API includes Pluggable Authentication Module (PAM) API, Generic Security Services
(GSS) API, and Generic Authorization and Access Control (GAA) API. This security API
is complement to the current NodeOS Interface Specification that focuses on fast network
packet-forwarding fine-grained quality of service.
2. Developed an Active Caching framework for our active capabilities. By caching the
reusable active capabilities, the system reduces the overhead of retrieving the active
capability every time a security decision has to be made.
3. Modified and enhanced the Security Architecture for Active Networks document and
circulated it throughout the active network community.
The modifications and
enhancements show the lessons learned from our Seraphim project and reflect the view of
flexible, dynamic and interoperable active network security based on active capabilities.
5
4. Developed the IRBAC model of secure interoperability between security domains
operating under the Role Based Access Control (RBAC) policy for dynamic role
translations.
5. Produced a PhD thesis on trust management in a distributed environment. The solution
proposed in this model avoids the use of global name spaces and central trust authorities.
The model enables fine-grained trust specification and flexible certificate management.
6. Implemented the NodeOS security API, and integrated it into our SAINTS platform that
uses active capabilities and security guardian for active security.
7. Extended the NodeOS security API to support Quality of Protection (QoP) in active
networks. The active applications can dynamically change the security and protection
characteristics while traveling from hop to hop. Some examples of security and protection
characteristics are different security algorithms, key sizes, and supports of security services.
8. Provided more input for the Security Architecture for Active Networks document
Implemented the IRBAC model in Seraphim architecture. With IRBAC, more than one
autonomous domain can seamlessly interact with each with adequate security support.
July 2000 - June 2001:
1. Developed the BARMAN (Bandwidth Authorization and Resource Management in
Active Network) protocol for the NodeOS. This protocol prevents denial of service attacks
that “flood” networks with unwanted packets and block legitimate network traffic.
2. Deposited Master’s thesis titled “A Componentized Framework for Dynamic Security
Policies”.
3. Participated in December 2000 AN PI Meeting with Team 4 integrated demo. Seraphim
package was integrated with CANES platform and provided dynamic security support. In
addition, BARMAN protocol was implemented inside the CANES Bowman NodeOS to
provide safety against flooding DDOS attacks.
4. Developed the Reactive Role Based Access Control model (R2BAC). R2BAC is a way
to use the IRBAC model as a defense mechanism against intrusions. We used R2BAC to
efficiently change the role hierarchy inside a security domain to counter the possible
security threats. We used INFOCON (Information Operation Condition) notion from DoD
to model the current threats to the networks and used R2BAC to dynamically reconfigure
the networks for tighter defense.
5. Developed a fuzzy logic based risk model. In this model, every threat is represented as
a fuzzy set. The risk analyzer calculates the network-wide overall risk based on the fuzzy
logic operation.
6. Participated in June 2001 AN PI meeting with a demonstration of R2BAC model and the
fuzzy logic based risk assessment system. In this system, every threat to the network is
characterized as a fuzzy set and the current risk to the whole network is calculated with
6
fuzzy logic. We also adopted the notion of DoD’s INFOCON (Information Operation
Condition) to show how our risk assessment system and R2BAC model can be used as an
efficient defensive mechanism.
July 2001 – May 2002:
1. Deposited Ph. D Thesis on “Securing the Node of an Active Network. This thesis
explores the security issues and develops a security architecture for NodeOS security by
implementing security as standardized services adapted to the Active Network architecture.
The thesis includes a validation of the design using secure flow analysis based on a type
system to validate the noninterference properties of the composition of these security
services.
2. Developed a formal model of dynamic policies and introduced the notion of property
preserving policies. We also used formal validation and verification techniques to make
strong safety guarantees about our dynamic access control policy framework.
3. Developing a formal Model of the Distributed Denial of Service problem.
7
4. REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[Liu00-1] Zhaoyu Liu, Prasad Naldurg, Seung Yi, Tin Qian, Roy H. Campbell, and
M. Dennis Mickunas, An Agent Based Architecture for Supporting Application
Level Security. DARPA Information Survivability Conference and Exposition,
Hilton Head Island, South Carolina, January 2000.
[Liu00-2] Roy H. Campbell, Zhaoyu Liu, M. Dennis Mickunas, Prasad Naldurg,
and Seung Yi, Seraphim: Dynamic Interoperable Security Architecture for Active
Networks.
IEEE Third Conference on Open Architectures and Network
Programming Proceedings (OPENARCH’2000), Tel Aviv, Israel, March 2000.
[Liu00-3] Zhaoyu Liu, Roy H. Campbell, Sudha K. Varadarajan, Prasad Naldurg,
Seung Yi, and M. Dennis Mickunas, Flexible Secure Multicasting in Active
Networks. International Workshop on Group Computation and Communications,
Taipei, Taiwan, April 2000.
[Liu00-4] Zhaoyu Liu, M. Dennis Mickunas, and Roy H. Campbell, Secure
Information Flow in Mobile Bootstrapping Process. International Workshop on
Wireless Networks and Mobile Computing, Taipei, Taiwan, April 2000
[Var00] Sudha K. Varadarajan, Tin Qian, and Roy H. Campbell, Dynamic,
Distributed, Secure Multicast in Active Networks. IEEE International Conference
on Communication (ICC’2000), New Orleans, Louisiana, June 18-22, 2000.
[Kap00] I-RBAC 2000: Apu Kapadia, Jalal Al-Muhtadi, Roy H. Campbell, and M.
Dennis Mickunas, Secure Interoperability Using Dynamic Role Translation.
Proceedings of the 1st International Conference on Internet Computing (IC’2000),
Las Vegas, Nevada, June 26, 2000.
[Liu00-5] Zhaoyu Liu, Roy H. Campbell, and M. Dennis Mickunas, Securing the
Node of an Active Network Active Middleware Services. Kluwer Academic
Publishers, Boston, Massachusetts, September 2000.
[Liu00-6] Zhaoyu Liu, Prasad Naldurg, Seung Yi, Roy H. Campbell, and M. Dennis
Mickunas, Pluggable Active Security for Active Networks. 12th IASTED
International Conference on Parallel and Distributed Computing and Systems
(PDCS’2000), Las Vegas, Nevada, November 6-9, 2000.
[Liu01] Zhaoyu Liu, Active Security for Active Networks, Ph. D Thesis,
Department of Computer Science, University of Illinois at Urbana-Champaign,
2001.
[Nal02] Prasad Naldurg, R. H. Campbell and M. Dennis Mickunas, Developing
Dynamic Security Policies, To Appear in the Proceedings of the 2002 DARPA
Active Networks Conference and Exposition (DANCE 2002), San Francisco, CA,
USA, IEEE Computer Society Press, May 29-31, 2002.
[Liu02] Zhaoyu Liu, Roy H. Campbell, and M. Dennis Mickunas, Security as
Services in Active Networks. To Appear in IEEE International Symposium on
Computers and Communication (ISCC 2002), Taormina, Italy, July 2002
8
[12]
[13]
[14]
[Qia00] Tin Qian, Dynamic Authorization Support in Large Distributed Systems,
Ph. D Thesis, Department of Computer Science, University of Illinois at UrbanaChampaign, 2000.
[Var99] Sudha Varadarajan, Dynamic Distributed Secure Multicast in Active
Networks. MS Thesis, Department of Computer Science, University of Illinois at
Urbana-Champaign, August 1999.
[Nal00] Prasad Naldurg, A Componentized Framework for Dynamic Security
Policies, MS Thesis, Department of Computer Science, University of Illinois at
Urbana-Champaign, August 2000.
9
APPENDICES
Papers attached to this report:
A
Zhaoyu Liu, Prasad Naldurg, Seung Yi, Tin Qian, Roy H. Campbell, and M. Dennis
Mickunas, An Agent Based Architecture for Supporting Application Level Security.
DARPA Information Survivability Conference and Exposition, Hilton Head Island, South
Carolina, January 2000.
B
Roy H. Campbell, Zhaoyu Liu, M. Dennis Mickunas, Prasad Naldurg, and Seung
Yi, Seraphim: Dynamic Interoperable Security Architecture for Active Networks. IEEE
Third Conference on Open Architectures and Network Programming Proceedings
(OPENARCH’2000), Tel Aviv, Israel, March 2000.
C
Zhaoyu Liu, Roy H. Campbell, Sudha K. Varadarajan, Prasad Naldurg, Seung Yi,
and M. Dennis Mickunas, Flexible Secure Multicasting in Active Networks. International
Workshop on Group Computation and Communications, Taipei, Taiwan, April 2000.
D
[Liu00-4] Zhaoyu Liu, M. Dennis Mickunas, and Roy H. Campbell, Secure
Information Flow in Mobile Bootstrapping Process. International Workshop on Wireless
Networks and Mobile Computing, Taipei, Taiwan, April 2000.
E
Sudha K. Varadarajan, Tin Qian, and Roy H. Campbell, Dynamic, Distributed,
Secure Multicast in Active Networks. IEEE International Conference on Communication
(ICC’2000), New Orleans, Louisiana, June 18-22, 2000.
F
[Liu00-5] Zhaoyu Liu, Roy H. Campbell, and M. Dennis Mickunas, Securing the
Node of an Active Network, Active Middleware Services. Kluwer Academic Publishers,
Boston, Massachusetts, September 2000.
G
[Liu00-6] Zhaoyu Liu, Prasad Naldurg, Seung Yi, Roy H. Campbell, and M. Dennis
Mickunas, Pluggable Active Security for Active Networks, 12th IASTED International
Conference on Parallel and Distributed Computing and Systems (PDCS’2000), Las Vegas,
Nevada, November 6-9, 2000.
H
[Nal02] Prasad Naldurg, R. H. Campbell, and M. Dennis Mickunas, Developing
Dynamic Security Policies, To Appear in the Proceedings of the 2002 DARPA Active
Networks Conference and Exposition (DANCE 2002), San Francisco, CA, USA, IEEE
Computer Society Press, May 29-31, 2002.
10
APPENDIXA A
APPENDIX
11
12
13
14
15
16
17
18
19
20
21
22
APPENDIXB B
APPENDIX
23
24
25
26
27
28
28
30
31
32
APPENDIX
APPENDIX CC
33
34
35
36
37
38
39
40
APPENDIX
APPENDIX D
D
41
42
43
44
45
46
47
48
APPENDIX E
49
50
51
52
53
54
APPENDIX F
Securing the Node of an Active Network
Zhaoyu Liu, Roy H. Campbell, M. Dennis Mickunas
Department of Computer Science
University of Illinois at Urbana-Champaign
Urbana, IL 61801
zhaoyu, roy, mickunas @cs.uiuc.edu
Abstract
Active networks aim to provide a software framework that enables network applications to customize the processing of their communications. Security is of critical importance to the success of active networking. This paper discusses the design of securing the node of an active network using active networking principles.
The secure node architecture includes an Active Node Operating System Security
API, an Active Security Guardian, and Quality of Protection (QoP) provisions.
The architecture supports highly customized and situational policies created by
users and applications dynamically. It permits active nodes to satisfy the application specific dynamic security and protection requirements. It aids the application
of the “need-to-know” security principle and associates quality of protection with
network software and application security. The secure node architecture can provide fundamental base for securing the active network infrastructure.
Keywords: active networks, security API, active capability, active security guardian,
quality of protection
1 Introduction
Active networks aim to provide a software framework that enables network applications to customize the processing of their communications. The current active network
research focuses on the support of flexible, dynamically changing, fine-grained quality of service. There is little research on dynamic, flexible, and application specific
security features that exploit active networking. Similar to traditional networks, active networks rely heavily on the underlying operating system for network security.
Current active network operating systems do not have explicit security support and
applications can not flexibly request security and protection requirements. The inflexibility of the systems makes security policy and service customization complex and
often leads to security holes.
In this paper we present the design of securing the node of an active network using
active networking principles. We term this approach active security. The secure node
architecture is integrated into the active node operating system and includes:
This research is supported by DARPA F30602-98-1-0192
55
A node operating system security API
An active security guardian
Quality of protection (QoP) provisions
The secure node architecture supports highly customized and situational policies
created by users and applications dynamically and provides fundamental base for securing the active network infrastructure.
The rest of the paper is organized as follows. Section 2 discusses the current security research on active networks. Section 3 describes the architecture of a secure active
node in detail. It discusses the principles to design the node operating system security
API, and describes the design of active security guardian and the support of quality of
protection. Section 4 presents the current implementation and the future work of this
active security research and then the final section concludes the paper.
2 Related Work
This section surveys the current security research on active networks. It provides background and motivation for the secure node architecture presented in the next section.
2.1 Active Network Security
It is difficult and complicated to retrofit security into Internet infrastructure [22]. The
active network research community considers security as an important part of the initial design. The security working group [23] of the active networks research community has been instrumental in publicizing and highlighting the importance of security
in active networks. The group emphasizes the importance of incorporating security
into the initial design stage of the active network architecture itself. The current security related research in this field can be classified into two general categories. The
first one deals with the more traditional notion of security, which includes authentication, access control, policies and enforcement. The security working group [23] has
launched some important exploratory research in this direction. The second category
is mostly about protection of nodes from mobile code originating in foreign domains
and protection of active packets or code from malicious hosts [32]. The PLANet effort
[1] raises some of the issues associated with these protections. In addition the effort
also provides a bootstrapping module that ensures that the system configures itself correctly at startup or reboot time. The protection from mobile code is provided by using a
type-safe, resource limited, functional programming language with dynamic type verification. Mobile code can install protocols at nodes securely by using the extensibility
features provided by the language. Naccio of MIT [10] also belongs to this category.
The high-level application specified policies limit Java mobile code capability and thus
provide the necessary protection to mobile code execution host.
2.2 Active Node Operating Systems
The high-level architecture for active node is shown in Figure 1 [5]. A node operating system (NodeOS) manages the resources such as memory regions, CPU cycles
56
and link bandwidth, and multiplexes packets among multiple execution environments
(EEs) running on the node. In order to support the porting EEs to multiple underlying
NodeOSes, a NodeOS interface is specified by the NodeOS working group [28].
Application
Application
Application
EE
IPv6
EE 2
EE 1
Management
EE
Flow
Other
Resources
NodeOS
Store
Channels
Figure 1: Active Network Node Architecture
The objectives of current NodeOS interface are to support fast network packets
forwarding and fine-grained quality of service. The interface doesn’t explicitly specify any security API. It defines the following five primary abstractions of system resources:
Thread Pool: computation resource.
Memory Pool: memory resource
Channel: communication resource, including not only network bandwidth, but
also CPU cycles and memory space.
File System: persistent storage resource.
Flow: Generally speaking, a flow is a sequence of packets satisfying some predefined attributes of interests. Typically flows are related to routing [27] and
quality of service [37], where groups of packets would receive similar treatment
in their network transport. Traditionally the flow concept can be used in both
datagram and connection-oriented communications. In active networks, the flow
concept is used to aggregate control and scheduling of the above four abstractions. It provides abstraction for accounting, admission control and scheduling
in the system. A flow can contain sub-flows and this results a hierarchical flow
structure.
Currently there are several NodeOS implementations in active networks research
community. They all comply to the general NodeOS interface specifications in various
degree:
Joust: Joust [11] is a small, fast JavaOS implemented in Scout [21]. It includes
an efficient Java virtual machine and a Java JIT compiler. It explores how Java’s
various features interact with Scout’s modular approach to building systems.
57
The current NodeOS interface for active network nodes is mostly based on the
experiences with Joust.
Janos: Janos is a Java-oriented active network operating system [4]. Its objective is to develop a principled local operating system for active network nodes,
which is oriented to executing untrusted Java byte code. The primary security
focus is resource management and control, with secondary objective of other
information security, performance, and technology transfer of broadly and separately useful software components. Janos interface provides a sample Java binding of the NodeOS API abstractions.
AMP System: AMP’s NodeOS is based on Exokernel operating system [12],
and uses Exokernel’s hierarchically-named capabilities [19] to support flexible
access control. Each Exokernel environment (similar to a Unix process) holds a
number of hierarchically-named capabilities, known as CAPs. The kernel maintains an array of CAPs and the environment specifies which CAP to use for each
system call or IPC operation.
Bowman: The Bowman node operating system is built to support the CANEs
EE. It is designed around three key abstractions: channel, a-flow, and state-store
[20]. A channel is the primary abstraction for communication and an a-flow
is the primary abstraction for computation. The state-store provides a mechanism for a-flows to store and retrieve state that is indexed by a unique key. The
Bowman NodeOS interface can be extended to provide support for additional
abstractions such as queues, routing tables, user protocols and services.
In summary, the current active node operating systems research focuses on high
performance, extensibility, and resource management. There is little research on explicit security support for authentication, authorization, integrity, and dynamic access
control. The secure node architecture presented in the next section addresses the above
security problems in active networks. It is complementary to the current NodeOS research and augments its functionality. It can be seamlessly integrated into the current
NodeOS implementations to provide dynamic security services and access control.
3 Securing the Node
The architecture of the secure node of an active network is shown in Figure 2. The secure node architecture includes a NodeOS Security API, an Active Security Guardian,
and Quality of Protection (QoP) provisions. The API provides support of authentication, authorization, integrity and access control services to EEs and active applications. It is implemented by a security library. An Active capability (AC) [18, 8, 7] is
used to support flexible distributed dynamic security policies. Essentially an AC is an
executable Java code which concisely represents dynamic security policies and mechanisms. The security guardian evaluates ACs in a secure sandbox environment and
enforces the security requirements of AC evaluation results. It obtains ACs securely
through the AC communication protocol. By using the NodeOS security API, active
security guardian, and active capabilities, it is feasible to provide quality of protection
to active applications.
58
The rest of the section is organized as follows. We first briefly describe the active
capability, Role Based Access Control policy type and active security guardian concepts. These concepts are developed and used in the Cherubim and Seraphim projects
[7, 18, 6]. Then we present the NodeOS security API and quality of protection provisions in detail. Finally we discuss the low-level code safety and the EE security.
EE
NodeOS
Security API
Security
AC
Evaluation
Engine
Other
NodeOS
Resources
Guardian
AC
Enforcement
Engine
Security
Library
AC
Communication
Protocol
Figure 2: Secure Node Structure
3.1 Active Capability
Active capabilities are used to support flexible distributed dynamic security policies
and services control, based on the similar active principles employed by active networks [18, 7]. Unlike a traditional capability, which is merely a static authorization
credential that encodes the principal and the permissions associated with the principal,
an active capability is a customized piece of code that encodes the type of access control policy and other constraints used in the access control decision making process. In
our implementation, an AC is an executable Java code which concisely represents dynamic security policies and mechanisms. In addition, an active capability is protected
by digital signatures, resides in user space and can be freely passed around.
By using an active capability various situational policies that depend on system
attributes can be encoded. For instance, by writing a piece of code that checks the
current system time and compares it with a value stored in the active capability one
can introduce a policy that expires after a certain time deadline. Similarly, various
enforcement and revocation schemes based on other attributes like quota, history, and
information content can be implemented. These schemes are very useful in an open
internetworking environment with diverse application requirements. An application
can use quota-based revocation to limit the amount of system resources a client can
consume.
An active capability could carry all policy information of decision in its code. This
heavy way of implementation is not elegant and efficient. A better way is to have a
59
generic policy framework to support different various policy types and ACs rely on
it for context. An application presents an active capability along with its regular data
or protocol capsules to the active router’s security guardian at execution time. The
access control policy type and user credentials are extracted from the capability. The
remote router’s security guardian recreates the context of the policy type within its
policy framework. If at any point during this process, the policy framework discovers
that it does not have an implementation for the type of the policy, it downloads the
code dynamically into the framework, using the underlying active network. It then
instantiates the run-time parameters associated with the application in its sandbox-like
environment and executes the active capability in this environment. Based on the result
of the evaluation of this active capability, the access control decision is enforced.
The principal of the active capability, which can be a user, a role, or other principal,
must be authenticated by a trusted authority. The trusted authority acts as the policy
server in our system. This entity is responsible for generating and keeping track of
the active capabilities. Usually one or more policy servers are associated with each
protection domain. Application programs contact their nearest or least-loaded server
and obtain the active capability dynamically.
3.2 Role Based Access Control (RBAC) Policy
The policy type used for dynamic access control in the architecture is Role Based
Access Control (RBAC) policy type, which is the most flexible type of access control
policy [33]. A Role Based Access Control policy, as the name suggests, uses the
concept of a role as its basis for representing permissions [33]. It is a form of access
control that emerges in the context of security policies for organizations. A role is
chiefly a semantic construct that forms the basis for an access control policy. With
RBAC, system administrators create roles according to the job functions performed in
an organization, grant permissions to those roles, and then assign users to the roles
on the basis of their specific job responsibilities and qualifications. The idea is that
the particular combination of users and permissions brought together by a role tends to
change over time while the permissions associated with a role are themselves relatively
more stable.
The biggest advantage that RBAC has over other forms of access control is that it
is extremely intuitive to use and maps easily to real-world situations. A hierarchy of
roles with senior roles inheriting all the permissions of junior roles closely follows the
structure of organizations. The access control policy in RBAC is embodied in components such as role-permission, user-role and role-role relationships. These components
collectively determine whether a particular user is allowed access to a particular operation on a particular component. These individual components can be easily (and
intuitively) configured to provide the required degree of access control. For example, adding a new user to a system would merely involve assigning appropriate roles
to the user according to the user’s functions in the organization. Likewise, changing
the nature of, for example, printer access, for all managers in an organization can be
accomplished by merely changing the permissions with the manager role in the organization. All managers can immediately see the effects of the change.
RBAC is the most flexible type of access control policy. All RBAC subjects are
60
assigned roles. Each role represents a particular set of objects and the allowed operations on each object. The major benefits of this aggregation are the considerable
saving in terms of space and simplification in terms of management and enforcement.
RBAC allows users to create policies with more sophisticated specifications than simple DAC, DDAC or MAC. A single user may have many different roles, and different
permissions depending on the current role. Different constraints related to role and
privilege may be enforced in RBAC. The RBAC constraints supported in our system include three important ones: mutually exclusive roles/permissions, prerequisite
roles/permissions and cardinality constraints.
3.3 Active Security Guardian
The security guardian in the architecture is to support AC evaluation and enforcement.
All accesses to node resources must go through security guardian which use the security library services to verify the signature on the active capability.
The security guardian’s functionality is similar to traditional reference monitor,
with several major differences. In traditional systems, a reference monitor is interposed
between the subjects and objects to control subjects’ access to objects based on access
authorizations (Figure 3). The traditional reference monitor is passive in the sense that
it never initiates actions but only reacts when it receives an operation message. Access
through the reference monitor is either granted or denied corresponding to a yes or
no access evaluation result. The power and functionality of the traditional passive
reference monitor are limited [2].
Authorization Database
Subject
Reference Monitor
Object
Audit Trail
Figure 3: Reference Monitor Concept
With the use of ACs, the security guardian is no longer passive. To make it active,
first we need to extend ACs. In addition to access control decision information, ACs
may carry other security information. For example, an AC may specify a particular
encryption key length for a particular region or country together with access control
information. To carry out the the intended security operations specified by ACs, an
evaluation engine and an enforcement engine are included in the security guardian.
The evaluation engine evaluates ACs in a secure sandbox. The enforcement engine
interacts with other NodeOS components to enforce faithfully the security operations,
using the security library services. The enforcement engine can initiate security actions
based on ACs requirements. So the security guardian may trigger or initiate security
actions. The triggers can be intrusion detection alarms, or explicit requests by EEs or
applications that use active networking features. For example, the security guardian
can initiate installing firewalls dynamically.
61
3.4 NodeOS Security API
As mentioned above, the current NodeOS API [28] focuses on fast network packetforwarding and fine-grained quality of service. It provides mainly an interface for resource management without explicit security support. As a complement, the NodeOS
security API is designed to provide explicit security support to EEs and active applications. It exports security services including authentication, authorization and integrity
to EEs and active applications. The security API is defined as generically as possible
to accommodate a wide variety of implementations.
A standard, generic security API promotes easy, widespread development and use
of secure applications utilizing security. It allows combinations of cryptographic security that support a range of protection levels. The API and different protection levels
support the needs of secure international software applications utilizing cryptography,
factoring law enforcement and national security interests. They enable flexible, lowcost methods for cryptographically protecting sensitive information.
An API should satisfy the needs of both simple and sophisticated applications and
should be easy to use. It should require applications to have a minimal degree of
cryptographic awareness. According to NSA [34], there are several considerations for
security API design:
Algorithm Independence
Application Independence
Cryptomodule Independence
Degree of Security Awareness
Modular Design and Auxiliary Services
Safe programming
Security Perimeter
We advocate a NodeOS security API that is generic and compatible with available
security API standards. Currently several related high-level APIs are available in the
research community:
1. Generic Security Service API (GSS API): The GSS API is designed specifically
for network communication protocols and provides additional support for securing network communications after authentication [15]. It provides protection
for communication using authentication, integrity, and/or confidentiality security services. Its extensions support access control and delegation [26].
2. Pluggable Authentication Module API (PAM API): This supports pluggable authentication in stand-alone, non-connection-oriented environments for users and
provides system level authentication service [31]. It also provides a uniform
interface for authentication that is compatible with many authentication provisions, and thus provides complementary functionality to the GSS API. The Java
Authentication and Authorization System API (JAAS API) bases its authentication on the PAM API in the Java language environment [14].
62
3. Generic Authorization and Access Control Application Program Interface (GAA
API): The GAA API supports authorization decisions for applications in a distributed environment [30, 29]. An application invokes the GAA API functions
to determine if a requested operation or set of operations is authorized or if
additional checks are necessary. An application can also use the GAA API to
request access control information about a particular resource. The GAA API
can be used to obtain a principal’s access rights on an object or a resource and
supports the needs of most applications. Developers don’t need to design their
own authorization mechanisms.
The NodeOS API combines the above APIs to support authentication, authorization, integrity, and access control. A security library implements the NodeOS security
API. The API is based on the active network flow concept and supports end-to-end
security, hop-to-hop security, and the active network protocols including routing protocols.
EE
Authentication
Authorization
Security Services
PAM API
GAA API
GSS API
X.509,
Password-based,
Kerberos,
SESAME,
Etc.
Active Capability,
PolicyMaker,
ACL,
Etc.
JCE,
Kerberos
SESAME,
Etc.
Security
Guardian
Public Key API
X.509 PKI
Dynamic Policy
Framework
RFC 2510
PKIX
NodeOS
Figure 4: NodeOS API Design
The NodeOS security API has three major components as shown in Figure 4, the
authentication API, the authorization API, and the security services API:
The authentication API authenticates EEs, AAs, or users. It is based on the PAM
API. As shown in Figure 4, a possible implementation of the authentication API
uses the X.509 public key infrastructure (PKIX). RFC 2510, the Internet X.509
Public Key Infrastructure Certificate Management Protocol, provides a detailed
description of the security functions supported by PKIX.
63
The authorization API helps protect NodeOS resources. It is based on the GAA
API. The security guardian in the Figure 4 supports access-control policy evaluation and enforcement. The security guardian’s functionality is similar to a
traditional reference monitor or to the role of the checking software that is invoked when a user process requests a supervisor privilege in a traditional operating system like UNIX. All accesses to node resources must go through security
guardian. One possible implementation of an access control mechanism is the
active capability described previously.
The security services API provides security services such as encryption and digital signatures. The security services API is based on the GSS API.
Our focus is to export core and essential security functionality to the EEs and active applications while securing the active network infrastructure. Thus, the EEs, the
active applications, and the NodeOS itself can use this API for security services, for
example, to support hop-hop authentication and security. The implementation of the
API must be secure if key management and principal identification are to be secure and
thus we locate the implementation of the API within the NodeOS and below the security guardian to take advantage of any hardware protection available to the NodeOS
implementation.
The NodeOS Security API we have described is comprehensive but not exhaustive. It can be extended easily for future security enhancements. For example, it can
be extended to include the IDUP-GSS-API later, if necessary. The IDUP-GSS-API,
Independent Data Unit Protection Generic Security Service API, is similar to GSS
API, but is designed for independent data unit protection [3]. It extends the GSS API
for applications requiring protection of a generic data unit (such as a file or message).
The protection of one data unit is independent of the protection of any other data unit
and independent of any concurrent contact with designated receivers of the data unit.
3.5 Quality of Protection
By using the NodeOS security API, active security guardian, and active networking
features, it is feasible to provide quality of protection to active applications. Similar
to QoS, QoP supports customized, flexible security and protection requirements of
applications. For example, applications can specify routing paths based on security
and protection requirements.
To provide quality of protection, the NodeOS API needs to be enhanced with different security and protection options. These options are supported by the underlying
security library implementation in the NodeOS. In addition the security and protection
features need to be characterized. Some sample QoP characteristics include:
Key length of security algorithms
Robustness or strength of security algorithms
Security mechanisms for authentication and privacy
Trust values for developers/vendors of security implementations: One may trust
more the implementation of security algorithms by reputable vendors.
64
Assurance level of a router NodeOS: The orange book defines the assurance
class for an operating system as D, C1, C2, B1, B2, B3 or A1 [9]. A router
NodeOS with higher assurance class is more trustworthy.
Geographical location of routers: One country may not trust the protection provided by the routers in enemy countries.
Active capabilities are used to specify, control and manage QoP. A trust party creates ACs upon the requests of applications.
With a NodeOS Security API, an Active Security Guardian, and Quality of Protection (QoP) provisions, the secure node can provide active security features to applications. Applications of active security include a security-customized routing path
specified by an application and stronger protection under intrusion. For quality of service applications, both time constraints and security features are important [24]. The
QoP allows dynamic reconfiguration and tradeoffs between security protection and
satisfaction of the QoS constraints. The protection may be provided on per-service,
per-flow, or per-capsule base to optimize performance overhead.
3.6 Low-level Code Safety
The evaluation engine of security guardian relies on Java language for low-level code
safety. The minimum requirements for low-level code safety are control flow safety,
memory safety, and stack safety [13]. Currently we use the Java byte code verifier
[36] provided by Java language for low-level code safety. Before loading a class, the
verifier performs data-flow analysis on the class code to verify that it is type safe and
that all control-flow instructions jump to valid locations [17].
There are several other approaches for low-level code safety. The PLAN project [1]
uses programming language techniques to address the code safety problem. Capsules
are written using a strongly typed, resource limited language and dynamic code extensions are secured by using type safety and other mechanisms. Another approach is
Proof-Carrying Code (PCC) [25]. Besides regular program code, PCC carries a proof
that the program satisfies certain properties. The proof is verified before the execution
of the code. The generation of a proof may be complex and time consuming, while its
verification should be simple and efficient. Software fault isolation (SFI) [35] provides
another alternative for low-level code safety. It uses special code transformations and
bit masks to ensure that memory operations and jumps access only the correct memory
ranges.
In summary, there are a variety of different mechanisms and protocols proposed.
Each method has its own advantages and disadvantages. Ultimately the application
must be given the choice to pick the mechanism that is most suitable for its purpose.
The secure node architecture is generic enough to allow all these mechanisms to coexist.
3.7 Discussion
An execution environment can also implement security requirements within itself [23].
It can set up security policies for active applications running inside it. While this paper
65
does not focus on the EE security, the same design principles discussed in this paper
can be applied to the EE security.
4 Current Status and Future Work
We have a prototype implementation of secure node architecture, with a simplified version of security guardian. The security guardian is used in the Seraphim architecture
framework [18, 6]. The security guardian of NodeOS can obtain ACs from a trusted
policy server and evaluate them. The evaluation result of a AC is either a yes or no.
The AC is used to control the access to the NodeOS resources, such as channels. Two
innovative applications [18, 16] are implemented to show the benefits of the proposed
research. They add little performance overhead to the network.
We are currently extending the prototype to a full implementation of the secure
node architecture. We plan to demonstrate the power of active security by various
applications. The applications include secure routing protocols, security-customized
routing paths specified by an application and strengthened protection under intrusion.
We also plan to investigate the dynamic reconfiguration and tradeoffs between security
protection and satisfaction of the QoS constraints.
5 Conclusions
This paper describes the design of securing the node of an active network. It shows
that such a secure node architecture, based on active network principles, can provide
fundamental base for securing the active network infrastructure and supporting application specific dynamic security requirements and policies. The research in this paper
complements the current active network research and augments its functionality. The
secure node architecture provides authentication, authorization, integrity, dynamic access control, and quality of protection for active applications.
The flexibility and expressibility afforded by the secure node enables us to implement a multitude of diverse, innovative and exciting applications. These applications
exploit the active networking paradigm without compromising the security of the infrastructure. In addition, our architecture lays the ground rules for seamless integration
with parallel and ongoing efforts in the active networks community. The same design
principles can be applied to the security support for the execution environment of an
active node.
6 Acknowledgments
The authors would like to thank other current Seraphim project members, Prasad Naldurg and Seung Yi, for their contributions to the design and implementation of the
Seraphim system. Part of the system is presented in Section 3.1, Section 3.2 and
Section 3.3. The authors would also like to thank Jalal Al-Muhtadi for the useful
discussions on NodeOS security API design.
66
References
[1] The SwitchWare Project Homepage http://www.cis.upenn.edu
switchware/.
[2] M. D. Abrams and J. D. Moffett. A higher level of computer security through active
policies. Computer & Security, 14(2):147 – 157, 1995.
[3] C. Adams. Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API). RFC 2479, December 1998.
[4] Godmar Back, Patrick Tullmann, Leigh Stoller, Wilson C. Hsieh, and Jay Lepreau. Java
operating systems: design and implementation. Technical Report 98—015, Department of
Computer Science, University of Utah, August 1998.
[5] K. Calvert et al. Architectural framework for active networks. AN Architecture Working
Group, Draft, 1998.
[6] Roy H. Campbell, Zhaoyu Liu, M. Dennis Mickunas, Prasad Naldurg, and Seung Yi.
Seraphim: dynamic interoperable security architecture for active networks. In IEEE OPENARCH 2000, Tel-Aviv, Israel, March 26–27, 2000.
[7] Roy H. Campbell, M. Dennis Mickunas, Tin Qian, and Zhaoyu Liu. An agent-based architecture for supporting application aware security. In the Workshop on Research Directions
for the Next Generation Internet, May 1997.
[8] Roy H. Campbell and Tin Qian. Dynamic agent-based security architecture for mobile
computers. In the Second International Conference on Parallel and Distributed Computing
and Networks, Brisbane, Australia, December 1998.
[9] National Computer Security Center.
The Interpreted Trusted Computer
System Evaluation Criteria Requirements, July 1995.
Also available at
http://www.radium.ncsc.mil/tpep/library/tcsec/ITCSEC.ps.
[10] David Evans and Andrew Twyman. Flexible policy-directed code safety. In IEEE Symposium on Security and Privacy, Oakland, CA, May 9-12, 1999.
[11] John Hartman, Larry Peterson, Andy Bavier, Peter Bigot, Patrick Bridges, Brady Montz,
Rob Piltz, Todd Proebsting, and Oliver Spatscheck. Joust: A platform for liquid software.
IEEE Computer, April 1999.
[12] M. Frans Kaashoek, Dawson R. Engler, Gregory R. Ganger, Héctor M. Briceño, Russell Hunt, David Mazières, Thomas Pinckney, Robert Grimm, John Jannotti, and Kenneth
Mackenzie. Application performance and flexibility on exokernel systems. In Proceedings
of the 16th ACM Symposium on Operating Systems Principles (SOSP ’97), pages 52–65,
Saint-Malô, France, October 1997.
[13] Dexter Kozen. Efficient code certification. Technical Report 98–1661, Department of
Computer Science, Cornell University, January 1998.
[14] C. Lai, L. Gong, L. Koved, A. Nadalin, and R. Schemers. User authentication and authorization in the Java platform. In 15th Annual Computer Security Applications Conference,
Phoenix, AZ, December 6-10, 1999.
[15] J. Linn. Generic Security Service Application Program Interface, Version 2. RFC 2078,
January 1997.
[16] Zhaoyu Liu, Roy H. Campbell, Sudha K. Varadarajan, Prasad Naldurg, Seung Yi, and
M. Dennis Mickunas. Flexible secure multicasting in active networks. In International
Workshop on Group Computation and Communications, Taipei, Taiwan, April 2000.
[17] Zhaoyu Liu, M. Dennis Mickunas, and Roy H. Campbell. Secure information flow in mobile bootstrapping process. In International Workshop on Wireless Networks and Mobile
Computing, Taipei, Taiwan, April 2000.
67
[18] Zhaoyu Liu, Prasad Naldurg, Seung Yi, Tin Qian, Roy H. Campbell, and M. Dennis Mickunas. An agent based architecture for supporting application level security. In the DARPA
Information Survivability Conference and Exposition, Hilton Head Island, SC, January
25-27, 2000.
[19] David Mazières and M. Frans Kaashoek. Secure applications need flexible operating systems. In Proceedings of the 6th Workshop on Hot Topics in Operating Systems (HotOS-VI),
pages 56–61, Chatham, Cape Cod, Massachusetts, May 1997. IEEE Computer Society.
[20] S. Merugu, S. Bhattachajee, E. Zegura, and K. Calvert. Bowman: A Node OS for active
networks. In Proceedings of INFOCOM 2000, March 2000.
[21] D. Mosberger and L. Peterson. Making paths explicit in the scout operating system. In
Proceedings of OSDI ’96, pages 153–168, October 1996.
[22] S. Murphy, O. Gudmundsson, R. Mundy, and B. Wellington. Retrofitting security into
internet infrastructure protocols. In the DARPA Information Survivability Conference and
Exposition, Hilton Head Island, SC, January 25-27, 2000.
[23] Sandra Murphy et al. Security architecture for active nets. AN Security Working Group,
July 15, 1998.
[24] Klara Nahrstedt and Duangdao Wichadakul. QoS-aware active gateway for multimedia
communication. In Proceedings of 6th International Workshop, IDMS ’99, Toulouse,
France, October 1999. Lecture Notes in Computer Science 1718, Springer.
[25] G. C. Necula. Proof-carrying code. In Principles of Programming Languages (POPL ’97),
pages 106–119, January 1997.
[26] T. Parker and D. Pinkas. Extended Generic Security Service APIs: XGSS-APIs Access
control and delegation extensions. Internet-Draft, November 1998.
[27] C. Partridge. Using the flow label field in IPv6. RFC 1809, June 1995.
[28] L. Paterson et al. NodeOS interface specifications. AN NodeOS Working Group, Draft,
1999.
[29] T. Ryutov and C. Neuman. Access Control Framework for Distributed Applications.
Internet-Draft, March 2000.
[30] T. Ryutov and C. Neuman. Representation and evaluation of security policies for distributed system services. In the DARPA Information Survivability Conference and Exposition, Hilton Head Island, SC, January 25-27, 2000.
[31] V. Samar and C. Lai. Making login services independent from authentication technologies.
In Proceedings of the SunSoft Developer’s Conference, March 1996.
[32] Tomas Sander and Christian F. Tschudin. Protecting mobile agents against malicious hosts.
In Mobile Agent Security, LNCS 1419. 1998.
[33] R. S. Sandhu and E. J. Coyne. Role-based access control models. IEEE Computer, 29(2),
February 1996.
[34] NSA Cross Organization CAPI Team. Security Service API: Cryptographic API Recommendation, July 1996. Second Edition.
[35] Robert Wahbe, Steven Lucco, Thomas E. Anderson, and Susan L. Graham. Efficient
software-based fault isolation. In SOSP ’93.
[36] Frank Yelin. Low-level security in Java. In WWW4 Conference, December 1995.
[37] L. Zhang, S. E. Deering, D. Estrin, S. Shenker, and D. Zappala. RAVP: A new resource
ReSerVation Protocol. IEEE Network Magazine, (5), 1993.
68
APPENDIX G
APPENDIX G
PLUGGABLE ACTIVE SECURITY FOR ACTIVE NETWORKS
ZHAOYU LIU, PRASAD NALDURG, SEUNG YI, ROY H. CAMPBELL, M. DENNIS MICKUNAS
Department of Computer Science
University of Illinois at Urbana-Champaign
Urbana, IL 61801
{zhaoyu, naldurg, seungyi, roy, mickunas}@cs.uiuc.edu
provide controlled access to the router resources. In
addition, active network routers have to provide support
to
• prevent malicious behavior of arbitrary user code
and
• protect the user code and data from malicious
routers
ABSTRACT
Security is of critical importance to the success of
active networking. In addition, we argue that active
security based on active networking principles can offer a
wide range of opportunities to build better security
systems. This paper describes the integration of active
security into a software system implementing the active
network architecture. The paper demonstrates that an
extensible, reconfigurable security architecture based on
active networking is flexible and accommodates a wide
variety of security policies and mechanisms. The active
security provides users the ability to dynamically create
and enforce highly customized and situational policies for
their applications. The active security also permits
security systems to react to intrusion and can aid the
application of the "need-to-know" security principle to
network software and application security.
Though a wide range of policy types [4] and
mechanisms [5] have been proposed, underlying
operating systems implement only a static subset of these
policies and mechanisms. Applications that want to use
sophisticated or customized policies have to make do with
lesser or weaker security guarantees. The overhead
associated with adding new policies and mechanisms can
also be prohibitive.
In order to exploit the active network flexibility, we
have developed a dynamic, fully extensible, interoperable
security architecture based on and built into the
underlying active network architecture [6]. We term this
approach active security [7]. The security architecture
enables both static and runtime application-aware
reconfiguration [8]. Adaptation allows the security
provisions of the network to meet specific individual
security requirements within different application
scenarios. Applications can request specific security
policy instantiations on specific parts of the network,
distributing the relevant security policies on a "need-toknow" basis. Alternatively, changes in the security
policies for the network can be triggered by the
invalidation of a trust model, perhaps by the detection of
intrusion or other abnormal behavior.
Keywords: active networks, security, reconfigurable,
active capability, interoperability
1 INTRODUCTION
An active network provides a software framework
that enables network applications to customize the
processing of their data [1, 2]. Active applications inject
capsules that contain programs (along with data) into the
network. Active routers dynamically install these
programs and execute them on the data. Though this
facilitates fast protocol and service deployment it also
makes the routers vulnerable to attacks from arbitrary
user-code. Securing the routing infrastructure against
threats and exposures remains a major challenge in this
paradigm [3].
In this paper we describe the integration of active
security into a software system (Bowman and CANEs
[13, 14]) implementing the active network architecture
[12] to showcase the above claimed advantages. Our
active security system is composable and can be easily
plugged into current active network systems. The
integration demonstrates that the active security can
provide users the ability to dynamically create and
enforce highly customized and situational policies for
their applications. It also shows that the active security
can permit security systems to react to intrusion and can
Traditional networks rely on the underlying
operating system to implement security mechanisms and
policies. The traditional definition of security in a
network environment includes authentication, access
control, and encryption. Applications and routers establish
a basis for trust by mutual authentication. To protect the
integrity of the contents of the capsules, encryption and
digital signatures can be employed. Access control
mechanisms or policies are defined and enforced to
69
policy, it downloads the code dynamically into the
framework, using the underlying active network. It then
instantiates the run-time parameters associated with the
application in its sandbox-like environment and executes
the active capability in this environment. Based on the
result of the evaluation of this active capability, the access
control decision is enforced.
aid the application of the "need-to-know" security
principle to network software and application security.
The rest of the paper is organized as follows.
Section 2 overviews our Seraphim active security
architecture. Section 3 describes the integration of our
architecture into a software system implementing the
active network architecture. Section 4 presents an
application example to show the flexibility of the active
security based on the current implementation. Section 5
shows the preliminary performance measurement. Section
6 describes the future plan of the integration. The last
section concludes this paper.
The principal of the active capability, which can be
a user, a role, or other principal, must be authenticated by
a trusted authority. The trusted authority acts as the policy
server in our system. The policy server is responsible for
generating ACs, serving ACs to applications and keeping
track of ACs. Usually one or more policy servers are
associated with each protection domain. Application
programs contact their nearest or least-loaded server and
obtain the active capability dynamically.
2 SERAPHIM: ACTIVE SECURITY
ARCHITECTURE
Seraphim is a dynamic, flexible, and application
specific security architecture that exploits the active,
dynamic functionality provided by active networking
using an active capability (AC) [6, 9]. Essentially an AC
is an executable Java code, which concisely represents
dynamic security policies and mechanisms. ACs are
evaluated by a security guardian in a secure sandbox
environment and the security guardian enforces the
security requirements of AC evaluation results. We
describe the architecture in more detail next.
2.2 POLICY FRAMEWORK
The policy framework is an object-oriented and
coded in Java. This allows users and commercial
organizations to specify policies tailored to their specific
operational needs. The framework itself is a hierarchy of
classes as shown in Figure 1.
DDAC
2.1 ACTIVE CAPABILITY
DAC
Active capabilities are used to support flexible
distributed dynamic security policies and services control
employing the same active principles as active networks
[6, 9]. Unlike a traditional capability, which is merely a
static authorization credential that encodes the principal
and the permissions associated with the principal, an
active capability is a customized piece of code that
encodes the type of access control policy and other
constraints used in the access control decision making
process. In our implementation, an AC is an executable
Java code that concisely represents dynamic security
policies and mechanisms. In addition, an active capability
is protected by digital signatures, resides in user space and
can be freely passed around.
MAC
RBAC
Interfaces
OS
Primitives
Figure 1: Component-level Map of the
Policy Framework
An active capability can carry all the decisions
policy information in its code. This way of
implementation is not modular, elegant and efficient. A
better way is to have a generic policy framework that
supports different various policy types. ACs use the
framework to implement specific policies. An application
presents an active capability along with its regular data or
protocol capsules to the active router’s security guardian
at execution time. The access control policy type and user
credentials are extracted from the capability. The remote
router’s security guardian recreates the context of the
policy type within its policy framework. If at any point
during this process the policy framework discovers that it
does not have an implementation for the type of the
The framework is dynamically configurable and
extensible. The classes at the bottom of the framework are
mostly abstract and are mainly used to represent
mathematical concepts such as sets and mappings. These
classes form the basis for a hierarchy of successively
incremented specialized classes representing concepts
such as labels and access control lists. Finally, at the top
of the framework are classes that can be used to represent
a variety of generic policy forms.
The policy framework supports the following
common types of access control: Mandatory (MAC),
70
provides lower level services. To make the elementary
Bowman channel, a-flow, and state-store abstractions
more useful for users, Bowman provides an extension
mechanism that is analogous to loadable modules in
traditional operating systems. Using extensions, the
Bowman NodeOS interface can be extended to provide
support for additional abstractions such as queues, routing
tables, user protocols and services ([15] provides a more
complete NodeOS API).
Discretionary (DAC), Double Discretionary (DDAC), and
Role-based (RBAC) [10]. More application specific
access control policy systems can be easily extended from
this object-oriented framework ([11] provides several
good examples). In our model, we can specify not only
the traditional <subject, object, operation> access control
triple, but also include a resource limit on usage,
situational decision rules, constraints and dependences,
e.g., based on current time of the day or current role of the
principal. The main policy type we use for active
networks is RBAC because of its flexibility. We will
describe its usage in more detail later.
The CANEs EE is built on the top of the Bowman
NodeOS. It provides a composition framework for active
services based on customizing a generic underlying
program by injecting code to run in specific points called
slots. The composition model basically has two parts.
The first part, the underlying program, is a fixed part for
uniform processing applied to every packet. The second
part, the injected program, is a dynamic part that provides
user-specific functionality for routing and processing the
packets. The injected program is dynamically executed at
the appropriate specific points (slots) in the underlying
program. CANEs uses signaling messages to control the
injected programs.
2.3 SECURITY GUARDIAN
The security guardian in the architecture supports
AC evaluation and enforcement. The security guardian’s
functionality is similar to a traditional reference monitor.
All accesses to node resources must go through the
security guardian. The security guardian uses the security
library services to verify the signature on the active
capability. To carry out the intended security operations
specified by ACs, an evaluation engine and an
enforcement engine are included in the security guardian.
The evaluation engine evaluates ACs in a secure sandbox.
The enforcement engine interacts with other NodeOS
components to enforce faithfully the security operations,
using the security library services. The enforcement
engine can initiate security actions based on ACs
requirements. So the security guardian may trigger or
initiate security actions. The triggers can be intrusion
detection alarms, or explicit requests by execution
environments (EEs) or applications that use active
networking features. For example, the security guardian
can initiate installing firewalls dynamically [6].
CANEs API
I1
I2
U
User A−flow
CANEs EE
CANEs Signalling A−flow
Security Guardian
Policy Administrator
GUI
(JNI, JVM)
Policy Server
System Thread
Bowman NodeOS
3 INTEGRATION OF SECURITY INTO
ACTIVE ARCHITECTURE
Host OS
This section describes the integration of the above
security system into a software system implementing the
active network architecture [12]. The software system has
two parts: the Bowman NodeOS and the CANEs
execution environment [13, 14]. We first briefly overview
the Bowman and CANEs systems, and then present the
integration.
Figure 2: Integration of Active Security into
Bowman and CANEs
3.2 INTEGRATION
The integration of active security, CANEs and
Bowman is shown in Figure 2. The security guardian is a
thin layer between the Bowman NodeOS and the CANEs
EE. The Bowman NodeOS interfaces are replaced by the
security interfaces. The security guardian does the
following security checkings [16]:
3.1 OVERVIEW OF BOWMAN AND CANES
The Bowman node operating system is built to
support the CANEs EE. It is designed around three key
abstractions: channel, a-flow, and state-store. A channel
is the primary abstraction for communication and an aflow is the primary abstraction for computation. The
state-store provides a mechanism for a-flows to store and
retrieve state that is indexed by a unique key. The
Bowman is layered on top of a host operating system that
•
71
Authentication: It verifies the identification and
the signature of the request messages. We use
X.509 certificates [17] and a simple public key
infrastructure (PKI) for authentication.
RBAC
RBAC
default_role, root@null, router B, o_aflow_create_default
default_role, root@null, router A, o_aflow_create_default
Router A
Router A
Router B
Router B
AC
AC
RBAC policy admin
installs new capability and
root can create flow now
Root can not create flow on Router B
No capability found
Figure 4: Second Demo Scenario
Figure 3: First Demo Scenario
•
AC
Flow
Flow
We have implemented a preliminary version of the
authorization part of the integration. Based on the
authorization part, we have developed an example
application scenario, which is shown in Figure 3, 4, 5 and
6. Figure 3 shows that on behalf of user root@null of role
default_role, the CANEs EE can create an a-flow on the
router A, but not on the router B. In order to have a
complete flow path from the user root@null to the router
B, we can dynamically create a new AC through the
policy GUI and install it at the router B. Now the CANEs
EE can create an a-flow on both router A and B on behalf
of the user root@null of role default_role (Figure 4). The
policy type of Figure 3 and 4 is RBAC. If we want to
have a stricter and less flexible policy we can dynamically
change RBAC to MAC (Figure 5). In this case, the trigger
for the policy type change may be an intrusion detection
alarm. In MAC policy every entity is assigned a security
level. A hierarchy is defined in terms of these levels.
Subjects with lower levels cannot read from objects of
higher levels and subjects with higher levels cannot write
to objects of lower levels. We assume that the MAC level
L1 is higher than MAC level L2. This means that the
router B has lower security level than the router A. So if
user root@null is also at security level L1, then user
root@null can create an a-flow at only the router A since
user root@null cannot write to router B (Figure 6).
Authorization: If authentication succeeds, it then
checks the access permission for the requests.
This requires fetching and evaluating ACs.
Since Bowman and CANEs are written in C to
obtain high performance and the Seraphim architecture is
implemented in Java for interoperability and security
purpose, we use JNI (Java Native Interface) in Bowman
and CANEs to invoke the security guardian in Java.
When Bowman starts, it starts the security guardian
component that invokes Sun JVM. Each security check
from CANEs to the Bowman NodeOS security interface
is attached to the Sun JVM as a Java thread. After the
checking, the Java thread is detached and destroyed.
The security guardian obtains ACs through a secure
channel from the policy server. The policy administrator
uses a GUI that allows users or system administrators to
create and define policy specific attributes and to generate
active capabilities. The GUI allows the administrator to
create role definitions and associate users and permissions
with the role, and supports other functionality (see [10]
for more details).
4 APPLICATION EXAMPLE
MAC
Change to MAC
label L1, root@null, router A, o_aflow_create_default
Admin AC: Revoke RBAC, Grant MAC
Router B
Router A
Router A
Router B
MAC
L1
MAC
MAC
L1
Flow
MAC
L2
(root@null, L1) can not write to (B, L2)
user root@null could be compromised
L2
Figure 5: Third Demo Scenario
Figure 6: Fourth Demo Scenario
72
We also show that the active security can permit security
systems to react to intrusion and can aid the application of
the "need-to-know" security principle to network software
and application security. We believe that exploiting active
security is a step in the direction of designing a
comprehensive and flexible framework to integrate
various security mechanisms and services into the active
network architecture.
5 PERFORMANCE
The overhead that the integration introduces
includes the JNI invocation overhead and the regular
security overhead. The regular security overhead, which
includes AC fetching and evaluation, is necessary for
flexible access control and has been studied previously
[6]. We used a simple active ping application
(atraceroute) between two machines A and B to measure
the JNI invocation overhead. Machine A is a Sun Ultra-5
machine, and machine B is a Sun Ultra-2 machine. Both
A and B are on the same 100Mbps Ethernet LAN.
Machine A sends an atraceroute to machine B that is
running the Bowman NodeOS. We measure the round trip
time (RTT) of the atraceroute command with and without
JNI invocation (When with JNI invocation, we let
security guardian simply return a true value in order not
to include the regular security overhead). Without any
optimization, the RTT is about 2400ms without JNI
invocation and about 9100ms with JNI invocation.
8 ACKNOWLEDGEMENTS
We would like to thank Matt Sanders, Ken Calvert
and Ellen Zegura to help us understand the Bowman
NodeOS and CANEs execution environment system.
This research is supported by DARPA F30602-981-0192.
REFERENCES
[1] D. Wetherall, J. Guttag, and D. Tennenhouse. ANTS:
A Toolkit for Building and Dynamically Deploying
Network Protocols. In OPENARCH’98, 1998.
In order to improve the performance, we plan to
have a leaner JVM replace the current Sun JVM. A
possible choice is Kaffe JVM [18]. A more dramatic
improvement would be to use a simpler language than
Java for ACs. The sandbox evaluation engine of the
security guardian of the simpler language must be
efficient.
[2] D. Wetherall, U. Legedza, and J. Guttag. Introducing
New Internet Services: Why and How. In IEEE Network
Magazine, July 1998.
[3] S. Murphy, ed. Security Architecture Draft. AN
Security Working Group. Draft.
6 FUTURE PLAN
[4] Ravi Sandhu. Role-Based Access Control. In
Advances in Computers, Vol. 46, Academic Press, 1998.
Also at http://www.list.gmu.edu/articles.htm
We plan to extend the current integration
implementation to provide security checking for all
CANEs signaling messages. We plan to add
authentication and dynamic revocation to the integration,
using the security NodeOS API [16]. We also plan to
integrate the Denial of Service prevention features into
the system. Finally we will install an experimental setup
for the flexible, secure, and composable demanded video
distribution application [19] to demonstrate the secure
composable services for active networks.
[5]
The
SwitchWare
Project
http://www.cis.upenn.edu/~switchware/
Homepage.
[6] Zhaoyu Liu, Prasad Naldurg, Seung Yi, Tin Qian, Roy
H. Campbell, and M. Dennis Mickunas. An Agent-based
Architecture for Supporting Application Level Security.
In the DARPA Information Survivability Conference and
Exposition, Hilton Head Island, SC, January 2000.
[7] Roy H. Campbell, Zhaoyu Liu, M. Dennis Mickunas,
Prasad Naldurg, and Seung Yi. Seraphim: An Active
Security Architecture for Active Networks. Tech. Report
2137, Department of Computer Science, University of
Illinois at Urbana-Champaign, November 1999.
7 CONCLUSION
This paper describes the integration of the Seraphim
active security into a software system implementing the
active network architecture [12]. The active security
architecture is dynamic, fully extensible, interoperable
and is based on the underlying active network principles.
The integration demonstrates that the active security
architecture can be easily plugged into the active network
architecture such as Bowman and is flexible and
accommodates a wide variety of security policies and
mechanisms. We show that active security can provide
users the ability dynamically to create and enforce highly
customized and situational policies for their applications.
[8] Roy H. Campbell, Zhaoyu Liu, M. Dennis Mickunas,
Prasad Naldurg, and Seung Yi. Seraphim: Dynamic
Interoperable Security Architecture for Active Networks.
In IEEE OPENARCH 2000, Tel-Aviv, Israel, March
2000.
[9] Roy H. Campbell, M. Dennis Mickunas, Tin Qian, and
Zhaoyu Liu. An Agent-based Architecture for Supporting
Application Aware Security. In the Workshop on
73
Research Directions for the Next Generation Internet,
Vienna, VA, May 1997.
[10] Vijay Raghavan. On the Design and Implementation
of a Security Policy Administration for a Dynamic
Security System. Master’s Thesis, Department of
Computer Science, University of Illinois at UrbanaChampaign, May 1999.
[11] Tim Fraser. An Object-Oriented Framework for
Security Policy Representation. Master’s Thesis,
Department of Computer Science, University of Illinois at
Urbana-Champaign, December 1996.
[12] K. Calvert, ed. Architectural Framework for Active
Networks. AN Architecture Working Group. Draft.
[13] S. Merugu, S. Bhattacharjee, Y. Chae, M. Sanders,
K. Calvert, and E. Zegura. Bowman and CANEs:
Implementation of an Active Network. In Proceedings of
37th Annual Allerton Conference, Monticello, IL,
September 1999.
[14]
The
CANEs
Project
http://www.cc.gatech.edu/projects/canes/
Homepage.
[15] L. Peterson, ed. NodeOS Interface Specifications.
AN NodeOS Working Group. Draft.
[16] Zhaoyu Liu, Roy H. Campbell, and M. Dennis
Mickunas. Securing the Node of an Active Network. In
Active Middleware Services, Salim Hariri, Craig Lee, and
Cauligi Raghavendra (editors), Kluwer Academic
Publishers, Boston, MA, September 2000.
[17] C. Adams and S. Farrell. Internet X.509 Public Key
Infrastructure Certificate Management Protocols. RFC
2510, March 1999.
[18] The Kaffe Homepage. http://www.kaffe.org/
[19]
The
PANAMA
Project
http://www.tascnets.com/panama/
Homepage.
74
APPENDIX H
75
76
77
78
79
80
81
82
83
84
85
86
View publication stats
RELATED PAPERS
Polonistyka "tu i teraz". Krajobraz po zmianie. Materiały Zjazdu Polonistów Warszawa 2022
Polonistyka wobec wyzwań kultury popularnej2023 •
2000 •
2018 •
ISPRS International Journal of Geo-Information
Hydrological Modeling with Respect to Impact of Land-Use and Land-Cover Change on the Runoff Dynamics in Godavari River Basin Using the HEC-HMS ModelHIKMA - Journal of Islamic Theology and Religious Education
A Sufi Treatise on Vampires: Muḥammad Nūr al-ʿArabī's Risāle-i Saʿīdiyye2024 •
2024 •
2008 •
Al-Tadzkiyyah: Jurnal Pendidikan Islam
The Evaluation of Students' Religious Development at SchoolJurnal Pengabdian Multidisiplin
Pengembangan Experiental Tourism di Kalitaji Kapanewon Kokap Kulon Progo2023 •
Emerald Publishing Limited eBooks
Research-related Information Management: Reflections from Southern African Practitioners2023 •
Journal of Applied and Computational Sciences in Mechanics
Numerical analysis of mix convection of sodium alginate non-Newtonian fluid with 〖Al〗_2 O_3nanoparticle in a channel with blockEnvironmental Research
Characteristics and health impacts of volatile organic compounds in photocopy centers2006 •
RELATED TOPICS
- Find new research papers in:
- Physics
- Chemistry
- Biology
- Health Sciences
- Ecology
- Earth Sciences
- Cognitive Science
- Mathematics
- Computer Science