1 / 39

Antigone: Security Policy Management in Group Communication

Antigone: Security Policy Management in Group Communication. Patrick McDaniel EECS, University of Michigan April 30, 2001. Outline. Problem Statement Ismene Group Policy Management Antigone Communication Infrastructure Implementation and Applications. Headquarters. Telecommuters.

davina
Download Presentation

Antigone: Security Policy Management in Group Communication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Antigone: Security Policy Management in Group Communication Patrick McDaniel EECS, University of Michigan April 30, 2001

  2. Outline • Problem Statement • Ismene Group Policy Management • Antigone Communication Infrastructure • Implementation and Applications

  3. Headquarters Telecommuters Scenario 1 Consultants Confidentiality Integrity Authenticity Authorization Customers

  4. Scenario 2 Confidentiality Integrity Authenticity Authorization Commitment Satellite Offices Contract Negotiation Arbitrator Legal Representatives

  5. Problem • How do we develop and enforce a group session security policy appropriate for the run-time environment and membership within a single framework? • Session requirements may be unique • Each entity may have unique abilities and constraints • The structure and needs of the group may change dramatically over time

  6. (Our) definition of session policy • “... a statement of the entirety of security relevant parameters and facilities used to implement the group.” • who are the entities allowed to participate and in what capacity (authorization and access control) • which mechanisms will be used to achieve mission critical goals (provisioning) • Note: historically not restricted to electronically distributed

  7. Related Work • Policy Management • IPsec SPS, Policy Working Group • Group/Coalition Policy Management • MSME, GSAKMP, DCCM, SMuG/MSEC • Authorization and Access Control • GAA-API, Extended ACLs, and many more • Trust management • REFEREE, PolicyMaker, KeyNote, SPKI/SDSI, Strongman

  8. Contributions • Investigation of Policy Group • Policy Design Space • Policy Determination (Ismene) • Policy Enforcement (Antigone)

  9. Goals • Policy Determination • Flexibly express conditional session requirements • Support reconciliation of member policies • Allow assessment of session policy with local requirements • Efficiently derive/evaluate policy • Policy Enforcement • Provide efficient, secure (unreliable) group communication • Support a wide range of security services/policies • Easily integrate new services/policies

  10. The Antigone/Ismene Approach

  11. Outline • Problem Statement • Ismene Group Policy Management • Antigone Communication Infrastructure • Implementation and Applications

  12. Secure Group Policy Dimensions • Session rekeying policy • How and when to rekey? • Data Security policy • Content guarantees • Membership policy • Distribution/accuracy of membership • Process failure policy • Failures detected/recovered from? • Authorization and Access Control

  13. Example Policy : Confidentiality • Confidentiality Policy : All code reviews using the distributed editor must be confidential. session: GroupType(codeReview), Application(DistEdit) :: config(datahandler(guar=conf)); • Policy states the requirements appropriate for application, data sensitivity, membership, and other aspects of the environment

  14. Example Policy: Group Participation • Group Participation Policy: Only members of the legal department can participate in contract negotiations. join : GroupType(contractNegotiation), credential( &cert, $cert.issuer=$CA, $cert.type="X.509", $cert.ORG=“LegalDept" ) :: accept; • Any number of possible services may be used for stating authorization and access control

  15. An Antigone Group

  16. Ismene Policy Description Language (IPDL) • Clause : (policy) tag: (if) conditionals :: (then) consequences • Tags identify sub-policies that must be satisfied, • Conditionals test the environment (predicate) • Consequences apply policy • E.g., “All Contract negotiations must use a leave-sensitive LKH key management service. Other sessions should use KEK key management.” groupprot: GroupType(contractNegotiation) :: config(lkhkeymgmt(sens=leave)); groupprot: :: config(kekkeymgmt());

  17. Consequences • Describes results of positive evaluation of conditionals • Tags • Configuration config(lkhkeymgmt()); config(lkhkeymgmt(keytime=10secs)); • Pick Statements pick(config(lkhkeymgmt(keytime=10secs)), config(kekkeymgmt(keytime=5secs)) );

  18. Provisioning Policy Evaluation provision : :: keymgt, dhandler, fprot; keymgt : GroupType(contractNegotiation) :: config(lkhkeymgt()); keymgt : :: config(kekkeymgt()); dhandler : GroupType(contractNegotiation) :: config(dhnd(crypt=aes)); dhandler : :: pick(config(dhnd(crypt=des), config(dhnd(crypt=rc4))); fprot: :: config(chainfp()), fpparms; fpparms: groupsize(>100) :: config(chainfp(hbperiod=5)); fpparms: config(chainfp(hbperiod=3));

  19. Authorization and Access Control • Credentials are modeled sets of attributes • E.g., X.509 Certificates consist of attributes for subject/common name, … • Credential conditions test the existence of credentials with specific attributes • Authorization and Access Control Clauses join : day(Monday), config(kekkeymgt()), credential(&tick,$tick.service=contractconference, $tick.server=bigco.com) :: accept; • IPDL represents a closed world

  20. Integrating External Authorization and Access Control • Current approach designed to express simple authorization and access control • Some applications may require more sophistication • Using external policy infrastructure (e.g. KeyNote) join : KeyNote($requestor, $attrset, $grppol, $creds) :: accept;

  21. Policy Reconciliation • The group and each local policy is evaluated (result: config, pick, Auth+A-Cntl statements) • Example: kekkeymgt(), chainfp(hbperiod=5), pick(config(dhnd(crypt=des), config(dhnd(crypt=rc4))) • Reconciliation: Given evaluated group and local policies, how do we arrive at single configuration?

  22. Provisioning Reconciliation Strategies • Option 1: Prioritized local policies, implemented • Option 2: Finding largest satisfiable subgroup • (NP-complete) Reduction:MAX2SAT Group policy a, b, pick(c,d), pick(e,f) Local policy A d, pick(e,f) Local policy B d, pick(e,g) Policy Instantiation a,b,d,e

  23. Authorization and Access Control Reconciliation Strategies • How do we reconcile the authorization and access control statements to arrive at a definition satisfying all local policies • OR (if any policy would accept) • AND (if all policies accept) Group policy join : C1 :: accept; join : C2 :: accept; Local policy A join : C3 :: accept; Local policy B join : C4 :: accept; Policy Instantiation join : ((C1 or C2) and c3 and c4) :: accept;

  24. Compliance • Is the session policy instantiation in consistent with my local policy? • Provisioning compliance (containment), • Simple search – P-time • Authorization and Access Control • For all actions/conditions, is the group policy more specific (less permissive) than local policy • Closely related problem of secure interoperatibility is NP [Gong and Qian, 1994] Note: reconciled policies are trivially compliant

  25. Ismene Summary • IPDL is a language for expressing group policy • Provisioning and access control flexibly specified • Policies sensitive to changing conditions • Algorithm Efficiency • Other features • Analysis, reconfig, …

  26. Outline • Problem Statement • Ismene Group Policy Management • Antigone Communication Infrastructure • Implementation and Applications

  27. Antigone • Group communication framework implementing policy though the the flexible composition of security mechanisms • Composition directed by the security policy specification • Study of the requirements and enforcement of group policy

  28. Antigone • Policy Enforcement Architecture • Given a group policy, coordinates the provisioning and enforcement of available services • Mechanism • … is a basic service used to implement the group • E.g., Data-handler (MSEC, GSAKMP, …) • Event-based architecture • Security relevant events are detected and distributed to interested mechanisms • Policy directs reaction to observed events

  29. Antigone Architecture

  30. Send? sent sent SE SE buf buf Yes SE SE SE SE SE buf buf buf sent SE buf buf hdr encr hmac buf Policy Enforcement SE SE SE SE

  31. Features/Optimizations • Message construction/marshalling • Implementing the many mechanism protocol variants difficult (e.g., AH, ESP, MESP, …) • Generalized message handling • Internal buffer handling • Messages are frequently created/destroyed • Internal heap of often used/resized buffer objects • Minimization of byte copying, key context switching

  32. Throughput and Latency Latency Throughput

  33. Antigone Overhead • Constant overhead (50usec /message)

  34. Antigone Summary • Framework for enforcing group policy • Supports a wide range of security services • Event based architecture • Easy integration of new services and policies • Efficient implementation • Low per packet overhead (50usec) • High throughput

  35. Outline • Problem Statement • Ismene Group Policy Management • Antigone Communication Infrastructure • Implementation and Applications

  36. Implementation Status • Antigone • API – six libraries, implementing various security, group management, and transport level services • Language grammar, apcc compiler • 30,000 lines of C++ code • Supports a wide range of secure group communication mechanisms (e.g., OpenSSL) • Currently alpha • Experimenting/optimizing/developing • Freely available http://antigone.eecs.umich.edu

  37. Applications • AMirD – secure filesystem replication • Filesystem state updated over secure “control group” • Simultaneous groups distribute files implementing policies appropriate for their content • Secure Group Messaging Service • Group based secure instant messaging (I.e., ICQ, MS-M) • Native Antigone - “Bump-in-the stack” • Secure existing applications

  38. Conclusions • Ismene : language and infrastructure for flexible and efficient policy determination • Flexible conditional statements of provisioning and authorization and access control • Efficient reconciliation and analysis (and compliance) • Antigone : framework for the flexible and efficient enforcement of group security policy • Unreliable group communication service • Easy integration of new services and policies • Low latency, high throughput group communication • Applications illustrate the Antigone policy approach

  39. Contact Information • Comments, questions are welcomed pdmcdan@eecs.umich.edu • Antigone/Ismene Website http://antigone.eecs.umich.edu/

More Related