IETF 86: IPsecme - 12 Mar 13, 9am Minutes taken by Dan Harkins Read the slides at https://datatracker.ietf.org/meeting/86/materials.html#ipsecme for more information. * where we are - auto discovery VPN PS is in IETF LC - as soon as LC is done, want some drafts on solutions - a few focused drafts on other stuff, almost done * ADVPN Problem Statement (Steve Hanna) - rev -04 posted, all comments except 2 have been addressed * on requirement 6 regarding endpoint roaming and the endpoint-to-endpoint use case. Tero says, "there are 2 possible ways to interpret that text. There are subtle changes in versions with different definitions of gateway. Are they spokes or end-points?" Steve says, "an endpoint may roam to a different network and go to a different spoke. If the e-2-e connection is affected then someting needs to be done. We need explanitory text to lay out all the implications." Tero says, "yes". Paul says, "we have a way forward by putting a better specification on the requirement. New things may be thought of as a result." Steve, "it may involve an endpoint moving or a spoke moving." Tero, "some people have been assuming that spokes are static. And not everyone understands this is a requirement." - Next steps: complete WGLC, send it to IESG. * IKE over TCP (Yoav Nir) - rev -01 out, no open issues, no discussion, probably ready for WGLC. - no one seems to be doing IKE over TCP anymore, even CP. The problems that caused it's attraction, like fragmenting IKE, is solved already. - is there value in this? Tero says, "are people doing fragmentation doing it for IKEv1 or IKEv2?" Yoav says, "cisco is doing it for both. MS?" Paul asks, "Tero, does your OEM toolkit do fragmentation and is there any problem with it receiving fragments?" Tero, "we have seen implementations that send us fragments even if we say we don't support them so we have to support receiving them. We use fragmentation when we need to." Yoav, "Valery Smyslov has a draft out but not sure if anyone is doing it." Brian Weis, "I think this is a valuable draft. THere's a hope that someone will implement it." - if there is no interest by implementors to do this.... - Tero says, "if we've already implemented fragmentation then we don't need 3 different ways to do something. We have IKEv1 implementations that support draft stuff and don't interoperate on the RFC stuff because no one tested it." - Sean Turner says, "we standardize some things that get used and some that don't. Maybe we can flush out some comments when we do LC." Paul, "is there use in doing this if vendors already feel they have different ways of doing it." Yoav says, "MS has a patent." - Derek Atkins, "we support IKE fragments." IKEv1? "It's hard to tell because our code is so combined." - Daniel Migault, what about making it Informational? Paul says, "that has historically caused vendor confusion." Yoav, "even Experimental is not appropriate because my company has over a decade of experience in doing this." - Yoav says, "I asked MS about their patent and they said they'd get back to me." - Please comment on list if you think you need this or if your company already supports fragmentation. * D-H tests for IKEv2 (Tero Kivinen) - some tests are missing. Recipient should verify DH public key. Applies to both initiator and responder. - tests are required if using ECDH and reusing public keys or using groups with a small subgroup. - IANA instructed to create a "Recipient Tests" column and it will be populated for existing groups and new groups must specify a value. - open issues & next steps: * what to do if the test fail? "It's dangerous to be helpful". Probably say "INVALID_SYNTAX". To be determined. * Like to go to WG LC after Orlando - Paul said that the document should support different types of groups we have out there - Jabber! Yaron says "this is true already." * Signature Auth in IKEv2 (Tero Kivinen) - rev -00 draft posted, -01 is ready but not out yet. Need to decide what to do with RSASSA-PSS before continuing. - Currently RSASSA-PSS is not supported. One way to change is to include full SubjecPublicKeyINfor object. Sean says, "we really should support PSS". Tero, "actually it's not SubjectPublicKeyInfo, it's the stuff that goes right before the signature." - Next steps: * are people interested? * should it be a WG item (change charter) or just continue as an individual submission. * Need more reviewers! * Raw Public Keys in IKEv2 (Tero Kivinen) - obsolete old way of doing raw public keys, update RFC 5996, add reference to RFC 5480. - Next steps: * adopt as a WG draft? Sean says, it's probably OK to do this prefers not to do individual standards track. * WG LC ready? * Crypto Algorithm Implementation Requirements and Usage Guidance for ESP and AH (Brian Weis) - proposal to change the mandatory-to-implement ciphers. Has feedback from WG: 3DES is MAY; HMAC-MD5 is ignored; MAY are listed if previous SHOULD, SHOULD+, or MUST - what's new? Section on alg diversity, more security rationale. - David Black says, important document because it's easy for iSCSI to pass limits that are being discussed in security rationale. Nice to have this information. - Sean says, "is there something we should say about, 'every 5 years we should evaluate security....'" Paul says that's a bad idea because we don't know how what we're mandating now will stand up. Sean says, "but in 5 years we will reevaluate." We can recommend the IETF do something but hopefully in 5 years this WG will not exist. - Read and comment, please. * IKEv2 Security Gateway Discovery Protocol (Daniel Migault) - problem: client attached to gateway. VPN service provided by a distributed VPN platform. Client is likely to change SG it is attached to. How does the client choose best? - SGDP is a query/response protocol. Request for neighbors, response with list of neighbors and options. Paul asks, "if I ask about your neighbors, do you answer about yourself too?" Yes. Wait. I'm not sure. - Options: interface, geo location, bandwidth, mobility mechanisms. If you want more options, let us know. Paul, "what happens if I ask you a question and you lie." Daniel, "don't prevent lying, assume you trust the device you're attached to." Jabber! Paul Wouters, "are these options available after authentication?" Yes. * IKEv2 Alternate Outer IP Address Extension (Daniel Migault) - Problem: want different path for IKEv2 (control) and VPN (data). How do negotiate the address to be used for the VPN? - Adds a new transform to the SA Payload proposal to add outer IP address. Tero, "you can't do this in the SA payload. You need to include all the stuff you are proposing and the responder picks one. This makes it hard to do negotiation. Initiator won't have all the information needed to make a proper proposal." - Dan Harkins, this sounds bad. There's SA disclosure and an assertion of ownership of an IP address. Sounds bad. - Lou Berger, we've been here before with endpoint discovery in BGP. At the time, the AD said "we're not gonna allow this". This was solved by adding a hash, check out RFC 5566 for an example. - Brian Weis, "if the client gets back more than 1 IP address it needs to know what to choose. Aweful lot of state that would need to be exchanged prior." Daniel, yea, the decision to choose 1 over the other can be fuzzy for some situations but it might be easier in other situations. Probably out of scope. - Steve Kent, "whenever I'm connecting to a SG they need credentials that identify it as a SG that maps back to a DB of what they represent. We have to go through an authorization procedure before we handoff responsibility." - Paul, why would one want to do this and how does the initiator know this is 2 interfaces on 1 gateway. Daniel, want to do this for offload, for instance 3G to WiFi. Authentication is heavy, takes time and nice to have a different path. (Did not answer 2nd question) - Tero, assumption that if the IKE SA "works" that the IPsec SAs also "work". Now that assumption is gone. DPD doesn't work. Daniel, we need to work on splitting the SAs.