2.6.7 Multicast Security (msec)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-20

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


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  Final review of protocol drafts.
DEC 02  Complete protocol drafts WG Last-Call and submit as Proposed Standard.
DEC 02  WG disband or re-charter for other work items.
  • - draft-ietf-msec-gdoi-07.txt
  • - draft-ietf-msec-gsakmp-sec-01.txt
  • - draft-ietf-msec-gkmarch-04.txt
  • - draft-ietf-msec-gsakmp-light-sec-01.txt
  • - draft-ietf-msec-mikey-06.txt
  • - draft-ietf-msec-tesla-intro-01.txt
  • - draft-ietf-msec-mikey-dhhmac-01.txt
  • - draft-ietf-msec-mesp-00.txt
  • - draft-ietf-msec-tesla-spec-00.txt
  • - draft-ietf-msec-ipsec-multicast-issues-01.txt
  • - draft-ietf-msec-tokenspec-sec-00.txt
  • No Request For Comments

    Current Meeting Report

    Minutes of MSEC WG Meeting, 56th IETF, 17 March 2003
    1. Recharter, Thomas:  A new charter was posted to the msec list for 
    discussion.  Thomas showed the current MSEC I-Ds list.  GDOI & MIKEY are in 
    Last Call.  Recharter to extend msec life to 2004 to finish work and 
    develop new focus on distributed architectures and many:many 
    multicast.  Mar 03 Last Call on GKMARCH with several more following.  New 
    focus areas are not on the list or Proposed I-Ds, but Ran thinks that 
    these problems should be issues for each of the present drafts rather than 
    separate drafts.
    2. TESLA Update, Adrian: Brief description of TESLA stream, outline of 
    current drafts, and future works on broadcast authentication.  Problem is to 
    prevent receiver from impersonating sender in a secure group.  Sender 
    precomputes N+1 keys, 0..N, where Kn = HMAC(Kn-1, 1), K0 = K.  K is 
    installed securely prior to the session start.  The sender creats a chain 
    from the installed key(0) to key(N-1) where key(N-1) is the first key to be 
    revealed in a TESLA packet during the session.  The receiver can always 
    verify that a key(n-k) is part of the chain by computing key(n-j), 
    j=k..n, and compute key(N-1) or some intermediate key that the receiver has 
    received and cached.  The TESLA I-Ds is 
    draft-ietf-msec-tesla-intro-01 that adds immediate authentication and 
    concurrent TESLA instances (to handle receivers over networks with a wide 
    range of packet delays. 
    draft-ietf-msec-tesla-spec-00 is current technical draft that gives a 
    bootstrapping procedures (e.g. time synchronization), format, 
    operation with ESP, etc.  B.Whillock has done a reference 
    implementation that is available on the web.  Looking for a second 
    implementation.  Also need to integrate with ESP/MESP.  
    3. IPSEC Multicast Issues, Brian: Ran, Mark, Thomas and Brian wrote an I-D to 
    document the multicast issues in AH/ESP while they are being revised by 
    S.Kent.  The issues are (1) SPI allocation and SA lookup using 3-tuple 
    without using source address, (2) Anti-replay protection for 
    multi-sender SAs (part of new charter of msec), and (3) ICV name.  
    Overall, this was a productive exchange IPSEC and MSEC with good 
    collaboration with S.Kent.  
    4. MESP, Mark:  Made MESP into a transform framework for ESP rather than a 
    separate protocol.  The framework is based on group secrecy, internal 
    authentication and external authentication where external 
    authentication protects internal.  Need to resolve making ENC, INT, EXT 
    processing order to be mandatory.
    5. Feedback messages, Lakshminath: Feedback is needed for GSA 
    synchronization, NAKs, and de-registration. Most GKM systems keep a 
    unique key per member; suggest we use that unique key for feedback from 
    each group member.  SA lookup could probably use the SPI. Proposed 
    feedback message resembles the groupkey push message in GDOI.  Hugh 
    pointed out that the unique key is usually a KEK and said that the use of a 
    KEK for a TEK could be problematic.  Replay protection may use the SEQ# and 
    this may work for NAKs and de-registration but not for out of sync 
    feedback messages.  Question:  is this something the group should do?  The 
    answer is yes.
    6. Group key management, Lakshminath:  Do one RFC for LKH, OFT, and OFC as 
    well as treating key tree management.  The latter uses binary or natural 
    number encoding, the goal is to manage the splitting and shrinking in an 
    efficient manner.  Zhang et. al. scheme keeps rekey messages small and 
    limits number of messages for maintaining tree.  Two Options.  First, 
    standardize key tree encoding and try to get a key tree encoding for all 
    interesting trees.  Second, GCKS may advertise a standardized scheme and use 
    it - tradeoffs footprint, communication cost, etc.
    7. GSAKMP, Hugh: GSAKMP Light done in Sep 2001 that was shorter and 
    simpler.  Since GSAKMP Light is favored, we decided to focus just on 
    GSAKMP Light and make it GSAKMP.  Old GSAKMP considered for 
    Informational RFCs; Russ favors Experimental over Informational; if it 
    catches on, then an Experimental track protocol can go standards track, 
    Informational cannot.
    8. Policy Token, Hugh: New spec has GSAKMP Roles and Policy token.  
    GSAKMP creates set of roles (GO, GCKS, Sub GCKS,and GM).  Policy token 
    wraps policy and sent from GO to GCKS who then distributes it to 
    subordinates of group members (GM).  GSAKMP protocol incorporates 
    policy-token dissemination.  Policy uses Identification, 
    Authorizations, Access Control, Mechanisms, and Signature.  Each was 
    9. DHHMAC for Mikey, Martin:  intended for proposed standard, identity 
    protection clarified, aligned with MIKEY v6, and editorial 
    improvements.  Document is ready for WG last call?  But a -02 version will be 
    submitted prior to last call. Ran said that this probably should not go 
    ahead of MIKEY.  Thomas will submit in two weeks.  Also, there may be some 
    need for EC for MIKEY.
    10. SDP Security Descriptions, Mark: After a brief overview of SDP, Mark 
    described two configurations for which SDP Security Descriptions apply; one 
    is an end-to-end RTSP running in TLS; the other is a hop-by-hop SIP 
    running over some collection of TLS connections.  He briefly described the 
    SDP status, syntax, parameters and next steps.  In the discussion, Russ 
    went thumbs down on the hop-by-hop SIP security descriptions as 
    offering no security.  Mark and Dan Wing wrote the 
    draft-ietf-mmusic-sdescriptions-00.txt and will be updating it to 
    draft-ietf-mmusic-sdescriptions-01.txt in the Spring. 


    AH/ESP Multicast Issues
    Group Key Management Algorithms (GKMA)
    Group Key Management Architecture -04
    Multicast ESP
    GSAKMP Policy Token Spec
    Securing Feedback Messages
    SDP Security Descriptions for Media Streams
    Current Status of the TESLA Drafts
    HMAC-authenticated Diffie-Hellman for MIKEY