2.6.9 Multicast Security (msec)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-07

Chair(s):

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)

Internet-Drafts:

  • draft-ietf-msec-gsakmp-sec-06.txt
  • draft-ietf-msec-gkmarch-08.txt
  • draft-ietf-msec-tesla-intro-03.txt
  • draft-ietf-msec-mikey-dhhmac-07.txt
  • draft-ietf-msec-ipsec-signatures-02.txt
  • draft-ietf-msec-srtp-tesla-02.txt
  • draft-ietf-msec-policy-token-sec-00.txt
  • draft-ietf-msec-gdoiv2-01.txt

    Request For Comments:

    RFCStatusTitle
    RFC3547 PS The Group Domain of Interpretation
    RFC3740 I The Multicast Security Architecture
    RFC3830 Standard MIKEY: Multimedia Internet KEYing

    Current Meeting Report

    ----------------------------------------------------
    MSEC WG Minutes, IETF-61, Washington D.C. (Nov 8, 2004)
    ----------------------------------------------------

    Meeting at Monday 8 November, 7:30-9:00PM

    Welcome - Ran Canetti
    ---------------------

    o No changes to agenda

    o Review of WG drafts

    - draft-ietf-msec-mikey-dhhmac-05.txt
    This draft is currently in AD Evaluation. There is third-party IPR claim on the draft. Russ Housley said that he will wait until the IPR claim is understood before reading the draft.

    - draft-ietf-msec-ipsec-signatures-01.txt
    This draft is under AD evaluation. Russ has submitted AD comments on the draft. Brian will be producing a new draft answering those comments shortly after the I-D queue re-opens. There was some discussion on whether the minimum (496 bits) is too small, or whether that is OK if only used for an SA with a short lifetime (e.g., 30 minutes). Russ would like the draft to have more guidance on acceptable key sizes.

    - draft-ietf-msec-gsakmp-sec-05.txt
    This draft is currently in IETF Last Call. Hugh had a question on what happened to the policy token draft, as it is referenced by the GSAKMP draft. Russ said that the GSAKMP draft should finish Last Call. It just can't proceed any further until the normative policy token document advances to the same level.

    - draft-ietf-msec-gkmarch-08.txt
    This draft included text to satisfy some IESG Discuss points. Russ will send the text to the people who brought up the Discusses and hope to get them resolved.

    - draft-ietf-msec-tesla-intro-03.txt
    Remarks from IESG are being addressed, and a new draft will be out soon.

    - draft-ietf-msec-tesla-spec-00.txt
    A revised I-D is needed.

    o Other drafts will be discussed in following presentations.

    General Payload Type in MIKEY - Elizabetta Carrara
    -------------------------------------------------

    o draft-carrara-newtype-keyid-00.txt

    o The objective of this draft is to define a new type in the general extension payload in MIKEY. This is needed by the multimedia broadcast/multicast service (MBMS) in 3GPP (Rel6). The streaming scenario uses SRTP for media protection and MIKEY for key mgmt. MBMS requires some extensions in order to pass all of MBMS types of keys.

    o Ran asked what type of document that the authors would like to see, and Elizabetta replied that they would like an Informational RFC.

    o Ran asked if anyone objected to this work item. No one did.

    o There was some question as to what the IANA considerations for MIKEY said was necessary in order to add to its namespaces, and whether an Info. RFC was acceptable. Later inspection showed that the MIKEY RFC does not specify any criteria regarding what type of document is required to update this.

    MIKEY DH-HMAC - Steffen Fries
    -----------------------------

    o draft-ietf-msec-mikey-dhhmac-05.txt

    o Steffan described the changes in the latest version of the document.

    o The next steps include an AD review. Russ asked for clarification on the third-party IPR statement. Steffan replied that it allegedly was sent to the IETF but that it hadn't appeared on the web site yet. It apparently addresses this draft particularly.

    Bootstrapping TESLA - Steffen Fries
    -----------------------------------

    o draft-fries-msec-bootstrapping-tesla-00.txt

    o This draft defines a new payload and policy parameters for bootstrapping TESLA in SRTP. There has been some questions on the mailing list about how to synchronize time between the sender and receivers, and Steffan favors using an out-of-band method (e.g., NTP or SNTP).

    - Mark pointed out that the most straightforward way to synchronize might be using a round-trip time (like a "ping" round-trip).
    - Steffan pointed out that it depends on which side initiates the MIKEY protocol. The content receiver would need to initiate the protocol.
    - Ran said that the content receiver would have to use the interactive version of MIKEY.
    - Steffan said that it still depends on who initiates MIKEY.
    - Ran said that in the 2 message the media receiver always starts first.
    - Lakshminath pointed out that is the optional exchange in MIKEY, not either of the two mandatory ones!
    - Steffan said that in those you need a 3rd message if the media sender is inviting the receiver.

    o The working group discussed whether or not that the draft should be stand-alone, or whether it should be combined with the TESLA-SRTP draft. It currently is only used by the TESLA-SRTP draft, but if it remains independent it could be used by other key management protocols supporting TESLA (e.g., GSAKMP). This was discussed at greater length in the next presentation.

    TESLA_in-SRTP update - Elizabetta Carrara
    ------------------------------------------

    o draft-ietf-msec-srtp-tesla-02.txt

    o Elizabetta discussed the changes that went into this draft.

    - Ran asked if is the TESLA information in Steffan's draft consistent with this draft?
    - Steffan replied that there were some differences.

    o Ran asked that the working group consider whether these should be one draft or two.

    - Mark said that the SRTP-TESLA draft should describe both the TESLA signaling and data parameters.
    - Mark had a concern that there weren't any implementations of the TESLA work, which is key to getting good drafts. We ought to have 2 implementations.

    o A vote was taken on whether the drafts should be merged. Four voted "for", and two against. The two against were the authors of the drafts, which led to more discussion.

    - Steffan said he'd like to keep them separate in case another protocol wanted to use the draft to bootstrap TESLA.
    - Brian pointed out that the draft had packet formats specific for TESLA, which might not work with other protocols.
    - Hugh mentioned that if you have a mixed group with different key management mechanisms both bootstrapping TESLA (e.g., GSAKMP, MIKEY) how else are they going to make sure the TESLA-SRTP policy works correctly? By marrying the two draft you are making this harder.
    - Mark summarized Hugh by saying that there could be an interworking problem in the different protocols if they define the policy independently.
    - Brian said that we didn't make it an objective to make the key management protocols interoperate up 'til now.
    - Lakshminath asked if the description can go in the TESLA docs?
    - Ran said that the TESLA introduction draft is informational, so that's the wrong place. We need a standards track document.
    - Mark asked how about if we create a new MIKEY draft based on the RFC to add the TESLA bootstrapping parameters, since that's where they should have been in the first place? Then the MIKEY draft would be cycled to proposed standard.
    - Russ gave some things to think about regarding going to proposed std: to advance it it has to have been stable for 6 months. So if you go this route, do the changes earlier so that the two interoperating implementations can be stable for 6 months.
    - Lakshminath said lots of people like to see a stable RFC before they implement it! That might be a worry to current MIKEY implementers. This decision should be taken to the list.

    Update on GDOIv2/GKDP - Lakshminath Dondeti
    -------------------------------------------

    o draft-ietf-msec-gdoiv2-01

    o This draft has a new name: Group Key Distribution Protocol. This is the result of comments against -00 which said that we might want to actually make a GDOIv2 someday based on RFC 3547.

    o This draft proposes a variant of GDOI using IKEv2 as the authenticated tunnel rather than IKEv1. There are few updates from -00 time. Lakshminath has a co-author, and is looking for more help.

    o Look for more updates on the mailing list.

    Flat Multicast Key Exchange - Emanneule Jones
    ---------------------------------------------

    o draft-duquer-fmke-01.txt

    o Emanneule Jones presented on behalf of authors, who were not able to attend.

    o The protocol is derived from GDOI, and provides an adapted solution for wireless links. IP over satellite is considered, and possibly also WiFi and WIMAX.

    o The -01 draft has been changed to be a use a case of GDOI, and underlines the differences between the protocols.

    - George pointed out that the reliability protocol in FMKE has attributes that resemble the RMT "NORM" protocol. It is an RMT building block that is optimal for this kind of problem.

    o Two demonstrators have been developed using FMKE. One was part of the IST Satip6 project. The other was a military DVB-RCS application. In both cases FMKE phase 1 and phase 2 ESP were implemented.

    o The next steps are to minimize the FMKE changes, fold them into GDOI if it is possible and publish a a new version of GDOI.

    - Brian said that he didn't see why the proposed changes could be added to GDOI rather than creating a new DOI value (as the current draft proposes), but we need to talk about the requirements, and what requirements that GDOI can currently solve. Specific comments should be posted to the list to start a discussion with the authors.
    - Mark said that GDOI doesn't address reliable multicast, and has no back channel operation. His thought is that GDOI should be able to support these in the base specification. A further proliferation of key mgmt protocols is not a good thing.
    - Hugh pointed out that Logica is solving this problem using GSAKMP.
    - Ran suggested that maybe this should be folded into GKDP.

    o Ran asked if this work in scope?
    - Brian said yes, that it is addressing the issue with an IP network with interesting characteristics.
    - Mark said that we should get together the GDOI and DMKE authors to talk about this in the next few weeks.

    Wrap Up - Ran Canetti
    ---------------------

    o Ran pointed out that according to our charter we should be done soon, and asked if there should be new work items?
    - George said a generic policy token.
    - Hugh clarified that this is the point of a policy token.
    - Lakshminath mentioned that we talked about reliable transport of rekey messages two years ago, and said that simple repeated transmission of rekey messages should work. Now that this is coming up again in FMKE, it might be time again in the March meeting to discuss this and how we should do this.
    - Ran mentioned a policy token for ESP.

    Slides

    HMAC-authenticated Diffie-Hellman for MIKEY
    Bootstrapping TESLA
    TESLA-in-SRTP Update
    GKDP: Group Key Distribution Protocol