Minutes of MSEC WG Meeting, IETF50, Minneapolis (March 19, 2001) ---------------------------------------------------------------- Chairs: Thomas Hardjono & Ran Canetti (NOTE: All slides are at www.securemulticast.org/msec-meetings.htm) (1) Thomas – opening and agenda bashing (none) (2) Ran – MSEC Charter discussions o Draft presented at BOF, o Discussions on list during January, o Updated posted to list and presented today Question from the floor: Is it any more complicated to cover both multi-source and single source multicast as opposed to just single source? - Ran: MSEC is keeping in mind multi-source, but will start with single source as the basis. - Kent: believes multi-source is more difficult and starting with single-source is appropriate Question from the floor: what is goal of group membership? Information cannot be protected once distributed to group. - Thomas and Ran acknowledge re-distribution problem and said that it is out of scope for MSEC (3) Group & Multicast Security Architecture – Mark Baugher o Based on work from SMuG o Goal is to base on work of RFC2401 IPsec architecture o Address security at both network layer and application layer o Focus on centralized designs o Differences from SMuG framework – move policy outside of area of interest and leverage IPSP and Policy WG Comments from the floor: - Harney: notes that some of the current proposals due handle distributed design and suggests we keep in it MSEC definition. We should not exclude it. - Ran: restated that architecture should not exclude distributed design. - Hardjono: suggested SMuG finish its distributed work by the end of this year to feed into MSEC (4) Group GDOI – Brian Weis o Two independent implementations underway o Security of protocol under evaluation by NRL Question from the floor: Is this a compromise between IKE and multicast? It seems that worst of both worlds. What was the motivation? - Brian: felt this was cleaner from system perspective. - Hilarie Orman: Why have two keys for authorization/authentication? Can you use key for POP in Phase 1? - Brian: we did not want to affect IKE Phase 1 (5) Group GDOI Analysis – Catherine Meadows o Using NRL protocol analyzer - forces you to write requirements of protocol - forces you to write a protocol specification o State an insecure state, and protocol analyzer determines if it can be reached o Just the statement of requirements results in two improvements to the GDOI protocol: one to proof-of-possession and one to sequence number checking. Questions: none (6) GSAKMP – Hugh Harney o Described distinction between peer policy and group policy o Groups have more indirections o GSAKMP is a layer on top of other protocols – runs over existing peer associations (e.g., IKE, TLS ) o Highlighted ability to distribute GCKS as part of the base protocol/system Questions: none (7) Multicast Data Security Transforms – Ran Canetti o Parallel to ESP o Add source authentication in addition to group authentication o Two identical transforms – one for transport/application, one for IP layer o Each provides all three security mechanisms o IP layer – MESP – multicast ESP o Application layer – AMESP – Application multicast ESP o MESP – add optional "internal" authentication Questions: none (9) TESLA – Ran Canetti o One method for source authentication o Designed for lossy channels Comments from the floor: TESLA seems appropriate for RM and in particular RTP. There is a secure RTP draft, but it does not cover source authentication - Ran: noted that GDOI and GSAKMP could be enhanced to provide time synchronization during SA 1 registration to support TESLA over SA3. (10) Close meeting (Thomas Hardjono) - The site www.securemulticast.org for both IRTF SMuG and IETF MSEC