* 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 —  
Chairs
 
 


IETF-102 ipsecme minutes

Session 2018-07-18 1520-1650: Saint-Paul/Sainte-Cath. - ipsecme chatroom

Minutes

minutes-102-ipsecme-01 minute



          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
                     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 .
          
          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 .
          
          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?
          
           ([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.
          
          



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