1. Multicast Security CSCE 6581 Advanced Computer Networks Vandana Gunupudi Chen Peng Avanthi Koneru

2. Agenda Introduction Applications Multicast Service Model Security Issues Background and Requirements Benchmarks and Metrics Summary of methods Conclusion Avanthi Peng Vandana

3. What is Multicasting? Unicast is conventional single point-to-point communication. Broadcast is transmission to multiple, unspecified recipients. Multicast is communication between a single sender and multiple receivers (one- to-many) on a network or multiple senders sending to multiple receivers (many-to- many)

4. Multicasting Figure from Internet Protocol Multicast, Cisco Systems, available at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm#xtocid2 http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm#xtocid2

5. Multicast Applications Streaming video/audio Live TV and Radio broadcasts to the Desktop, IPTV Real-Time financial data delivery Whiteboard/Collaboration Multiplayer games File/Software downloads/updates News Feeds Multimedia phone service

6. Multicasting - Video Conference Ex: Network video tool, LBL video conferencing tool, Inria video conferencing system

7. Multicasting - Video Broadcasting Figure from The grounds-wide Tele-Tutoring System, University of Virginia, available at http://www.cs.virginia.edu/~gwtts/ ● gwTTS - University of Virginia tele-tutoring system (Distance Learning)

8. (Figure from Cisco Systems' Internetworking Technology Handbook available at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm#xtocid0 ) http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm#xtocid0

9. Advantages Enhanced Efficiency: Controls network traffic and reduces server and CPU loads Optimized Performance: Eliminates traffic redundancy Distributed Applications: Makes multipoint applications possible (Figure from Introduction to IP Multicast, Cisco IP Multicast Groups, available atftp://ftpeng.cisco.com/ipmulticast/networkers03/RST1051-IntrotoIPMulticast.pdf )ftp://ftpeng.cisco.com/ipmulticast/networkers03/RST1051-IntrotoIPMulticast.pdf

10. Disadvantages Best Effort Delivery: Drops are to be expected. Multicast applications should not expect reliable delivery of data and should be designed accordingly. No Congestion Avoidance: Lack of TCP windowing and “slow-start” mechanisms can result in network congestion. Duplicates: Some multicast protocol mechanisms (e.g. Asserts, Registers and Shortest-Path Tree Transitions) result in the occasional generation of duplicate packets. Out-of-Sequence Packets: Various network events can result in packets arriving out of sequence.

11. Multicast addresses Multicasting employs a Class D address format, which ranges from 224.0.0.0 to 239.255.255.255. Every IP datagram whose destination address starts with "1110" is an IP Multicast datagram.

12. Multicast Service Model Invented by Steve Deering RFC1112 : Host Extensions for IP Multicasting - 1989 Senders transmit IP datagrams to a host group “Host group” identified by a class D IP address Members of host group could be present anywhere in the Internet All members receive all packets sent to the address Open group memberships Members join and leave the group and indicate this to the routers Senders and receivers are distinct: i.e., a sender need not be a member of the group Routers listen to all multicast addresses and use multicast routing protocols to manage groups

13. How does a host join a group ? Internet Group Management Protocol (IGMP, RFC 3376) – Used by end hosts to signal that they want to join a specific multicast group – Used by routers to discover what groups have have interested member hosts on each network to which they are attached. – Implemented directly over IP Currently at version 3 Join and Leave messages

17. Multicast Properties Three main properties of multicast: – All members receive all packets sent to the address – Open group memberships – Open access to send packets to the group In order to have a secure multicast application, certain security requirements must apply to avoid the vulnerabilities.

18. Requirements The most basic security requirements: – Secrecy – Authenticity Other requirements include: – Anonymity – Non-repudiation – Access Control – Service Availability

19. Requirements Secrecy usually means that only the multicast group members (and all of them) should be able to decipher transmitted data. Group authenticity means that each group member can recognize whether a message was sent by a group member. Source authenticity means that it is possible to identify the particular sender within the group.

20. Requirements anonymity is to keep the identity of group members secret from outsiders or from other group members, or keep the identity of the sender of a message secret. non-repudiation is the ability of receivers of data to prove to third parties that the data has been transmitted.

21. Requirements Access control is the ability to make sure that only registered and legitimate parties have access to the communication addressed to the group. service availability is critical in multicast since DOS attacks are easy to mount and are much more harmful.

22. Requirements Figure from Paul Judge, Mostafa Ammar, “Security Issues and Solutions in Multicast Content Distribution: A Survey," IEEE Network Magazine, 2003.

23. Performance Metrics In Seminar I We talk about general performance metrics from multicast application perspective. In Seminar II we will talk about each area in detail on how to achieve the performance using different solutions and benchmarks.

24. Performance Metrics Performance is a major concern for multicast security applications. Major performance metrics include: – latency and work overhead per sending and receiving data packets – bandwidth overhead incurred by inflating the data packets via cryptographic transformations

25. Performance Metrics Other performance metrics: – Lengths of keys Ephemeral (Short-term) security: smaller key lengths Long-term security: Longer key lengths – Group management activity such as group initialization and member addition and deletion.( Time Delay in milliseconds) – Possible congestion, especially around centralized control services at peak sign-on and sign-off times.

26. Summary of metrics  General Metrics: – Computation overhead (depends on key lengths) ● Time to verify and decrypt data ● Time to authenticate and encrypt data – Communication bandwidth/latency overhead – Congestion  Key Management Metrics: – Key set-up and key refresh overhead – Group set-up and member enrolment time

27. Authentication Confidentiality Access Control ( Sender/Receiver ) Key Management Security Requirements Overview of Multicast Security

28. Core Problem Areas Source Authentication – TESLA Group Key Management – Many protocols – Focus on IETF standardization efforts Access Control – Receiver and Source Access Control – Focus on receiver primarily

29. Standardization efforts Secure Multicast Research Group (SmuG) – IRTF Working Group to discuss research issues in Multicast Security – Identify security requirements for a variety of applications – define a common and general reference framework composed of useful building blocks – Use building blocks to construct solutions for multicast security problems

30. Properties of Secure Multicast Preserve authentication and secrecy for all group communication Only registered senders can send packets Only registered receivers can read packets Registration means the registration by the group controller/key server Encryption/Decryption of sent packets with a shared group key Only registered senders and receivers can encrypt and decrypt the packets The group key is distributed only to the eligible senders and receivers

31. Source Authentication Motivating Scenario – Group of subscribers get periodic stock quotes from a server – Need to verify the identity of the sender of the stock quote Definition – Ability of members of a multicast group to verify the identity of the sender

32. Requirements  Authenticity  Integrity of received data  NonRepudiation  Efficiency  Communication and Computation Overhead  Collusion Resistance  Minimal Latency

33. Proposed Solutions Figure from Paul Judge, Mostafa Ammar, “Security Issues and Solutions in Multicast Content Distribution: A Survey," IEEE Network Magazine, 2003.

34. Source Authentication Methods Hash-based Schemes Packet Chaining Data stream partitioned into chains Each packet in chain contains hash of of the next packet in the chain Therefore, only first packet in chain is signed, saving space Tree Chaining Data stream partitioned into blocks Each block of n messages authenticated with 1 signature Nodes are message digests Receiver can recreate path

35. MAC-based Schemes Efficient MACS Sender holds a set of n MAC keys Receivers hold a subset of the n keys Each message “MACed” with each of the n keys and receiver verifies the MAC with the subset of keys it holds Appropriate choice of subsets Timed Efficient Stream Loss-Tolerant Authentication Protocol (TESLA) Sender signs the first packet and provides notification of a chain of MAC keys Later packets in chain reveal prior keys Synchronization required between sender/receiver Source Authentication Methods

36. Group Key Management (GKM) Why do we need GKM? – Data in multicast applications typically encrypted using symmetric-key cryptography – Need to protect the keys Hosts may belong to many groups with many different keys Hosts may send to many groups with different keys Support dynamic creation of groups, dynamic membership, dynamic sources

37. Proposed Schemes Source: Paul Judge, Mostafa Ammar, “Security Issues and Solutions in Multicast Content Distribution: A Survey," IEEE Network Magazine, 2003.

38. GKM Framework Group Key Management Framework Entities Group Controller/Key Server(GCKS) Hosts Registration Protocol When members join the group ReKey Protocol When members leave the group Types of Keys Key Encrypting Key (KEK) Traffic Encrypting Key (TEK)

39. IETF-proposed Standards Group Secure Association Key Management Protocol (GSAKMP) – Network layer – Distributed Architecture – One-to-many or many-to-many – Scalable Multimedia Internet Keying (MIKEY) – Targeted at real time multimedia applications – Application-layer (SRTP) – Can be tunneled over Session Initiation Protocol(SIP)

40. MIKEY End-to-end security of the key exchange End-to-end mutual authentication Pre-shared key, public key, signed Diffie- Hellman Suitable for unicast and small groups Simplicity Efficiency low extra bandwidth consumption low computational workload small code size Minimal number of round trips Independent of any specific security functionality of the underlying transport

41. Application Scenarios peer-to-peer, simple one-to-many, and small- size (interactive) groups peer-to-peer (unicast) a SIP-based call between two parties, where it may be desirable that the security is either set up by mutual agreement or that each party sets up the security for its own outgoing streams. simple one-to-many (multicast) real-time presentations, where the sender is in charge of setting up the security. many-to-many small-size interactive groups where each party may set up the security for its own outgoing media. Initiator of the group acts as the group server

42. Receiver Access Control Open access to distributed content on the Internet Any host can join a group using IGMP Security threats: – DoS Resource exhaustion – Eavesdropping – Theft of service Restrict access to multicast group

43. Receiver Access Control

44. Requirements Group Policy Specification Functions – Group Owner specifies a group policy Access Request Functions – Hosts requests permission to join a group Access Control Functions – Receive host's request, authenticate and then authorize

45. Proposed Solutions Hardjono and Cain[10]: – Access tokens to members – Authorization through Access Control Lists (ACLs)-like tokens – Token included in join request to router – Router verifies that the access-token is in the token list Ballardie and Crowcroft[12]: – Authorization servers that have ACLs distributed by an initiator – Host obtains an authorization stamp from server – Router forwards the join request to server for approval

46. Solutions GOTHIC[9] Comprehensive architecture for group access control Identity-based and time-limited capabilities Host requests a capability from server and forwards it to router as part of join request Router authenticates the host and verifies the capability before allowing access Integrate group access control with group key management

47. Conclusion Introduced multicast Discussed Security Issues Focus on core problem areas Next seminar will focus on protocols and methods that will be incorporated into the Next Generation Internet like TESLA, MIKEY

48. References 1. Paul Judge, Mostafa Ammar, “Security Issues and Solutions in Multicast Content Distribution: A Survey," IEEE Network Magazine, 2003. 2.2. T. Hardjono and G. Tsudik, “IP Multicast Security: Issues and Directions''}, Annales de Telecom, July-August 2000, pp 324-340 3.Use of TESLA in SRTP: Internet Draft: available at http://www.ietf.org/internet- drafts/draft-ietf-msec-srtp-tesla-03.txthttp://www.ietf.org/internet- drafts/draft-ietf-msec-srtp-tesla-03.txt 4.Y. Challal, H. Bettahar, A. Bouabdallah, A taxonomy of multicast data origin authentication: issues and solutions', IEEE Communications Surveys and Tutorials 6 (3) (2004) 34—57. 5.Perrig, A., Ran Canetti, Dawn Song, and Doug Tygar, Efficient and Secure Source Authentication for Multicast ', in Proceedings of Network and Distributed System Security Symposium NDSS 2001, February 2001. 6.R. Gennaro and P. Rohatgi, How to Sign Digital Streams ', LNCS, vol. 1294, 1997.

49. References 1.P. Judge, “Security and Protection Architectures for Large-Scale Content Distribution'', Ph.D. thesis, Georgia Tech, Atlanta, GA, Dec. 2002. 2. Sandro Rafaeli, David Hutchison, A survey of key management for secure group communication, ACM Comput. Surv. 35(3): 309-329 3. M. Moyer, J. Rao, and P. Rohatgi, `A Survey of Security Issues in Multicast Communications, IEEE Network, vol. 13, Nov.-Dec. 1999, pp. 12-23. 1.The Multicast Security Architecture: (RFC 3740) available at: http://www.ietf.org/rfc/rfc3740.txthttp://www.ietf.org/rfc/rfc3740.txt 2. MIKEY: Multimedia Internet KEYing (RFC 3830) available at: http://www.ietf.org/rfc/rfc3830.txthttp://www.ietf.org/rfc/rfc3830.txt 1. Multicast Security Group Key Management Architecture (RFC 4046) \\ available at: http://www.ietf.org/rfc/rfc4046.txt http://www.ietf.org/rfc/rfc4046.txt 2.GSAKMP: available at http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-10.txthttp://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-10 3.P. Q. Judge and M. H. Ammar, “Gothic: Group Access Control Architecture for Secure Multicast and Anycast”, IEEE INFOCOM, July 2002. 4.2. T. Hardjono and B. Cain, “Key Establishment for IGMP Authentication in IP 5.Multicast'', IEEE ECUMN, CREF, Colmar, France, 2000. 6.3. A. Ballardie and J.Crowcroft, “Multicast-Specific Security Threats and Countermeasures'', Proc. ISOC Symp. Net. and Distrib. Sys. Sec., San Diego, CA, Feb. 1995, pp. 2-16.