* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ipsecme Status Pages

IP Security Maintenance and Extensions (Active WG)
Sec Area: Eric Rescorla, Kathleen Moriarty | 2008-Jul-08 —  

IETF-100 ipsecme minutes

Session 2017-11-13 0930-1200: Orchard - Audio stream - ipsecme chatroom


minutes-100-ipsecme-00 minutes

          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 know—it 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 +
          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
          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.
              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
          Mark: I support this as a charter item. Some of the concerns could be
          addressed by re-wording that the solution is algorithm agnostic.
              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
              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
          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.
              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.
              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

Generated from PyHt script /wg/ipsecme/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -