IPsecME WG Thurs morning, 2009-11-12 Minutes taken by Gabriel Montenegro 0900 Agenda bash and start blue sheets and RFID scanning Agenda includes proposed new items. Not for technical discussion. 0905 Brief review of document status 1st RFC! 5685 in RFC editor queue: resumption and IPv6 config IESG review: traffic visibility heuristics: not enough WG reviews chairs pushing for more review, only 2.5 so far roadmap: few open issues, ready to close AES-CTR waiting for next rev and then WGLC IKEv2- bis ongoing ECDH erratum draft slowly progressing IANA registry updates - thanks to Tero announcements: TAHI test event, Jan 25-29, 2010, in Chiba, Japan IPv6 with IPsec, etc QKD Rod Van Meter (Keio Univ), integrating IKE with quantum key distribution ("IPsec with QKD") need more input for informational? will post to IPsecme list 0915 Review of proposed new work items The list of the drafts to be discussed is available at: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/RecharterNov2009 The format for each proposal will be: - Less than 10 minutes presentation of the draft This will cover both technology and why it should be part of the WG. - Less than 5 minutes mic discussion This will cover *only* whether it should be a WG item, not the technical merits of the draft. Document order: EAP-only authentication Yaron Sheffer Failure detection Yoav Nir Childless IKE SA Yoav Nir HA extensions Yoav Nir Password authentication Dan Harkins WESP extensibility Gabriel Montenegro Labelled IPsec Joy Latten Rechartering discussion goal is not to have technical discussion but to gauge interest will continue with poll on the mailing list Hui Deng - China Mobile child-less initiation of the IKE SA simple extension to initial IKE exchange signal support in IKE_SA_INIT in IKE_AUTH intiator does not sen payload related to the child SA leave out lots of stuff... result: authenticated IKE SA, no child SA IKE SA may be used *later* to create a child SA or not why? Remote access pre-create the IKE SA and then as needed child SA created without bugging the user any more (instead of bugging for credentials all the time) 3GPP - physically secure network, just want to authenticate the other side, so no child SA is actuallly needed Location awareness remote access client not to encrypt when in a secure network still want authentication other : monitoring peer liveness via liveness check NAT detection EAP-IKEv2 etc different usages, industries Tero: not interested, current way is enough Steve Kent - location awareness? geopriv seems a more appropriate layer Yaron: not "location" but awareness of the security properties in a given location Steve Kent: this definitely changes also "physically secure networks" does not parse first motivation seems the clearer Michael Richardson: yes, support Yoav: ?? Joe Touch: good idea, Tero's idea that you create it and then delete it is not a good way to go Yoshihiro Ohba: this functionality overlaps with PANA (e.g., used with DSL) Labeled IPsec - Joy Latten RFC2401 provides support MLS and IPsec support for implicit labeling MAC system being used (SELinux) have security contexts and attributes besides the security level these now include attributes beyond MLS (user, role, etc) others: SMACK in Linux and SEBD for FreeBSD Vista: mandatory integrity control - not traditional MLS label MAC on network communications IPSO allowed addition of MLS security context to IP header, but not protected, and MLS specific RFC2401 does support MLS, but they need more generic context extended to more generic labeling implicit labeling scheme using Domain of Interpretation for security context DOI included in SPD security context included in the SA protects label and data binds label to the data IKE communicates this info, does not negotiate implemented in Linux kernel since version 26.16 and ipsec-tools since version 0.7.0 perhaps WESP header could also include security context Greg Daley: suggestion to express it as a traffic selector securing and preserving the various labels across the network will become increasingly important so an explicit labeling scheme is highly desirable Steve Kent: Yes, IPSO was very narrow, so doing more flexible things can't. But CIPSO is fine and flexible enough, I know I wrote the first one. This was removed from RFC2401 since doing it well required too much additional mechanism. Questioning how mainstream really is. We removed it since the vendors told us nobody needed or wanted it, and going back on that would be highly questionable. Ken Grewal: from a usage perspective this is very interesting and may be opportunity for intermediary devices to participate given the right mechanisms. Support it. Paul: Joy, you need to explain better the applicability to the WG. Joy: was not aware that CIPSO would handle more than MLS and the protection. Steve Kent: Yes, we do this in tunnel mode. Tero: We removed things in IKEv2 for a reason and don't want to go back on that. Chairs: to be continued on the mailing list. EAP-only authentication in IKEv2 - Yaron client using certs is har to do. ever server auth requires provisioning trust anchors, etc IKE shared secret not a good alternative and often abused with small passwords EAP-only auth is more practical EAP-AKA - long shared secrets in a SIM card for mutual auth EAP-EKE, EAP-PWD - password currently in IKEv2, even if doing EAP AUTH payload in message 4 so server auth still required goal: eliminate server auth in msg 4 so in msg 3 add client notif EAP_ONLY_AUTHENTICATION and limit to EAP methods that can be used for this purpose: mutual authentication, key generation EAP methods channel binding must authenticate the IKE responder to prevent rogue APs masquerading as VPN gateways beyond above requirements, IKE identity should be crypto-bound into MSK (binding between IKE and EAP layer) important extension to mainstream use (VPN) likely to be adopted as a replacement to insecure PSK use Tero: probably useful to IKEv2. May not be able to ignore the server cert if sent, might lead to problem. Must also clarify which methods can be used here. Paul: should we have an IANA registry for the allowed methods? Pasi: not all EAP methods have IANA entries Yaron: we were thinking of new registry Pasi: wrote this 5 years ago, not much interest back then. It was abandoned cuz if you don't do EAP method channel binding (which nobody does) then even if AAA server is safe, anybody connecting to AAA server can masquerade, so this includes any legal AP. Dan Harkins - on SPSK ( secure PSK) authentication for IKE draft-harkins-spsk-auth currently require PSKs to be hard to remember and error-prone to provision (say, 128 bits of entropy, or 100 character passphrase), but humans have trouble over 12 characters so existing scheme is insecure as PSK in IKEv1 and IKEv2 are subject to dictionary attack (even if using long keys) solution: Zero Knowledge Proof advantage of one bit only available via interaction (not computation) and nothing leaked on passive attacks, so resistant to dictionary attacks discoverable and dealt with secure even for weak PSKs EAP is not a good fit security based on knowing the secret, not knowing someone who knows someone who knows the secret pointless encapsulation both sides have to implement client and server state machines lots of overhead, doubling the number of messages, for no good reasons Steve Kent: enthusiastic about this cuz IPsec is supposed to be peer-to-peer even though many use cases are client-server. The response that detecting an attack and backing off can be used as a DoS, so we must be careful. Greg Lebowitz. IPR? Dan: no patents that I know of. Greg: Routing community would really like to see this, per output from KARP (routing security) as they use PSKs commonly. Not that KARP is currently bent on IKE, but this stands a chance of doing this. Yaron: not a good idea. Adds a full-blown mode into IKEv2. On the other hand, there are EAP methods that are extremely similar to this and is more advanced. Argument that you need the AAA server is not true, most cases VPN gateways have termination of EAP exchange anyways. So continuing with EAP is preferable approach. Michael Richardson: I support this. Tero: support this. Greg: ...step 2 of KARP is layering key management over base manual keying, so at that time we could use IKE, so this could do it all. They child SA would not be for ESP, would be a new type of child SA we'd need to ask IPsecme for eventually. QCD - Yoav - Quick crash discovery for IKEv2 method in RFC4306 takes several minutes (after several liveness tests before giving up) propose a secure method to signal they have lost state based on exchanged tokens based on IKE SPIs liveness check is protected but: there is the SIR competing proposal Pasi: (no hats) I think the last version is elegant and simple, finally, so support it. Tero: not useful work we shouldn't work on protocols that are only used infrequently, just fix the boxes Greg on question to Yoav: is this like the failover stuff? No, this is just an indication to delete the IKE SA itself. Greg supports it. Good for troubleshooting, maintenance, saw some good use cases Rod Van Meter: supportive, but will this result in a storm of reconnects, which results in a huge load at the gateway. Paul: if you're expecting that many you might need hardware crypto anyways. Yaron: this is my favorite draft out of the seven we're seeing. Greg: failover Pasi: became session resump;tion WESP Extensions - Gabriel Steve Kent opposes this unless we have clear options we're interested in. A framework like this can be misused later on. Tero: yes, concerned about this. Paul: yes, we'd only do this if we have, say 2 options about which we have clear consensus Daniel Migault: support this, important for enterprise deployments Gabriel: of the 7 committed reviewers only 1 is here in the room, so we might see better support in the mailing list Yaron: generally supportive, but hate to bring up the fact that we might have to revisit WESP Gabriel: I'd rather not derail WESP for this, specially if we'll spend some time arriving at consensus about it Pasi: WESP has WG consensus and is past IETF last call, so this is not reasonable, lets not revisit WESP with WESP Extension considerations Yaron/Yoav on high availability unlike DHCP, DNS, HTTP servers, IKE and IPsec are not friendly towards HA and even less towards load sharing a stand-by gateway needs to do very costly operations crash discovery session resumption Yoav's draft is just a PS, but goal is to solve it solution 2 GWs w/same policy share state failover is detected "quickly" peers see them as a single GW (e.g. multicast address) goal: specification so the *peer* implementations can use HA and load sharing configurations (but not the back-end mechanism at the GWs) describe requirements from cluster members what data need to be synchronized between cluster members (in RFC4301 terms) Dan Harkins: if the point is to make a transparent cluster, and we know these are available, then what is the problem that needs to be solved? Yaron: degree of transparency differs, so may need to further work here Dan H: then fix those cluster implementations Tero: we've pushed it out of Mobike and IPsec, so we should do that here as well, but problem statement is fine. Greg: who is asking for this? Yaron: 2 large VPN vendors Pasi: if we allow some visibility to the peers into the fact that their GW is a cluster, this might reduce the synch requirements among the cluster Steve Kent: really confused as to why we need to do this. So yes, we need a problem statement on this. Greg Lebovitz - we don't need a problem statement (we've tried it 4 times already) what we need is for folks to document their use cases. 1045 Initial call for volunteers who will review each document. This will help determine which documents have the most interest. Gauge interest on Pasi: 3 Qs: who's reviewing, contributing, editing EAP-only IKEv2 auth R: Tero, Gregory, Dan Harkins, Yoav, Rene C: Rene E: Yaron Quick Crash Detection R: Gregory, Dan Harkins, Tero, Min Huang C: Gregory E: Child-less IKE SA R: Jean-Michel, Daniel, Simon, Tero, Michael Richardson C: E: IPsec HA and Load Sharing (assuming only problem statement and use cases) R: Gregory, Jean-Michel, Tero, C: Jean-Michel E: SPSK - secure PSK R: Rene, Gregory, Tero, Jim, Michael Richardson C: Tero, Gregory, Rene, Michael Richardson E: Greg, Tero WESP Extensibility R: Daniel Migault, Ming, C: Daniel E: Daniel Labeled IPsec (IKEv2 item) R: Ken C: Ken E: Ken Pasi: to be followed up on the mailing list and then filtering applied 1100 IKEv2bis certificate issues Open issues from the mailing list, plus anything new Issue #22 - simultaneouis IKE SA rekey Paul: we've said "no new functionality" in IKEv2 bis. But this is a proposal to add new functionality. Add new TEMPORARY_FAILURE errot type notify, and new DHILD_SA_NOT_FOUND error type notify for one collision case. Pasi: with no hat on, this is reasonable and implementable by mere mortals. Paul: will this be an issue at the IESG review phase? Pasi: will need a good justification to avoid this. Tim will be the shepherd and will convince him that this is the least bad option. Greg: we need to fix things so our protocols can eventually go from PS to standard, so I'm ok with this going into the IKEv2-bis document. 1130 Adjourn