Active Network Security for the ABone

Transcription

1 Active Network Security for the ABone The ISI ARP Project University of Southern California/Information Sciences Institute (ISI) 4676 Admiralty Way Marina del Rey, CA November INTRODUCTION This document proposes an approach to implementing security for active networking within the ABone, a DARPA-funded active network testbed[1]. The ABone provides a platform for testing active networking concepts on a relatively large scale and in a realistic networking environment. At present there are two major EEs installed in the ABone: the ANTS EE from MIT/UWashington/Utah[2-4], and the ASP EE from USC/ISI[5] ABone Security Security is vital for the ABone for operational as well as research reasons. Operationally, compromised nodes can make the testbed unusable. Many of the ABone nodes are supplied by research sites with the assurance that participation in the ABone will not facilitate penetration of the nodeos by an attacker. From the research viewpoint, it is important to experiment with active network security in the ABone environment. Security affects the three main components of active networking: the node operating system (nodeos), the execution environments (EEs), and the active applications (AAs)[6]. In most ABone nodes, the nodeos is a production UNIX platform Linux, FreeBSD, or Solaris that executes EEs as UNIX processes. The normal operating system facilities -- e.g., process model, accounts, and file system permissions -- are used to protect the OS from the EEs and protect the EEs from each other. The ABone architecture assumes that EEs themselves can be relatively well trusted, but that the EEs may execute arbitrary AA code. The ABone provides a software mechanism that allows researchers to load experimental EEs into remote ABone nodes. Although EEs execute as UNIX application programs, an EE that is designed for mischief could easily subvert a standard UNIX kernel. Hence, in the ABone the nodeos must place considerable trust in EEs. This is consistent with (but stronger than) the active nets architectural philosophy that installing a new EE has very significant security implications[6]. To ensure that only trusted EEs can be loaded, the ABone uses cryptographic security to prevent unauthorized users from installing EEs. Thus, the ABone builds a chain of trust from EE developers (principals who are generally trusted members of the active networking research community) to the EE code which only they can install. Besides loading EEs, the ABone s remote management mechanism also support the secure distribution of EE configuration files[1]. This facility can be used to distribute the configuration files for EE security that are described later in this document The Active Network Security Architecture (ANSA) Within the active network architectural framework[6], the research community has designed a standard active network security architecture (ANSA)[7]. In the ANSA, the primary security players are the principals that initiate active network operations. Principals are typically individuals, although other types of principals include any member of a group (e.g., one of the system administrators) or an individual acting in a specific capacity (e.g., Joe Smith in his role a

2 -2- County Treasurer). Active network security needs to address two kinds of threats: 1. Bogus active packets, originating in a non-active node or in a node that has been compromised, may interfere with the operation of legitimate AAs. 2. A malevolent AA may threaten the EE and/or the nodeos of an active node. The ANSA counters these two kinds of threats by (1) hop-by-hop security, i.e., integrity and neighbor-node authentication, and (2) end-to-end security, i.e., node policy enforcement based upon authenticated principal IDs, respectively. Under the end-to-end security mechanism of the ANSA, an active packet that is launched into the network may include a cryptographic certificate defining the principal ID and a digital signature binding that certificate to invariant fields of the packet. This certificate and signature are carried along as an active packet is forwarded hop-by-hop. While processing an active packet, each node can control its access to privileged operations and control its consumption of system resources using some policy that is keyed on the principal ID. The ANSA proposes to perform all of the hop-by-hop security and most of the end-to-end security functions in the nodeos. Implementing the ANSA in the nodeos means that security is applied equally to all EEs, and that EEs themselves need not be highly trusted. Node OS functions requested by an EE or an AA are subject to policy approval, i.e., permissions, that depends upon the authenticated principal IDs. A prototype of the ANSA called SANTS[8], based on the ANTS EE, has been implemented by NAI. SANTS introduces a modification to the ANEP packet header to carry the certificate and signature, and it use a very general piece of policy machinery, the Keynote system [ref?], for checking access to node OS services and resources. Besides SANTS, the AMP NodeOS, developed by a different group at NAI, also implements major components of the ANSA. 2. AN ABONE SECURITY ARCHITECTURE 2.1. Hop-By-Hop Security for the ABone Previous notes have discussed the problem of hop-by-hop security in the ABone. This is essentially the same problem as hop-by-hop security in the ANSA, and there are several candidate mechanisms. Hop-byhop security allows a node to authenticate packets from its directly connected neighbors, preventing both address spoofing and man-in-the-middle attacks on AAs. A simple implementation would be to protect each packet with a keyed cryptographic hash attached by the EE to all packets. Lindell has defined a more comprehensive solution for the ABone[9]. In the ABone, hop-by-hop security could be implemented either in the EEs or in the network I/O daemon netiod. The latter is logically equivalent to implementation in the nodeos without kernel changes. Howev er, implementation in netiod would add a processor-intensive function to a common I/O path, which would force a addition of multi-threading and CPU scheduling to netiod. Although we have not yet decided upon a single mechanism or installed the necessary key management infrastructure, we regard hop-by-hop security as an essentially solved problem. The rest of this document will be concerned only with end-to-end security End-to-End Security for the ABone As discussed previously, the ABone security model assumes relatively trusted EEs but arbitrary AAs. In order to be trusted, an EE must be able to effectively sandbox its AAs, isolating them from each other (to the extent required by the EE model), and protecting itself from their actions. An AA in the ABone still has two avenues for mischief: excessive resource consumption and misuse of privileged EE/nodeOS services. The EE and the nodeos need to be able to control the consumption of resources by an AA. For example, an AA must not be able to use all the CPU time in the node or to exhaust the

3 -3- memory resources. This also includes network resources consumed by sending packets. The EE needs to be able to enforce a policy on what calls an AA can invoke across the AA/EE boundary, which we will call the protocol programming interace or PPI. 1 Such PPI services include sending packets and perhaps changing routing tables. In executing a PPI call, the EE may make system requests to the nodeos. This leads to the question: how does the EE determine whether an AA execution instance can satisfy the policies restricting what PPI calls an AA can make and what resources it can use? Under the ANSA, the privileges of an AA in a particular node are be determined by the privileges associated with the principal ID responsible for invoking that AA. This is basically a good solution, but unfortunately the ANSA cannot be applied directly to the ABone. The ANSA implements security machinery in the nodeos, but it is not practical to modify the production UNIX systems of the ABone to include active networks security mechanisms while continuing to provide robustness against intrusions. To resolve this conflict, the ABone security model will implement a (simplified) version of the ANSA endto-end security mechanism in each EE rather than in the nodeos. This design choice, EE-level security, is based both on the practical considerations of making the system deployable in the ABone and on the research objective of encouraging security experimentation in the ABone. Just as active networking can accelerate innovative networking research by moving it into user space from the difficult kernel environment, so moving the security mechanism into user space can accelerate security experimentation. Implementing end-to-end security in the EEs has the disadvantage that it requires multiple implementations of the security code. We hope to provide portable Java classes that can be easily incorporated into a variety of EEs to implement much of the end-to-end security machinery (see Section 4). The proposed ABone end-to-end security architecture works in the following manner. 1. An arriving active packet is demultiplexed to an EE, using the ANEP Typeid. 2. The hop-by-hop security code in the EE validates the packet and discards it if validation fails. 3. The ANEP header may carry a credential and a signature over inv ariant parts of the packet. If so, the end-to-end security code in the EE validates the signature and extracts the principal ID. The EE passes this principal ID to the AA along with the incoming active packet. The EE also keeps a copy of the principal ID in a table bound to that AA instance. 4. The AA will generally record the different principal IDs it receives, and it must passes the appropriate ID in each restricted PPI call it makes. 5. When a PPI call is made, the EE verifies that a principal ID passed in the call matches its own copy in the per-aa-instance table. This check makes the principal ID unforgable by the AA. It also provides an obvious revocation mechanism: the EE only has to remove a principal ID from its table. 6. The EE then invokes some policy mechanism to determine whether to allow the PPI request or deny, based on the principal ID supplied in the call and perhaps on the identity of the AA. The architecture in Figure 1 shows the component data structures used by the EE to provide security on PPI calls. There is a per-aa table of principal IDs, and a shared access control list containing permission (i.e., policy) rules. These rules map a combination of AA ID and principal ID(s) to the privilege to get service from the EE. In Figure 1, the dashed lines indicate a correspondence between an AA principal cache and the EE table for that AA instance. In that figure, AA 1 has cached only a subset of the principal IDs that are available to it for use, while AA 2 has cached some that are invalid or revoked Persistent AAs It is important to notice that the ANSA, at least realized in SANTS, does not provide a sufficiently general resource model for the ABone. To understand the problem here, we need to understand the distinction 1 Although the PPI is an ASP construct, it is such a simple name for a global idea, the EE/AA interface, that we use it generically through this document.

4 -4- AA 1 AA 2 EE Permissions Principals NodeOS (Unix) Principals Figure 1: Active Nets Architecture with ABone AA/EE Security between transient and persistent AAs. A transient AA is created on packet arrival, performs some operation on the newly arrived packet, and terminates after forwarding the packet to its next hop. It leaves no persistent thread of execution after the initiating packet has been retransmitted or discarded, although it may cache persistent state. A transient AA cannot spontaneously send more packets at a later time or in response to a timer event; any action taken by a transient AA can be directly associated with the arrival of a packet. On the other hand, a persistent AA has a persistent execution thread that may be long-lived. It may send packets and issue other PPI requests at any time as the result of timer expirations rather than as the direct result of receiving new packets. Persistent AAs for control-plane functions like routing will need to execute with privileges (e.g., the right to change the routing table locally) that may exceed the privileges of the principal whose packet triggered the initial loading of the AA. The ANTS EE supports only transient AAs, although as a special case it supports one built-in persistent AA for routing. The ASP EE was designed for supporting persistent AAs in general. The ABone must provide for both. Transient AAs, for which execution events are tightly bound to individual packet reception events, invite and allow a tight per-aa allocation of resources. This typically takes the form of a "generalized TTL", a resource vector whose components are decremented at each hop until one of them expires. SANTS makes use of this model to control AA resources. On the other hand, an EE that supports persistent AAs requires a more general model for resource control Policy Mechanisms For each restricted PPI call, the policy mechanism evaluates a predicate over the principal ID and perhaps the identity of the AA. The call is allowed only if the predicate is true. There are two major motivations for allowing the AA identity to participate in validation of PPI requests: persistent AAs and performance. A persistent AA may receive many different principal IDs, and it may not be obvious what principal ID(s) it should use for issuing PPI calls. For example, the packet that causes an AA to be loaded may not come from a principal with enough privileges to initialize that AA. This problem can be avoided by simply assigning the privilege to the AA itself in such cases. Performance is another motivation for assigning privileges to AAs. Validating the signature, which requires public key cryptography, inv olves significant overhead. Every subsequent stage of handling a principal ID -- passing it to the AA, maintaining a table of unique principal IDs in an AA, passing it back to the EE in a PPI call, and validating it in the call -- involves some overhead. In contrast, the AA identifier can be validated once when the AA starts, and then its identity will be known with absolute certainty to the EE. PPI calls that can be allowed or disallowed based on the AA identity should be less expensive that those that require principal validation.

5 -5- SANTS uses a very general but complex policy mechanism, Keynote [ref?]. In the ABone, however, we want to approach such complexity only in incremental steps. Initially, the ABone security architecture will use the simple and specific policy mechanisms already implemented in the ANTS and ASP EEs: simple permission lists. Policy description is expected to be an area of continued research, so future policy descriptions may become more complex, up to the point of a full policy language that maps arbitrary combinations of principal IDs and AA names to privileges. In the nearer term, the permission lists for PPI calls will be used to allow or deny elementary privileges such as the examples shown in Table 1 The particular syntax and complexity of policy algorithm may be EE-specific, but logically the permission list may be considered to be a set of triples with one of the forms: ( <Principal ID>, <AA ID>, <privilege>) => ALLOW ( <Principal ID>, <AA ID>, <privilege>) => DENY Here any of the components of the triple may be a special value that matches "any", which may denote with an asterisk. We assume that the Permission list entries are scanned in order and the first matching entry for a giv en <privilege> is used. The permission list is expected to be ordered with the "longest" matches (i.e., fewest asterisks) at the beginning. Privilege initiate interface route divert process file socket native noaaspec Description The privilege to start this AA The privilege to modify the EE network interface table. The privilege to modify the EE network route table. The privilege to perform arbitrary packet interception. The privilege to terminate another AA. The privilege to read and write outside the file space of an AA. The privilege to use the Java sockets interface rather than using the channel based interface. Useful for legacy or third party software. The privilege to load native code into the Java Virtual Machine The privilege to suppress the mandatory AASpec generated by the EE in outgoing packets (ASP EE). Table 2: Example AA Privileges Note that it is entirely possible to have multiple instances of the same AA code executing at the same time under the same EE, whether these are considered different AAs or merely different execution instances of the same AA. Presumably each execution instance will have its own private state, including its cache of principal IDs. Although the different instances using the same AA code will be subject to the same permission rules, the permission decisions may differ since they may be running with different principal IDs. Initially a permission list will be a static file associated with the EE in each active node. It may also be possible for privileged AAs to update the permission list dynamically. One of the privileges controlled by the access control list could be the privilege to change the permission list. Although the permissions list is a simple linear table in theory, there are a variety of known techniques to keep the data structure size small and the access times low. This specification is not intended to preclude such optimizations. The permission list may also be used to control resource consumption by AAs. The details have not been worked out yet An Example This example considers a packet arriving at an EE for an AA that has not been loaded. The AA is a persistent AA that needs to initialize internal state based on information from the EE.

6 -6- A packet with a request for the example AA arrives at the EE. The EE performs hop-by-hop and end-toend authentication on the packet, validating the principals in the packet as well as any other information needed to start the AA. It checks the principal ID(s) to confirm that there is a privilege to start the AA. If so, the AA code is fetched, from remote or local code servers, and any authentication required on that code is performed. Once the AA code is acquired and authenticated, the AA is started. In this example, the AA may immediately make some PPI calls to initialize its internal state. These calls will be made with no principal IDs, because the AA has no IDs at this point. The EE will validate those calls only on the basis of the AA identity. This allows operations like initialization to function regardless of which principal issues the request that initiates the AA. After the AA has been started, the EE will also pass to the AA the packet and principal IDs included in it. The AA may read later packets and subsequently make PPI calls necessary to service the packet s requests. These PPI calls will include the principal IDs from the packet. Once the AA has been given a principal ID, the EE loses control over how that principal ID is used in a PPI request. Depending on the semantics of the AA, a single arriving packet may be cause any number of PPI calls, or none, and a PPI call may be or may not be associated with the arrival of a packet. AAs are allowed to decide which principal IDs to present with each PPI request. Although AAs are given the privileges to cache credentials and use them while they are valid, the EE maintains absolute control over the principal IDs, in the sense that the EE can destroy them[10]. At some later time, the EE may decide that any processing to be done on behalf of this packet or principal must have been done and may revoke the ID. This may be determined by a simple time out, by counting CPU cycles spent on requests carrying this ID, by an explicit revocation from another node, or any other means at the EE s disposal. An EE is free to choose its own revocation policy. 3. EE-Specific Implementation Issues 3.1. Principal ID Management Principal IDs may be passed in the clear because the EE validates the principal IDs used in PPI calls. Howev er, there may be more efficient representations. For example, a principal IDs might be represented in an AA by the integer index of the principal ID in the EEs per-aa table. Lazy validation of principal IDs is extremely desirable for efficiency. The ANSA seems to preclude this, indicating that the principal IDs need to be validated when the packet is received. However, for the ABone it is vital that we support AAs that require no special privilege and carry no credentials, and that we avoid expensive public key cryptography unless it is necessary. An AA cannot do any damage except by an improper PPI call or a resource violation. We claim that validation of the principal ID can be, and indeed should be, deferred until one of these events occurs. However, an EE should support a PPI call that has no effect except to force validation of any non-validated credential(s) for the current AA. It could also turn off future lazy evaluation for this AA. The AA can use this to avoid processing questionable data and protect its own operation against subversion by bogus active packets. Some PPI calls will require privilege only for particular values of the PPI arguments. When no privilege is required, security overhead should be avoided. This means applying lazy validation of the principal ID and the lazy evaluation of the policy predicate in each PPI call.,lp 3.2. Principal ID Presentation One or more additional parameters must be added to each PPI call, to pass principal IDs. The complexity of the underlying policy model determines whether one or more than one principal ID must be allowed in each PPI call. A problem is how much information to propagate back to the calling AA when a request is disallowed. AAs certainly need the information that, for example, a credential has been revoked. On the other hand, if an AA is trying to forge credentials, the less information fed back, the better. This is a topic for interface

7 -7- design Establishing AA Identity In order to determine privileges from the identity of an AA, an EE must be able to securely verify the AA s identity, i.e., verify that the AA code matches the AA ID. While this is relatively simple when all AAs are loaded at most once from local code on the node, many EEs support loading code from remote code servers. In the limit, each packet contains the entire code of the AA for which it is intended; such packets are called capsules. Each EE has its own way of specifying the AA code to load. However,the AA name executable code mapping must be one-to-one and secure. Some possible difficulties to consider include systems that load different parts of the AA from different locations (e.g., some Java classes from one place and some from another), AAs that dynamically load code after they hav e been started, and AAs that are loaded from userspecified locations. Combinations of code signing and trusted code sources can be used to insure that AA names map correctly to executable code. The exact mechanisms used are EE-dependent, as are the names. The techniques used by current EEs are: The ASP EE requires all code to be loaded from a known set of secure repositories and authenticated as being from those repositories. The specific valid repositories are part of the AA name (called the AASpec) and AAs requesting code from insecure servers are simply denied. It would be reasonable to require all code to be signed by a trusted party as well, but this check has not yet been implemented. ANTS is capsule-based, so the code is loaded directly from the packet. It uses a hash of a digital signature of the code as the AA ID. The code must be correctly signed by a principal with the permission to run code at the node to which the capsule arrives. An EE may prevent some AAs, e.g., those arriving in capsules, from having per-aa privileges in the permission list. Such AAs could bypass AA code validation. The AA identity must also be determined on each PPI call so that it can be used to determine the privileges of the requester. Exactly how this is carried out depends on the EE. Some options include stack tracing to determine what code called the PPI, authenticated RPC calls if the AAs are in different processes or choose to communicate that way, or something like a Mach port if the OS supports that. ABone EEs are largely Java-based, so stack tracing will probably be the most common. Current ABone EEs accomplish this by: ASP identifies AA instances through an EE process mechanism. Any thread created for an AA is associated with the controlling AA instance through a data structure tied to the thread by the Java Virtual Machine and inaccessible to the AA threads themselves. The result is an efficient mechanism to tie threads, and therefore PPI requests, to AAs. ANTS associates an AA with the capsule carrying it. Because ANTS is capsule-based, it is conceptually simpler to tie the thread started for a given packet to the AA started for that packet. Because the thread terminates when the processing of the current packet is done, longterm AA thread mapping is not required. 4. Implementation Plan And Open Issues Based on the foregoing considerations, the ABOCC chose the following plausible path towards progress in active network security for the ABone at a meeting at ISI early in Deconstruct the prototype SANTS code and extract the central cryptographic and authentication parts. Omit the Keynote-specific parts of the policy specification mechanism, leaving a general interface to the policy mechanism. Package the resulting code to form an active networks/abone security library. Incorporate this library code into each of the EEs, using their individual packet format conventions and policy mechanisms.

8 -8- This sounds straightforward, but in practice the object-oriented nature of the SANTS code made deconstruction very difficult. An alternative strategy now under consideration is to adopt ANSA-based mechanisms from the AMP nodeos. There are a number of open issues. Encoding end-to-end security information in packets Successive SANTS versions have adopted two different formats of ANEP header options for this purpose[8]. We could allow an EE-specific ANEP header format, or we could adopt a common format, either the latest ANSA format or some other format. Should it contain information about a single contiguous block of invariant data in the packet, e.g., something like starting offset and length, or do we need a more general ability to specify a collection of discontiguous invariant fragments? A standard permission list file format Extending the permission list to control resource usage by AAs. Determine hop-by-hop security encoding. Key distribution for hop-by-hop security. A public key infrastructure (PKI) for end-to-end security. Under the ANSA, certificates are kept in a central repository, and active packets carry only references (URLs) for them. SANTS uses secure DNS (DNSSEC) as this certificate repository. This is one option for the ABone. Another would be to develop an ABone-specific certificate distribution mechanism based upon the existing ABone public key mechanism that controls who can load EEs. 5. Conclusions This document has described an a ABone security architecture that is based upon the ANSA but operates at the EE rather than the nodeos level. This document has mostly been concerned with the end-to-end security mechanism, which provides policy enforcement to limit AA actions, based upon authenticated principal IDs and AA identities. It includes a simplified policy mechanism and supports both transient and persistant AAs. Other elements of the architecture not specified here include a hop-by-hop integrity mechanism, node configuration standards, and ABone mechanisms for remote management that allow only trusted EEs to be loaded into ABone nodes. References 1. Steven Berson, Bob Braden, and Livio Ricciulli, Introduction To The ABone (June 15, 2000), URL: 2. David Wetherall, Developing Protocols With The ANTS Toolkit, Design Review (August 1997), URL: 3. David J. Wetherall, John Guttag, and David Tennenhouse, ANTS: A Toolkit for Building and Dynamically Deploying Network Protocols, Proceedings of IEEE OPENARCH 98, San Francisco, CA (April 1998), URL: 4. David J. Wetherall, Service Introduction In An Active Network, Ph.D Thesis, Massachusetts Institute of Technology (February 1999), URL: 5. Bob Braden, Alberto Cerpa, Ted Faber, Bob Lindell, Graham Phillips, Jeff Kann, and Viv ek Shenoy, Introduction to the ASP Execution Environment (v1.3.2) (March 20, 2001), URL: 6. K. L. Calvert, ed., Architectural Framework For Active Networks, no. 1 (July 27, 1999), URL: 7. AN Security Working Group, Security Architecture For Active Nets (May ), URL: calvert/seclatest.ps. 8. NAI Labs ANETS Group, SANTS Security Overview (May 18, 2000), URL: ftp://ftp.tislabs.com/pub/activenets/santssecurityoverview.doc.

9 -9-9. Bob Lindell, Protocol Specification Specification for Hop-By-Hop Message Authentication and Integrity (December 1999), URL: Frank Herbert, Dune, Chilton Book Company (1965).