Subject: [MSEC] Draft minutes, thanks to Brian Weis

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 13 Jul 2006 10:11:44 -0700

Folks,

Please review the minutes below.  I plan to upload them on Monday 
evening Pacific TZ.

Thanks again to Brian Weis for taking the minutes.

regards,
Lakshminath

++++++++++

Laksminath presented an overview of the working group status, including the
list of RFCs recently published and work in progress.

Russ asked about the TESLA document organization. There used to be seperate
documents describing the TELSA protocol description, and one applying it to
IPsec, whereas now they have been combined in one draft. He suggested
returning to the original organization, where the TELSA protocol description
is an Informational document, and the IPsec one a Standards Track document.

The hash function agility analysis has not completed for all MSEC protocols,
in particular MIKEY and GSAKMP.

Vincent Roca presented a draft "The Use of TESLA in the ALC and NORM
Protocols" (draft-ietf-msec-tesla-for-alc-norm-00.txt). This version aims to
be a full TELSA building block in the RMT framewrok, and it proposed new
message formats. George Gross wondered if the this document could share a
generic header with some other work, and there will be a discussion on the
working group mailing list on this topic.

Sheela Rowles presented the draft "Updates to the Group Domain of
Interpretation (GDOI)" (draft-ietf-msec-gdoi-update-00.txt). In Dallas it was
pointed out that we used he key wrong, and David Mcgrew pointed
out a better way. Now if PFS is used in GDOI, the draft uses a NIST derived
key derivation function to choose a key from the Diffie-Hellman 
shared secret.  Also, more text was added regarding authorization. 
This is to  mitigate the
Meadow/Pavolvic attack.  The mitigation method differes whether or not the
GDOI CERT/POP payloads are used.  She also mentioned in that the authors are
planning to incorporate a proposed change to the POP hash computation that
stops the attack altogether. However, the authorization text is still useful
guidance.

Stephan Fries presented the draft "On the applicability of various MIKEY modes
and extensions" (draft-ietf-msec-mikey-applicability-01.txt).  This draft
describes the existing options for key management given in MIKEY as well as
extensions to MIKEY. There have been two versions since last IETF. The authors
feel that the draft is ready for working group last call. Lakshminath asked
for more use cases to be included in the document (e.g., conferencing
scenarios, particularyly XCON working group scenarios).

Lakshminath presented a proposal for using MIKEY to at yesterdays RTPSEC BOF.
There were a number of decision points made in the BOF, but requirements are
ongoing. Until they are complete there is no point in adding more details to
the proposal, but he did describe it a set of slides to give a flavor of what
MIKEY in what media path would look like, see the slides. He also mentioned
that RTPSEC said that group keying was not its first priority because voice
conferencing is usaully point-to-point.

Brian Weis presented "Multicast Extensions to the Security Architecture for
the Internet Protocol (draft-ietf-msec-ipsec-extensions-02.txt). There were
some minor terminology changes, and some changes based on comments posted to
the mailing list. The next version will be sent to the IPsec mailing list for
comments, with a following  draft expected to go go to working group last
call.

George Gross presented his individual submission "Multicast IP Security
Composite Cryptographic Groups" 
(draft-gross-msec-ipsec-composite-group-00.txt).
This work was extracted from the multicast IPsec extensions draft, and it
describes the problem of an IP multicast stream being needing to be sent to
different sub-groups of receivers, where each sub-group has a unique IPsec
policy. For example, if two sets of recievers cannot support the same
cryptographic algorithms but need to receive the same data. George asked the
MSEC working group to take this on, with the target being published as an
Experimental protocol. Both Lakshminath and Brian agreed.

George Gross also discussed some RMT working group security work and its
impact on MSEC protocols. Several RMT protocol building blocks are approaching
final standardization phase but still need to find answers for seom DoS and
message alteration issues.

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