IETF 101 IPsecME WG meeting in London Friday, March 23, 2018 11:50-13:20 Park Suite - Agenda bashing, Logistics -- Chairs (5 min) - Rechartering (5 min) - Draft status -- Chairs, Valery (10 min) - Update on QR IKEv2 - Valery Smyslov - draft-ietf-ipseme-qr-ikev2 - Work / Other items (70 min) - Postquantum Key Exchange to IKE - CJ Tjhai - draft-tjhai-ipsecme-hybrid-qske-ikev2 - Labeled IPsec - Paul Wouters - draft-sprasad-ipsecme-labeled-ipsec - Auxiliary Exchange in the IKEv2 Protocol - Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux - Group Key Management using IKEv2 - Valery Smyslov - draft-yeung-g-ikev2 - IKE_SA_INIT privacy concerns - David Schinazi - draft-dschinazi-ipsecme-sa-init-privacy-addition - Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica - draft-spiriyath-ipsecme-dynamic-ipsec-pmtu WG Actions: ----------- Update QR Ikev2 to Standards track in datatracker. - Done. Session Notes: -------------- Chair Slides - Chairs https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-chair-slides-01 split-dns waiting for ad Ready for WGLC on implicit IV (no new comments). 6 or 7 reviewers raised hands. Most Milestones of old charter completed New Milestones on new charter MOBIKE and privacy not included in the charter due to ongoing discussion, can be added later. Update on QR IKEv2 - Valery Smyslov https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-quantum-resistant-ikev2-00 Changes from -00: - Most important is the change from prf to prf+ At least 4 vendors implemented the draft Some interop-tests where done Ready for last call? Paul W.: - negotiation of authentication mechanism needed - Should we do this negotiation more generic? --> offering two authentication does not scale Tommy Pauly: - Some of the text should be more clear about the structure of the Auth_Data (just the latter portion of auth payload, not the type) --> Tommy volunteers to provide the text Postquantum Key Exchange to IKE - CJ Tjhai https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-framework-to-interate-post-quantum-key-exchange-into-ikev2-01 New Design criteria based on the various feedback, mainly due to interoperability concerns and handling fragmentation in version -00 Needs to be future proof, and work in parallel with existing mechanisms (hybrid algorithms). Try to keep the amount of data as minimal as possible Backwards compability: no new transform type, no new payload. Notification is OK. New approach uses new DH group number that denotes hybrid approach in first INIT exchange. Second round would be quantum safe. Fragmentation only applies to IKE_AUTH onwards. Proposing adding a fragmentation pointer. Yoav: - how large is large? --> Some 1KB or more - No trouble with payload length? --> No Tommy: - What message type for second exchange (with regards to new DH and Fragmentation Bit)? Tero: - Two different Key Exchange labels in two different packets? - Better not to overlap KE payload --> introducing new payload type Paul W.: - would be nicer to have the two different KE payloads in the INIT --> If not understood, should ignore that Yoav: - could have done that for all new groups we support and we didn't. Doesn't introduce something fundamentaliy different to e.g. curve2559 Question to the WG: how to deal with Fragmentation? --> Valery will have a talk on that Mark: - seems sufficient Valery: - prefers different approach for fragmentation issue. Not a good idea to rely on some buggy implementations around for such a long-term solution Yoav: - do you actually achieve FIPS compliance? --> Yes Tero: - Mentioned use the existing INVALID_KE_PAYLOAD style mechanism; we don't want an explosion of combinations. ?: Fragmentation reassembly is an attack vector, how do we handle that? Tero: We use no fragmentation on INIT, and the reassembly we do is in the encrypted AUTH payloads Tero (Chair): Wait for Valery's presentation for fragmentation discussion Auxiliary Exchange in the IKEv2 Protocol - Valery Smyslov https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-auxiliary-exchange-in-ikev2-protocol-00 Fragmentation for IKE_AUTH is possible, as they tend to be much larger than IKE_INIT Driver behind this idea is quantum safe key exchange, as it will most likely have larger pub keys Add a new exchange between IKE_INIT and IKE_AUTH called IKE_AUX Integrity protected and encrypted Paul W: They are not integrity protected? -> they are not authenticated but integrity protected Yoav: You assume they are strong against Quantum Computers. Tero: Delayed authentication of IKE_AUX Approach is ment to be generic, not only for QSKE (but of coursed inspired by QSKE) additional skeyseed after IKE_AUX ?: How does the initiator know when to move to ike_auth? Tero: - Responder cannot change, because the responder requires another request. - How to prevent x-times SKEYSEED after every IKE_AUX - Maybe you not only one request-response for QSKE Tommy: - should we specify the responder behaviour as in IKE_AUTH? Responders in not allowed to initiate its own IKE_AUX. - Do we assume that there is always a new key after IKE_AUX? Should be generic - maybe we should just specify that it is mandatory to get keys, as the point about IKE_AUX is to secure IKE_AUTH. Michael R.: - doesn't seem to be generic cause of the re-key. - why not do a re-key after IKE_AUTH - As DH is broken, this approach does not seem to protect it. Tero: - discussion to the list Valery: if IKE_INIT can be broken in real-time Paul W.: Do we need the same for CREATE_CHILD_SA? It already can be fragmented, so no issue there. Summary: IKE_AUX seems simple and doesn't need fragmentation. Adds round-trips but seems affordable. Labeled IPsec - Paul Wouters https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-labeled-ipsec-00 Idea: Move an SA from one machine to the other (already in IKEv1, need it in IKEv2 to let IKEv1 die) Valery: need different selectors (Tobias: don't know if I got the question correctly) Tero: IP ranges are an issue. Jared Lu (?): Concern about deployment with exact vs inexact match for secret channels, and downgrade attacks. Group Key Management using IKEv2 - Brian Weis https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-group-key-management-using-ikev2-01 Motivation: GDOI should die along with IKEv1. This covers multicast security. There are two protocols (registration to join the group, and rekey to roll the keys) Would add GSA_AUTH (like IKE_AUTH with new payloads) and GSA_REGISTRATION (like CREATE_CHILD_SA) two re-keys (INBAND and "normal") - INBAND: new key distributed unicast - REKEY: new key distributed in multicast new Payloads: - GSA_PAYLOAD sending the sa information to the clients (no negotiation as in IKEv2) - KD Payload distributing the keys, - some optimizations for key distribution in the groups exist (e.g. LKH) - issues with IVs (solution so called sender-ids) Re-used payloads: - ID Payload for Group ID - Notify Tero: harmonizing with IKEv2 Yoav: harmoinizing the names for the keys - multicast? - CRFG has some proposals without the need the sender ids Who has read the draft? (about 7-10 hands) Ask for reviews on the list IKE_SA_INIT privacy concerns - David Schinazi https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-privacy-additions-to-the-ikev2-ike-sa-init-exchange-00 Concerns around privacy of the peers (who the initiator is, and if the responder is running IKE) IDi can be leaked to the entity that intercepted your IKE_SA_INIT. Initiator identity is leaked. Servers can hide behind TCP using TCP encapsulation, allowing someone to connect in with IKEv2 unbeknownst to anyone. Traffic could be recognized as IKE rather than HTTP. The privacy issue is that these could be probed to discover who is running VPNs behind websites. Proposal is to add a shared secret and a PRF. These are added as an optional notify in the IKE_SA_INIT. Responder can silently drop the packet, or choose to verify. If the initiator doesn't get back the reply, it will refuse to do IKE_AUTH. MAC based on shared key, a constant string, and the nonces. Vulnerable to reply attack for the initial IKE_SA_INIT. This is okay for the hidden server case, which could be protected from on-path attackers via TLS encaps. Michael Richardson: Smells like IKEv1 PSK with XAUTH. Unhappy about that. Seems that you're able to provision PSKs to the clients. I would prefer to provision a raw public key than a PSK. In the case of a TLS connection, you already have a public key the server can sign with. I don't want more PSKs, let's do public key instead. Tero: The problem is that when the responder validates the the INIT, the server can't scale if it has to check all of the options. I think the identity case is more important than the hidden server. Could use a random identity to protect the user. Have a scheme of psuedonyms. Hidden server problems seems not to be a good idea, as you can analyze the packet otherwise Valery: ? Tommy: Client authentication in TLS? -> that's also clear-text Privacy of the IDi would be the better and clearer focus. Daniel M.: splitting to two different solutions is better, especially the privacy of the IDi Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-discovery-01 Problem: IPsec Tunnel has an PMTU as any other tunnel. Solution in Transport Area: Inband Path discovery