2.6.7 Multicast Security (msec)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-01

Ran Canetti <canetti@watson.ibm.com>
Thomas Hardjono <thardjono@verisign.com>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.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 Reference Framework that includes a number of functional building blocks. Each such building block will be instantiated by one or more protocols that will be interchanable. The Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast.

In addition, as a secondary goal the MSEC WG will also focus on distributed architectures for group key management and group policy management, where for scalability purposes multiple trusted entities (such as Key Distributors) are deployed in a distributed fashion. For this purpose, the Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast.

MSEC will generate at least the following documents, which could be considered as base documents:

1. An RFC describing the security requirements of multicast security and an RFC describing the MSEC Architecture.

2. An RFC describing the Group Key Management Architecture and an RFC describing Group Policy Management Architecture in MSEC.

3. Several RFCs describing specifications for protocols that implement source authentication, group key management and group policy management. As multicast security covers a broad range of issues, and therefore touches other Working Groups in the IETF, the MSEC WG will work closely with othersecurity-related Working Groups (e.g. IPsec, IPSP), as well as other Working Groups which maybe considered a 'consumer' of the technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA).

With this in mind, the MSEC WG is open to receiving new work items, whenever it is considered appropriate to be homed in the MSEC WG. Such drafts will be matured in conjunction with the MSEC base documents.

Goals and Milestones:
Done  Working Group Last Call on GDOI Protocol
Done  Working Group Last Call on MIKEY Protocol
Done  WG Last Call on MSEC Architecture draft
Done  WG Last Call on Group Key Management Architecture
Done  WG Last Call on DHHMAC for MIKEY
Dec 03  WG Last Call on MSEC Security Requirements draft
Dec 03  WG Last Call on MSEC Policy Token
Dec 03  WG Last Call on GSAKMP
Dec 03  Last Call on GSAKMP-Token
Dec 03  WG Last Call on IP Multicast issues with IPsec
Mar 04  WG Last call on TESLA-Intro draft
Mar 04  WG Last Call on MESP Framework (Data Security Architecture) draft
Mar 04  WG Last call on TESLA-Spec draft
Jul 04  WG re-charter for other work items (or disband)
  • - draft-ietf-msec-gsakmp-sec-04.txt
  • - draft-ietf-msec-gkmarch-06.txt
  • - draft-ietf-msec-gsakmp-light-sec-01.txt
  • - draft-ietf-msec-gspt-02.txt
  • - draft-ietf-msec-mikey-07.txt
  • - draft-ietf-msec-tesla-intro-01.txt
  • - draft-ietf-msec-mikey-dhhmac-04.txt
  • - draft-ietf-msec-mesp-01.txt
  • - draft-ietf-msec-tesla-spec-00.txt
  • - draft-ietf-msec-arch-03.txt
  • - draft-ietf-msec-tgsakmp-00.txt
  • - draft-ietf-msec-secure-feedback-00.txt
  • Request For Comments:
    RFC3547 PS The Group Domain of Interpretation

    Current Meeting Report

    MSEC WG Minutes, IETF-58, Minneapolis (Nov 10, 2003)
    Meeting at Monday 10 November, 9:00am-11:30am
    Welcome - Thomas Hardjono
       o No changes to agenda
       o Review of WG status: I-D Milestones since last IETF foil
    www.securemulticast.org/msec-drafts.htm gives the draft status
         - Ran:  mesp features have been incorporated into IPsec ESPbis
         - Thomas: Multicast issues draft could go to informational notably the 
    "IPsec issues draft"
         - Russ: If ESPbis has incorporated everything then should drop this; 
    the consensus is to drop it
         - No status on secure feedback draft.
         - Ran: have nothing on how key management works with 
    application layer data protection
         - Mark: Hard to do this without having a particular application data 
    security protocol in the pipeline but there is some work underway on 
    multicast transport-layer security
         - Ran: We should define this in anticipation of an 
    application-security protocol
         - Andrea: GSAKMP is supporting an app protocol that is not an IETF 
    standard; Ran thought that the API and object definition would be of 
         - Brian:  Is this specifically an API?  Ran: Yes.  Brian: not sure we 
    need to do an API in the MSEC WG.  The thing of interest is the objects and 
    bindings in the protocol for doing this.
         - Thomas: We need to discuss policy token; we'll do this after 
    Andrea's presentation
    MIKEY update - Elisabetta 
        o IESG evaluation reviewed (see foilset)
         - Brian: Is a new PRF RFC required or is this is an extension?
             Elisabetta said that this was an extension mechanism.  
          - Russ: some means are needed to signal the use of a new PRF
          - General discussion on the need to decouple MIKEY from the mmusic 
          - Russ recommends to not reference the key-mgt document from MIKEY
        o Status is that a revised I-D is needed for IESG last call
    GKMARCH update - Ran  (see foils)
        o  There are two outstanding issues from WG Last Call, one being  peer 
          - George: From receiver, what's important is how the controller is 
    authenticated.  Will next draft allow re-key from peers?
          - Brian: It seems important to allow for this.
        o We will incorporate needed changes and resubmit to WG last call
    GSAKMP update - Andrea (see foils)
        o Changes from last I-D and new additions presented
          - Ran:  are cookies still include in request to join?  
          - Andrea: yes
        o Draft 04 is out is out and 05 will follow for possible last call
          - Thomas:  Policy token is now broken into two pieces with a 
    generic piece.  Would GDOI use them?  
          - Brian: Yes, GDOI could use the policy token
        o Ran:  We are going to be asked about having two separate group key 
    management protocols when GSAKMP goes to the IESG last call in the 
    future.  Do we need two?
          - Mark: historically the difference was between the ISAKMP header 
    that GDOI used and GSAKMP did not.  Now there are a lot of different 
    functions in today's GSAKMP.
          - Brian:  GSAKMP also is closely tied to the policy token
          - Thomas: There is an important application for GSAKMP that is 
    distinct from GDOI just as there was a need for GDOI to leverage the IKE 
    installed base.  We need to move GSAKMP forward to WG Last Call 
    a.s.a.p. given that MSEC Charter ends in July 2004.
          - George: There is something to be said for parallel 
    development of the two protocols; could focus on rekey message as a 
    unifying message, e.g. GDOI uses a great variety of different 
    authorization methods and these distinctions are a concern for the 
    registration protocol and not the rekey protocol
          - Thomas: When will GSAKMP be ready for last call?  How about 
    January or February. 
          - Andrea thought that was reasonable
    DHHMAC update - Steffen Fries presenting on behalf of Martin (see foils)
        o Changes from last I-D
        o Version 05 will be done by xmas and this is recommended as a last 
    call document
          - Ran:  is there a constituency for this?
          - Mark:  This aligns MIKEY with H.235?  Steffen said 'yes'
          - Betta: Is this needed for H.323?  Steffen said 'yes'
          - Thomas:  Is there opposition to moving this forward?
              (No one in audience opposses). Lets move it forward.
          - Mark: The motivation would be to align this IETF protocol 
    (MIKEY) with H.235 (would like to do the same with SRTP as well).
          - Ran: Should take to WG last call?
          - Thomas:  We can do this with draft 05 is submitted.
    MSEC & AAA - George (see foils)
        o Status given and motivation for including AAA/Diameter in MSEC 
        o GDOI could leverage ISAKMP/IKE AAA work but GDOI does not 
    separate KS from GC functions; 
          - Mark: What is the distinction?
          - George: GC does registration but does not have the key for the 
          - Mark:  This distinction is not generally well-defined in msec.
          - George:  This was discussed in the MSEC architecture.
          - Brian: KS could be closest to member but the GC would do 
          - Mark: In general, this problem is difficult and not yet solved in 
    security systems, viz. X.509 PKI across domains.
          - George:  Large-scale multicast groups are likely to be 
    multi-realm and we will need to solve this in MSEC.
          - Andrea:  It is unlikely to be able to separate these functions 
    since there is always a potential collusion problem.
        o GSAKMP uses the Diameter "push" model as opposed to the GDOI "pull" 
        o Have not yet decided how to introduce this to msec.
          - Thomas: Can't this be in the generic policy token I-D?
          - George:  It will at least influence the design of the generic 
    policy token and could be completely defined there
    Wrap Up
        o Korea IETF in Mar 2004: Thomas took a show of hands and found ~9 
    persons were planning to attend.
        o Ran might attend so there may be an msec meeting at IETF 59.
        o Discuss again in mailing-list in early 2004.


    HMAC-authenticated Diffie-Hellman for MIKEY
    GKMARCH Updates
    GSAKMP Update
    Multicast Security with Authentication, Authorization, and Accounting (AAA)
    MIKEY IESG Evaluation