Ipsecme Status PagesIP Security Maintenance and Extensions (Active WG)
Sec Area: Eric Rescorla, Kathleen Moriarty | 2008-Jul-08 —Chairs:
IETF-100 ipsecme minutes
Session 2017-11-13 0930-1200: Orchard - Audio stream - ipsecme chatroom
100 IPsecME WG meeting in Singapore Monday, November 13, 2017 09:30-11:00 (+8) Orchard - Agenda bashing, Logistics -- Chairs (5 min) --------------------------------------------- David Waltmire: Some updates on drafts, mainly going to go over recharter - Draft status -- Chairs (5 min) -------------------------------- EDDSA draft recently rev-ed, IETF last call has been requested by EKR. Concluded WGLC on Split DNS and Implicit IV Quantum Resistant IKEv2 getting close to WGLC, some recent changes that need to be reviewed. - Work / Other items (30 min) ----------------------------- * Split DNS - draft-ietf-ipsecme-split-dns Paul: We just submitted -03 to address Valery's comments which were mainly typographical, had a discussion last time so everything should be resolved. David: We'll confirm on the list that we're all good then send forward * Implicit IV - draft-mglt-ipsecme-implicit-iv Daniel: Addressed a few recent comments. Using Implicit IV is not compatible with all IKEv2 extensions. The current text is to not use implicit IV for IKE traffic Paul: It would be nice to make it work with IKEv2, since it is trying to help the IoT devices. Just because we think there is more ESP than IKE, some IoT devices may just do short exchanges. I'd like to see this figured out. Tero: We have more work coming for compressed IoT approaches for IKEv2 and ESP, which may be simpler than adding it into this Implicit IV document. We can get this out now, and finish up later. Valery: The current document doesn't explain how to use it with IKEv2 at all. It uses Extended Sequence Number for ESP, and doesn't explain how to use for IKEv2. So in its current form, can't be used for IKE. * Postquantum preshared keys - draft-fluhrer-qr-ikev2 Valery: Summary of background/PPK solution. Previous version had a problem in which a missing PPK was a silent failure. Proposed solution is to let initiator send optional NO_PPK_AUTH, which is an AUTH payload without PPK assumed. Upon receiving, either fallback to old auth, or abort exchange. Expanded security considerations to contain mitigations for DoS attacks and downgrade attacks. Added operations considerations about how to distribute PPK keys. Document likely should be moved from Informational to Standards Track. Paul: Agreed that should be standards. Libreswan currently does fluher draft, but will update to current draft. Want to do interop. Q: Does the NO_PPK_AUTH create some sort of oracle that helps an attacker crack the crypto based on two signed values. Mark McFadden: Support standards track. In operational considerations, you mention possible way to distribute PPK. It seems like the mechanism is something that should be in a separate document to explain. Is it the intention to have a distribution document? Valery: I don't knowit was written to help operaters think of how to adopt PPKs. Not sure it should be in a different document. Note that this is a short-term solution. Scott: If the Quantum computer can break everything, it can already get the full IKE_SA_INIT values already by recovering DH. THey'll already be able to see everything in the standard AUTH payload (NO_PPK_AUTH). So having both doesn't expose anything new. Is that clear? David: We should hum on moving to standards track. Tero: Think it should be standards, just started as info. Paul: Informational is counter-productive, since we want people to adopt it asap. Hum: Strong in favor of standards, silent against. Tero: Next question is if we should update the base IKEv2 document. Signatures already does. This should make everyone aware of it. Paul: I think so too, because we really want people to do it. Tommy: I'm OK with this updating the base document, but the concern is if we will in the future have another document that doesn't use PPK that is the full QR solution. Mark Orzechowski: Would like to see the same status given to asymmetric solutions to QR. Hum on updating: Some in favor, stronger against updating the base IKEv2 document - Rechartering / New items (45 min) ----------------------------------- Current charter expiring in December, so we need to recharter. Many discussions on the list about new work to do. A few items still in charter in progress. Current first two paragraphs are general, and could be kept, but can refresh. Hu Jun: Should we still be mentioning IKEv1 here? Tero: I was thinking that. We will not do work on IKEv1. But if there is, it should be here. Lorenzo: Just deprecate/historic IKEv1 Tommy: Could mention that not only we work on mainly IKEv2, but IKEv2 + ESP. Paul: Technically, there should be ipsecops and ipsecme, but there's likely not enough people here. EKR: I'm happy to leave it as one, the ops side is small enough. === Tero: There's an existing QR work item we still need to finish. Keep. Remove implicit IV, split DNS, etc, since they're done. New stuff: Group DOI, based on IKEv1 historically, should probably be adopted for IKEv2. Brian Weis: A few implementations already of this. In the spirit of making IKEv1 historic, we need this in IKEv2. Tero: Is this clear enough? Hu Jun: It looks like the use case is just multicast from the description, but does this include VPN as well? Yoav Nir: Supposed to replace GDOI, which is multicast and unicast. We should do this because this is the best place for it left. Hum: Do we understand this work? Strong favor, no against Should we do the work here? Strong favor, no against Tero: We should take this in the charter EKR: Hands for working on this? 4-5 willing to review. All are non-authors. Post-Quantum IKEv2 (using new algorithms, not just PPK). Also how to handle large payloads before auth. Quynh: This is going to be really good work. But there may be dozens of submissions (37 or more?). Do we want to test them all? Pay attention to NIST significant ones. Tero: Some problems we need to work on in the IKE protocol anyway, regardless of the end crypto algorithm. Valery: Can see as two step process: first make IKEv2 ready for big payloads in INIT. Then adopt new algorithms. Rick Salz: Depending on how we do it, we can avoid large payloads. We should wait for NIST, and do this in the next recharter. Not ready yet. EKR: No hats. What Rick says make sense. The one thing to work on maybe is much much larger keys, but we may not need it. Then, with hats, we should not be selecting algorithms here. Debi: This is key exchange, not signatures, so you can't use hash-based. This is important to start working on and thinking about. It's algorithm independent, and we need creativity in how to handle. Tero: I don't think we can separate out the big INIT payloads from the algorithms. Mark: I support this as a charter item. Some of the concerns could be addressed by re-wording that the solution is algorithm agnostic. Hum: Can we decide whether or not to take this? Mainly yes. Do we work on this in the charter? Strong favor, barely any against. How many review? Over 6 Help write? 4 Diet-ESP (also include Diet-IKE), generally working for IoT type networks. Hum: Do we understand this work: Strong favor, barely against Charter as WG item? Strong favor, one against Review? 5 Write? 4 Signature algorithm negotiation: We negotiate hash algorithms, but not keys. The thought is, like PSKs, you know which key you'll use for the IDs. Valery: The key may be the same in some cases across algorithms, and could be the case with future schemes. Paul: While you're thinking of the pre-configured Server-Client case, we may be doing opportunistic, and so there is work indeed to do here. Hum: Do we understand this work: Solid favor, no against Charter as WG item? Strong favor, weak against Responder MOBIKE: The question is if you can use redirect. Valery: Redirect has a penalty of creating a new IKE SA. MOBIKE provides a lighter-weight solution General support for updating parts of MOBIKE, extending this to be clarifications, not just responder document. Hum: Do we understand enough to work on new MOBIKE stuff? Strong favor, no against. Do we want to take some MOBIKE update in the charter? Strong favor, medium against. 60/40 Probably go to the list. Need to work out charter text for a MOBIKE update maybe in addition to this. Other items that are new: Address failure errors were requested to IANA. Tero wants it to go through IPsec first. Coming from 3GPP side. Labeled IPsec: feature in IKEv1, we want a better solution for IKEv2. We need to take discussion of this work item to the list. Mitigating privacy conerns in restricted deployments. Consider adding operational guiadance - PPK distribution, etc. Maybe BCPs.