1. Defeasible Security Policy Composition for Web Services Adam J. Lee, Jodie P. Boyer *, Lars E. Olson, and Carl A. Gunter University of Illinois at Urbana-Champaign 3rd November 2006

2. 2 Motivation Security policies –Tend to be large and difficult to understand –Do not always have a well-defined means of composition –May be governed by multiple organizations or entities Can we provide an intuitive way to specify and compose security policies? Approach: Defeasible security policy composition

3. 3 What is Defeasible Logic? A computationally efficient non-monotonic logic Why non-monotonic logic? –Allows for “jumping to conclusions” but later retracting conclusions if contradictory evidence comes to light –Models human reasoning

4. 4 Defeasible Theories Defeasible theories have three parts –Facts dog(Sam) –Three types of rules Strict rules: terrier(X) -> dog(X) Defeasible rules: dog(X) => bark(X) Defeater rules: sick(X) ~> ¬bark(X) –A superiority relationship Prioritizes rules to eliminate conflicts

5. 5 Example Superiority Relationship The logical theory: basenji(Jasmine) basenji(X) -> dog(X) r : dog(X) => bark(X) r’ : basenji(X) => ¬bark(X) r’ > r Note: What happens without r’ > r?

6. 6 Solution Overview Each entity specifies a defeasible logic “meta policy” Group of entities determine a precedence hierarchy Policies are merged using a composition function,  Resultant composed policy is converted into its XML representation using a projection function, 

7. 7 Graphical Composition Overview Entity 1 Local Resource  A meta policy A Resource Policy

8. 8 Graphical Composition Overview  

9. 9 What Does a Meta-Policy Look Like? A meta-policy, P, is a tuple P = (P reas, P req ) –The reasoning theory, P reas, is a theory in the defeasible logic –The requirements theory, P req, is a propositional logic theory Used as a “sanity check” after merging to ensure this entity’s requirements are met If the conclusions drawn during the merge can prove the statement SATISFIED in P req, the defining entity is, well, satisfied with the outcome

10. 10 Predicate Syntax Security Token –securitytoken(Type, Issuer, {Claims}) Integrity –integrity({Algorithms}, TokenInfo, {Claims}, {MessageParts}) Confidentiality –confidentiality({Algorithms}, KeyInfo, {MessageParts})

11. 11 Examples of Predicate Syntax securitytoken('x509','uiuc',C) Represents an X.509 certificate issued by UIUC with no restrictions on the claims. confidentiality({algorithm('encryption','r sa')}, securitytoken(T,'uiuc',C), {messageparts('xpath',S,'/body')}) Represents RSA encryption of the element using a security token issued by UIUC.

12. 12 Composition using  Define  recursively in terms of a two policy composition function  * Two cases for  *(p 1, p 2 ) –p 1 and p 2 unrelated by partial order –p 1 dominates p 2  * can be used iteratively to compose any collection of partially ordered meta-policies

13. 13 Projection Using  Derive C, the set of all conclusions that can be defeasibly proven from the composite reasoning theory For each C i  2 C that satisfies the requirements theories, add C i to the set of sets S Fail if S is empty, otherwise generate XML

14. 14 XML Generation Find I, the intersection of each s  S Insert the elements of I into an clause in the WS-SecurityPolicy Create an clause For each s  S, construct an clause containing each conclusion in the set (s \ I ) Add this clause as an item to the new clause

15. 15 Example 2 organizations want to deploy a joint web service Organization 1 –Wants X.509 to be used as the security token. –Allows a combination of tokens to replace X.509 when resources are constrained in mobile apps Organization 2 –Deploys mobile apps –Requires Confidentiality The organizations are unrelated in the partial ordering

16. 16 Example Policy (Part 1) Req: hassecuritytoken -> satisfied. securitytoken('x509','uiuc',C) -> hassecuritytoken. securitytoken('saml',I,C),securitytoken('unt',I,C) -> hassecuritytoken. Reas: R1: {} => securitytoken('x509','uiuc',C). R2: {} => securitytoken('saml',I,C). R3: {} => securitytoken('unt',I,C). R4: mobile ~> ~securitytoken('x509',I,C). R5: securitytoken('x509',I,C) ~> ~securitytoken('saml',I,C). R6: securitytoken('x509',I,C) ~> ~securitytoken('unt',I,C). R4 > R1. R5 > R2. R6 > R3.

17. 17 Example Policy (Part 2) Req: hassecuritytoken,hasconfidentiality -> satisfied. securitytoken('saml','uiuc/cs/dais',C) -> hassecuritytoken. confidentiality({algorithm('encryption','aes128cbc')}, securitytoken('unt',I,C)), {messageparts('xpath',S,'/body')}) -> hasconfidentiality. Reas: mobile. R1: {} => securitytoken('saml','uiuc/cs/dais',C). R2: {} => confidentiality({algorithm('encryption','aes128cbc')}, securitytoken(T,I,C), {messageparts('xpath',S,'/body')}).

18. 18 Merged Reasoning Theories R1_1: {} => securitytoken('x509','uiuc',C). R1_2: {} => securitytoken('saml',I,C). R1_3: {} => securitytoken('unt',I,C). R1_4: mobile ~> ~securitytoken('x509',I,C). R1_5: securitytoken('x509',I,C) ~> ~securitytoken('saml',I,C). R1_6: securitytoken('x509',I,C) ~> ~securitytoken('unt',I,C). R1_4 > R1_1. R1_5 > R1_2. R1_6 > R1_3. mobile. R2_1: {} => securitytoken('saml','uiuc/cs/dais',C). R2_2: {} => confidentiality({algorithm('encryption', 'aes128cbc')}, securitytoken(T,I,C), {messageparts('xpath',S,'/body')}).

19. 19 Set of Possible Conclusions securitytoken('saml','uiuc/cs/dais',C) securitytoken('unt',I,C) confidentiality({algorithm('encryption','aes128cbc' )}, securitytoken('unt',I,C), {messageparts('xpath',S,'/body')})

20. 20 Expected WS-Policy Output wsse:SAMLAssertion uiuc/cs/dais wsse:UsernameToken <wsse:Algorithm Type="wsse:AlgSignature" URI="...AES128_CBC"/> wsse:UsernameToken /Body

21. 21 Web Services and Beyond This policy composition method is not only useful for merging WS-SecurityPolicy documents Reliable messaging policies –WS-RM Policy specification –Investigating the interplay between security and reliable messaging policies would be an interesting area Firewall policies –Example: Multiple groups sharing lab space –Efficiency of defeasible logic makes temporal firewall rules possible

22. 22 Conclusion Presented a system to compose security policies –Preferences for composition are encoded in meta-policies –Single operation for composition Allow organizations to specify long term meta-policies –can be used for local resource policies –can be composed to determine the policy for a shared resource

23. Thank you for your attention. http://seclab.cs.uiuc.edu/ampol

24. 24 Example Policy (Part 1) Req: hassecuritytoken,hasintegrity -> satisfied. securitytoken('x509','uiuc',C) -> hassecuritytoken. securitytoken('saml',I,C),securitytoken('unt',I,C) -> hassecuritytoken. integrity({algorithm('signature','rsa'),algorithm('transform',' enveloped')}, securitytoken(T,'uiuc',C1), C2, {messageparts('xpath',S,'/')}) -> hasintegrity. integrity({algorithm('signature','hmac'),algorithm('transform', 'enveloped')}, securitytoken('unt',I,C1), C2, {messageparts('xpath',S,'/')}) -> hasintegrity. Reas: R1: {} => securitytoken('x509','uiuc',C). R2: {} => securitytoken('saml',I,C). R3: {} => securitytoken('unt',I,C). R4: mobile ~> ~securitytoken('x509',I,C). R5: securitytoken('x509',I,C) ~> ~securitytoken('saml',I,C). R6: securitytoken('x509',I,C) ~> ~securitytoken('unt',I,C). R4 > R1. R5 > R2. R6 > R3. R7: securitytoken('x509',I,C) => integrity({algorithm('signature','rsa'),algorithm('transform',' enveloped')}, securitytoken(T,I,C1), C2, M). R8: securitytoken('unt',I,C) => integrity({algorithm('signature','hmac'),algorithm('transform', 'enveloped')}, securitytoken('unt',I,C), C2, M). R9: integrity({algorithm('signature','rsa')}, securitytoken(T,'uiuc',C1), C2, M) ~> ~integrity({algorithm('signature','hmac')}, S, C3, M). R10: integrity({algorithm('signature','hmac')}, securitytoken('unt',I,C), C2, M) ~> ~integrity({algorithm('signature','rsa')}, S, C2, M).

25. 25 Example Policy (Part 1) Req: hassecuritytoken,hasintegrity -> satisfied. securitytoken('x509','uiuc',C) -> hassecuritytoken. securitytoken('saml',I,C),securitytoken('unt',I,C) -> hassecuritytoken. integrity({algorithm('signature','rsa'),algorithm('transform','enveloped' )}, securitytoken(T,'uiuc',C1), C2, {messageparts('xpath',S,'/')}) -> hasintegrity. integrity({algorithm('signature','hmac'),algorithm('transform','enveloped ')}, securitytoken('unt',I,C1), C2, {messageparts('xpath',S,'/')}) -> hasintegrity. Reas: R1: {} => securitytoken('x509','uiuc',C). R2: {} => securitytoken('saml',I,C). R3: {} => securitytoken('unt',I,C). R4: mobile ~> ~securitytoken('x509',I,C). R5: securitytoken('x509',I,C) ~> ~securitytoken('saml',I,C). R6: securitytoken('x509',I,C) ~> ~securitytoken('unt',I,C). R4 > R1. R5 > R2. R6 > R3. R7: securitytoken('x509',I,C) => integrity({algorithm('signature','rsa'),algorithm('transform','enveloped' )}, securitytoken(T,I,C1), C2, M). R8: securitytoken('unt',I,C) => integrity({algorithm('signature','hmac'),algorithm('transform','enveloped ')}, securitytoken('unt',I,C), C2, M). R9: integrity({algorithm('signature','rsa')}, securitytoken(T,'uiuc',C1), C2, M) ~> ~integrity({algorithm('signature','hmac')}, S, C3, M). R10: integrity({algorithm('signature','hmac')}, securitytoken('unt',I,C), C2, M) ~> ~integrity({algorithm('signature','rsa')}, S, C2, M).