* 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-103 ipsecme minutes

Session 2018-11-07 1350-1520: Boromphimarn 4 - Audio stream - ipsecme chatroom

Minutes

minutes-103-ipsecme-00 minutes



          IETF 103 IPsecME WG meeting in Bangkok
          Wednesday, November 7, 2018
          13:50-15:20 Boromphimarn 4
          
          Agenda:
          - Agenda bashing, Logistics -- Chairs (5 min)
          - Draft status -- Chairs (15 min)
            - draft-ietf-ipsecme-eddsa -> RFC8420
            - draft-ietf-ipsecme-split-dns
            - draft-ietf-ipsecme-qr-ikev2
            - draft-ietf-ipsecme-implicit-iv
            - draft-ietf-ipsecme-ipv6-ipv4-codes
          - Work items
            - PSK authentication (10 min)
              Paul Wouters
            - IKE over TCP implementation issues (10 min)
              Valery Smyslov
              - draft-smyslov-ipsecme-tcp-guidelines
            - IPsec Compression mode for ESP (EHC) (15 min)
              - draft-mglt-ipsecme-ikev2-diet-esp-extension
            - IKEv2 Notification Codes for IPv4/IPv6 Coexistence (15 min)
              - draft-ietf-ipsecme-ipv6-ipv4-codes
          
          
          Agenda bashing, Logistics
          =========================
          Slides:
          https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-chair-slides-02
          
          agenda is bashed...
          
          Draft status
          ============
          
          Tero: not a whole lot done since IETF 102 ("we have been lazy").
                ECDSA draft is out as RFC 8420
          Paul Wouters: split dns draft is on IESG telechat
          Tero: is the implicit IV draft ready? minor head nods
                not much discussion on QR IKEv2 draft.
          Valery Smyslov: it's ready, it's been ready since August.
          Paul: we've got interop testing done, it's more than ready
          Tero: still working on ipv6-ipv4 codes draft.
                Anyone else have a document you want to work on? Contact the chairs.
          
          PSK authentication
          ==================
          Slides:
          https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-psks-will-always-be-weak-00
          Paul Wouters
          
          PSKs Will Always Be Weak
          New dictionary attacks on IKEv1
          IKEv2 PSK mode is susceptible to dictionary attack.
          Information we give on use of PSKs is not really followed.
          PPK draft says use PSKs with 256 bits of entropy. But we know no one
          will do that.
          FIPS 198 and 198-1 has recommendations but what should we do?
          Users are not implementors and do not follow these recommendations.
          Main attack vector in IKEv2 is weak PSKs
          Do we need a new RFC to recommend minimum strength PSKs? This could
          cause implementations to do something.
          
          Dan Harkins: I like the title, yes they will always be weak. I'm not
                       sure about an RFC to update this. I think the problem is
                       that the protocol is weak, and the users must use a
                       stronger key to avoid weak keys. We should use a PAKE,
                       and write an RFC. Have a secure way to use PSKs.
          
          Yoav: You're saying we should obsolete PSK for something better? We
                don't have PAKE yet though. Easy to generate secure PSK. The
                problem is the inconvenience.
          
          Tero (as chair): PSKs are not meant to be readable by humans.
          
          Paul: problem is we punted this to users-- "don't do stupid things."
          
          Tero: if it's human readable then we need to use a secure PSK mode.
                Then mandate some size restrictions on PSKs.
          
          Stanislav: We should use a PAKE. CFRG is going to be discussing what
                     PAKE to use. The way to address the problem you describe is
                     to use a PAKE.
          
          Hu: We should not obsolete PSK, it's not going away. To make it secure
              we should use a PAKE.
          
          Valery: you can't stop users from doing stupid things. PAKE is a good
                  option to use weak PSKs. But the framework doesn't make it
                  easy to implement.
                  State machine became more complex. But don't drop PSK mode.
          
          Sean Turner: we screwed the PAKE thing up the first time around but
                       I'm not sure whether it would be fixed a second time.
                       We have recommendations on PSK entropy and I would help
                       to write a new one for IKEv2.
          
          Tero: The problem is that if we asked for doing one PAKE today, we
                would still not know what to do
          
          Stanislav: the CFRG process is just starting. There will be a process
                     of identification, evaluation, and selection. Not sure of
                     time frame but not years.
          
          Dan: we need a balanced PAKE because either side can initiate.
          
          Yaron Sheffer: we need a PAKE, we need a balanced PAKE. We should
                         bring this input more formally into CFRG.
          
          Tero: we should ask CFRG to pick a balanced PAKE for us to use.
          
          ACTION ITEM FOR CHAIRS: send a note to the list on this and then
          forward request to CFRG.
          
          
          IKE over TCP implementation issues
          ==================================
          (draft-smyslov-ipsecme-tcp-guidelines)
          Slides:
          https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-clarifications-for-using-tcp-encapsulation-in-ikev2-00
          Valery Smyslov
          
          Valery: TCP encapsulation is specified in RFC 8229. Need some
                  optimizations though for reliability and interoperability.
                  Should we do a RFC8229-bis to deal with all this?
                  Yes, there are things to improve upon but none of these things
                  are critical or showstopping.
          
          Tommy Pauly: On retransmissions: not sure why the congested issue is
                       red. Tunneling ESP in TCP is a far greater concern for
                       congestion than IKEv2.
                       For cookie calculation, isn't that the same for UDP
                       because you could be behind a NAT?
          
          Valery: yes but it's red because cookie calculation is a local matter.
          
          Paul: we have seen how NATs cause problems by rewriting the port
                number very quickly.
          
          Tommy: for MOBIKE, it should be identical to what you do over UDP.
          
          Valery: possibility of not detecting a NAT
          
          Tero: when you switch IP addresses in MOBIKE you can't recalculate.
                But when you update addresses, if they don't work change again
                and when the final one works then update. Should do same here.
          
          David Skenazii: what's the benefit of doing NAT detection in TCP? We
                          can just throw the results on the floor.
          
          Valery: yes it's more tolerable.
          
          David: we can say if you use TCP then we can disregard any NAT detected.
          
          Paul: it's a little too soon to do a bis document, need a little more
                experience.
          
          Mark McFadden: Maybe instead of doing a bis just take this work, which
                         is very good, and adopt it for implementation
                         guidelines.
          
          Yoav: we can have a document that we work on but there's no rush to
                publish, it might become a bis eventually.
          
          Tero: we had a clarification document for IKEv2 but not sure how
                useful it was to publish. Could've just been a draft. We could
                do the same thing here. When we are ready we can work on a bis
                document. Opinions? Hums to work on it, no hums to not. Have to
                talk with ADs.
          
          
          IPsec Compression mode for ESP (EHC)
          ====================================
          (draft-mglt-ipsecme-ikev2-diet-esp-extension)
          Slides:
          https://datatracker.ietf.org/meeting/103/materials/slides-103-ipsecme-esp-header-compression-ehc-00
          Daniel Migault
          
          Valery: the idea to compress is exciting but it seems complex both in
                  implementation and negotiation. Will not be easy to select all
                  theose parameters.
                  Is it possible to focus on the most effective options?
          
          Daniel: we took a long time defining the rules but the implementation
                  should not be as long as the specification.
          
          Paul: you keep saying this is simple and straightforward but I read
                the draft and don't understand anything. There's a lot of
                complexity and IPsec and IKE are already compllicated.
          
          Yoav: how does this complain toe RFC 5756?
          
          Daniel: there is no down stream signaling. You have rules on each
                  side. This is static, that is dynamic.
          
          David: yes this is simpler than that but battery powered devices are
                 not just light switches, if we can improve lifetime of phones
                 and watches there's value.
          
          
          IKEv2 Notification Codes for IPv4/IPv6 Coexistence
          ==================================================
          (draft-ietf-ipsecme-ipv6-ipv4-codes)
          Daniel Migault
          
          Valery: too many notifications for failures. In first case (slide 1),
                  why not just say what you support (2nd and 3rd cases)?
          
          Tero: if you ask for both and you get back 1 you know. But
                SINGLE_AF_SUPPORTED does not help. Maybe reduce to 2.
          
          Lorenzo: These are 3GPP error codes, right? Is it harmful to do this?
          
          Daniel (continues with presentation, slide 2)... seems like there are
                 some objections to assigning 4 new codes, should reduce it.
                 Should we negotiate an extension?
          
          Tero: comments saying this should be simplified. Author wants to get
                draft out soon. Good to get them feedback.
          
          Open Discussion
          ===============
          
          we're done!
          
          



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