Multicast Security CSCE 6581Advanced Computer Networks
Vandana Gunupudi
Chen Peng
Avanthi Koneru
Agenda
Introduction Applications Multicast Service Model Security Issues Background and Requirements Benchmarks and Metrics Summary of methods Conclusion
Avanthi
Peng
Vandana
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)
Multicasting
Figure from Internet Protocol Multicast, Cisco Systems, available at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm#xtocid2
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
Multicasting - Video Conference
Ex: Network video tool, LBL video conferencing tool,
Inria video conferencing system
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)
(Figure from Cisco Systems' Internetworking Technology Handbook available at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm#xtocid0 )
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 at
ftp://ftpeng.cisco.com/ipmulticast/networkers03/RST1051-IntrotoIPMulticast.pdf )
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.
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.
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
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
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.
Requirements
• The most basic security requirements:– Secrecy– Authenticity
• Other requirements include:– Anonymity– Non-repudiation– Access Control– Service Availability
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.
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.
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.
Requirements
Figure from Paul Judge, Mostafa Ammar, “Security Issues and Solutions in Multicast Content Distribution: A Survey," IEEE Network Magazine, 2003.
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.
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
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.
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
Authentication Confidentiality
Access Control(Sender/Receiver)
Key Management
Security Requirements
Overview of Multicast Security
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
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
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
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
Requirements
Authenticity
Integrity of received data
NonRepudiation
Efficiency Communication and Computation Overhead
Collusion Resistance
Minimal Latency
Proposed Solutions
Figure from Paul Judge, Mostafa Ammar, “Security Issues and Solutions in Multicast Content Distribution: A Survey," IEEE Network Magazine, 2003.
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
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
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
Proposed Schemes
Source: Paul Judge, Mostafa Ammar, “Security Issues and Solutions in Multicast Content Distribution: A Survey," IEEE Network Magazine, 2003.
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)
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)
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
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
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
Receiver Access Control
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
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
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
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
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.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.
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.txt
2. MIKEY: Multimedia Internet KEYing (RFC 3830) available
at: http://www.ietf.org/rfc/rfc3830.txt
1. Multicast Security Group Key Management Architecture (RFC 4046) \\ available at: http://www.ietf.org/rfc/rfc4046.txt
2. GSAKMP: available at http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-10.txt
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.