Multicast Security (msec) ------------------------- Charter Last Modified: 2010-02-23 Current Status: Active Working Group Chair(s): Brian Weis Vincent Roca Security Area Director(s): Sean Turner Tim Polk Security Area Advisor: Tim Polk Mailing Lists: General Discussion:msec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/msec Archive: http://www.ietf.org/mail-archive/web/msec/current/maillist.html 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 Done WG Last Call on MSEC Security Requirements draft Done WG Last Call on GSAKMP Done WG Last Call on MSEC Policy Token Done WG Last call on TESLA-Intro draft Done WG Last call on Use of RSA/SHA-1 Signatures within ESP and AH Done WG Last Call on The Use of TESLA in SRTP Done WG Last Call on Bootstrapping TESLA Done WG Last Call on MIKEY-RSA-R Feb 2007 WG Last Call on Multicast Extensions to IPsec Mar 2007 WG Last Call on MIKEY-ECC May 2007 WG Last Call on TESLA-Spec Jul 2007 WG Last Call on GKDP Sep 2007 WG re-charter for other work items or disband Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 Mar 2010 The Group Domain of Interpretation Feb 2007 Mar 2010 Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC3547 PS Jul 2003 The Group Domain of Interpretation RFC3740 I Apr 2004 The Multicast Security Architecture RFC3830Standard Aug 2004 MIKEY: Multimedia Internet KEYing RFC4046 I May 2005 Multicast Security (MSEC) Group Key Management Architecture RFC4082 I Jun 2005 Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction RFC4359Standard Jan 2006 The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) RFC4383Standard Feb 2006 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP) RFC4442 PS Mar 2006 Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) RFC4534 PS Jun 2006 Group Security Policy Token v1 RFC4535 PS Jun 2006 GSAKMP: Group Secure Association Group Management Protocol RFC4563 PS Jun 2006 The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) RFC4650 PS Sep 2006 HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) RFC4738 PS Nov 2006 MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) RFC5197 I Jun 2008 On the applicability of various MIKEY modes and extensions RFC5374 PS Nov 2008 Multicast Extensions to the Security Architecture for the Internet Protocol RFC5776 E Apr 2010 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols