[IPsec] Minutes from the IPsecME meeting in Bangkok IETF 103

[Tero Kivinen <[e-mail]>]

Thanks for minutes takers for taking the minutes in the etherpad. I
cleaned them up bit, and posted them to the meetings materials page:

----------------------------------------------------------------------
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!
-- 
[e-mail]