Multicast Security CSCE 6581 Advanced Computer Networks

1
Multicast Security CSCE 6581Advanced 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

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/univer
  cd/cc/td/doc/cisintwk/ito_doc/ipmulti.htmxtocid2

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

• gwTTS - University of Virginia tele-tutoring
  system (Distance Learning)

• Figure from The grounds-wide Tele-Tutoring
  System, University of Virginia, available at
  http//www.cs.virginia.edu/gwtts/

8
(Figure from Cisco Systems' Internetworking
Technology Handbook available at
http//www.cisco.com/univercd/cc/td/doc/cisintwk/i
to_doc/ipmulti.htmxtocid0 )
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.cisc
  o.com/ipmulticast/networkers03/RST1051-IntrotoIPMu
  lticast.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

14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
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
Overview of Multicast Security
Security Requirements
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

Source Authentication Methods

• 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

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 Cain10
• 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 Crowcroft12
• 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

• GOTHIC9
• 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

• Paul Judge, Mostafa Ammar, Security Issues and
  Solutions in Multicast Content Distribution A
  Survey," IEEE Network Magazine, 2003.
• 2. T. Hardjono and G. Tsudik, IP Multicast
  Security Issues and Directions'', Annales de
  Telecom, July-August 2000, pp 324-340
• Use of TESLA in SRTP Internet Draft available
  at http//www.ietf.org/internet-drafts/draft-ietf-
  msec-srtp-tesla-03.txt
• Y. Challal, H. Bettahar, A. Bouabdallah, A
  taxonomy of multicast data origin authentication
  issues and solutions', IEEE Communications
  Surveys and Tutorials 6 (3) (2004) 3457.
• 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.
• R. Gennaro and P. Rohatgi, How to Sign Digital
  Streams', LNCS, vol. 1294, 1997.

49
References

• 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.
• The Multicast Security Architecture (RFC 3740)
  available at http//www.ietf.org/rfc/rfc3740.txt
• MIKEY Multimedia Internet KEYing (RFC 3830)
  available
• at http//www.ietf.org/rfc/rfc3830.txt
• Multicast Security Group Key Management
  Architecture (RFC 4046) \\ available at
  http//www.ietf.org/rfc/rfc4046.txt
• GSAKMP available at http//www.ietf.org/internet-
  drafts/draft-ietf-msec-gsakmp-sec-10.txt
• P. Q. Judge and M. H. Ammar, Gothic Group
  Access Control Architecture for Secure Multicast
  and Anycast, IEEE INFOCOM, July 2002.
• 2. T. Hardjono and B. Cain, Key Establishment
  for IGMP Authentication in IP
• Multicast'', IEEE ECUMN, CREF, Colmar, France,
  2000.
• 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.