WG ACTION: Multicast Security (msec)

[The IESG <[e-mail]>]

A new working group has been formed in the Security Area of the IETF.
For additional information, contact the Area Directors
or the WG Chair.


Multicast Security (msec)
-------------------------
 
 Charter 
 Last Modified: 08-Feb-01
 
 Current Status: Active Working Group
 
 Chair(s):
     Ran Canetti <[e-mail]>
     Thomas Hardjono <[e-mail]>
 
 Security Area Director(s): 
     Jeffrey Schiller  <[e-mail]>
     Marcus Leech  <[e-mail]>
 
 Security Area Advisor: 
     Marcus Leech  <[e-mail]>
 
 Mailing Lists: 
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         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.