=========================================== 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. Martin Euchner 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 ---------------------------------------------------------------------------------------