Minutes IETF102: ipsecme
minutes-102-ipsecme-01

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
          <something> 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 <missed it>.

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 <missed 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?

<no answer> ([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.