January 12, 2001

Dynamic Coalitions PI Meeting

Agile Management of

Dynamic Collaboration

John Mitchell Patrick LincolnStanford University SRI International

David Dill, Li Gong, Mary BakerNinghui Li

January 12, 2001

Slide 2

Project Organization

Contract• Start date:

5/4/2000• Duration: 48 months (12 mo optn)

Agent POCSteve SpendloveSPAWAR

Personnel• Stanford

– John Mitchell (PI)– Mary Baker, David Dill (Faculty)– Ninghui Li (Researcher)– Graduate Students

• SRI– Patrick Lincoln (co-PI)– Research scientists

• Consultant– Li Gong (Sun/JavaSoft)

January 12, 2001

Slide 3

Goal

Trust and security for dynamic coalitions• Coalitions via peer-to-peer service concept

– Sites may offer to provide services– Clients search for services– Service may be established using mobile code

• Secure adaptive (wireless) networking– Key management, discovery, search and delivery

for secure peer-to-peer communication

• Decentralized authentication and trust decisions

– Policy language and compliance checkerService-oriented infrastructure based on secure

communication protocols, decentralized trust management, and secure mobile code

January 12, 2001

Slide 4

Background

Jini• Dynamic service search

and configuration• Based on Java, RMI• Limited Java security

Peer-to-peer• Napster: centralized• Gnutella, Freenet:

decentralized• Inefficient n2 coalition

update• No security

Trust management• Emerging approach for

distributed infrastructure• Based on keys, policies,

inference engine• No off-the-shelf

implementation Protocols

• Secure multicast, P2P: rests on key management

• Decentralized routing flawed (e.g., AODV, BGP)

• Security, reliability require careful design and analysis

January 12, 2001

Slide 5

Progress Summary

Jini architecture• Code filter• Architecture design• Implementation of

some parts in progress

Peer-to-peer• Evaluate current

systems– coalition discovery

and search problems– network simulation

Trust management• Comparison with other

access control mechanisms• Identify role-based TM• Implementing inference

engine

Protocols (ad hoc wireless routing)

• Improve DSR reliability – watchdog, pathrater

• Discover looping in AODV– model checking, abstraction

New Personnel:Ninghui Li, Trust ManagementMary Baker, Wireless Networking

Collaboration: Drew Dean, Xerox

Collaboration: Jon Millen, SRI

January 12, 2001

Slide 6Jini-Based Service Architecture

Three phases for dynamic service installation• Request lookup server; receive lookup proxy code• Specify service via lookup proxy; receive service proxy

code• Access service via downloaded service proxy

Service

LookupService

Group

Client serviceproxy

lookupproxy

Mobile code

Problem: Standard Java-based Jini has limited security guarantees

Approach: Develop protocols, trust mechanism, mobile code security

Solutions useful for Jini and for other dynamic coalition platforms

January 12, 2001

Slide 7

Mobile Code Security

Asdfasdg./assdfgsdfggfsdfg s

gfdsdfg sdfg sdfgdsdfgf

Asdfasdg./assdfgsdfggfsdfg s

gfdsdfg sdfg sdfgdsdfgf

Code transmitted and executed• E.g., transparent dynamic installation of user

interface, communication protocol, device driver, Jini service proxy

Problem: Untrusted code executed inside mission-

critical system Approach: Dynamic code analysis, code monitoring, and

load-time code modification to insert checks and controls

January 12, 2001

Slide 8

Dynamic peer-service goals

Manage client risks• Authenticate or establish trust in service (solution:TM)

• Contain mobile code risks (solution: code filter)

Manage service risks• Authenticate or establish trust in client (solution:

TM)

Dynamic trust (solution:Trust Management)

• Service has no prior knowledge of client• Client has no prior knowledge of service• Establish trust through signed statements by

transitively known principals

January 12, 2001

Slide 9

Illustrative scenarios

Disneyland• Wireless device for

– Electronic cash– Data communication– Attraction UI

• Functions– Store, communicate secure data– Find trusted friends and family– Control local devices

Mobile reconnaissance team• Ad hoc wireless networking• Secure group communication• Client obtains real-time data

and control features from service

January 12, 2001

Slide 10

Jini Architecture

Lookup Service

TrustMgmt

Client Service

Client trusts service

Lookup Service

TrustMgmt

Client Service

Service trusts client

Lookup Service

Client

Client filters mobile code

Filter

•Lookup server stores credentials

•Client, server consult TM•Client runs bytecode filter•Trust management is a

service

January 12, 2001

Slide 11Client authentication of service

Lookup Service

ServiceClient

TM Engine

(1) discovery

(3) register(Sp, ID, attr[])

attr[]

ID#Sp

attr[]

ID#

Sp

(1) discovery

(2) query(attr[])

(3) serviceItem[]

serviceItem

(4) query(key, trust credentials)

(5) Trust proof or yes/no

Extract key/authinfo from attr[]

Database and cache;Fetches credentials

Constructs auth proof

credentials

PKI / Trust CA(not a peer)

(2) ServiceRegis (w/ ID)

More details

January 12, 2001

Slide 12

Peer-to-peer systems

Several recent systems in use• Napster, Gnutella, Freenet, Casino 2000, …• Move toward decentralized peer-to-peer services

Basic functions• Maintain decentralized network of active peers• Search active peers for document, other resource

Problems• Gnutella uses DFS, Freenet uses BFS, both wasteful• How to maintain network of active peers efficiently• How to query active peers and forward responses• How to evaluate, analyze, simulate system

January 12, 2001

Slide 13

Peer-to-peer effort

Study existing systems• Install, test, analyze Gnutella, Freenet, …• Build ns (network sim) test environment (in

progress)

Design improved protocols (in progress)

• Efficient discovery and query • Consider applications

– Public key infrastructure – Nameserver for Baker’s MobilePeople architecture

• Close analogy to ad hoc wireless routing

January 12, 2001

Slide 14

Trust Management

Problem: Authentication and trust• Service may not be what client wanted• Client may not be authorized for service

Solution: Trust management• Decentralized security management based on

authorities granted to a cryptographic key• Distributed policy determined by service policies and

delegation (ability to transfer partial authority)

ComplianceChecker

Request

Policies

Credentials

Yes/No

Proof

January 12, 2001

Slide 15

Trust management progress

Study revocation• Feigenbaum and Li

Comparison with other mechanisms• Chander, Dean, Mitchell

Begin development of Role-based trust mgmt• Increase expressiveness, appropriate for trust

based on role of individual in organization

Begin study of distributed implementation • Current experimental implementations require

centralized deduction (Prolog theorem prover)

January 12, 2001

Slide 16Role-Based Trust Management

Background• Traditional role-based access control lacks

– distributed roles, distributed credentials, role-delegation

• Existing trust management lacks: – explicit support for roles, the ability to use partial rights

Approach• Principals named by Entities and Roles

– e.g., companyA’s employee

• Permissions: assigned to roles by distributed policy

• Role-delegation • Request with a role

January 12, 2001

Slide 17

Work in progress on RBTM

Identify concepts for dynamic coalitions• role-delegation• role-formula

Develop logic-based language for concepts

Implement a RBTM engine that• manages roles and credentials for entities• does distributed certificate discovery

Integrate RBTM engine into Jini framework

January 12, 2001

Slide 18Why isn’t SPKI/SDSI the answer?

Problems with delegation and names• Delegation from SPKI, local names from SDSI• Need better integration to be useful

SPKI/SDSI lacks some desirable features• intersections of names• parameterized names K_hospital's physician(alice)

Some issues not addressed by SPKI/SDSI• Distributed certificate discovery

– find a certificate chain in a set of credentials

• Privacy issues, deliver minimal certificates, etc.

Need better implementation of superset of subset of SPKI/SDSI

January 12, 2001

Slide 19

Protocols

Reliability• Routing protocols assume nodes follow protocol• Investigate problems caused by misbehavior• One solution: improve throughput by monitoring

Correctness• Model checking

– Exhaustively check all states of a system – Works only for finite-state model

• Predicate abstraction – Use automatic theorem proving for arbitrary size system– Reduce unbounded system to finite-state approximation

January 12, 2001

Slide 20

Background: Ad hoc routing

Mobile wireless network• composed of limited range wireless devices• no dedicated routers

Several routing protocols proposed• Dynamic Source Routing (DSR)

– On-demand source routing, maintains route cache

• Ad hoc, On-demand, Distance Vector routing (AODV)

– Not source routing; node only knows what’s next

S D

January 12, 2001

Slide 21

Node Misbehavior

Node agrees to forward other nodes’ packets but instead drops the packets

Reasons for node misbehavior:• Malicious nodes mounting denial of service

attacks• Selfish nodes conserving resources• Overloaded nodes• Broken software

January 12, 2001

Slide 22

Solutions

Watchdog and Path Rater mitigate the effects of node misbehavior

Assumptions• Bi-directional links• Promiscuous mode

Philosophy: avoid adding more complexity to the routing protocol

January 12, 2001

Slide 23

Watchdog

Forwarding node verifies next node passes on packet

Watchdog notifies source of possible node misbehavior

A listens to B forwarding to C

S DA B C

January 12, 2001

Slide 24

Path Rater

Rate nodes based on reliability (as reported by watchdog)

• Node rating initially neutral • Misbehaving node gets strongly negative rating

Increment rates of nodes on active paths• Decrement rating of nodes on paths if link-break

occur

Pick path with highest average rating Fallback: route discovery

• If all known paths contain misbehaving nodes, run Path Rater Route Request (PRRR)

S DA B C

January 12, 2001

Slide 25

Throughput

17% improvement at 40% misbehaving (low mobility) 27% improvement at 40% misbehaving (high mobility)

High Mobility

0%

5%

10

%

15

%

20

%

25

%

30

%

35

%

40

%

Low Mobility

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0%

5%

10

%

15

%

20

%

25

%

30

%

35

%

40

%

Fraction of misbehaving nodes

Th

rou

gh

pu

t (%

p

ackets

receiv

ed

)

Everything on PRRR disabled Path rater only Baseline DSR

January 12, 2001

Slide 26

High Mobility

0%

5%

10

%

15

%

20

%

25

%

30

%

35

%

40

%

Fraction of Misbehaving Nodes

Low Mobility

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0%

5%

10

%

15

%

20

%

25

%

30

%

35

%

40

%

Ove

rhea

d r

atio

Everything on PRRR disabled Watchdog only Baseline DSR

Overhead Results

January 12, 2001

Slide 27

Protocol correctness

Protocols are notoriously difficult to design Goal: make formal verification techniques

applicable to important network protocols Approach:

• Model checking systematically generate states of a system for fixed numbers of nodes

– Mature; works only for finite-state models.

• Predicate abstraction uses automatic theorem proving to verify for any number of nodes.

– New: works for descriptions with unbounded states.

January 12, 2001

Slide 28

Predicate abstraction

Reduce verification of large or infinite-state systems to standard finite-state model checking

Predicateabstractor

Protocol description

Properties tocheck

SimplePredicates(e.g. x > 0)

Abstract FSM

FSMchecker

January 12, 2001

Slide 29

Predicate Abstraction Details

Prototype checker exists • Combines several different libraries• SVC: “Stanford Validity Checker” (automatic theorem

prover)

• BDD-based model checking– uses Boolean functions to represent FSMs and their states

Performance increased 10-fold in last 2 months• Successive approximation based on

counterexamples.

Used on AODV and cryptographic protocols

January 12, 2001

Slide 30

AODV

“Ad hoc, On-demand, Distance Vector routing”• Automatically assemble networks of mobile nodes

Routes are required to be loop-free• Routes may fail if loops exist

Route loops found using Mur model checker• During timeout of routes

– previously discovered by Broch and Maltz of CMU

• During processing of RERR messages – previously unknown; newly introduced in AODV version 4

AODV is broken. Can we fix it?

January 12, 2001

Slide 31

AODV Modification

Changed protocol to eliminate (?) loops• Mur verification with 4 nodes found no problems

Found bugs in “fixed” protocol• Use predicate abstraction to study larger networks• Problem results from arbitrary message delays• Example requires 5 nodes (too big for Mur !)

Goal• Complete repair of AODV protocol• Verify version 5 of AODV using predicate abstraction

January 12, 2001

Slide 32

Progress Summary

Jini architecture• Code filter• Architecture design• Implementation of

some parts in progress

Peer-to-peer• Evaluate current

systems– coalition discovery

and search problems– network simulation

Trust management• Comparison with other

access control mechanisms• Identify role-based TM• Implementing inference

engine

Protocols (ad hoc wireless

routing)

• Improve DSR reliability – watchdog, pathrater

• Discover looping in AODV– Formal tools find new bugs

January 12, 2001

Slide 33

Deliverables

Upcoming Year 1 report deliverables• Trust-management approach to policy

analysis and negotiation for dynamic coalitions,

• A Jini-based system for dynamic discovery, query, and selection of services and community members

• Architecture for trust management used negotiations for dynamic coalitions,

• Mobile-code security mechanisms in Jini environment