Protocols for Secure Interactions in Distributed Collaboration Systems

1
Protocols for Secure Interactions in Distributed
Collaboration Systems

• Masters Plan B Presentation26th November 2002
  Richa KumarAdvisor Dr. Anand
  TripathiComputer and Information Science
• University of Minnesota

2
Outline

• Background
• Collaborative Systems
• Construction of collaborative systems from high
  level specifications
• Role-based model for collaboration
• Interaction between collaboration entities
• Middleware components and generic managers
• Runtime security requirements
• Security protocols
• Conclusions

3
Collaboration Systems

• CSCW (Computer Supported Cooperative Work)
  Systems
• Workflow Structured asynchronous interactions,
  e.g. medicare systems, office automation systems
• Groupware Less structured synchronous
  interactions, e.g. whiteboard
• Characteristics of CSCW systems
• Group of users, shared objects, common objectives
• Important Issues
• Coordination
• SECURITY

4
Background Building a Collaboration Environment
from High-level Specifications
Collaboration Specification
Derivation of Policy Templates
1. Object access control
2. Event subscription and notification
3. Role management policies
Analysis and Verification Tools
4. Meta-policies ownership, policy updates
1. Consistency of coordination constraints
2. Security vs. ownership conflicts
Middleware
1. Generic managers and secure interaction
protocols
2. Runtime creation of activity specific policy
objects from policy templates
3. Integration of policy objects with generic
managers
5
BackgroundBasic Entities in a collaboration

Activity
users
roles
objects
GradeSheet
Examiner
ExamPaper
Grader
AnswerBook
Student
6
Background Role-Based Model

• Roles
• A role defines a set of operations executed by a
  participant
• Role operations represent a participants tasks
  and privileges to perform actions on shared
  objects
• Operations
• Preconditions to coordinate users actions
• Actions method invocations, synchronization
  actions
• Operation related events start, finish
• Role admission Constraints
• Meta roles Owner

7
Background Role-Based Model

• Activities
• Protection domain for roles, objects and
  privileges
• Hierarchical nesting of activities
• Activity template defines a reusable pattern for
  collaboration
• Objects
• Managed on servers trusted by their owners
• Objects may enforce both role-based as well as
  user-id based access control
• Role-based access control is derived from role
  operation definitions
• Dynamic access control facilitated by operation
  preconditions

8
Collaboration Components
User Coordination Interface
User Coordination Interface
User Coordination Interface
Collaboration Specification with Application
Level Objects
Activity Definitions
Role Definitions
Object Definitions
Policy Modules
Policy Modules
Policy Modules
Generic Role Managers
Generic Activity Managers
Generic Object Managers
Middleware Components
Name Service
Public Key Service
Activity Management
Middleware Services
9
Distributed Middleware

• Participants may be from different administrative
  domains
• No single node may be trusted by all participants
• Not all participants are equally trusted for
  enforcing collaboration policies
• Owner role for an entity defines which
  participants can be trusted for managing the
  entity
• Manager is maintained on owners trusted site
• Managers within the same activity may be
  distributed

10
Generic Manager Functionality

• Evaluation of conditions
• Role admission constraints, operation
  preconditions, activity termination conditions
• Conditions are based on
• Event counts related to role operations
• Conditions are represented as tree structures
• Leaf nodes event counts
• Internal nodes operators and, or, -
• Nodes updated using two strategies
• Push model Event notifications
• Pull model Context based evaluation

11
Generic Manager Functionality

• Peer-peer event service
• Event Generators
• Generation of primitive event counts and event
  predicates based on operation start and finish
• Based on subscription policy
• Event Handlers
• Updating condition trees on incoming events
• Based on notification policy
• Ticketing Module
• Creation and verification of tickets used in
  interaction protocols
• Data structures for maintaining context
  information

12
Generic Manager Design
Event Notification
Event Subscription
Role Manager/Adapter Object
Ticketing
OPERATION TABLE
INCOMING EVENT TABLE
Handler
OpName
Precondition
Action
Event
Source
EVENT MANAGER TABLE
Primitive Event
Count Information
Event Generators
op1.start
3, u11, u2 2
op1.start gt 2
op1.start(invoker thisUser) 0
To event dispatcher
13
Object Manager

• An object manager is constructed for each object
  in the collaboration system
• Extends the generic object manager
• Adapts the interface of the object to include
  ticketing for authentication and session
  management
• Object Interface Adapter Interface
• m1() m1(ticket)
• m2(int) m2(int, ticket)
• M3(String) m3(String, ticket)

14
Interaction Among Basic Entities
User
Role
Object
1
2
1
2
3
4
1
2
4
3
5
2
1
3
4
15
Runtime Security Requirements

• User authentication during role admission and
  operation invocation
• Facilitate enforcement of role admission policies
  and preconditions
• Integrity of operation context
• Authorization for invoking object methods
• Role context of the user must be established and
  verified
• Object methods are invoked by the role manager on
  behalf of the user -- role manager needs to be
  authenticated
• User based access control may need to be
  performed
• User may need to provide the role manager with
  authorization to invoke object methods on its
  behalf
• Object manager may not trust role manager
• Prevent role manager from forging requests on
  behalf of user

16
Runtime Security Requirements(2)

• User-Object Interaction
• Role manager initiates the user-object session
• Preconditions verified only once at the time of
  session initialization
• Subsequent requests verified for valid session
  information
• Session management
• Authentication of user
• Integrity of method name, parameters and session
  id
• Prevent replay (possibly by same user at a later
  time)
• Not dealing with confidentiality
• User needs to authenticate the object manager,
  which sends the object interface
• User may not know a priori which object manager
  will be involved as part of the role operation
  due to the notion of role operation abstraction
• Event notifications must be authenticated

17
Name and Certificate Service

• Secure Name Service
• Component of Ajanta a java based mobile agent
  programming framework
• Every entity in the collaboration has a unique
  name given by the name service
• URN Uniform Resource Name (RFC 2141)
• Associated with each entity is a public-private
  key pair for authentication
• Name service also issues X509 Certificates for
  providing a secure binding between the entitys
  name and public key

18
Basic Authentication Protocol
Basic Challenge Response protocol used in Ajanta
Client C
Server S
19
Role Operation Invocation Protocol
User U
Role Manager R
InvokeOperation(opName, Ticketop)
Ticketop R, NrSign(U) , Ticketu
Ticketu R, u_contextSign(U), u_context
u_context U, UCI, opName, TS
1. Role Manager verifies basic ticket for user
authentication
2. Verifies user ticket for integrity of
operation context
3. Checks operation preconditions
20
Role-Object Interaction Protocol
Role Manager R
Object Manager O
objRef.method(parameters, Ticketm)
Ticketm R, O, No, method, parameters
Sign(R), Ticketro
Ticketro O, TicketuSign(R), Ticketu
Ticketu ticket provided by user U
1. Object manager verifies extended basic ticket
for role authentication
2. Operation preconditions are checked for
enforcing dynamic access control

3. User Ticket verified for user authorization
and user based access control
4. Ticketro is used by the object manager to
establish a session with the user
21
User-Object Interaction
User U
Object Manager O
interfaceRef, Ticketou
Ticketou O, U, Ticketu, Nou , sessionId
Sign(O), Nou, sessionId, Ticketro
Ticketu ticket provided by U to R (included in
Ticketro )
Ticketro ticket provided by R to O to initiate
a session
1. User verifies that the user ticket is still
valid (one time use only)
2. Object managers identity is extracted from
Ticketro

3. Basic ticket verified for authentication
(one-time user ticket acts as a nonce)
22
User-Object Interaction
User U
Object Manager O
method(parameters, Tickets)
Tickets U, O, Nou, s_contextSign(u)
,s_context
s_context U, UCI, sessionId, method,
parameters
1. Extended basic ticket verified for user
authentication
2. Integrity of session context is verified

3. Operation context obtained from session table
4. Operation-to-method mapping verified
23
Data Structures for Session Mgmt.
Role Manager
UCI
User
Object
Object Manager
Session Table
Object Interface
Op-methods mapping
op
ticket
id
ticket
Access Control
User Ticketing
Object Ticketing
Object Manager
User Coordination Interface
24
Preventing Attacks

• Impersonation
• Man in the middle
• Prevented by including destination entitys
  identity in each ticket (Due to Gavin Lowe, 1995)
• Replay attack
• Tickets include nonces where both parties can
  communicate to establish the initial challenge
• Time stamps used where nonces cannot be
  pre-established
• Assumption of securely synchronized clocks
• Tampering of request parameters
• Request parameters are signed

25
Preventing Attacks (2)

• Role manager forging user requests
• By requiring that the role manager present to the
  object manager a signed authorization from the
  user, this can be prevented.
• If role operation preconditions are not
  satisfied, the role manager may use the
  authorization at a later time. Time stamps are
  used to prevent this.
• Authenticating the object manager
• Authenticating the correct object manager
• Identity certified by the role manager
• User gets back the initial delegation given to
  role manager
• Role operation was really initiated by the user
• User tickets valid only for one time use
• Object manager signs a known piece of information
  for authentication. Also provides signature on
  sessionId for integrity. Time-stamp included for
  freshness.

26
Preventing Attacks (3)

• Session Termination
• Session is invalidated after the
  session-terminating method is invoked for a
  given object interface preventing a user from
  using a stale session id for circumventing
  dynamic access control
• Session timeout

27
Conclusions and Future Work

• Generic Middleware components and their
  interactions
• Security protocols
• Authentication
• Access control
• Integrity of request parameters
• Future Work
• Meet requirements of confidentiality and
  pseudonyms
• Analysis of security protocols

28
The End.
29
Literature on Designing Protocols

• Prudent Engineering Practice for Cryptographic
  Protocols
• Martin Abadi and Roger Needham, 1995
• Hidden Assumptions in Cryptographic Protocols
• C. Boyd, 1990
• An Attack on the Needham-Schroeder Public-key
  Authentication Protocol
• Gavin Lowe