Gothic : A Group Access Control Architecture for Secure Multicast and Anycast

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 • Security Issues • Security Objective • Proposed Design • Evaluation • Conclusion

3. Communication Paradigms • Unicast • Point-to-point flow of packets • Multicast • Point-to-multipointflow of packets • 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 Sender Receiver 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 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. Multicast Security • 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 • 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

11. Vulnerabilities of Multicast • Multicast suffers from increased vulnerability due to: • Sessions are frequently advertised • Greater number of points of vulnerability • Attack affects a broader base of people • 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 • Verify the user is who he says he is • Authorization • Only admit those with proper authorization into the group • Integrity • Group members maintain privacy from those not in the group • System must be scalable

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

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

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

17. Gothic Architecture • Group Policy Management System (GPMS) = Specify group policy • 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) • Problem – How to verify that host is a group owner? • Solution – Group Owner determination and Authentication System (GODAS)

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

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

21. Authorization Protocol • 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 • 3. H  R : JR = CAP • 4. R  H : JA = Status

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

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

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. • How the system verifies that a particular host is the group owner? • 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). • Source-Specific Multicast (SSM). • GLOP • Session Announcement Protocol (SAP)/Session Description Protocol (SDP).

28. Group owner determination and authentication in anycast environments • IP Anycast. • Global IP 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 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.

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. • 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. • 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. Hardjono and Cain. 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. Two vulnerabilities identified. Replay attacks and 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. Related Work

34. Evaluation • Gothic evaluation examines the efficiency of Gothic in terms of message overhead and computational overhead. • The evaluation is done in multicast environment. • 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!!