Lakshminath 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, particularly XCON working group
scenarios). 

Lakshminath presented a strawman design of MIKEYv2, with a reference to
the requirements work being done at the 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 usually 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.