+ 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 framework that includes a number of "functional building blocks". Each such building block will be instantiated by one or more protocols that will be interchangable. The functional building blocks and protocols developed at the SMUG Rsearch Group of the IRTF will be used as the starting point for the work of MSEC. Specifically, the following functional building-blocks will be the basis of the standard:
(BB1) Data security transforms functional building block. This building block provide for group and source authentication and group secrecy, assuming that the parties hold the necessary cryptographic keys. This BB will support both IP-layer and transport/application layer security services.
(BB2) Group key management and group security association (GSA) functional building block. This building block makes sure that the group members have the cryptographic keys needed for BB1. This includes secure generation, distribution, and update of the cryptographic keys.
(BB3) Group policy management functional building block. This building block provides means for determination and disemination of group security policy, that governs the behavior of BB1 and BB2. (It is stressed that MSEC will not address general policy management issues, and will concentrate on mechanisms required for BB1 and BB2.)
MSEC will work closely with the Secure Multicast (SMUG) and Reliable Multicast (RMRG), IRTF research groups, and with the Multicast Transport (RMT), IP Security (IPsec) and Policy (Policy Framework and IPSP) WGs of the IETF.
DELIVERABLES
MSEC will generate the at least the following documents:
1 An informational RFC describing the security requirements and problem-space for group and multicast security for one-to-many communications.
This RFC will be based on draft-irtf-smug-taxonomy-01.txt.
2 An informational RFC that specifies the overall framework for the solution. This includes specifying the general functionality of the building blocks and their inter-relations.
This RFC will be based on draft-irtf-smug-framework-01.txt.
3 RFCs detailing the structure and functionality of each building block.
These RFCs will be based on:
draft-irtf-smug-data-transforms-00.txt
draft-irtf-smug-gkmbb-gsadef-01.txt
draft-irtf-smug-mcast-policy-01.txt
4 Standards-track RFCs describing specific protocols that instantiate each one of the functional building blocks. At least one protocol for instantiating each building block will be standardized.
Some of these RFCs will be based on:
draft-irtf-smug-gdoi-00.txt
draft-harney-sparta-gsakmp-sec-02.txt
draft-irtf-smug-tesla-00.txt
| Apr 01 | Initial Drafts on requirements and problems space, and framework (items 1 and 2 above) | |
| Jun 01 | Submit requirements and problems space, and framework drafts for publication as Informational RFC. | |
| Jul 01 | Initial drafts on the functional building blocks (item 3 above). | |
| Aug 01 | IETF-51: Review building-block drafts | |
| Nov 01 | Initial Drafts on protocols for instantiating the functional building blocks (item 4 above). | |
| Dec 01 | IETF-52: Presentation of protocol drafts. | |
| Feb 02 | Complete building-block drafts WG Last-Call and submit as Proposed Standard. | |
| Mar 02 | Second Review of protocol drafts. | |
| Jul 02 | Third review of protocol drafts. | |
| Jul 02 | Third review of protocol drafts. | |
| Dec 02 | Final review of protocol drafts. | |
| Dec 02 | Complete protocol drafts WG Last-Call and submit as Proposed Standard. | |
| Dec 02 | Final review of protocol drafts. | |
| Dec 02 | WG disband or re-charter for other work items. |
Current Meeting Report
Multicast Security WG Minutes at 52nd IETF
Friday December 14, 2001, Salt Lake City
Agenda:
-------
Agenda Bashing
Review of WG Status (T. Hardjono/R. Canetti)
GKM Architecture (L.Dondeti)
Rekey protocol (L. Dondeti)
MIKEY (F. Lindholm/E. Carrara)
GDOI Implementation (B. Weis)
Discussion: Last call for GDOI
Review of WG Status (T. Hardjono)
---------------------------------
Co-Chair Thomas Hardjono opened the Multicast Security WG meeting promptly at 9:00 AM Friday, December 14, 2001. He was the only chair present during this meeting.
Thomas summarized the three categories of documents that are required to be delivered per the terms of this WG's charter. Unfortunately, the document production is behind schedule. A brief overview of the schedule looks like this:
- High level or framework drafts
- Architecture/functionality drafts
- Protocol and algorithms drafts
Additionally, there has been additional work submitted to the MSEC WG, such as the MIKEY draft.
Thomas reports that within the RMT WG forum, there is a lack of clarity as to what they are seeking in the way of security support. There has been no firm security definition put forward by RMT. Mark Baugher agrees with Thomas' assessment. He further suggests that MSEC co-chairs asks RMT specifically what are the necessary security requirements while at the same time have GSEC issue a report on what elements of IGMP security currently exist. However, some basic requirements exist and Thomas articulated those. They are:
Multicast routing protection (PIM Authentication Draft in the PIM WG begins to out line minimal requirements.)
Sender/receiver access control (controlling distribution to the access tree.)
Key management (work being done in this WG securing the Content is the next critical element of this work.)
Thomas states that an ad hoc group of the chairs from GSEC, RMT, Magma and the Area Directors from Transport will form in the near future. Their purpose is to define and stipulate in writing what are the security requirements that best serve the needs of the involved parties and move forward with the creation of relevant documents.
Co-chair provides a status of the WG's documentation thus far. Under the major categories, the following documents exist.
High Level Drafts
- Security Requirements – Canetti
- MSEC Architecture – Hardjono/Baugher
Architecture/Functionalities
- Data Transforms (A/MESP) – Canetti
- Group Key Management Architecture – Baugher/Dondeti
- Group Security Policy Architecture – needs authorship
Protocols and Algorithms
- Group DOI – Weis et al
- GSAKMP & GSAKMP Light – Harney et al
- TESLA with A/MESP - Canetti
- TESLA Algorithms - Perrig/Canetti
- LKH/OFT – Dondeti/McGrew
- Policy Token Definition & Structure – needs authorship
Other Issues
With respect to Group Policy, Thomas indicates a need for an overall policy architecture and to make the defined policies known to the appropriate consumers. He raises the question, "should policy be driven by the applications of group security?". This concluded Thomas' WG status presentation.
GKM Architecture – L. Dondeti
-----------------------------
Lakshminath Dondeti made next presentation on his Group Key Management (GKM) Architecture draft. Current draft is v.01 and review help is requested. There were no comments following the presentation.
Rekey Protocol – Dondeti/McGrew
-------------------------------
One important aspect of this draft protocol is that rekey was a spin-off from the GKM architecture.
In hindsight, this bifurcation was not a good move as, among other things, it created the burden of a separate protocol, two sets of documentation, and additional packet header space. Mark Baugher expands on the issue, implosion and scalability. At this point it might make sense to keep rekey as a separated entity under KM – Key Management.
Discussion from the floor suggested an inclination that rekey work should fall under the WG's Architecture/Functionalities document category. The group is aware that "swirling" rekey may adversely impact development of GODI. Membership will comment further on the mailing list.
Back channel was another issue raised during the presentation that requires further attention. Likewise, Brian Coan brings up from the floor the issue of Reliable Multicast over TCP.
MIKEY (F. Lindholm/E. Carrara)
------------------------------
MMUSIC wants it done by Mar 2002 for a WG last-call (chair Colin Perkins)
Baugher: We can separate into various issues.
Security issues will be discussed in MSEC in more detail
SDP, RTSP issues can go on independently in MMUSIC
GDOI might also be able to ship keys using SDP, RTSP etc.
Another person (?) mentioned that he has a fourth key establishment scheme in mind. Will write an I-D and post to the mailing list.
The chair (Thomas) had no problem. MIKEY authors had no problem, but they want to see the I-D and the discussion in the mailing list.
GDOI Implementation (B. Weis)
-----------------------------
port 500 SHOULD not to be changed to MUST not
Lakshminath mentioned and Thomas seconded.
Presented deltas from 01
IANA considerations for payloads
Security issues brought up by Cathy Meadows (during presentation) being addressed.
A man in the middle attack in real-time.
Dishonest member problem (could send a bogus rekey message).
Could send a rekey message as N_i and get it signed by GCKS.
Resolve this by a) proposal to use a different algm for Reg and rekey b) bounding the nonce size and rekey message size
Cathy proposes a redefined POP payload
Conclusion: Bring the discussion to the mailing list!
Interop:
two implementations
Nortel's based on FreeSWAN on Linux (Lakshminath)
Cisco's based on isakmpd on Linux (Brian)
GDOI Registration protocol interoperates!
Brian went further:
and implemented SA downloads and IPsec testing
and SRTP as data security protocol
Discussion: Last call for GDOI
------------------------------
Last call (5th version including SMuG versions)
- Security analysis done (Cathy Meadows)
- Two interoperating implementations
- Testing shows GDOI creates IPsec and SRTP SAs properly
Mark: Ran had issues with rekey being up in the air
Brian and Mark disagree with Ran
Mark proposes removing: AMESP, LKH, SRTP support and so on (from GDOI draft)
We could keep SRTP in. There are important apps without the need for LKH.
Thomas: GDOI is more or less done. Having a last call does not preclude new additions or corrections (ie. old RFCs can be deprecated)
Lakshminath: Does GDOI propose support for only small scale groups?
Mark: We will support large scale groups.
Lakshminath: Proposed a discussion in the mailing list.
Thomas: Last call ending two weeks into January (Jan 18th).
There were no objections.
isakmpd implementation will be released later next year.
Thomas noted that Rekey issue is complicated!
Thomas mentioned that we need definitive and quick resolution.
Lakshminath mentioned that in the interest of progress he supports the last call discussion. He agreed with Ran's observation that rekey protocol is up in the air.
It was noted that rekey protocol has a lot of baggage:
-- reliability
-- splitting a rekey message in case of batch rekeying or group initialization
-- key tree management
-- detailed documents on LKH, OFT etc., to support interoperability
It was more or less agreed that rekey protocol work should not hinder GDOI going forward! To be discussed in the mailing list as noted earlier.
Meeting Closed
---------------------------------------------------------------------------------------
Slides
Group Domain of Interpretation (GDOI)
Rekey protocol
MIKEY: Multimedia Internet KEYing
Group key management architecture
MSEC Status Review