1. Protocols for Secure Interactions in Distributed Collaboration Systems Masters Plan B Presentation 26 th November 2002 Richa Kumar Advisor: Dr. Anand Tripathi Computer 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. Collaboration Specification Analysis and Verification Tools 1. Consistency of coordination constraints 2. Security vs. ownership conflicts Derivation of Policy Templates 1. Object access control 2. Event subscription and notification 3. Role management policies 4. Meta-policies: ownership, policy updates Middleware 2. Runtime creation of activity specific policy objects from policy templates 3. Integration of policy objects with generic managers Background: Building a Collaboration Environment from High-level Specifications 1. Generic managers and secure interaction protocols

5. Background:Basic Entities in a collaboration ExamPaper Examiner Grader Student GradeSheet AnswerBook users roles objects Activity

6. Background: Role-Based Model Roles –A role defines a set of operations executed by a participant –Role operations represent a participant’s 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 Role Definitions Generic Role Managers Policy Modules Activity Definitions Generic Activity Managers Policy Modules Object Definitions Generic Object Managers Policy Modules Middleware Components Collaboration Specification with Application Level Objects Middleware Services Name ServicePublic Key ServiceActivity Management User Coordination Interface

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 owner’s 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 To event dispatcher Event Notification op1.start3, u1=1, u2 = 2 op1.start > 2op1.start(invoker = thisUser) = 0 Primitive Event Count Information Event Generators EVENT MANAGER TABLE INCOMING EVENT TABLE Event Source Handler Ticketing OPERATION TABLE OpName Precondition Action Event SubscriptionRole Manager/Adapter Object

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 InterfaceAdapter Interface m1()m1(ticket) m2(int)m2(int, ticket) M3(String)m3(String, ticket)

14. Interaction Among Basic Entities User Role 1 2 1 2 4 3 12 43 5 1 2 3 4 Object

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 entity’s name and public key

18. Basic Authentication Protocol Client CServer S {C, N c } {[C,N c ] Sign(S), S, N s } server S authenticated client C req(parameters, Ticket c ) authenticated Ticket c = [C, [S, N s ] Sign(C ) ] Basic Challenge Response protocol used in Ajanta: N s ++

19. Role Operation Invocation Protocol User URole Manager R InvokeOperation(opName, Ticket op ) Ticket u = [[R, u_context] Sign(U), u_context] Ticket op = [[R, N r ] Sign(U), Ticket u ] 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, Ticket m ) Ticket u = ticket provided by user U Ticket m = [[R, [O, N o, method, parameters] Sign(R) ], Ticket ro ] Ticket ro = [[O, Ticket u ] Sign(R), Ticket 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. Ticket ro is used by the object manager to establish a session with the user

21. User-Object Interaction User U Object Manager O [interfaceRef, Ticket ou ] Ticket ou = [[O, [U, Ticket u, N ou, sessionId] Sign(O) ], N ou, sessionId, Ticket ro ] Ticket ro = ticket provided by R to O to initiate a session Ticket u = ticket provided by U to R (included in Ticket ro ) 1. User verifies that the user ticket is still valid (one time use only) 3. Basic ticket verified for authentication (one-time user ticket acts as a nonce) 2. Object manager’s identity is extracted from Ticket ro

22. User-Object Interaction User U Object Manager O Ticket s = [[U, [O, N ou, s_context] Sign(u) ],s_context] s_context = [U, UCI, sessionId, method, parameters] method(parameters, Ticket s ) 1. Extended basic ticket verified for user authentication 3. Operation context obtained from session table 2. Integrity of session context is verified 4. Operation-to-method mapping verified

23. Data Structures for Session Mgmt. User Role Manager Object Manager Object UCI User Coordination Interface Object Manager op ticket User Ticketing Object Ticketing Object Interface Access Control Session Table ticket id Op-methods mapping UT

24. Preventing Attacks Impersonation –Man in the middle Prevented by including destination entity’s 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