2.6.9 Multicast Security (msec)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-03-02


Ran Canetti <canetti@watson.ibm.com>
Lacshminath Dondeti <ldondeti@nortelnetworks.com>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

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
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
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-07.txt
  • draft-ietf-msec-gkmarch-08.txt
  • draft-ietf-msec-tesla-intro-04.txt
  • draft-ietf-msec-mikey-dhhmac-09.txt
  • draft-ietf-msec-ipsec-signatures-04.txt
  • draft-ietf-msec-srtp-tesla-03.txt
  • draft-ietf-msec-policy-token-sec-01.txt
  • draft-ietf-msec-gdoiv2-01.txt
  • draft-ietf-msec-newtype-keyid-01.txt
  • draft-ietf-msec-bootstrapping-tesla-00.txt

    Request For Comments:

    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-62, Minneapolis, MN (Nov 8, 2004)

    Meeting at Thursday 10 March, 9:30-10:30AM

    Minute takers: Marshall Eubanks & Brian Weis

    Welcome & Draft Updates - Brian Weis
    o No changes to agenda

    o Review of WG drafts

    Two drafts are in the RFC Editor Queue:
    - draft-ietf-msec-gkmarch-08
    - draft-ietf-msec-tesla-intro-04

    Three drafts are currently in IESG Evaluation
    - draft-ietf-msec-gsakmp-sec-07
    - draft-ietf-msec-ipsec-signatures-04
    - draft-ietf-msec-mikey-dhhmac-09

    The WG chairs will be forwarding three drafts to the Security ADs:
    - draft-ietf-msec-bootstrapping-tesla-00
    - draft-ietf-msec-newtype-keyid-01
    - draft-ietf-msec-srtp-tesla-03

    Th WG chairs will be putting deadlines on two drafts in hopes that they will move forward:
    - draft-ietf-msec-tesla-spec-00
    - draft-ietf-msec-gdoiv2-01

    Several other drafts need status updates from the authors.
    - draft-ietf-msec-policy-token-sec-02
    - draft-ietf-msec-tokenspec-sec-00
    - draft-ietf-msec-gspt-02

    2401bis and multicast issues - Russ Housley

    o The IPSEC and MSEC WGs coordinated to ensure that ESPv3 and AHv3 could accommodate multicast. However, RFC2401 specifies the framework for IPsec. It also has some issues with multicast. As part of the 2401bis document review they found that 2401bis does not support all multicast security associations.

    o Rather than hold up the 2401bis document, Russ is asking the MSEC WG to publish a new document to support multicast in the 2401bis framework.

    o Specific issues include:

    - The Multicast Security Architecture (RFC 3740) needs to be specifically applied to IPsec.
    - The Group SPD (GSPD) described in RFC 3740 needs to be described specifically for IPsec. For example, the outbound traffic directed to a multicast address will not have a companion inbound SA with the multicast address as the source.
    - The Security Association Database (SAD). Currently, only manually configured multicast SAs are supported.

    o Russ indicated that this work should begin once the 2401bis document has been approved for publication by the IESG. This should happen soon.

    Additional mode of key distribution for MIKEY - Francois Audet

    o draft-ignjatic-msec-mikey-rsa-r-00

    o The current MIKEY Public key mode requires initiator to have the responder's Public key before sending the first message. Yet very often one does not have the receiver's public key in advance, especially for p2p communications such as SIP. Without the certificate of the responder, the initiator cannot use the MIKEY public key mode.

    o There are cases where the initiator is willing to do SRTP even he does not know exactly who the responder will be: for example, in a corporate telephony environment. Furthermore, SIP calls may be made to a group of devices (e.g., group aliases, SIP forking), and the initiator cannot be sure in advance which one will answer.

    o The authors propose a new MIKEY mode, where the responder sends its public key in the reply message, along with its signature.

    o This mode is useful for unicast, and also for multicast where a client contacts a key server, but doesn't already have the key server's public key. However, the multicast case needs further description in the document.

    o The authors ask that this be accepted as a WG document. This request will be taken to the WG mailing list.

    Richard Graveman: There are two cases this is useful: 1) when you don't have the responders public key, or 2) when you don't know who is on the other end. The first case makes sense, but can you give guidance on when this mode is appropriate in the second case?

    Francois: Its the initiators choice on when to use it. The key question for the initiator is, "Am I trying to connect to a particular person, or do I just want to use encryption?".

    Steffen Fries: This is a really helpful approach, but the draft needs mode description on the multicast case, when you can't use DH.

    Francois: Lakshminath will be adding a multicast case to the document. It is clear that this is what got him excited about this approach.

    MIKEY using elliptic-curve methods - Andrew Milne

    o draft-ietf-msecmikey-ecc-00 (not yet submitted)

    o Elliptic curve (ECC) is useful in MIKEY because you can use a shorter key to achieve the same security. For example, if you went equivalent security as a 356 bit symmetric key you would need to use 15,360 bit DH/RSA but just a 571 bit ECC public key.

    o There are four primitives described in this draft:
    - ECDSA (Digital Signature Algorithm).
    - ECDH (Elliptic Diffie-Hellman).
    - ECIES (Integrated Encryption Scheme). This is Equivalent to public key, and is a good one-pass method.
    - ECMQV. This is a drop-in replacement for signed Diffie-Hellman, although is a little awkward for MIKEY.

    o ECMQV has three versions: one-pass, two-pass, and three-pass. At least the two-pass and three-pass variants would require quite a bit of change to MIKEY.

    Russ Housley: MQV is really cool, but not a simple plug-n-play replacement, so the WG needs to decide if it wants to do the work to modularize MIKEY or not to accommodate this.

    Russ Housley: Can you explain the IPR situation?

    Andrew: Certicom has IPR in this area. It would be difficult to implement much in this draft without Certicom, although it depends a bit on which curve you are doing. ECMQV is covered by the US Government Elliptic Curve Licensing Agreement. [Editor's Note: See the SAAG minutes for IETF61 for a discussion of this licensing agreement.]

    Richard Graveman: Regarding IPR, are there any documents that describe the algorithms publicly?

    Andrew: There are IEEE and ANSI documents for which you must pay. I did put a description of MQV in the document (which did not make the deadline).

    Update on DHHMAC draft - Steffen Fries

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

    o There have been two drafts with minor changes since IETF61, and the AD Review has been completed.

    o A third-party IPR disclosure entry has been submitted to IETF, see https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=539

    Bootstrapping TESLA draft - Steffen Fries

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

    o At IETF61 there are a lot of discussion regarding whether this should be its own document, or merged with the srtp-tesla Internet-Draft. After a discussion on the mailing list it was decided to keep it separate.

    o This draft has a clarification about time synchronization, that it can be done either by using NTP, or by piggybacking this information in MIKEY.

    o The WG last call for the document ended on March 4th; no further technical comments were made.


    MSEC WG Status
    2401bis and multicast issues
    Additional mode of key distribution for MIKEY
    MIKEY using elliptic-curve methods
    Update on DHHMAC draft
    Bootstrapping TESLA draft