[IPsec] IPsecME@IETF102 Montreal meeting mnutes

[Tero Kivinen <[e-mail]>]

Thanks for Brian Weis taking minutes from the IPsecME WG meeting. I
did some editing and posted them on the datatracker:
https://datatracker.ietf.org/meeting/102/materials/minutes-102-ipsecme-00

If you find something that needs to be fixed send me email (I did add
Yoav's comments that did not get relayed to mic from jabber, and added
comment that I did check the one item where there was no answer about
whether you get same keys if you run KEYMAT twice (you do get same
keys, there is only nonce there, no SPI).

----------------------------------------------------------------------
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 ossible mis-use by DNS server. They want to resolve
this issue. A new version was posted addressing this, and we'll
discuss this now.

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 <missed it>. Is it neceesary for
	security?

Scott: No, but I put it in there because <missed it>.

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 only 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: One one hand you're saying you don't have enough memory to do
     	full DH, but you're doing it.

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.




-- 
[e-mail]