Subject: [MSEC] [Fwd: MSEC meeting minutes]

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 04 Jan 2008 17:05:44 -0800

Hi all,

Enclosed are the minutes of the Vancouver meeting from Vincent.  Please 
review and suggest corrections ASAP.  I plan to forward them to the 
secretariat on Monday.

thanks,
Lakshminath
		MSEC minutes, IETF-70, Vancouver, Canada, November 2007

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

_______________________________________________
MSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/msec