Correcting a Delegation Protocol for Grids

1. Correcting a Delegation Protocol for Grids Dr Benjamin Aziz School of Computing University of Portsmouth Presentation in the 8th International Conference on Trust, Privacy & Security in Digital Business (TrustBus'11), Toulouse, France, 02 September 2011

2. Objectives • Study the delegation properties within the context of a recent delegation protocol, DToken, designed for a large-scale distributed operating system • Gain some appreciation of the subtlety of vulnerabilities that can be hidden in even the simplest protocols and propose fixes for those vulnerabilities

3. Content • Overview of the current DToken protocol • Round-up of vulnerabilities in the current protocol • DToken II: A more secure version • Conclusion and future work

4. Delegation Protocols • Generally, delegation means some degree of trust that a user (delegator) holds on some entity (delegatee) in carrying out some task on behalf of the user • In computing systems, delegation is often established by means of some delegation protocol, which involves exchanges of; • digital certificates • cryptographic tokens carrying various delegation information

5. Desirable Properties of Delegation Protocols • Correctness of delegation mechanism • Delegated permissions are handed in the intended manner • Traceability • Unique identity • Accountability • Verifiable traceability by means of cryptography • Non-repudiation • Two-way accountability • Deterministic delegation chains • A chain must be possible to construct unambiguously • Performance • Scalability w.r.t. long of chains of delegation

6. Grid Systems Sharing of large-scale computational resources among organisations in a virtual collaboration Org1 Org3 Grid Infrastructure ... Org n Org2 Ian Foster’s Anatomy of the Grid: http://www.globus.org/alliance/publications/papers/anatomy.pdf

7. Grid Computing – User Perspective Resource 1 (Org1) Delegation Step = Protocol Delegation Step = Protocol Resource 2 (Org2) User Trusted Machine Gateway Delegation Enforcement Point

8. Essentials of the DToken Protocol • Appeared in 2009, designed in the framework of the XtreemOS Operating System (www.xtreemos.eu) • Based on the idea that each delegation step introduces a token (DToken), which: • is signed by both sides of the delegation step • contains information on the delegated permissions • can be used to form a chain of trust from the delegator to the delegatee • Contains other relevant information (e.g. token validity, delegation session identification)

9. The DToken Protocol Message 1. Message 2. = DToken Gateway (Delegatee) User (Delegator) User’s Signature Delegated Permissions Session Identifier Gateway’s Signature

10. DToken Integrity • The integrity of a DToken implies that the following two facts can be correctly validated • The consent of the delegator to the delegation step • The consent of the delegatee to the delegation step

11. Traceability and Accountability • Traceability and accountability are achieved in the DToken protocol by means of the verifiablenon-repudiation property • No delegated permission is used unless it is signed by both sides of the delegation

12. Deterministic Delegation Chains • Given a set of DTokens, this property states that we should be able to infer the exact delegation chain behind these token 2 4 1 2 3 4 1 3

13. Design-time Mistakes • A few vulnerabilities where introduced at design time • Non-matching Hash Validation • Delegation Repudiation • Non-deterministic Delegation Chains • Highlighted in a formal analysis by Aziz and Hamilton • B. Aziz and G. Hamilton, Verifying a Delegation Protocol for Grid Systems. In Future Generation Computing, vol. 27(5), pp. 476-485, 2011.

14. Non-matching Hash Validation • Mismatching of hash values due to different values of the session identifier DS in the two messages of the protocol From Property 1 first hash validation, we arrive at the inequality: hash(CDor,CDee,Vfr,Vto,TS,PDor→Dee,DSDor→Dee)  hash(CDor,CDee,Vfr,Vto,TS,PDor→Dee,DSDor→Dee0) Novice design error

15. Delegation Repudiation • Delegatee receives permission prematurely, thus is able to repudiate the delegation • The delegatee can use a received permission without signing the permission 1st message of a protocol session U to G 2nd, 3rd messages, different protocol G to itself

16. Delegation Repudiation • One argument for this style of delegation (i.e. premature permissions passing) is that: Delegation enforcement points will ensure authorization policies are maintained at the point of access to a resource • But, this implies that the robustness of the protocol is dependant on external entities (policies)

17. Non-deterministic Delegation Chains • The current protocol assumes that it is possible to construct chains from DTokens: • If A delegates to B, and B delegates to C, then C gets two tokens: one for “A->B” and one for “B->C” • Hence, it is possible for C to infer the chain “A->B->C” • Now, consider the following case: A delegates to B (A->B), B delegates to C (B->C), C delegates to A (C->A), A delegates to C (A->C) and C delegates to D (C->D)

18. Non-deterministic Delegation Chains • D will obtain the following set of tokens: {A->B, B->C, C->A, A->C, C->D} • But from these tokens, D can construct the following “different” chain: A delegates to C (A->C) C delegates back to A (C->A) A delegates to B (A->B) B delegates to C (B->C) C delegates to D (C->D) Original chain A delegates to B (A->B) B delegates to C (B->C) C delegates to A (C->A) A delegates to C (A->C) C delegates to D (C->D)

19. Non-deterministic Delegation Chains • The essence of the vulnerability is that it breaks chains of trust • Crucial in some areas such as digital forensics and handling of delegated evidence • The vulnerability appears as a result of: • Lack of relationship across the different tokens • richer structure underlying the sets (sets convey little information regarding ordering or multiplicity) • Designers assumed that two-step delegations will correctly scale up to any n-step delegations • Not the case, due to loops!

20. DToken II: An Improved Version Request for delegation Delegatee signs (session id + request) before receiving the permissions Session identifier is the same in both messages Tokens are passed as lists rather than sets = Multiplicity and ordering preserved

21. Future Work • Carry out a formal verification of DToken II • Test a model of DToken II within a Grid simulation environment • Implementation DToken II into a real Grid system

22. Conclusion • Designing of even the simplest protocols can be tricky • Some verification is always necessary when feasible • Vulnerabilities presented in this paperreflected • Novice design mistakes • Invalid assumptions regarding external context and policies • Invalid assumption on the scalability of certain properties, e.g. determinism of delegation chains from 2 to n participants

23. Correcting a Delegation Protocol for Grids Dr Benjamin Aziz School of Computing University of Portsmouth Presentation in the 8th International Conference on Trust, Privacy & Security in Digital Business (TrustBus'11)