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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
