2.6.8 Multicast Security (msec)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Ran Canetti <canetti@watson.ibm.com>
Thomas Hardjono <hardjono@nortelnetworks.com>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortelnetworks.com>

Security Area Advisor:

Marcus Leech <mleech@nortelnetworks.com>

Mailing Lists:

General Discussion:msec@securemulticast.org
To Subscribe: msec-request@securemulticast.org
In Body: subscribe
Archive: http://www.pairlist.net/mailman/listinfo/msec

Description of Working Group:

The purpose of the MSEC WG is to standardize protocols for securing group communication over internets, and in particular over the global Internet. Initial efforts will focus on scalable solutions for groups with a single source and a very large number of recipients. Additional emphasis will be put on groups where the data is transmitted via IP-layer multicast routing protocols (with or without guaranteed reliability). The developed standard will assume that each group has a single trusted entity (the Group Controller) that sets the security policy and controls the group membership. The standard will strive to provide at least the following basic security guarantees:

+ Only legitimate group members will have access to current group communication. This includes groups with highly dynamic membership.
+ Legitimate group members will be able to authenticate the source and contents of the group communication. This includes cases where group members do not trust each other.
An additional goal of the standard will be to protect against denial-of-service attacks, whenever possible.
Due to the large number of one-to-many multicast applications and the sometimes conflicting requirements these applications exhibit, it is believed that a single protocol will be unable to meet the requirements of all applications. Therefore, the WG will first specify a general framework that includes a number of "functional building blocks". Each such building block will be instantiated by one or more protocols that will be interchangable. The functional building blocks and protocols developed at the SMUG Rsearch Group of the IRTF will be used as the starting point for the work of MSEC. Specifically, the following functional building-blocks will be the basis of the standard:
(BB1) Data security transforms functional building block. This building block provide for group and source authentication and group secrecy, assuming that the parties hold the necessary cryptographic keys. This BB will support both IP-layer and transport/application layer security services.
(BB2) Group key management and group security association (GSA) functional building block. This building block makes sure that the group members have the cryptographic keys needed for BB1. This includes secure generation, distribution, and update of the cryptographic keys.
(BB3) Group policy management functional building block. This building block provides means for determination and disemination of group security policy, that governs the behavior of BB1 and BB2. (It is stressed that MSEC will not address general policy management issues, and will concentrate on mechanisms required for BB1 and BB2.)
MSEC will work closely with the Secure Multicast (SMUG) and Reliable Multicast (RMRG), IRTF research groups, and with the Multicast Transport (RMT), IP Security (IPsec) and Policy (Policy Framework and IPSP) WGs of the IETF.
MSEC will generate the at least the following documents:
1 An informational RFC describing the security requirements and problem-space for group and multicast security for one-to-many communications.
This RFC will be based on draft-irtf-smug-taxonomy-01.txt.
2 An informational RFC that specifies the overall framework for the solution. This includes specifying the general functionality of the building blocks and their inter-relations.
This RFC will be based on draft-irtf-smug-framework-01.txt.
3 RFCs detailing the structure and functionality of each building block.
These RFCs will be based on:
4 Standards-track RFCs describing specific protocols that instantiate each one of the functional building blocks. At least one protocol for instantiating each building block will be standardized.
Some of these RFCs will be based on:

Goals and Milestones:

Apr 01


Initial Drafts on requirements and problems space, and framework (items 1 and 2 above)

Jun 01


Submit requirements and problems space, and framework drafts for publication as Informational RFC.

Jul 01


Initial drafts on the functional building blocks (item 3 above).

Aug 01


IETF-51: Review building-block drafts

Nov 01


Initial Drafts on protocols for instantiating the functional building blocks (item 4 above).

Dec 01


IETF-52: Presentation of protocol drafts.

Feb 02


Complete building-block drafts WG Last-Call and submit as Proposed Standard.

Mar 02


Second Review of protocol drafts.

Jul 02


Third review of protocol drafts.

Jul 02


Third review of protocol drafts.

Dec 02


Final review of protocol drafts.

Dec 02


Complete protocol drafts WG Last-Call and submit as Proposed Standard.

Dec 02


Final review of protocol drafts.

Dec 02


WG disband or re-charter for other work items.

No Request For Comments

Current Meeting Report

Minutes of MSEC WG Meeting, IETF50, Minneapolis (March 19, 2001)
Chairs: Thomas Hardjono & Ran Canetti

(NOTE: All slides are at www.securemulticast.org/msec-meetings.htm)

(1) Thomas - opening and agenda bashing (none)

(2) Ran - MSEC Charter discussions

o Draft presented at BOF,
o Discussions on list during January,
o Updated posted to list and presented today

Question from the floor: Is it any more complicated to cover both multi-source and single source multicast as opposed to just single source?

- Ran: MSEC is keeping in mind multi-source, but will start with single source as the basis.
- Kent: believes multi-source is more difficult and starting with single-source is appropriate

Question from the floor: what is goal of group membership?
Information cannot be protected once distributed to group.

- Thomas and Ran acknowledge re-distribution problem and said that it is out of scope for MSEC

(3) Group & Multicast Security Architecture - Mark Baugher

o Based on work from SMuG
o Goal is to base on work of RFC2401 IPsec architecture
o Address security at both network layer and application layer
o Focus on centralized designs
o Differences from SMuG framework - move policy outside of area of interest and leverage IPSP and Policy WG

Comments from the floor:

- Harney: notes that some of the current proposals due handle distributed design and suggests we keep in it MSEC definition.
We should not exclude it.
- Ran: restated that architecture should not exclude distributed design.
- Hardjono: suggested SMuG finish its distributed work by the end of this year to feed into MSEC

(4) Group GDOI - Brian Weis

o Two independent implementations underway
o Security of protocol under evaluation by NRL

Question from the floor: Is this a compromise between IKE and multicast? It seems that worst of both worlds. What was the motivation?

- Brian: felt this was cleaner from system perspective.

- Hilarie Orman: Why have two keys for authorization/authentication? Can you use key for POP in Phase 1?

- Brian: we did not want to affect IKE Phase 1

(5) Group GDOI Analysis - Catherine Meadows

o Using NRL protocol analyzer
- forces you to write requirements of protocol
- forces you to write a protocol specification

o State an insecure state, and protocol analyzer determines if it can be reached
o Just the statement of requirements results in two improvements to the GDOI protocol: one to proof-of-possession and one to sequence number checking.

Questions: none

(6) GSAKMP - Hugh Harney

o Described distinction between peer policy and group policy
o Groups have more indirections
o GSAKMP is a layer on top of other protocols - runs over existing peer associations (e.g., IKE, TLS )
o Highlighted ability to distribute GCKS as part of the base protocol/system

Questions: none

(7) Multicast Data Security Transforms - Ran Canetti

o Parallel to ESP
o Add source authentication in addition to group authentication
o Two identical transforms - one for transport/application, one for IP layer
o Each provides all three security mechanisms
o IP layer - MESP - multicast ESP
o Application layer - AMESP - Application multicast ESP
o MESP - add optional "internal" authentication

Questions: none

(9) TESLA - Ran Canetti

o One method for source authentication
o Designed for lossy channels

Comments from the floor: TESLA seems appropriate for RM and in particular RTP. There is a secure RTP draft, but it does not cover source authentication

- Ran: noted that GDOI and GSAKMP could be enhanced to provide time synchronization during SA 1 registration to support TESLA over SA3.

(10) Close meeting (Thomas Hardjono)

- The site www.securemulticast.org for both IRTF SMuG and IETF MSEC


Evolving the SMuG Framework to a Group and Multicast Architecture
TESLA: Multicast Source Authentication Transform
Multicast Data Security Transformations
Formalizing Security Requirements For GDOI
Group Domain of Interpretation