Ipsecme Status PagesIP Security Maintenance and Extensions (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2008-Jul-08 —Chairs:
IETF-103 ipsecme minutes
Session 2018-11-07 1350-1520: Boromphimarn 4 - Audio stream - ipsecme chatroom
IETF 103 IPsecME WG meeting in Bangkok Wednesday, November 7, 2018 13:50-15:20 Boromphimarn 4 Agenda: - Agenda bashing, Logistics -- Chairs (5 min) - Draft status -- Chairs (15 min) - draft-ietf-ipsecme-eddsa -> RFC8420 - draft-ietf-ipsecme-split-dns - draft-ietf-ipsecme-qr-ikev2 - draft-ietf-ipsecme-implicit-iv - draft-ietf-ipsecme-ipv6-ipv4-codes - Work items - PSK authentication (10 min) Paul Wouters - IKE over TCP implementation issues (10 min) Valery Smyslov - draft-smyslov-ipsecme-tcp-guidelines - IPsec Compression mode for ESP (EHC) (15 min) - draft-mglt-ipsecme-ikev2-diet-esp-extension - IKEv2 Notification Codes for IPv4/IPv6 Coexistence (15 min) - draft-ietf-ipsecme-ipv6-ipv4-codes Agenda bashing, Logistics ========================= Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-chair-slides-02 agenda is bashed... Draft status ============ Tero: not a whole lot done since IETF 102 ("we have been lazy"). ECDSA draft is out as RFC 8420 Paul Wouters: split dns draft is on IESG telechat Tero: is the implicit IV draft ready? minor head nods not much discussion on QR IKEv2 draft. Valery Smyslov: it's ready, it's been ready since August. Paul: we've got interop testing done, it's more than ready Tero: still working on ipv6-ipv4 codes draft. Anyone else have a document you want to work on? Contact the chairs. PSK authentication ================== Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-psks-will-always-be-weak-00 Paul Wouters PSKs Will Always Be Weak New dictionary attacks on IKEv1 IKEv2 PSK mode is susceptible to dictionary attack. Information we give on use of PSKs is not really followed. PPK draft says use PSKs with 256 bits of entropy. But we know no one will do that. FIPS 198 and 198-1 has recommendations but what should we do? Users are not implementors and do not follow these recommendations. Main attack vector in IKEv2 is weak PSKs Do we need a new RFC to recommend minimum strength PSKs? This could cause implementations to do something. Dan Harkins: I like the title, yes they will always be weak. I'm not sure about an RFC to update this. I think the problem is that the protocol is weak, and the users must use a stronger key to avoid weak keys. We should use a PAKE, and write an RFC. Have a secure way to use PSKs. Yoav: You're saying we should obsolete PSK for something better? We don't have PAKE yet though. Easy to generate secure PSK. The problem is the inconvenience. Tero (as chair): PSKs are not meant to be readable by humans. Paul: problem is we punted this to users-- "don't do stupid things." Tero: if it's human readable then we need to use a secure PSK mode. Then mandate some size restrictions on PSKs. Stanislav: We should use a PAKE. CFRG is going to be discussing what PAKE to use. The way to address the problem you describe is to use a PAKE. Hu: We should not obsolete PSK, it's not going away. To make it secure we should use a PAKE. Valery: you can't stop users from doing stupid things. PAKE is a good option to use weak PSKs. But the framework doesn't make it easy to implement. State machine became more complex. But don't drop PSK mode. Sean Turner: we screwed the PAKE thing up the first time around but I'm not sure whether it would be fixed a second time. We have recommendations on PSK entropy and I would help to write a new one for IKEv2. Tero: The problem is that if we asked for doing one PAKE today, we would still not know what to do Stanislav: the CFRG process is just starting. There will be a process of identification, evaluation, and selection. Not sure of time frame but not years. Dan: we need a balanced PAKE because either side can initiate. Yaron Sheffer: we need a PAKE, we need a balanced PAKE. We should bring this input more formally into CFRG. Tero: we should ask CFRG to pick a balanced PAKE for us to use. ACTION ITEM FOR CHAIRS: send a note to the list on this and then forward request to CFRG. IKE over TCP implementation issues ================================== (draft-smyslov-ipsecme-tcp-guidelines) Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-clarifications-for-using-tcp-encapsulation-in-ikev2-00 Valery Smyslov Valery: TCP encapsulation is specified in RFC 8229. Need some optimizations though for reliability and interoperability. Should we do a RFC8229-bis to deal with all this? Yes, there are things to improve upon but none of these things are critical or showstopping. Tommy Pauly: On retransmissions: not sure why the congested issue is red. Tunneling ESP in TCP is a far greater concern for congestion than IKEv2. For cookie calculation, isn't that the same for UDP because you could be behind a NAT? Valery: yes but it's red because cookie calculation is a local matter. Paul: we have seen how NATs cause problems by rewriting the port number very quickly. Tommy: for MOBIKE, it should be identical to what you do over UDP. Valery: possibility of not detecting a NAT Tero: when you switch IP addresses in MOBIKE you can't recalculate. But when you update addresses, if they don't work change again and when the final one works then update. Should do same here. David Skenazii: what's the benefit of doing NAT detection in TCP? We can just throw the results on the floor. Valery: yes it's more tolerable. David: we can say if you use TCP then we can disregard any NAT detected. Paul: it's a little too soon to do a bis document, need a little more experience. Mark McFadden: Maybe instead of doing a bis just take this work, which is very good, and adopt it for implementation guidelines. Yoav: we can have a document that we work on but there's no rush to publish, it might become a bis eventually. Tero: we had a clarification document for IKEv2 but not sure how useful it was to publish. Could've just been a draft. We could do the same thing here. When we are ready we can work on a bis document. Opinions? Hums to work on it, no hums to not. Have to talk with ADs. IPsec Compression mode for ESP (EHC) ==================================== (draft-mglt-ipsecme-ikev2-diet-esp-extension) Slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-esp-header-compression-ehc-00 Daniel Migault Valery: the idea to compress is exciting but it seems complex both in implementation and negotiation. Will not be easy to select all theose parameters. Is it possible to focus on the most effective options? Daniel: we took a long time defining the rules but the implementation should not be as long as the specification. Paul: you keep saying this is simple and straightforward but I read the draft and don't understand anything. There's a lot of complexity and IPsec and IKE are already compllicated. Yoav: how does this complain toe RFC 5756? Daniel: there is no down stream signaling. You have rules on each side. This is static, that is dynamic. David: yes this is simpler than that but battery powered devices are not just light switches, if we can improve lifetime of phones and watches there's value. IKEv2 Notification Codes for IPv4/IPv6 Coexistence ================================================== (draft-ietf-ipsecme-ipv6-ipv4-codes) Daniel Migault Valery: too many notifications for failures. In first case (slide 1), why not just say what you support (2nd and 3rd cases)? Tero: if you ask for both and you get back 1 you know. But SINGLE_AF_SUPPORTED does not help. Maybe reduce to 2. Lorenzo: These are 3GPP error codes, right? Is it harmful to do this? Daniel (continues with presentation, slide 2)... seems like there are some objections to assigning 4 new codes, should reduce it. Should we negotiate an extension? Tero: comments saying this should be simplified. Author wants to get draft out soon. Good to get them feedback. Open Discussion =============== we're done!