IPsecME WG Monday, November 5, 2012, 1740-1940 Minutes stuckee: Carl Wallace Easiest way to get slides: http://www.ietf.org/proceedings/85/ipsecme.html Blue sheets, agenda -- 2 mins ****************************************************************************************** WG status -- 5 mins draft-ietf-ipsecme-ad-vpn-problem ECDSA design team ****************************************************************************************** draft-ietf-ipsecme-ad-vpn-problem went through WG last call. New draft is needed based on the comments. New draft will be produced soon. Folks who commented before should review new draft; a full WG last call may not be conducted. Lou Berger: Is interested in gateway-to-gateway implications. Is concerned that issue is not understood from routing perspective. Steve Hanna: Not at point for proposed solutions. Lou: Sees failure to take routing issues into account. Dynamic connection of end points is not fully discussed. Paul Hoffman: Why is that under problem statement? Lou: The fact that problems exist should be covered. Referenced requirement 3 or 4 and notes OSPF doesn't work that way. Steve: Happy to talk about the issue further. Lou: Mainly after plan for addressing it. Paul: Plan was for last call, but input from routing community is welcome and could be factored in before IETF last call. Paul asks Lou to solicit other routing folks to review the draft. Lou: Will review next revision and provide input. Paul: Requests Lou to review current revision. If nothing is heard from Lou they will go to last call. Lou: Will send to routing director and seek other folks to review. Tero Kivinen: Agrees there are some routing issues. Thinks new version with new terminology will make it easier to identity routing issues. Paul: WG will not rush review of the next revision. Wants two things: previous commenters should review and comment; routing folks should review and comment. ECDSA Design team report had two parts: rational for recommendation and protocol proposal. A new Internet-Draft will be produced. Comments are sought now before the first version. Anticipates only a few versions will be required. First draft should appear within a few weeks. ****************************************************************************************** draft-kivinen-ipsecme-oob-pubkey -- 15 mins Motivations Description of problem that is being solved Question about whether this updated 5996 to replace RSA raw key format ****************************************************************************************** Tero presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-ipsecme-0.pdf). Paul: Does anyone know of usage of RSA raw key format? None identified. Will ask on the list. If no usage is identified, old format will be obsoleted. Procedurally, it is not a WG document. It will be discussed on list but not consensus Daniel Migault: Paul: Will ask on the list. Doc will go though IETF last call since it is standards track. Sheila (Frankel?): Suggests both formats not be allowed. Yaron from jabber: Unhappy with this being individual since it obsoletes old format. Two threads on list: obsolete format; whether to have as WG doc Michael Richardson: Asks why not just adopt it. Paul: Needs to re-charter to adopt it. ****************************************************************************************** draft-mcgrew-ipsec-me-esp-ah-reqts -- 15 mins Motivations Description of problem that is being solved ****************************************************************************************** David McGrew presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-ipsecme-5.pdf). How is AES better than TDES? Faster, sure. Security-wise? Key size and block size. Sent note to mailing list today with link to paper with some analysis. Yoav Nir: HMAC-MD5 is twice as fast as HMAC-SHA1. AES-GMAC is faster still. Based on personal timing data. Slides complete. Yoav: Algorithm diversity. All of recommendations here are based on AES. Should be looking for another algorithm with TDES as backup until 2019. Dave: Suggests this warrants IETF-wide discussion. Paul: At least a SAAG level thing. May or may not need research. Dave: Suggests that effort should not hold up this work. Michael: Agrees with Yoav. What does it mean to say MAY? Implementors will read this doc. Second group to read it, procurement folks. Not sure what MAY means to them. Thinks it is not useful for this type of person. Cryptographers are another group who will read. Is concerned MAY for vanity cipher 24 may misdirect efforts. Tero: Thinks MAY+ should be used. Paul: Things listed before should be MAY or SHOULD NOT. MAY is a placeholder. Tero: SHA2 is something to look into implementing. Dave: What about algorithms not mentioned in the document? Early draft did not have HMAC SHA2. Will be flexible on including algorithms. Tero: This should be a WG item and should not require re-chartering since it is a maintenance item. Yoav (channeling Paul Wouters): People don't follow MUST/SHOULD let alone +/- Tero: Helpful when presenting implementation details to mgmt. ?: AES-XCBC-MAC-96 is useful as cipher-based MAC for diversity. Dave: GMAC meets requirement and performs better. ?: Would like SHOULD chnaged to SHOULD+. Daniel: Another group of readers are folks who configure IPSec. Should note how secure and how efficient the different options are. Dave: Someone could look at performance specs for dedicated hardware. Is software more of interest? Yoav (channeling Yaron): Would like sense of room regarding Yoav's proposal to have another algorithm for encryption. Paul: Calls for a hum. Who believes backup other than TDES: some hum. Who does not support: some hum. Inconclusive. Hums on both sides. Will take this to mailing list and consider whether or not this is a WG document on the list. Tero (channeling jabber): There were more hums and support for Camelia. ****************************************************************************************** draft-zhang-ipsecme-multi-path-ipsec -- 15 mins Motivations Description of problem that is being solved ****************************************************************************************** Will Liu presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-ipsecme-6.pdf). Dan Harkins: Are you breaking security of scheme if using counter? Tero: Answered Dan's question regarding how counters work. Dan: Missed that. Tero: Does not add reliability, actually reduces it. Does not think there is anything useful here. Daniel: How can you ? If you have several gateways, how do you get all IP addresses. Michael: So, if you remove the sequence number stuff, and you simply make sure that you do what most routing gear does anyone by keeping single flow you don't have any reordering issues. If you remove that, no changes on receiver. In IKEv2, multiple chile SAs can be negotiated so becomes local question for which link to use for performance reasons. Ignoring more secure etc and focuses on bandwidth. Only thing remaining is liveness check since as Tero notes you lose some packets otherwise. If you want to do this you can do so without a standard action and can be done using routing part of gateway splitting things up. David: Re: security to splitting traffic, there's no improvement to security in splitting the traffic. Though it may provide some protection against traffic analysis. Limited protection. This relies on assumption that attacker cannot observe both flows. Better approaches include breaking plaintext into fixed length blocks. Paul: You need to better justify some of these techniques. Is there interest in this being a WG document? None seen on list yet. ****************************************************************************************** draft-harkins-ikev3 and draft-kivinen-ipsecme-ikev2-minimal -- 15 mins each Motivations Description of problem that is being solved ****************************************************************************************** Dan Harkins presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-ipsecme-7.pdf). Tero Kivinen presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-ipsecme-1.pdf). Derek Atkins: Dan, how do you propose having a VPN client if the user can't have a password because you don't have EAP? Lots of vendors are interested in VPN suck. ?: Passwords suck. Derek: Passwords may suck but will remain in use. Dan: If you are using AD type thing, you can use hash of hash of a password. Can only work with that kind of controller. Won't work for everything. Derek: Will be a problme in general. Likes Tero's proposal. Yoav (channling Paul Wouters): How to deal with deleting IPsec SA's and how do you setup multiple tunnels per end point if you kill off IKE SA when one IPsec SA is up? Dan: Another layer handles it, not key exchange layer (re: deleting SA). For multiple tunnels with same peer, you do multiple IKE exchanges. Paul H.: Feels like early JFK mechanism in early IKEv2 discussions. Yoav: Learn from experience of IPSec and TLS, lots of years until things get implemented all over. If we standardize IKEv3 now, may see implementations in 2020. Better to fix IKEv2? Dan: Fixing IKEv2 involves grafting more and more stuff on there and does not see why it would take 8 years to standardize IKEv3. IKEv2 did not learn from IKEv1. Sheila: It did learn from IKEv1 in that number of documents went down. What do you gain if you must implement features somewhere else? Dan: Doesn't think things implemented elsewhere are the business of key mgmt. Brian Weis: IKEv3 idea is interesting. Fresh way of looking at it but does not see it replacing IKEv2. May apply to constrained environments. Paul H: Compare that with Tero's for internet of things. Same for constrained env. Brian: Minimal IKEv2 is probably more likely to be done as vendor. Tero: Need SA management. Thinks punting to another layer is a big mistake. In most cases, minimal spec would be full IKE because many features keep getting added. Paul: Dan has two peers vs Tero approach involving initiator. Dan: Many assumptions left to implementors, and assumptions were different. IKEv3 would remove those assumptions. Defining things properly is the aim. Daniel: IKEv3 is probably simpler than IKEv2. How can you be sure extensions don't change this? Dan: I don't know. Individual submission he can control. WG could create Frankenstein version. Paul: Do you have an anti-extension mechanism? Daniel: Compared to MOBIKE? Derek: 22k lines of C code for IKEv2. Full implementation. For simplification, take IKEv2 and write as a state machine. Would be easier to reframe the protocol as it exists. Sees no security issues. Yes or no? Dan: Also does not see security issue, but does see weird parts. Derek: So writing as a state machine could provide clarity without removing useful bits that are being used in the field. Reframe as easier to think about as state machine to ensure correctness. Dan: That's an interesting idea that was considered but discarded because all of the weird parts make it difficult to know what state you will wind up in. Nightmare to define state machine. Paul: List discussion will ensue. Tero's draft is being discussed in LWIG. ****************************************************************************************** draft-mglt-mif-security-requirements -- 10 mins Introduction and where to follow up ****************************************************************************************** Daniel Migault presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-ipsecme-4.pdf). Michael: Two questions: are you biased towards solving this for v4 or v6? Daniel: No specification on whether v4 or v6 Michael: Multihomed is a festering wound. Needs to be solved though some attempts. Some of that stuff may work for this situation for v6. Would not do anything for v4. Other question relates to whether you are trying to do, why is it you want to have 3 SAs up with different inner addresses via 3 SAs up that can carry traffic for some set? Daniel: You mean you want all inner addresses to be the same? Michael: Let's say they're not the same. Is it desirable that the packet to IF 3 goes through IF1? Is that a goal. Daniel: Yes. Michael: This violates SPD concept. Paul: Hence it being discussed here. Michael: Thinks inner addresses will not vary for v6 not sure about v4. Will take to MIF per Paul's request. Tero: SPD can be per interface. Are you going to try to use 1 IKE SA. Would it be possible to create multiple IKE SAs, one for each interface. Could just use MOBIKE to move IP addresses. Paul: We've gone done the rabbit hole, take it up on the mailing list. Michael: Procedurally, the reqs doc goes to MIF and sends back to here. Paul: Not necessarily. Process is not clear. ****************************************************************************************** draft-gont-opsec-vpn-leakages -- 10 mins Introduction and where to follow up ****************************************************************************************** Fernando Gont presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-ipsecme-9.pdf). As title indicates, draft primarily targeted to opsec. Will be discussed during opsec slot on Friday. Paul: Read the document, show up on Friday. ****************************************************************************************** draft-ietf-ipsecme-ike-tcp -- 15 mins Status report Open issues Next steps ****************************************************************************************** Yoav Nir presented slides (http://www.ietf.org/proceedings/85/slides/slides-85-ipsecme-3.pdf). Tero: We need to deal with NATs consistently.