MSEC meeting minutes Minute taker: Sheela Rowles =========================== Documentation status -------------------- * One RFC published; * Three active drafts remaining. - draft-ietf-msec-tesla-for-alc-norm in working group last call; appears ready to go on. Tim Polk: there needs to be a proto write-up, information that other Ads want to see about consensus in the WG. Tim to send Brian an email on this. - draft-ietf-msec-ipsec-group-counter-modes in the same position; Brian will coordinate with Lakshminath. Tim: if Lakshminath unavailable, can find someone else. - GDOI update draft; Sheela to present on that, and hopefully will go to last call. * No current WG items at the moment. There are some proposed work items. Tim: in favor of keeping WG open, since there are things that need to be done. ItÕs a good plan to re-charter by Stockholm. Start on the list. draft-ietf-msec-gdoi-update-04 Sheela Rowles ------------------------------ Sheela described the changes to the newest GDOI update draft. The document has been reorganized somewhat. There are two major changes: one is that the KE payload is deprecated, and the other is the addition of the Group Associated Policy payload to pass some of the new policy attributed defined in RFC 5374 and draft-ietf-msec-ipsec-group-counter-modes. The draft appears ready for working group last call. Jianqing Zhang asked if there interest in revising GDOI to work with IKEv2. Sheela relied that there is an expired MSEC I-D that began to specify implementing GDOI as a modification to IKEv2, but there hasn't been sufficient need to continue that work. Jianqing noted that it would be more efficient since IKEv2 does not have the two phases of IKEv1. David McGrew asked if IKEv2 added any new compelling features, such as integration with EAP? Brian answered that there don't appear to be any compelling features for GDOI, and given that MSEC has produced three group key management protocols already there would need to be a compelling reason to do yet another. Brian asked if there were volunteers to review this draft, and four hands were raised. He will ask Lakshminath to send it out for working group last call. GDOI MIB Sheela Rowles ------------- Sheela the need for a GDOI MIB, and presented some of the items that would go into one. She asked if this as a reasonable item for the working group to take one, and noted that there were no standardized IKE or IPsec MIBs, which are in the same problem space as GDOI. Tim indicated a concern for taking on this work. The security area has not been successful in completing a MIB, and there are no experts on MIBs in the area. To do this work you would need the assistance of the MIB doctors. Tim asked where the need for a GDOI MIB came from? Sheela replied that it was from internal feedback. Tim asked if anyone else felt a MIB was needed? Jianqing indicated an interest. He also said that multiple groups would be useful in the MIB. Bill Atwood suggested that if anything like a distributed KS was part of KMART work, multiple groups would be very useful. The decision was to take the question to the list to see if there was any support for this item. Using the SEED Cipher Algorithm with MIKEY Seokung Yoon ------------------------------------------ The motivation for this work is that VoIP is more popular and the prediction is the VoIP market could grow to as much as $10 billion. The SEED Cipher Alg developed by KISA (Korean Information Security Agency) in 1999. The SEED with SRTP defines 3 modes of running SEED. For the SEED to be used with MIKEY new values need to be added to security policy. Brian asked if this draft only adding values to namespaces Š no other protocol changes? Seokung said that was correct. This is a very simple draft Š David McGrew asked about SDP security descriptions -- this draft is only an update to MIKEY and not SDP security descriptions? What is the motivation? Seokung said that we need 3 modes in the MIKEY. David: you said you implemented SDP sec desc for the SEED, but its not included in the draft. Is this intentional? Do you plan to use any standards work to explain SDP SEED or is this future work? Seokung replied that was a different WG, and he didnÕt know where he could put that information, so he only mentioned MIKEY. Tim: the parameters for MIKEY are IETF consensus so doesn not have to be WG Most of the SDP code points only require "specification required" status. If you have a published spec somewhere, you could get the code points. There's a RFC which says how to do the registration. ItÕs not required that this goes through the WG. Brian: What's the alternative? Tim: AD sponsored document. Informational; it would be an IETF last call, but not a WG last call. If this group opposes the document, I wouldnÕt take it on. Brian: is anyone opposed to taking this on? Tim: anyone willing to review? David: should clarify SEED; what about ARIA? Those both seem to be the national ciphers of the republic of Korea . Are there really two? Seokung: SEED is developed for national use. ARIA is the next SEED. ARIA is for govt use only, and SEED is for the public market. Richard Graveman: There are already three security standards for the update of SEED. Not adopting SEED here would be inconsistent with past work -- unless itÕs determined that there is cryptanalysis saying this isnÕt the right thing to do. Brian: We could take this on as a WG item, but it is not really likely to change. Is it better for the authors to have an AD sponsor it? Tim: either 2 week or 4 week IETF last call. You need to decide to take this on or not. You may have to recharter, which isnÕt really necessary. Send an email to this WG so those not on IETF can review, since expertise is really here. No compelling reason for it to go through this WG. Brian: THe proposal is that Tim will take this as an informational, as an AD-sponsored draft. Tim: And will Brian shepherd this? Brian: I'd prefer a MIKEY expert to help with this. Richard Grave: All 3 SEED documents are proposed standards. So this shouldnÕt be Informational. Tim: Either way, itÕll be AD sponsored. KMART Discussion Working Group ---------------- Brian presented a few slides introducing draft-lebovitz-kmart-roadmap-01 while we wait for Gregory to join us. He pointed out that it covers some group security scenarios, and and asked members of the working group to consider commenting on the draft Tim: Struggling to figure out what is right approach to key management for routing protocols. What is the right overall direction and what should the priorities be? In Dublin, routing ADs, security ADs, and some IAB members worked on a roadmap for key management for routing protocols. WeÕre here because the security area is guilty of providing gold-plating solutions, and they are a great leap forward to the routing protocols. The routing protocols are quite happy with just using authentication tags (as TCP-MD5 is used today). This document is only on its second round. ItÕs not just ADs talking to each other, they're talking to the community about this. There is a KMART, not-WG email list. We believe routing protocols need to have crypto agility, have key identifiers, but not inline key negotiation, have to be able to use preshared keys, but seamless when not using preshared keys. For group security, preshared keys, but in most cases, itÕs point to point protocols. Richard Graveman: These protocols donÕt use confidentiality (I seem to be in minority in thinking that they could use it) Operational considerations define the threat model. The biggest problem is integrity & authentication. but saying they donÕt need confidentiality offends me. Brian: A number of protocols have defined the use of IPsec, which means they could use confidentiality if necessary. Richard: IPsec is not the issue here. Richard: The document completely ignores IPv6; I.e., it says OSPF without saying saying OSPFv2 or V3. The process baffles me. I read the guidelines for AD submission; itÕs a plan for a bunch of work, but this doesnÕt fit in the exceptions. Richard: There was some relevant work in the OPsec group. Tim: Why the draft is an individual submission Š it doesnÕt fit into any one group. It didnÕt qualify as an IAB or IESG draft. Who knows where this document goes correctly. Let me know if we violated the process Š but it isnÕt intentional if so. It doesnÕt have one home which is the reason we couldnÕt get the work off the ground. Richard: I appreciate the difficulties. It is a real problem and it needs to be solved. IÕm 100% behind this. Dan Harkins: This draft is solving problem of integrity. KMART needs to say what exactly what are the problems. Routing people are not convinced that IGPs need to be secured. They donÕt care about using plaintext passwords. Say what the problem is, so we can explain the solution. Tim: All the TCP-AO work is trying to fix the static key problem, and provide the crypto agility. WeÕve spent a lot of time talking to people from OPs area. If operators still say we wonÕt do it, we need to do more. There is a real impediment making people see that they should want more; if we make it hard for them it wonÕt happen. Craig J: IÕve been working in medium size enterprises Š telling customers they need more security. People are willing to go that way. If we can give them migration information. We need to make this digestible by vendors with best practices. Thomas Hardjono: IÕm for available options. This problem is 10 years old now. This is all about cost now, right? Tim: Big routing vendors are on board. We in the security area are always looking for perfect security. We need to provide more deployable situations. Brian: We have routing people & security people in MSEC to help improve the base security. Need to focus on automated key management. Tim:this is where the group keying should happen. The right expertise is in this group. I would not be opposed to a rechartering to address this. Brian: I would like to get some commitment, that they will actively work on this. We have been low on commitment. Tim: hopefully this will create new interest. There are two choices: either re-charter or shut down since there is only 1 active document. Richard Grave: draft-liu-ospfv3-automated-keying-req-01 is badly expired. RSVP and OSPFv3 that can fundamentally benefit from group keying. There have been a number of drafts that have come and gone on those topics, and theyÕve never latched on and taken hold. Brian: should we resurrect these drafts? Mike Barnes: IÕm one of the routing people. With regards to the OSPF draft, it was in the RPsec WG, which closed. Work definitely needs to continue and maybe this would be a good group to take this on. If we could devise some mechanism where people donÕt need to become security experts, this would be useful. Craig: This group can be valuable. I would be very cautious to have this group drive protocol development and hence the misunderstanding from the routing people. The problem needs to come before the solutions. Brian: we are never going to do routing protocols but we can be involved in helping out with requirements. Tim: We wonÕt drive the routing protocols. The whole idea of the roadmap is to bring together the 2 pieces of the puzzle. Gregory: There are a couple of things to think about. This work is consuming and very complicated and many little debates. If youÕre not careful, it becomes a DoS attack on the WG. This happened in TCPM work. The work in TCP-AO took up so much time that other work couldnÕt go on. So we can put this work in a WG, which is about to shut down Tim: This is a good place to do the group-keying piece and thereÕs a lot of expertise here. Gregory: OSPF, ISIS, and RIP all have modes where they donÕt behave like group keying, and behave like p2p, or a virtual link. So when we write a document, the document around these 3 needs to have the group, p2p, and virtual. So is MSEC the right place for this? Brian: A group doesnÕt have to be 3 or more. It is possible to deploy pairwise & group with the same security characteristics. It's reasonable to have a protocol with one method handle both. It may be more advantageous to have 2 different methods for these for other reasons (security). Gregory: Another idea Š close MSEC Š we spin up a KMART for group keying, invite the applicable routiing people. Brian: Either way we would invite the right routing people. Also we have history of doing pairwise work here (for better or worse). Tim: I donÕt believe itÕs necessary to close the WG and restart another one. This is a re-charter that the community will know about Š it wonÕt be a minor re-charter. MSEC can just expand its charter. Brian: The issue about group & pairwise needs to be explicitly mentioned in the new charter. Gregory: BoF gets a lot more attention than a recharter. If we treated it like a whole new thing, there would be a lot of fanfare and attention. Or we can recharter and encourage the fanfare. Craig: there is lower risk as a re-charter. OSPR, ISIS, and RIP are unicast mechanism; need to investigate whether same original Gregory: The original slides for KMART are under the RTGarea WG meeting materials. A pointer to them is on the KMART Discussion slides presented here.