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