2.6.11 Multicast Security (msec)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27

Chair(s):

Ran Canetti <canetti@watson.ibm.com>
Lakshminath Dondeti <ldondeti@qualcomm.com>

Security Area Director(s):

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

Security Area Advisor:

Russ Housley <housley@vigilsec.com>

Mailing Lists:

General Discussion: msec@securemulticast.org
To Subscribe: msec-request@securemulticast.org
In Body: subscribe
Archive: http://six.pairlist.net/pipermail/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-10.txt
  • draft-ietf-msec-mikey-dhhmac-11.txt
  • draft-ietf-msec-ipsec-signatures-06.txt
  • draft-ietf-msec-srtp-tesla-03.txt
  • draft-ietf-msec-policy-token-sec-03.txt
  • draft-ietf-msec-newtype-keyid-01.txt
  • draft-ietf-msec-bootstrapping-tesla-01.txt
  • draft-ietf-msec-mikey-ecc-00.txt
  • draft-ietf-msec-mikey-rsa-r-00.txt
  • draft-ietf-msec-ipsec-extensions-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3547 PS The Group Domain of Interpretation
    RFC3740 I The Multicast Security Architecture
    RFC3830 Standard MIKEY: Multimedia Internet KEYing
    RFC4046 I Multicast Security (MSEC) Group Key Management Architecture
    RFC4082 I Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction

    Current Meeting Report
    MSEC@IETF-63 Meeting Minutes

    MSEC Working Group

    Chair(s):

    Ran Canetti <canetti@watson.ibm.com>
    Lakshminath Dondeti <ldondeti@qualcomm.com>

     

    Security Area Director(s):

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

     

    Charter:
    http://www.ietf.org/html.charters/msec-charter.html

     

    Supplemental:
    http://www.securemulticast.org/msec-meetings.htm

     

    02.08.2005, 18.15

     
    Minute takers: Steffen Fries (steffen.fries@siemens.com)
    Lakshminath Dondeti (ldondeti@qualcomm.com)
     
    Please send comments and/or corrections to msec@securemulticast.org
     

    AGENDA:

     

    * Blue sheets, Agenda Bashing etc.,                          2 mins

    * MSEC status report                   (Ran/Lakshminath)    10 mins

      Revised milestones

      Notes on cross-area work and reviews

    -        Agenda

    -        Two liaison activities

    -        Increasing number of drafts in MIKEY – need to work on umbrella document

    -        TESLA is a topic to be discussed

    -        IPsec extensions

    -        Published 2 RFC

    o        RFC4046

    o        RFC4082

    -        IESG

    o        draft-ietf-msec-bootstrapping-tesla -01 2005-05-24

    §         AD Evaluation::Revised ID Needed

    o        draft-ietf-msec-newtype-keyid -01 2005-02-14

    §         Waiting for AD Go-Ahead

    §         Waiting for 3GPP SA3 coordination

    §         Incremental additions, add on document to RFC3830

    §         Finished IESG last call?

    o        draft-ietf-msec-srtp-tesla -03 2005-02-14

    §         Waiting for AD Go-Ahead::Revised ID Needed

    -        RFC Editors queue

    o        draft-ietf-msec-gsakmp-sec -10 2005-05-17

    o        draft-ietf-msec-ipsec-signatures -06 2005-06-22

    o        draft-ietf-msec-mikey-dhhmac

    -        Work in Progress

    o        draft-ietf-msec-ipsec-extensions -00 2005-07-25

    o        draft-ietf-msec-mikey-ecc -00 2005-07-07

    o        draft-ietf-msec-mikey-rsa-r -00 2005-07-08

    o        draft-ietf-msec-policy-token-sec -03 2005-07-08

    -        Milestones:

    o        See slides

    o        Nov 05 WG Last Call on "MIKEY-RSA-R"

    o        Dec 05 WG Last Call on "MIKEY-ECC"

    -        If more time is needed for review time let chairs know

    -        Liaison statements:

    o        802.16e review request

    §         wanted it before their July meeting, but were not able to use it directly

    §         Several folks volunteered and most returned reviews

    §         Comments pending from a few

    §         Outstanding requests for the draft spec from a few

    §         What next?

    ·     The plan was to compile all the comments and submit to 802.16 as a contribution

    o         

    -         

     

    * draft-ietf-msec-bootstrapping-tesla   (Steffen)            5 mins

    -        Made changes after LC and chair review

    -        received comments from AD

    -        will provide revised ID

     

    * draft-ietf-msec-newtype-keyid        (Ran/Lakshminath)     5 mins

    -        This was a 3GPP-related contribution.  After the I-D finished last call, the authors realized that a few additional extensions need to be added.

    -        Russ will place the document in hold, pending a revised submission.

    -        MSEC will run a last call after the updated I-D has been submitted

    -        An IETF last call will also be needed

     

    * draft-ietf-msec-srtp-tesla           (Ran/Lakshminath)     5 mins

    -        (Mark provides a summary of the IETF last call reviews on the SRTP-TESLA I-D)

     

    * draft-ietf-msec-ipsec-extensions      (Dragan)            10 mins

    -        enumerate point necessary to discuss in IPSec

    -        RFC2401-bis IP Security profile

    o        Concurrent coexistence with IKEv2

    -        Security Association modes

    o        Transport

    o        Tunnel, must be supported by GW

    -        Routing

    o        Address preservation

    §         Destination address should be maintained

    §         New flag introduced to copy the remote address

    -        SPD changes

    o        Directional attribute added (common, send only, receive only)

    o        Should support multicast destination address

    -        Traffic Processing

    o        Inbound traffic

    o        Outbound

    -        SAD

    o        Replay protection is needed : TBD

    o        Chair things it should (RFC2401 talks about it)

    -        PAD

    o        Needs to be extended for peers with specific roles (GCKS, group speaker, member, root certs)

    -        NATs

    o        SSM adversely impacted by it

    -        Discussion

    o        Review ASAP needed to define scope on this, what topics should be covered, what not

    o        Russ notes 2401bis says multi-sender replay protection can’t be done

    o        Sandy M. (Sparta) This topic is relevant to a discussion in the RPSEC meeting; mentioned problems with manual keying regarding replay protection (keywords: MD5 and OSPF); current draft seems not to cover multi sender anti-reply-protection

    §         Suggests that multisender replay protection is a topic of interest that MSEC should pursue

    §         Lakshminath and Brian had some idea exchange regarding this point, will be documented

    o        Ran C.: Multi-sender replay-protection may need an own draft

    §         We’ll take that discussion to the list.

    o        Haitham C.: GSAKMP has notes on multi-sender replay protection about this and says that having a separate GSA for each sender would work

     

     

    * draft-ietf-msec-mikey-ecc             (Lakshminath/Andy)         10 mins

    -        Revised, some more work to do

    -        MIKEY-ECIES ½ RT

    -        MIKEY-DHSIGN with EC : Steffen will look for more comments if necessary, text may be merged with draft text

    -        Outstanding issue

    o        ECIES doesn’t use envelop keys

    -        Need IPR statements, if any, before forwarding I-D to the AD

    -        Planned last call in Dec 2005

    o        Let the chairs know if anyone needs more time to review etc.

     

     

    * draft-ietf-msec-mikey-rsa-r           (Dragan)            10 mins

    -        status update

    -        turned to WG item (mailing list)

    -        Ran notes: In the use cases mentioned, the sender is also the GCKS

    -        added better support for multicast case (includes GenExtSBID) payload

    -        WGLC some time in November 2005

    o        Please review ASAP

    -        Discussion

    o        Responder chooses the key, not the sender

    o        Approach regarding multicast similar to the GCKS model

    -        Changes

    o        Dos prevention caps spelled out in Security considerations

    o        GenExt included (see above)

    o        If initiator does not include policy, responder MUST

    -        Open Issue

    o        Multiple media line support within ta session level MIKEY (in the SDP body)

    §         Single TGK, multiple media streams

    §         Absolute position of a stream in SRTP-ID map affects key derivation

    §         Different initiators offer different number of streams the responder needs to be able to correctly map the keys to streams

    §         May need review from MMUSIC WG 

     

     

    * draft-dondeti-msec-inband-key-updates (Lakshminath)       10 mins

    -        send key updates along with data encapsulation protocols

    -        send a rekey message via data packets

    -        Motivation

    o        GSA updates may be lost in transmission

    o        Current approach is sending it multiple times

    o        3GPP2 BCMCS specification already uses MKI field, but MKI field is not integrity protected

    -        optional MKI field in the SRTP packet payload which is protected by the SRTP auth. Field

    -        Strawman proposal for the WG’s consideration

    -        May be interesting for this WG, influences also other protocols (IPsec and SRTP)

    -        : please send comments to the list

     

     

    * draft-faurite-rmt-tesla-for-alc-norm  "RMT proposal for   10 mins

                                             MSEC review"

    -        submitted to the RMT WG

    -        part of discussion on RMT and MSEC mailing list was related to the home of this draft

    -        goal TESLA being used for ALS/NORM/FLUTE (feedback of receivers)

    -        lot of good TESLA work in MSEC

    o        (draft-ietf-msec-tesla-spec-00 is not that dead, it will come back)

    o        Bob Briscoe: A number of changes have been made to the TESLA Informational RFC 4082

    §         Be sure to update the ESP-TESLA spec accordingly when it is revived

    -        several features are missing in this document

    o        only MIKEY based bootstrapping is considered

    §         but ALC can use in-band signaling (NO NEED FOR EXTRA PROTOCOL)

    -        INDIRECT SYNCHRONIZATION IS MENTIONED BUT NOT DETAILED : ALC sessions have no back channel : problem for sync

    -        Key chain switching is not addressed (ALCs may have very long sessions) : specification needed how this can be done reliabily

    -        Information payload formats are missing

    o        No bootstrapping information formation in bootstrapping-tesla ID

    -        Requires an initial bootstrap information message

    o        Sent in a dedicated ALC/NORM control packet containing only a bootstrap info header extension

    o        Only sent at the beginning of a session

    -        Indirect time synchronization

    o        Added suggestion to use SNTP (server sends cert)

    -        Signature extension

    o        Each ALC/NORM packet contains a signature header extension

    -        What is next?

    o        Split ID or not

    §         One part standardized in RMT group

    §         TESLA part in MSEC WG

    §         Keep streamlined ALC/NORM instantiation document, avoiding duplications

    o        Work on some technical aspects

    -        Discussion

    o        Ran: Which information shpuld be approved here?

    §         Indirect time sync should be explained in MSEC, usage of SNTP; time reference

    §         Bootstrap information is part of the TESLA protocol

    §         Maybe more issues to solve here

    o        Requirements come from RMT

    o        Ran: TESLA in MSEC : informational RFC

    §         Describes TELSA independent of a protocol

    §         One document almost fully specified SRTP-TESLA together with MIKEY

    §         TESLA in ESP

    §         This draft could fit in in implementing TESLA

    §         Draft has his own different featrue (key chain, sync, key establishement) : different than in current approaches, therefore good to have it.

    §         Splitting of the document might depend on the RMT interworking, RMT depending parts should be handled in RMT WG

    o        Bob B: Does it make sense to send control packets in between an ALC data stream?

    §         Some discussion ensued ...

    o        ?:Control packet better to fit into the data stream than in bootstrapping?

    §         Control packet contains only dedicated information (see slides)

    §         MIKEY is used anyway, why not sending this information as well

    §         Needs to be discussed : (S. Fries) MIKEY bootstrapping currently application independent, this approach would bring in some dependencies on ALC/NORM

    o        Discussion regarding WG handling this ID will be done on the list, maybe the transport AD need to be consulted

    o        Russ: make last call on both MSEC and RMT mailing lists

    o        Author: Indirect time sync and key chain switching may be used for other apps as well.

    o        Lakshminath: SRTP mentions key chains ... may add more details in ESP-TESLA draft

    o        Ran: RFC4082 talks about indirect sync (but maybe not elaborately)

    o        Currently two public implementations available, but only one supporting this feature

     

    * draft-cruickshank-ipdvb-sec-00.txt    "IPDVB proposal for 10 mins

                                             MSEC review"

    §         ULE security extensions

    §         IP over DVB (over MPEG2 networks)

    §         Security features shall be provided (encryption, …)

    §         Should not conflict with IPsec

    §         Motivations

    o   Implementation of GSAKMP with AH

    o   Better access control for operators

    o   Capability to work with non-IP packet format

    o   Protect identity of the sender receiver within MPEG2 transmission network (UID)

    §         SNDU format for encryption header

    o   New ULE mandatory extension header for encryption

    o   ULE sec ID is 32 bit value

    o   Can be used by a receiver to filter PDUs

    §         Key management orthogonal, GSAKMP or GDOI can be used

    §         MSEC compatibility issues

    o   Encryption algorithms, key length use of standard IPsec and MSEC suites)

    o   Key space (re-use MSEC key database)

    §         Discussion

    o   Comments needed

    o   Sam Hartman: Ethernet packets can be encapsulated, IP infrastructure used for key management : Ran: all MSEC key management use IP (e.g., dedicated UDP port), maybe IPsec sufficient?

    o   Author will think about it

    §         (Lakshminath asked Haitham to follow-up with Hugh Harney and other GSAKMP authors to see if GSAKMP can be run on non-IP networks and what are the “transport” requirements.)

    §         (Lakshminath had a discussion with the IPDVB co-chair, Gorry Fairhurst, after the MSEC meeting.  The IPDVB list is to discuss the issue of having to run key management over IP while encapsulated data will not be using IP networks.  The MSEC list will be cc’ed.)

     

    * MIKEY/TESLA discussion

    -        5 drafts on MIKEY

    -        umbrella document may be the best way to handle the different MIKEY extensions

    -        Ran C: Roadmap regarding documents needed

    -        Further discussion on the list

    -        IPsec extension : draft has been sent to mailing list for review

    o        Lakshminath to send the draft to IPsec to get initial comments on the scope

     

     

    * closing remarks                                            3 mins

     

                                                                90 mins

    Slides

    MSEC WG Status review
    Update on SRTP-TESLA
    Bootstrapping TESLA
    Multicast Support in IPsec
    MIKEY-RSA-R
    MIKEY-ECC
    Inband Key Updates
    RMT-TESLA
    IPDVB-SEC
    Session Summary