MSEC minutes, IETF-70, Vancouver, Canada, November 2007 Minute Taker: Vincent Roca (vincent.roca@inrialpes.fr) ======================================================================== Agendas and slides can be found at URL: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=70 ======================================================================== MSEC WG (L. Dondeti) December 5th, 2007 ======================================= Using Counter Modes with ESP and AH to Protect Group Traffic (draft-ietf-msec-ipsec-group-counter-modes-01), Brian Weis ------------------------------------------------------------ This document explains how to partition the IV value in case of multiple senders in order to make sure that none of them use the same IV (with the same key) over the time. This coordination relies on a split of the IV field into two sub-fields, one that contains a unique sender identifier (SID), value allocated by the GCKS, and a sender specific IV (SSIV), allocated locally by each sender. When a sender is about to exhaust its SSIV space, the GCKS assigns new SAs. Brian: should we start a WGLC? Lakshminath: yes Updates to the GDOI (draft-ietf-msec-gdoi-update-03), Sheela Rowles ------------------------------------------------------------------- This document introduces several updates to the GDOI protocol: it clarifies some points in the original RFC 3547), discusses cryptographic algorithm agility, and it introduces several new attributes. In particular, one of these attributes, SENDER_ID, enables the use of AES counter modes with multiple senders (see draft-ietf-msec-ipsec-group-counter-modes-01.txt). The presentation describes how to generate session level unique Sender IDs (SID). Sheela: should we start a WGLC? Lakshminath: yes GDOI Key Establishment for the SRTP Data Security Protocol (draft-ietf-msec-gdoi-srtp-01.txt), Sheela Rowles ---------------------------------------------------------- This document explains how to establish a shared group key with GDOI in SRTP sessions. This is particularly useful with multicast flows where all the receivers of the SRTM session must share the SRTP master key to decrypt and authenticate messages. In this version, several text clarifications have been made. A few on-going issues need to be fixed: - pros/cons of use of distributed vs. centralized approach; - make SRTP SA TEK SRC optional; Lakshminath: we should involve the AVT group in this discussion. - IANA issues: should we add a GDOI-SRTP registry? Lakshminath: this question needs to be sent to the list TESLA for ALC/NORM (draft-ietf-msec-tesla-for-alc-norm-03.txt), Vincent Roca ---------------------------------------------------------------------------- Vincent quickly reminds the main changes made in previous version 02 (July 07). The fact that in some circumstances no key is disclosed does not compromise robustness in front of erasures since any key can be used to compute the previously disclosed keys. The current version 03 does not provide any new feature but rather text clarification and an error correction. An implementation is under progress and is currently used to proof-check the document. Some preliminary performance results show that TESLA and Group MAC have very similar performance at the sender (and perform several orders of magnitude faster than a digital signature scheme which is well known result). Lakshminath: is the document ready for WGLC? Vincent: it is wiser to wait until this implementation is finished before starting a WGLC. Group security model for RSVP message authentication (draft-weis-gdoi-for-rsvp-00), Brian Weis ---------------------------------------------------- This document introduces the policy required for the GDOI [RFC3547] group key management system to distribute security policy and keying material for the RSVP resource reservation protocol. More precisely, RSVP includes an authentication mechanism that can be used to provide hop-by-hop sender authentication and message integrity for the RSVP messages. Within a given trust domain (intra-domain), using manual pair-wise keying leads to serious limitations because of the possibility of multiple paths. Using group keys with a dynamic group key management (GDOI) is more attractive. This document describes several updates that allow GDOI to be used in this context. XXX: ? Francois Le Faucheur: explains where this situation comes from. Essentially, it's quite difficult to set up in real world. Lakshminath: What is exactly the problem we want to solve here? Brian: ? Brian: Should this work be supported by MSEC? Tim Polk: Since there is a dependency between this document and the draft-behringer-tsvwg-rsvp-security-groupkeying-01 document, he suggests to wait that the work go forward, otherwise it does not make sense to work on it in MSEC. Lakshminath: continue this discussion offline and do a report to the group Achieving Local Availability of Group SA (), Ya Liu ---------------------------------------------------- (draft-liu-ospfv3-automated-keying-req) (draft-ietf-pim-sm-linklocal) This document introduces the possibility to have automated group keying for OSPF and PIM-SM, using a group key management protocol (GKM). The difficulty is that GKM rely on a client-server model, which implies that the server must be reachable, which is not necessarily the case until OSPF has been initialized => chicken and egg problem. Several solutions exist, like: - locally deploying a GCKS (no extension needed); - separating GC/KS and locally deploying KS while centrally deploying the GC; - locally deploying delegates, centrally deploying GCKS; One solution should be chosen. Bill Atwood: PIM and OSPF both try to do the same thing => makes sense for MSEC to do the job. It's probably the right place. Lakshminath: is the underlying method already available, and is it just a matter of exchanging the keys? Bill Atwood: yes Tim Polk: OSPF and PIM working groups don't have the expertise needed to work on this solution, none of them will come up with a solution. MSEC is a good place to have the two teams collaborate and make progress. Lakshminath: if the problem is to find a SA it's okay. Tim Polk: ??? Lakshminath: Go to the mailing list and explain what is needed.