1. Gothic : A Group Access Control Architecture for Secure Multicast and Anycast Paul Judge, Mostafa Ammar Georgia Institute of Technology Presenters: Dheeraj Thumma Boppanna Madhrira

2. Outline Communication Paradigms Communication Paradigms Security Issues Security Issues Security Objective Security Objective Proposed Design Proposed Design Evaluation Evaluation Conclusion Conclusion

3. Communication Paradigms Unicast Unicast Point-to-point flow of packets Multicast Multicast Point-to-multipoint flow of packets Anycast Anycast Point-to-point flow of packets

4. Unicast Point-to-point flow of packets between a source (client) and destination (server) host Server is identified by a unique IP unicast address contained in the header of each packet sent from the client Routers make a best-effort attempt to deliver the packet to the destination host identified by unicast address. Examples - Web-browsing, file transfer (FTP)

5. Unicast Receiver Sender Receiver

6. Multicast Point-to-multipoint flow of packets between a single source host and one or more destination hosts. Source host sends a single copy of the packet to group address (e.g. 227.12.33.2). Destination hosts configured with a multicast group address. Routers deliver the multicast packets to all destination hosts identified by the multicast group address. Example - Broadcast-style videoconferencing

7. Multicast Receiver Sender Receiver

8. Anycast Point-to-point flow of packets between a single client and the “nearest” destination server identified by an anycast address. Client sends packets to any one of several possible servers offering a particular service or application but does not really care which one. A single anycast address is assigned to one or more servers contained within an anycast group. Sends packets to an anycast server by placing the anycast address in the packet header. Routers attempt to deliver the packet to a server with the matching anycast address.

9. Anycast

10. Must maintain security of transmission, while allowing users to join or leave the multicast session Must maintain security of transmission, while allowing users to join or leave the multicast session New members into the session should not be able to decrypt earlier transmissions, nor should ex-members be able to decrypt later transmissions New members into the session should not be able to decrypt earlier transmissions, nor should ex-members be able to decrypt later transmissions We need a system of changing keys, while assuring ourselves that all legitimate members are able to transmit and receive to/from all other legitimate members We need a system of changing keys, while assuring ourselves that all legitimate members are able to transmit and receive to/from all other legitimate members Multicast Security

11. Vulnerabilities of Multicast Multicast suffers from increased vulnerability due to: Multicast suffers from increased vulnerability due to: Sessions are frequently advertised Sessions are frequently advertised Greater number of points of vulnerability Greater number of points of vulnerability Attack affects a broader base of people Attack affects a broader base of people Attacker can pose as a legitimate user easier (larger “crowd” of principals) Attacker can pose as a legitimate user easier (larger “crowd” of principals)

12. Anycast Security Similar issues as in multicast security and more! Unauthenticated server advertisements Anycast server authenticity Secure anycast communications Connection and SA migration – For fault-tolerance

13. What does ‘security’ need to provide? Authentication Authentication Verify the user is who he says he is Verify the user is who he says he is Authorization Authorization Only admit those with proper authorization into the group Only admit those with proper authorization into the group Integrity Integrity Group members maintain privacy from those not in the group Group members maintain privacy from those not in the group System must be scalable System must be scalable

14. Gothic Multicast group access control (MGAC) Multicast group access control (MGAC) Control ability of hosts join multicast group Control ability of hosts join multicast group Anycast server group access control (ASGAC) Anycast server group access control (ASGAC) Control the ability of a host to advertise itself Control the ability of a host to advertise itself for the anycast address for the anycast address MGAC + ASGAC = GAC = GOTHIC MGAC + ASGAC = GAC = GOTHIC

15. Design Goals Maintain Security Maintain Security  Scalable System  Low overhead on Routers  Low message overhead  Low support infrastructure requirements

16. Functions Group policy specification Group policy specification Specify group policy, authenticate host, verify group owner Specify group policy, authenticate host, verify group owner Group owner ? Group owner ? Access Request Access Request Notify wish to become member Notify wish to become member Access Control Access Control Receive request, authorize Receive request, authorize

17. Gothic Architecture Group Policy Management System (GPMS) = Specify group policy Group Policy Management System (GPMS) = Specify group policy Group Member Authorization System (GMAS) = Access request + Access control Group Member Authorization System (GMAS) = Access request + Access control

18. GPMS Group owner provides list of authorized members and the security policy to access control server (ACS) Group owner provides list of authorized members and the security policy to access control server (ACS) Problem – How to verify that host is a group owner? Problem – How to verify that host is a group owner? Solution – Group Owner determination and Authentication System (GODAS) Solution – Group Owner determination and Authentication System (GODAS)

19. GMAS Perform authorization before host is allowed to become member Perform authorization before host is allowed to become member Authorization protocol Authorization protocol Reauthorizations and Revocations Reauthorizations and Revocations

20. Authorization Protocol Host H, Router R, Access Control Server (ACS) Host H, Router R, Access Control Server (ACS) Assume H & ACS possess public key pairs or certificates Assume H & ACS possess public key pairs or certificates K +H, K +ACS  public keys K +H, K +ACS  public keys K -H, K -ACS  private keys K -H, K -ACS  private keys CERT K+X  certificate with public key K +x CERT K+X  certificate with public key K +x [message] K-X  digitally signed message [message] K-X  digitally signed message

21. Authorization Protocol 1. H  ACS : AR = [GID, CERT K + H ] K - H 1. H  ACS : AR = [GID, CERT K + H ] K - H 2. ACS  H : AA = CAP = [IP H, DN H, GID, T exp, CERT K + ACS ] K - ACS 2. ACS  H : AA = CAP = [IP H, DN H, GID, T exp, CERT K + ACS ] K - ACS 3. H  R : JR = CAP 3. H  R : JR = CAP 4. R  H : JA = Status 4. R  H : JA = Status

22. Reauthorizations and Revocations Protocol uses time-limited capabilities for revocation Protocol uses time-limited capabilities for revocation Members refresh their membership state Members refresh their membership state Problem – Refreshing state heavyweight Problem – Refreshing state heavyweight Solution – Extend lifetime of capabilities Solution – Extend lifetime of capabilities Drawback – Weakens Security Drawback – Weakens Security Tradeoff reauthorization overhead and security Tradeoff reauthorization overhead and security

23. Ideal – Small revocation window and low reauthorization overhead Ideal – Small revocation window and low reauthorization overhead Proposed Method Proposed Method Host uses the group key as the authenticator Host uses the group key as the authenticator Requires router to possess group key Requires router to possess group key Reauthorizations and Revocations

24. Group Policy Management System This system involves a group owner providing the list of authorized members and possibly other security policy for the group to the ACS. This system involves a group owner providing the list of authorized members and possibly other security policy for the group to the ACS. How the system verifies that a particular host is the group owner? How the system verifies that a particular host is the group owner? Two solutions are proposed that provide group owner determination and authentication. Two solutions are proposed that provide group owner determination and authentication.

25. Group owner certificates Similar to traditional digital certificates. The group owner certificate can be issued by a local certificate authority (CA).

26. Group ownership service This service is a query/reply protocol based service. It accepts queries specifying a particular group address and responds with the identity of the host that owns the group.

27. Group owner determination and authentication in multicast environments Multicast Address Allocation Architecture (MAAA). Multicast Address Allocation Architecture (MAAA). Source-Specific Multicast (SSM). Source-Specific Multicast (SSM). GLOP GLOP Session Announcement Protocol (SAP)/Session Description Protocol (SDP). Session Announcement Protocol (SAP)/Session Description Protocol (SDP).

28. Group owner determination and authentication in anycast environments IP Anycast. IP Anycast. Global IP Anycast. Global IP Anycast. Application-Layer Anycast. Application-Layer Anycast.

29. Group Access Control Aware GKM How the existence of a group access control system changes the requirements of Group key management (GKM)?. How the existence of a group access control system changes the requirements of Group key management (GKM)?. How Gothic integrates with the multicast routing system?. How Gothic integrates with the multicast routing system?. The group access control aware group key management (GACA-GKM) technique leverages the existence of a group access control system to substantially reduce overhead. The group access control aware group key management (GACA-GKM) technique leverages the existence of a group access control system to substantially reduce overhead.

30. Gothic and Routing System Trusted router correctly authorizes all join requests according to the protocol. An untrusted router is a router that may accept unauthorized join requests or forward fake or unauthorized join requests. Scope of trust extends from the source to the multicast tree and is bordered by trusted routers. Trusted subtree is a subtree of the multicast tree rooted at a trusted router.

31. GACA-GKM GKM focuses on dynamic group problem. When a member joins or leaves, the group key must be changed so that the new member can not decrypt past content or the former member can not decrypt future content. GKM focuses on dynamic group problem. When a member joins or leaves, the group key must be changed so that the new member can not decrypt past content or the former member can not decrypt future content. With group access control in place, the host can not receive the encrypted content before it is a member. There are similar implications for a member leave. So, there is no need to rekey the group. With group access control in place, the host can not receive the encrypted content before it is a member. There are similar implications for a member leave. So, there is no need to rekey the group. But if a new member, host A, is on a shared broadcast link with current group member, host B, then A had access to the distribution tree before she became a member. In cases like these we need to rekey the group. But if a new member, host A, is on a shared broadcast link with current group member, host B, then A had access to the distribution tree before she became a member. In cases like these we need to rekey the group. Eavesdropping in the form of wiretaps and network sniffing are also possible. Eavesdropping in the form of wiretaps and network sniffing are also possible.

32. GACA-GKM technique If a host h joins multicast session G from a trusted subtree that has previously been part of the multicast tree for session G, then a rekey must occur. If a host h leaves multicast session G from a trusted subtree that will remain part of the multicast tree for session G, then a rekey must occur. Otherwise, there is no need to rekey.

33. Related Work Hardjono and Cain. Hardjono and Cain. They present a method for delivering keys to enable IGMP authentication. They present a method for delivering keys to enable IGMP authentication. The authorization server provides capability-like access tokens to group members and access control list (ACL)- like token lists to routers. The authorization server provides capability-like access tokens to group members and access control list (ACL)- like token lists to routers. Two vulnerabilities identified. Two vulnerabilities identified. Replay attacks and Replay attacks and Malicious users can cause the router to accept fake access tokens since issuer signature is not verified by router. Malicious users can cause the router to accept fake access tokens since issuer signature is not verified by router. Ballardie and Crowcroft. They present a version of IGMP that allows receivers to be authorized before joining the group. The architecture has authorization servers that possess ACLs distributed by an initiator. Two vulnerabilities identified. An unauthorized user can obtain an authorization stamp by authenticating as itself, but then providing the spoofed address of an authorized user. An unauthorized user can cause AS accept an invalid authorization stamp.

34. Evaluation Gothic evaluation examines the efficiency of Gothic in terms of message overhead and computational overhead. Gothic evaluation examines the efficiency of Gothic in terms of message overhead and computational overhead. The evaluation is done in multicast environment. The evaluation is done in multicast environment. GACA-GKM evaluation shows the reduced message overhead compared to traditional GKM. GACA-GKM evaluation shows the reduced message overhead compared to traditional GKM.

35. Evaluation To simulate the performance of these schemes, they used data collected by the Mlisten tool over several days for the Mbone multicast of the space shuttle mission STS-80 November 1996. The session has a duration of 13 days and over 1600 join requests. This figure shows the group membership over the length of the session.

36. Gothic Evaluation This figure shows the total network overhead at all last hop routers involved in the system. This figure shows the overall network overhead.

37. Gothic Evaluation This figure shows the total network overhead at all group members. This figure shows the cumulative network overhead at the ACS.

38. Gothic Evaluation This figure shows the computational overhead of the three schemes at the router in terms of processing time. The computational overhead of Gothic is an order of magnitude less than that of the other scheme. So the Gothic authorization system achieved its goal of reducing the computational overhead at the router.

39. GACA-GKM Evaluation In addition to the session trace they also used a trace from a simulated multicast group. This allows to simulate the performance for a range of trusted subtree sizes. The simulated multicast group model has the following parameters: The pool of potential receivers has 65536 receivers. Each receiver joins and leaves the group independently. The ratio of active to inactive duration of individuals is 1:10, so the average group size is approximately 5958 during steady state. The length of the group session is 100 τ.

40. GACA-GKM Evaluation This figure shows the results for the actual mlisten trace data.

41. GACA-GKM Evaluation This figure shows the simulated trace results. This shows performance in terms of GKM message overhead at the group key controller.

42. Conclusion This paper has generalized the problem of secure multicast group joins and secure anycast server advertisements problems into a single group access control problem and proposed a framework that includes a group member authorization system and a group policy management system. Proposed Gothic, a secure and scalable group access control architecture based on this framework. Presented a novel authorization system that improves the scalability and security over previous solutions. Identified the need for group owner determination and authentication and proposed two approaches to achieve this.

43. Conclusion (Contd.) The discussion of group access control was presented in the context of many flavors of multicast and anycast including global IP-anycast, application-layer anycast, source-specific multicast, and application-layer multicast. Suggested that group key management schemes can leverage group access control systems to reduce the overhead involved in GKM. Presented the GACA-GKM technique and presented evaluation results that show the performance improvements. Future work remains in further integrating group access control, group key management, and content distribution.

44. Thank you. Happy Thanksgiving!!