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, MITs 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 EEs as a channel Any channel/flow can start subchannels/flows with a portion of their resources

Security Assumptions: EEs

Multiple EEs in a Node
small number installed, replaced, terminated dynamically changes to an EE and the number of EEs are infrequent

EEs 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: EEs

EEs provide their API to the code in active packets EEs have services and resources to protect Active packets 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

EEs 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