Current Meeting Report
Slides
Jabber Logs


2.6.6 Multicast Security (msec)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 03/26/2002

Chair(s):
Ran Canetti <canetti@watson.ibm.com>
Thomas Hardjono <thardjono@verisign.com>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Steve Bellovin <smb@research.att.com>
Security Area Advisor:
Steve Bellovin <smb@research.att.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.

DELIVERABLES

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:

draft-irtf-smug-data-transforms-00.txt

draft-irtf-smug-gkmbb-gsadef-01.txt

draft-irtf-smug-mcast-policy-01.txt

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:

draft-irtf-smug-gdoi-00.txt

draft-harney-sparta-gsakmp-sec-02.txt

draft-irtf-smug-tesla-00.txt

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.
Internet-Drafts:
  • - draft-ietf-msec-gdoi-05.txt
  • - draft-ietf-msec-gkmarch-02.txt
  • - draft-ietf-msec-gsakmp-light-sec-01.txt
  • - draft-ietf-msec-mikey-03.txt
  • No Request For Comments

    Current Meeting Report

    None received.

    Slides

    Agenda, Status Review
    MIKEY Update
    Multicast ESP
    TESLA Overview
    Digital Signature Authentication for ESP/AH
    Group Key Management Architecture
    HMAC-authenticated Diffie-Hellman for MIKEY (DHHMAC)
    EDOI Update
    GSAKMP-Light Update