* 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, Benjamin Kaduk | 2008-Jul-08 —  

IETF-101 ipsecme minutes

Session 2018-03-23 1150-1320: Park Suite - Audio stream - ipsecme chatroom


minutes-101-ipsecme-00 minutes

          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 -
            - Labeled IPsec - Paul Wouters - draft-sprasad-ipsecme-labeled-ipsec
            - Auxiliary Exchange in the IKEv2 Protocol - Valery Smyslov -
            - Group Key Management using IKEv2 - Valery Smyslov -
            - IKE_SA_INIT privacy concerns - David Schinazi -
            - Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica -
          WG Actions:
          Update QR Ikev2 to Standards track in datatracker. - Done.
          Session Notes:
          Chair Slides - Chairs
          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
          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
          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.
              - how large is large? --> Some 1KB or more
              - No trouble with payload length? --> No
              - What message type for second exchange (with regards to new DH
                and Fragmentation Bit)?
              - 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
              - 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
              - seems sufficient
              - prefers different approach for fragmentation issue. Not a good
                idea to rely on some buggy implementations around for such a
                long-term solution
              - do you actually achieve FIPS compliance? --> Yes
              - 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
          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?
              - Responder cannot change, because the responder requires another
              - How to prevent x-times SKEYSEED after every IKE_AUX
              - Maybe you not only one request-response for QSKE
              - 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.
              - 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.
              IKE_AUX seems simple and doesn't need fragmentation.
              Adds round-trips but seems affordable.
          Labeled IPsec - Paul Wouters
          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
          Motivation: GDOI should die along with IKEv1. This covers multicast
          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
          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
          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
          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
          Problem: IPsec Tunnel has an PMTU as any other tunnel.
          Solution in Transport Area: Inband Path discovery

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