Securing the Node of an Active Network - CiteSeerX

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

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

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 1

Management EE

EE 2 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.

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.

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

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

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.

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].

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.

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.

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

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.

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´ector M. Brice˜no, Russell Hunt, David Mazi`eres, 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ˆo, 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.

[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`eres 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.