IETF-65 MSEC meeting Mar 21, 2006 Minutes taken by: Lakshminath Dondeti GDOI Update ----------- Three purposes: clarifications, algm agility and security fix (Cathy Meadows's MiTM attack on POP signing) We'll have a 3547bis, it seems like. Ran: Is algm selection consistent (or inherited) between phases? Sheela: Yes that's correct. Some changes to SEQ numbers. SEQ =0 for Phase 1 and SEQ = 1 for Phase 2 and reset to 1 after rekey There was a note about key derivation and a mixing function Russ: For key delivery, do you plan to use AES-KW? Because, if the thing that's encrypted is bigger than a block there's a problem Brian lists the KEK algorithm choices in 3547. KW is not currently a choice. * On the Meadows attack Fixes for MiTM on POP signing have been added. The solution is different from that proposed in Cathy's paper. There are two parts to the proposed solution: The first is a membership policy check and the second is a modified POP construction. Lakshminath: Why is this different from what's in Cathy's paper? Brian: To keep things consistent with the original signature structure. Lakshminath (as co-chair): Req: Please get this reviewed by Cathy. Of course others should review too. * Adding AH support. Lakshminath: Why is this needed? Brian: PIM says AH is a MUST and recall that we use transport mode Lakshminath (as co-chair): Check on the PIM requirement, especially to see if there are plans to change it etc. GKDP: ----- update from Lakshminath: Made some effort to finish the work with author conf calls etc., but was still unable to make significant progress (fewer cycles for this for Lakshminath) Sheela provides an update on Rekey protocol specification and Delete message specification. The authors to make a more concerted effort to meet the July deadline. MSEC IPsec extensions: ---------------------- Scoping issues have been resolved. Additions to 4301: SA directionality. Defining roles of the group members: sender, GCKS and receiver/member Lakshminath: Does key management need to speak about this? Is this a MUST? Why is it *needed? and why can't we say SHOULD. The reference to composite groups came up. Russ notes: I hope not! Lakshminath thinks that this should be a mailing list discussion. The next issue is when to take this IPSEC mailing list Conclusion: Resolve open issues: AH and directionality Do a quick revision and send to IPSEC list for review. Russ: Thanks to the authors for following up on my request. MIKEY extensions: ----------------- This draft describes the various MIKEY modes and use cases. Use cases work is pending still and Steffen requests folks to send their use cases. * No objections to making this a WG item at the meeting. We'll ask the question on the list and confirm. Ran: post this to RAI, AVT and MMUSIC. MIKEY-SAML: ----------- What's next on this? We need to see the draft on what's involved Bob M notes that if there is interest, will work on a draft. Lakshminath: we need to see why this is better than MIKEY-DH; We realize that this talks about operational details etc. anyway, encouraging Bob to write the spec to flesh out the details. ALC/NORM-TESLA: --------------- Brian Q: Is this like SRTP-TESLA and IPsec-TESLA? Ran: Yes Q: any objection to do the work here Vincent notes that RMT has consensus. ToDo: Check with RMT WG Check on the list for any objections