Minutes IETF101: ipsecme
minutes-101-ipsecme-00

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 -
    draft-tjhai-ipsecme-hybrid-qske-ikev2
  - Labeled IPsec - Paul Wouters - draft-sprasad-ipsecme-labeled-ipsec
  - Auxiliary Exchange in the IKEv2 Protocol - Valery Smyslov -
    draft-smyslov-ipsecme-ikev2-aux
  - Group Key Management using IKEv2 - Valery Smyslov - draft-yeung-g-ikev2
  - IKE_SA_INIT privacy concerns - David Schinazi -
    draft-dschinazi-ipsecme-sa-init-privacy-addition
  - Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica -
    draft-spiriyath-ipsecme-dynamic-ipsec-pmtu

WG Actions:
-----------
Update QR Ikev2 to Standards track in datatracker. - Done.

Session Notes:
--------------

Chair Slides - Chairs
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-chair-slides-01
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
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-quantum-resistant-ikev2-00
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
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-framework-to-interate-post-quantum-key-exchange-into-ikev2-01
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.

Yoav:
    - how large is large? --> Some 1KB or more
    - No trouble with payload length? --> No
Tommy:
    - What message type for second exchange (with regards to new DH
      and Fragmentation Bit)?
Tero:
    - 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

Yoav:
    - 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

Mark:
    - seems sufficient
Valery:
    - prefers different approach for fragmentation issue. Not a good
      idea to rely on some buggy implementations around for such a
      long-term solution
Yoav:
    - do you actually achieve FIPS compliance? --> Yes
Tero:
    - 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
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-auxiliary-exchange-in-ikev2-protocol-00
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?
Tero:
    - Responder cannot change, because the responder requires another request.
    - How to prevent x-times SKEYSEED after every IKE_AUX
    - Maybe you not only one request-response for QSKE
Tommy:
    - 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.
Tero:
    - 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.

Summary:
    IKE_AUX seems simple and doesn't need fragmentation.
    Adds round-trips but seems affordable.

Labeled IPsec - Paul Wouters
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-labeled-ipsec-00

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
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-group-key-management-using-ikev2-01

Motivation: GDOI should die along with IKEv1. This covers multicast
security.
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
GSA_REGISTRATION (like CREATE_CHILD_SA)
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
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-privacy-additions-to-the-ikev2-ike-sa-init-exchange-00

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
instead.

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
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-discovery-01

Problem: IPsec Tunnel has an PMTU as any other tunnel.
Solution in Transport Area: Inband Path discovery