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.