Edward Tsai – CS 239 – Spring 2003 Strong Security for Active Networks CS 239 – Network Security Edward Tsai Tuesday, May 13, 2003.
Published byModified over 5 years ago
Presentation on theme: "Edward Tsai – CS 239 – Spring 2003 Strong Security for Active Networks CS 239 – Network Security Edward Tsai Tuesday, May 13, 2003."— Presentation transcript:
Edward Tsai – CS 239 – Spring 2003 Strong Security for Active Networks CS 239 – Network Security Edward Tsai Tuesday, May 13, 2003
Edward Tsai – CS 239 – Spring 2003 Agenda Active Networks Overview AN Security Requirements Architecture Security Components Authorization Authentication Security Processing Problems / Future Work
Edward Tsai – CS 239 – Spring 2003 Active Networks Overview Active Networks are comprised of “nodes” that transmit “active packets” which can “active code” that can be executed to manipulate packets that traverse through the node. An execution can be a modification of the state of the node, a modification of the packet, or the transmission of one or more packets.
Edward Tsai – CS 239 – Spring 2003 Active Networks Client Server Routers / Nodes User Code
Edward Tsai – CS 239 – Spring 2003 Within an Active Network Node Active Network Nodes include NodeOS – operating system of which the interface document describes the resource abstractions of memory pools (memory), thread pools (computation), channels (communication), files (persistent storage), and domains. Execution Environments – provides a programming interface or VM that can be programmed or controlled by the active packets. Domains – primary abstraction for resource management and are allocated a set of channels, a memory pool, and a thread pool.
Edward Tsai – CS 239 – Spring 2003 Active Network Security Requirements End User Viewpoint – data protection (exposure, access, unauthorized use or modification), untrusted EEs, policy enforcement Node Viewpoint – mistrust of EEs – resource usage, policy adherance EE Viewpoint – malicious active code, bad peer EEs (shared persistent state or services) Active Code Viewpoint – malicious peer active code (state and services). Hopes EEs enforce policies. Protection Techniques 1.Language (type-safe and namespace limiting) 2.Authorization (principal agents and policies)
Edward Tsai – CS 239 – Spring 2003 Architecture Naming – globally unique credentials that represent aggregate security attributes Packet Format – identification of packet portions that are authenticated and those that are not, credential list, hop-hop integrity Policy Language – ubiquitous language describing authorization policy for node, EE, or user. Security Support System – cryptographic engine (JCE), credential system (DNSSEC), key management system (Java Keystore), policy mangaement system (storage, retrieve, revoke, etc.) Enforcement Architecture – non- forgeable security context (protection domain), security bindings to execution (class loader), enforcement engine (AccessController), policy evaluation engine (Keynote)
Edward Tsai – CS 239 – Spring 2003 Security Components X.509v3 certificates – verification of principal identities and attributes (groups, etc.). DNSSEC - storage of the credentials Java Crypto API and Java Cryptographic Extensions – cryptographical operations Keynote policy system – ubiquitous policy language and enforcer for NodeOS and EE to enforce operating restrictions given through the Active packets. Java 2 Security Architecture – class loading / operational security EE and Node class separation - BulletinBoard – Used to share data between nodes, such as “best path” information
Edward Tsai – CS 239 – Spring 2003 Authentication Hop to hop / neighbor node protection using HMAC – Secure Hash Algorithm (SHA-1) End to end protection using multiple X.509 identifiers for each packet, for each attribute. When a packet arrives, its credential references are extracted, the multiple X.509v3 certs are retrieved from DNSSEC and their signatures verified (again, remember this is *per packet*).
Edward Tsai – CS 239 – Spring 2003 Authorization Classes have granted permissions. Protected objects have required permissions. Access Controller checks to see that each class has a sufficient permission, specified in its protection domain. Object execution permission checking is done through ClassLoader / Java 2 security architecture. Active code won’t be able to circumvent protections by calling classes that have greater permissions than itself. End user’s policies travel through the network through active code. Multiple policy handling (local, national, corporate) where EE policy supersedes more lenient policies.
Edward Tsai – CS 239 – Spring 2003 Security Processing – NodeOS Receive packet Verify hop-hop integrity Assign packet to existing domain Extract credential list Check credential authenticity according to authentication policy for the domain Check credentials against access control policy for domain Deliver entire packet to the domain
Edward Tsai – CS 239 – Spring 2003 Security Processing - EEs Receive a packet including credentials Create a subdomain, providing the security content parameters for the domain and the access control and authentication policies for the domain Modify the access control policy of a domain, the authentication policy of a domain or the security context of a domain Add or remove cryptographic protections to user data
Edward Tsai – CS 239 – Spring 2003 Problems / Future Work 1.High overhead for certificate retrieval for each packet, for each credential listed. 2.Lack of Detail on various implementation issues such as how Keynote policies are created and what type of policies are used. 3.Lack of Performance Measurements 4.Lack of Scalability Analysis 5.“woulds” and “shoulds” in Security Architecture portion – many features not mature.