Secure Active Network Prototypes Sandra Murphy TIS Labs at Network Associates March 16,1999

Secure Active Network Prototypes Goal Produce a sequence of secure prototypes designed for ever increasingly complex environments; provide for dynamic policies and policy distribution Guide / participate in determination of Active Network security architecture

Work Completed First prototype: Enterprise Networks –Environment: enterprise LAN, single administrative control, common knowledge of identities and keys –Completed July 1998 Security Architecture –First version completed June 1998 Connection to ABONE active

Prototype Features Source authentication and integrity protection Hop-by-hop authentication and integrity protection Authorization of access to Node services based on source

Prototype Components Extension of ANTS, MIT’s Active Network environment Ported to JDK 1.2 beta3/beta4 (from JDK 1.0.2) Used JDK 1.2 cryptographic interface –DSA only authentication algorithms available Used JDK 1.2 security architecture –protection domains, permission objects, policy files, stack introspection

Prototype Design Source signature over unvarying packet contents Variant packet contents –initial value included in packet –used in signature and verification Hop-by-hop signature of inter-node communications –prevents outsider attacks

Prototype Design Node policy relates permissions to key id in packet Incoming active applications are given reference to “wrapper” object instead of reference to Node API Wrapper object intercepts calls to Node services and checks policy Source of request is checked as well as parameters of the service

Current Work - Completed Porting to JDK v2 (release of JDK 1.2) Incorporation of JCE cryptography Investigation of mechanisms for dynamic policy change

Current Work - In Progress Common AN credential / packet format –credentials will carry security attributes –packet might carry crypto related to packet sender, code author, prior node, modifying node, etc. Preparation for Team #6 demo –implementation of ANTS version of PLAN application exhibiting interesting security requirements

Current Work - In Progress Policy representation –Keynote and Keynote Engine strong possibilities Redesign of class hierarchy of ANTS for extensibility (e.g., signatures) and provision for shareable resources

Work To Come Extension of protection to active code services and resources –adopt same “wrapper” paradigm, if possible to create code on the fly Credential retrieval Policy distribution Backward compatibility with unauthenticated packets

Security Assumptions: Node NodeOS provides API to EE NodeOS establishes channels/flows, assigns resources to channels/flows and controls usage NodeOS starts EE’s as a channel Any channel/flow can start subchannels/flows with a portion of their resources

Security Assumptions: EE’s Multiple EE’s in a Node –small number –installed, replaced, terminated dynamically –changes to an EE and the number of EE’s are infrequent EE’s can share services and resources –NodeOS API must provide for inter-EE calls, creation of shared state, provision for EE policy governance of inter-EE calls and sharing

Security Assumptions: EE’s EE’s provide their API to the code in active packets EE’s have services and resources to protect Active packet’s code (Active code) runs *inside* EE –I.e., active code is not NodeOS level object using EE library

Security Assumptions: Active Packet/Code Active codes share services and resources –EE must provide for inter-active code calls, creation of shared state, provision for active code policy governance over calls and sharing Active code can change EE state (and therefore Node state), including leaving itself behind for other active code to use Packet can be modified by Node, EE or Active Code

Security Enforcement EE can create a separate subflow for active code EE relates a principal with subflow EE informs NodeOS of principal behind each NodeOS API call –otherwise, call is mediated and charged to EE principal EE’s are trusted to accurately inform the NodeOS of the principal

Policies Node, EE, and Active Code and Packet Source all have policies governing their use: –Node: e.g., packets from the following source may use no more than K units of bandwidth –EE: code from the following author can install itself here –Active Code: active code from the following source may use my data –Packet Source: payload confidentiality must be protected

Policies Existing policies are safety properties Liveness properties not possible to ensure –rely on fairness assumptions –rely on design Ergo, cannot ensure that requested service will be supplied Termination turned into safety property

Network Operation Packet arrives and is assigned to channel Active Code is executed in the channel Channel may transmit one or several subsequent packets Output packets have no necessary relationship to incoming packets Active Code, EE or Node may determine route of outgoing packets