+ All Categories
Home > Documents > July 26, 2001Dynamic Coalitions PI Meeting Agile Management of Dynamic Collaboration John Mitchell...

July 26, 2001Dynamic Coalitions PI Meeting Agile Management of Dynamic Collaboration John Mitchell...

Date post: 22-Dec-2015
Category:
View: 214 times
Download: 0 times
Share this document with a friend
Popular Tags:
39
July 26, 2001 Dynamic Coalitions PI Meeting Agile Management of Dynamic Collaboration John Mitchell Patrick Lincoln Stanford University SRI International David Dill, Li Gong, Mary Baker Ninghui Li
Transcript

July 26, 2001

Dynamic Coalitions PI Meeting

Agile Management of

Dynamic Collaboration

John Mitchell Patrick LincolnStanford University SRI International

David Dill, Li Gong, Mary BakerNinghui Li

July 26, 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)– Drew Dean– Vitaly Shmatikov

• Consultant– Li Gong (Sun/JavaSoft)

New additions!

July 26, 2001

Slide 3

Goal Trust and security for dynamic coalitions

• Decentralized authentication and trust decisions– Dynamic policy determined by coalition member

policies– Policy language, deduction engine, examples

• Secure adaptive networking– Key management, discovery, search and delivery for

secure peer-to-peer communication; wireless

• Coalition peer-to-peer services– Sites may offer to provide services– Clients search for services– Some services may be established using mobile code

Service-oriented infrastructure based on secure communication protocols, decentralized trust

management

July 26, 2001

Slide 4

Background

Trust management• Emerging approach for

distributed infrastructure

• Based on keys, policies, inference engine

• No standard off-the-shelf implementation

Jini• Dynamic service search

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

Protocols• Secure multicast, P2P

require key management

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

• Security, reliability require careful design and analysis

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

decentralized• Inefficient n2 search• No security

July 26, 2001

Slide 5Progress Summary (since 1/01)

Trust management• Role-based TM

language• Inference engine, impl• Comparison with other

access formalism

Jini architecture• Secure architecture • Code filter

Protocols• Discover errors …• Predicate abstraction

– Verify AODV, contract sign without finite bounds

• Decidable protocol case

Peer-to-peer• Evaluate systems

– coalition discovery, search– network simulation

• Mobile People System– Map names to device addr– Track addr changes over

time

Collaboration: Drew Dean (Xerox), Jon Millen (SRI), Will Winsborough (NAI)

July 26, 2001

Slide 6

Talk Outline

Year 1 Accomplishments• Report deliverables and publications

Trust Management• Role-based policy language, demo systems

Protocol analysis• Methods and applications

Distributed services• Decentralized name server, distributed

timestamps

July 26, 2001

Slide 7

Report Deliverables

Technical report sections documenting• 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 in a highly dynamic environment

• Mobile-code security mechanisms adapted to a Jini environment.

July 26, 2001

Slide 8Sample Publications (Year 1)

• Trust Management– A state-transition model of trust management and

access control, CSFW 2001.– Nonmonotonicity, User Interfaces, and Risk Assessment

in Certificate Revocation, FC 2001.

• Mobile code security– Mobile code security by Java bytecode instrumentation,

DISCEX II 2001.

• Protocol analysis– Successive Approximation of Abstract Transition

Relations, LICS 2001.

• Coalition services and peer-to-peer systems– Mitigating Routing Misbehavior in Mobile Ad Hoc

Networks, Mobicom 2000.– Building Trusted Distributed Services Across

Administrative Domains (unpublished).

July 26, 2001

Slide 9

Remainder of presentation

Trust management• Example• Outline of RBTM language• Demo summary

Protocol analysis• Predicate abstraction• Sample application

Distributed services• Decentralized name server, distributed

timestamps

July 26, 2001

Slide 10

Distributed Policy Example

Coalition Member A• Staff Baugh, Giaccia• Give A.General. BattleDamageAssessor read access to SatelliteImagery(HiRes)

Coalition Member B• General Hanson• Coalition_files(A) General.Coalition_files(A)• Give A.Staffread access to Coalition_files(A)

Hanson• BattleDamageAssessor Jones• Assistant …• Coalition_files(A) Plan.ppt, map.jpg• Coalition_files(A) Assistant.Coalition_files(A)

July 26, 2001

Slide 11

Credential Chains

Conference Registration

Regular $1000Academic $500Student $100

Root CA

Stanford

Mitchell

Chander

Stanford is accred university

Mitchell is regular faculty

Chander is my student

Registration message

Root signs: Stanford is accred universityStanford signs: Mitchell is regular faculty Faculty can ident studentsMitchell signs: Chander is my student

Certification

Faculty can ident students

July 26, 2001

Slide 12

Hierarchical naming (SDSI)

Names, keys, and namespaces• A name denotes a principal or group

– Each principal has one or more keys

• Each principal may define own names– Write A.B for A’s definition of B

Specification of groups• A.B C A’s group B contains C

• A.B C.D A’s group B contains C’s group D

• A.B C.D.E A’s group B contains d.E,

for every d C.D

July 26, 2001

Slide 13

“Trivial” extension to roles

Name, key, namespace• A name denotes a set of principals (Role)• Principal may define own names roles

– Write A.B for A’s name role B

Simplified logic of roles• A.B C A’s role B contains C

• A.B C.D A’s role B contains C’s role D

• A.B C.D.E A’s role B contains d.E,

for every d C.D

July 26, 2001

Slide 14

Example

Friends and Family• Alice. Friend Bob• Alice. Friend Carol• Bob. Friend Ted• Bob. Friend Alice• Alice. Friend Alice. Friend. Friend

Role defined by this policy• Alice. Friend = {Bob, Carol, Ted, Alice}

July 26, 2001

Slide 15Graph algorithm [Li, Winsb…, M]

Build graph based on policy• Keep table for local name at local site • Propagate keys along links• Digitally sign credentials when leaving local site

AliceFrien

dBob

Carol

BobFrien

dTed

Alice

Alice. Friend Bob.Friend

July 26, 2001

Slide 16

Enhanced Policy Language RT1

Relations between entities• Manager(x), Physician(y), FileOwner(z)

Permissions over resource groups• Read(reconnaissance_maps)

Threshold structures• Allow access if two guards grant access

Quantification over entities (subtle)

• Read(?f) Supervisor(Owner(?f)) Supervisor can read subordinate’s file

Intermediate language: reducible to Datalog, poly-time

July 26, 2001

Slide 17Calendar Demo (Thursday PM)

July 26, 2001

Slide 18

Calendar Policy

Concepts• Time categories

– Time slot identified by hour of day and day of week– Time slots grouped into overlapping categories

• Activity categories– Same names as time categories

• Read permission– Principal or group given read permission for category– Only read appt for activity category, regardless of time

• Write permission– Principal or group given priority for a category– Appointment with highest priority takes precedence

July 26, 2001

Slide 19

Part of Tony Soprano’s policy

Tony.Crew Chris Moltisanti, Paulie Walnuts Tony.Boss Jackie AprileTony.Wife Carmela Tony.Children Anthony Jr. , MeadowTony.Family_Members Tony.Mother, Tony.Wife, Tony.Children

Tony.Read(Work) Tony.BossTony.Read(Family) Tony.Wife

Tony.Schedule(Work,Important) Tony.CrewTony.Schedule(Work,Most important) Tony.BossTony.Schedule(Family,Very important) Tony.Family_MembersTony.Schedule(Family,Most important) Tony.WifeTony.Schedule(Personal,Very important) Tony.Wife

Roles

Read

Write

July 26, 2001

Slide 20Future Demo (under construction)

Web-based storage and file sharing• Users can upload, download files• User policy determines file access

Policy concepts• Locker owner determines upload

capabilities, download policy• File owner can determine read, write• Extensions: version control, application

support

passwd

July 26, 2001

Slide 21

Site design

Key generation on browserRegistration, server signatureInstall browser certificate

Client

cert?

SSL with client authentication

https

Create spaceVisit spaceModify policy

Enter name for shared space

Upload filesDownload files

Policy Manager

July 26, 2001

Slide 22

Remainder of presentation

Trust management• Example• Outline of RBTM language• Demo summary

Protocol analysis• Predicate abstraction• Sample application

Distributed services• Decentralized name server, distributed

timestamps

July 26, 2001

Slide 23Formal Verification Techniques

Model checking has had a real impact on system design• Explicit-state protocol verifiers (Spin, Murphi)• BDD-based symbolic model checking for hardware design (SMV,

VIS, FormalCheck, Rulebase, etc.)• Advantage: Automation reduces user effort to a feasible level• Limitation: Models must be finite-state.

Interactive theorem proving• Systems: ACL2, HOL, Isabelle, PVS, STeP• Practical impact on floating point algorithms (Intel & AMD)• Advantage: generality. E.g., can verify systems with

unbounded state spaces, or families of systems.• Limitation: Labor-intensive.

July 26, 2001

Slide 24The Wedge of Formal Verification

Valueto Design

Effort Invested

Verify

RefuteAbstract

Invisible FM

Need a dial to tune up or down accuracy of analysis

July 26, 2001

Slide 25

Conservative abstraction

Concrete system Abstract system

AbstractionFunction

If abstract system satisfies safety property, so does concrete system

Goal: use abstraction to reduce infinite system to finite state

July 26, 2001

Slide 26

Abstraction with refinement

ApproximatePredicateAbstractor

Predicates12N

ConcreteTransitionSystem

ModelChecker

AbstractTransitionSystem

(finite-state)

OK

Counter-exampleTrace

(refine)

July 26, 2001

Slide 27Abuse-free contract signing protocol

Protocol proposed by Garay, Jakobsson and MacKenzie, CRYPTO ’99.

Protocol has two participants (signers) and a trusted third party who mediates in case of disputes

Protocol is supposed to guarantee fairness• Fairness means that a honest participant can not be

cheated (“fairness” is a safety property!)• Shmatikov & Mitchell (1999) discovered a flaw where

unfairness could result, using finite-state model checking• We checked corrected protocol using predicate abstract

for arbitrary numbers of simultaneous contract signings• The revised protocol was proved fair

July 26, 2001

Slide 28

Remainder of presentation

Trust management• Example• Outline of RBTM language• Demo summary

Protocol analysis• Predicate abstraction• Sample application

Distributed services• Decentralized name server, distributed

timestamps

July 26, 2001

Slide 29Mobile people (example decentralized service)

People move between applications, devices, roles• Desktop, laptop, PDA, cell phone, pager, hotel phone

Why do they do this?• One device does not serve all purposes• Changes in job, organizations

Previous mobility work • “anywhere/anytime” connectivity to a single device

Our motivation• People are the true endpoints of much communication• Similar issues if “role” is intended endpoint

July 26, 2001

Slide 30

Decomposition of Problem

Mobile People Architecture • On what device do I reach a mobile person in a timely manner?

IdentiScape • How do I name mobile people as endpoints, rather than their

devices?

work emailhome emailwork phonepagerhome phone

cell phonework emailwork phoneICQhome phoneDan Jane

July 26, 2001

Slide 31

IdentiScape goals

Easily name people online Map name to

• Contact information for people– Could be personal proxy information for extra privacy

• Other stuff people want Reduce information management problems

• Name reuse issues• Name change issues• Name robustness issues

Service avoids individual update of individual address books

July 26, 2001

Slide 32

Naming problems

Name reuse• Defunct pizza parlor phone # reassigned to Jane• Jane gets lots of pizza orders

Name changes• Email from Jane’s lawyers goes to old address• Old address controlled by party she’s now suing

Name robustness• Your address/number is too similar to someone

else’s

July 26, 2001

Slide 33

IdentiScape solution

Naming service(s)• Allow callers to use one identifier to reach a

person• Provide robustness of names

Directory services (identity object services) • Enable people to control the contents and

accessibility of their own online identity information

Separation of naming and directory • Scalability• Trust

July 26, 2001

Slide 34

IdentiScape Architecture

Sender

IdentiScape service

Identity object

1

2

3

4

Query “[email protected]

Return: address of identity object

1

3

2

4

Query identity object

Return: contact information

•jane•dan•supervisor

Jane’s contact information

July 26, 2001

Slide 35

History service

Authenticated list of name transitions• Signed by name holder and name services• We assume a public key infrastructure

“Persistence” and control over old names• You’ll reach me with my old name if you run

it through history service• Nobody else can prove they used that name

at that time• Name space manager cannot retract

existence of old name

July 26, 2001

Slide 36Example use of history service

• 1990 - mgb gets a name from UCB• 1994 - mgb gets a name from Stanford• 1996 - Berkeley removes mgb name• 1994 - name change inserted• 1998 - another mgb gets a name from UCB• 2050 - Query: Current ([email protected], 1992) ?? Response: [email protected]

[email protected]

[email protected] 1996 1998

Implementation uses cryptographic timestamping method

July 26, 2001

Slide 37

Failure

• Does not make the problem go away• Provides insight used to solve problem eventually

Prefer the term “Challenge”

Disappointment Peak

Grand Teton

July 26, 2001

Slide 38Project Challenges (“Failures” as req)

Management• SRI team too small initially

Jini• Jini is not as successful “out there” as it could be• Jini protocols are over/under specified

Mobile Code Security• Code filter is good general tool• Have not produced convincing application of tool

Distributed policy management• Problem is P-complete: will design for “expected

case”

Failure = learn by trying

July 26, 2001

Slide 39

Progress Summary

Trust management• Role-based TM language• Inference engine, impl• Comparison with other

access formalism• Continue demos, design

distributed policy service

Jini architecture• Secure architecture • Code filter• Apply to calendar demo

Protocols• Discover errors …• Predicate abstraction

– Verify without finite bounds

• Decidable protocol case• Key mgmt, coalition security

Peer-to-peer• Evaluate systems

– coalition discovery, search– network simulation

• Mobile People• Decentralized coalition

services

Collaboration: Jonathan Smith (Penn), Jon Millen (SRI), Will Winsborough (NAI)


Recommended