July 26, 2001Dynamic Coalitions PI Meeting Agile Management of Dynamic Collaboration John Mitchell Patrick Lincoln Stanford University SRI International.
Post on 22-Dec-2015
214 Views
Preview:
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 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 “jane@IdentiScape.nom”
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 (mgb@ucb.edu, 1992) ?? Response: mgb@stanford.edu
mgb@stanford.edu1994
mgb@ucb.edu1990 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)
top related