Ipsecme Status PagesIP Security Maintenance and Extensions (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2008-Jul-08 —Chairs:
IETF-102 ipsecme minutes
Session 2018-07-18 1520-1650: Saint-Paul/Sainte-Cath. - ipsecme chatroom
IETF 102 IPsecME WG meeting in Montreal Wednesday, July 18, 2018 15:20-16:50 SAint-Paul/Sainte-Catherine Agenda: - Agenda bashing, Logistics -- Chairs (5 min) 15:20 - Rechartering (5 min) 15:25 - Draft status -- Chairs, Valery (10 min) 15:30 - draft-ietf-ipsecme-eddsa - draft-ietf-ipsecme-implicit-iv - draft-ietf-qr-ikev2 - Work items - Split-dns (10 min) 15:40 - draft-ietf-ipsecme-split-dns - Auxiliary Exchange in the IKEv2 Protocol (15 min) 15:50 Valery Smyslov - draft-smyslov-ipsecme-ikev2-aux - Postquantum Key Exchange for IKEv2 (10 min) 16:05 - draft-tjhai-ipsecme-hybrid-qske-ikev2 - Labeled IPsec (10 min) 16:15 - draft-sprasad-ipsecme-labeled-ipsec - Diet ESP (10 min) 16:25 - draft-mglt-ipsecme-diet-esp - Controller IKE (10 min) 16:35 - draft-carrel-ipsecme-controller-ike Agenda bashing, Logistics ========================= Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ipsecme-chair-slides-01 No agenda bashing. Rechartering ============ EKR has a draft charter, will re-revise it. He doesn't see any problems. Draft Status ============ Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ipsecme-quantum-resistant-ikev2-00 Some of the drafts in RFC editor status are out of the 48hours author review (some of the same documents in the same cluster as EDDSA). Split DNS had some issues, and would come back later. draft-ietf-ipsecme-qr-ikev2 (done after IKE_AUX presentation, but added to minutes here, where it was supposed to be presented): Valery presenting. There are a few clarifications since -02, no changes on the wire. At least four vendors have implemented. Believes it is ready for LC. Jonathan Hammell: Why send N(USE_PPK) with IKE_SA_INIT, which allows an attacker to profile which connections might be QR and which not? Valery: Needed for support of legacy, and implementations that don't support PPK. Jonathan: Cant you handle that as if the responder didn't know what is? Valery: There are more advantages than disadvantages. Jonathan: Suggesting to just remove the Notify from the IKE_SA_INIT. Tommy: With the current structure, if you do support the PPK then you are replacing the AUTH payload with the PPK derived key. If you don't want to negotiate up front they will not recognize the NO_PPK_AUTH payload, and the AUTH payload won't match. Stanislav Smyshlyaev: DO you have any formal security analysis of the draft? Valery: None he is aware of. But . Chairs: Should be ready for WGLC. They'll be starting it soon Split Dns ========= (draft-ietf-ipsecme-split-dns) Slides: posted part as chair slides Tommy presenting. Document was about done, then EKR gave some good comments about possible mis-use by VPN server. They want to resolve this issue. A new version was posted addressing this, and we'll discuss this now. [Added after meeting to clarify: It is assumed a CA/provisioning server is more secure then a VPN gateway] IKE clients MUST uses a set of whitelisted names. Updates to the list of trusted servers must be done on the client, or done administratively out-of-band. Paul W: Issue is that the VPN headend might try to re-configure the clients. Tommy: Should add that they should only include domains that are really considered "internal". EKR: Explain that serious thought should be given before adding it to the white list. Tero: Everytime you go below a dot you have problems. Paul W: Were talking about opening redirections, not installing trust anchors. No objections the text on the slide, plus text that would be added to make EKR's points more clear: that a white list is not required to be sent. The draft will then go back to the AD (EKR) and he'll progress it. Auxiliary Exchange in IKEv2 Protocol ==================================== (draft-smyslov-ipsecme-ikev2-aux) Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ipsecme-auxiliary-exchange-in-ikev2-protocol-00 Valery presenting. The auxiliary exchange takes place between IKE_SA_INIT and IKE_AUTH, to distribute large amount of data (probably large keys as part of a quantum resistent algorithm. They are so large that they are likely to be fragmented. Current draft says that IKE_AUX messages are authenticated by including their ICVs in the signature calculation in IKE_AUTH. Some issues were found with this. The slides show possible solutions. Tero: (slide 7) We are using the PRF of the data for auth payload so what is the difference. Valery: In the auth payload calculation the key is not known, here it might be. Paul W: We have at this point exchanged algorithsm. Valery: We haven't finished the negotiation until IKE_AUTH. Propsed solution 3 seems like the best compromise and he'll update the draft with that, other comments welcome though. Postquantum Key Exchange for IKEv2 ================================== (draft-tjhai-ipsecme-hybrid-qske-ikev2) Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ipsecme-postquantum-ikev2-00 Scott F presenting. Framework to Integrate Post-Quantum Key eXchanges in IKEv2" Skipping to Slide 3. Slide 4: Revised ideas, which were pretty complex. Using the IKE_AUX exchange now. Valery: I like it. You outlined that you send Nonce payload for each KE exchange, and not reuse one from IKE_SA_INIT. Is it neceesary for security? Scott: No, but I put it in there because we reused an existing key update mechanism, and as that mechanism used nonces, we included them. Valery: I think we should not allow multiple key exchanges per IKE SA. Scott: We didn't want to break compaibility with existing IKE implementations, and play games with the SA payload where they might get confused. Dan H: Are all NIST protocols two message protocols? Scott: Pretty much. Only one requires a three-pass protocol and we're ignoring that. Labeled IPsec ============= (draft-sprasad-ipsecme-labeled-ipsec) Slides: no slides Paul W presenting. There some some discussion, but wasn't enough guidance to decide which way to go. So was hoping for more guidance. Tero: There were different ideas on what the labelling was. We need to understand what the labels are before we can decide how to transport / negotiate them. Paul: With SE-Linux there's no hierarchy. The question is what to do with other systems that have hierarchy. Paul: The problem with hierarchy is underspecifying is as bad as overspecifying. Valery: If label is presented it . Paul: The problem is that selectors is that then we have to define the properies of those selectors. Valery: If you define labeled IPsec then you have to define the labels and how to use them. Tero: Are the labels numbers? Paul: No variable strings. Tero: Then the comparisons get uglier. Paul: I here two voices in favor of traffic selector type, who was in favor of the other mthod? Tero: The meanings of the lables ... negotiated? A mapping? That's hard. Paul: It's not a negotiation. It's either "I need this label" or "I don't need a label". Tero: What happens when the peer ignores the label and sends back traffic without the label? Tero: Pick one method and go with it. Diet ESP ======== (draft-mglt-ipsecme-diet-esp) Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ipsecme-esp-header-compression-00 Daniel M. presenting. ESP header compression. Compress for transmission, and uncompress before ESP receive processing. In the maximum case (for IoT), the ESP header bytes are greatly reduced and when combined with Implicit IV it's even smaller. In the VPN use case, the savings might not be so great. Believes that the draft is ready for adoption. Have one implementaiton, and should have another except that it's delayed due to unavailabilty of students. David: The one snag is that we're waiting for the charter to be approved. Tommy: Going back to slide 7: I do like the solution. Has it been added to the IKE document how to negotiate this? Daniel: Could have a list of Notify payloads, and one is returned. Tommy: It would be like the Notify for Transport mode. That's good. In terms of deploying it, if we're in a place where we don't allow fragmentations and IP options, then it would make sense to only offer this. Tero: You could also created on the fly, i.e., when you first time send packet with does not work with compression, you cause trigger to go to IKE, and IKE negotiates new child SA without ESP compression and then you send the frame through it. Tommy: You should mantion this more in the document, about adding an additional Child SA. Valery: One drawback, which is to do DH twice. Tero: You don't have to. Valery: You save bandwidth, but you spend on compution. Daniel: Focus was on reducing bandwidth, the computation costs much less than sending one more byte. Tero: You can't use the same key, because the sequence numbers would be differnet. You could do KEYMAT twice. Daniel: would it use exactly the same keys for the two? ([Tero] checking this later yes, KEYMAT does not include SPI in, thus they keys would be same, so that is not option, needs to do new CREATE_CHILD_SA)? Controller IKE ============== (draft-carrel-ipsecme-controller-ike) Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ipsecme-controller-ike-00 Dave Carrel presenting. Building a controller-based network in a full mesh, need to have IPsec gateways ready to do IPsec immediately. Don't want a man in the middle for the session keys. Paul W: On one hand you're saying you don't have enough memory to do thousands of DH, but on the other hand you can store 1000 DH keys? Dave: There's a lot of state going on in IKE, it's not that there isn't enough memory to keep all the DHs. Q: So you have a controller to control all the communication, why can't it create the keys? Davie: Don't want to do that. Q: But controller can hold all of the DH public numbers, can be a MITM by replacing all of the shares. Dave: Right, you could have nodes signing their DH public numbers before sending them up. Q: So the two nodes have the communicaton where they can sign/verify signatures ... what more do they need? Dave: But they may not have bi-directional communication between them. Q: Seems like the controller has everyting EKR: What makes this "IKE" David: It's on the Internet and it's a key exchange? EKR: It's out of charter for this WG. Tero: I2NSF is doing similair things, this is better. Not in our charter now, but might be intersting to people so that's why its presented here. Dave: It's a key exchange protocol for IPsec. EKR: But it's not IPsec maintenance, so it needs to either be rechartered or start a new WG. Tero: Or go to I2NSF. Valery: Each peer has a private key, uses it with every peer in the network. The key must be changed. How often do you see that happening, e.g. based on volume. Then different connections to differnet peers have different bandwidths. David: You are limited by your business connection, but standard key lifetimes today are so long that time-based will happen first. Linda Dunbar: Question for the WG. In our environment we have similar environment, don't want to a peer authentication for every remote node. Could the name be "simplified IPsec" or something? In I2NSF we talk about constrained devices (maybe in the cloud). David: The controllers are in the most well protected places, the devices less so. Q: In that scenario, and in his application the node has to use signatures. David: In our environments we don't sign, but it could be done. Q: If you don't sign the DH shares than you don't need to do DH because it could just send keys. David: No we want to know that customers keys, can't come in a supoena records from the controller. We want the keys just on the end nodes. Q: Then just have the controller not keep the keys that are generated. [The chairs cut the discussion because its not part of the charter.] EKR: This sounds like a new WG. You can ask for a mailing list. Open Discussion =============== Tero: (not as WG chair). Send an email recently on the list regarding using larger DH groups. Does it make sense?. Paul W: I think its OK as long as you also add "don't add this to your default proposals" Daniel van Geest: If your just doing this to check a box, it's false security. Tero: It does actually provide 256-bit security. Daniel van Geest: Does DH provide 256-bits of quantum security? Tero: We don't know what security will be left with current methods after quantum computers. Tero: Most people aren't required to use 256-bit crypto, but that it must be able to do it. Daniel van Geest: Because they are scared of quantum computers. Tero: Yes Valery: Looks useful, but the public key exponent for these groups are quite huge, exceeding the typical IP packet size, and will make life a little bit difficult. But lets define them, why not? Yoav Nir: from jabber, not relayed on the mic because of time constrains: mic: I haven't heard anyone say they want this. I don't think anyone does. I think we should not do this. -- Paul W: I opened a case where someone wants to do mutual NULL authentication first, then upgrade them. What we used was the same trick as the PPK case. We've implemented it, squatting on a private use number. Should we write a draft and get a real number? David: Anyone intersted in the solution? Valery: Please bring it to the list. Tommy: Sounds intersting enough, one concern is does having that other option encourage people to use the wrong one (the NULL auth if they don't know what they're doing)? Is it somehtin we want to encourage long term or make it easy? David: Please take it to the list and summarize.