* 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: Roman Danyliw, Benjamin Kaduk | 2008-Jul-08 —  
Chairs
 
 


2020-01-10 charter

IP Security Maintenance and Extensions (ipsecme)
------------------------------------------------

 Charter

 Current Status: Active

 Chairs:
     Tero Kivinen <kivinen@iki.fi>
     Yoav Nir <ynir.ietf@gmail.com>

 Security Area Directors:
     Roman Danyliw <rdd@cert.org>
     Benjamin Kaduk <kaduk@mit.edu>

 Security Area Advisor:
     Benjamin Kaduk <kaduk@mit.edu>

 Mailing Lists:
     General Discussion: ipsec@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/ipsec
     Archive:            https://mailarchive.ietf.org/arch/browse/ipsec/

Description of Working Group:

  The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
  RFCs, IKEv1 is now obsoleted), IKEv2 (RFC 7296), and the IPsec
  security architecture (RFC 4301). IPsec is widely deployed in VPN
  gateways, VPN remote access clients, and as a substrate for
  host-to-host, host-to-network, and network-to-network security.

  The IPsec Maintenance and Extensions Working Group continues the work
  of the earlier IPsec Working Group which was concluded in 2005. Its
  purpose is to maintain the IPsec standard and to facilitate discussion
  of clarifications, improvements, and extensions to IPsec, mostly to
  ESP and IKEv2. The working group also serves as a focus point for
  other IETF Working Groups who use IPsec in their own protocols.

  The current work items include:

  IKEv1 using shared secret authentication was partially resistant to
  quantum computers. IKEv2 removed this feature to make the protocol
  more usable. The working group will add a mode to IKEv2 or otherwise
  modify the shared-secret mode of IKEv2 to have similar or better quantum
  resistant properties to those of IKEv1.

  Currently, widely used counter mode based ciphers send both the ESP
  sequence number and IV in the form of a counter, as they are very
  commonly the same. There has been interest to work on a document that
  will compress the packet and derive IV from the sequence number
  instead of sending it in separate field. The working group will
  specify how this compression can be negotiated in the IKEv2, and
  specify how the encryption algorithm and ESP format is used in this
  case.

  The Group Domain of Interpretation (GDOI - RFC 6407) is an IKEv1-based
  protocol for negotiating group keys for both multicast and unicast
  uses. The Working Group will develop an IKEv2-based alternative that
  will include cryptographic updates. A possible starting point is
  draft-yeung-g-ikev2.

  Postquantum Cryptography brings new key exchange methods. Most of
  these methods that are known to date have much larger public keys than
  conventional Diffie-Hellman public keys. Directly using these methods in
  IKEv2 might lead to a number of problems due to the increased size of
  initial IKEv2 messages. The working group will analyze the possible
  problems and develop a solution, that will make adding Postquantum key
  exchange methods more easy. The solution will allow post quantum key
  exchange to be performed in parallel with (or instead of) the existing
  Diffie-Hellman key exchange.

  A growing number of use cases for constrained networks - but not
  limited to those networks - have shown interest in reducing ESP (resp. IKEv2)
  overhead by compressing ESP (resp IKEv2) fields. The WG will define
  extensions of ESP and IKEv2 to enable ESP header compression.

  Possible starting points are draft-mglt-ipsecme-diet-esp,
  draft-mglt-ipsecme-ikev2-diet-esp-extension,
  draft-smyslov-ipsecme-ikev2-compression and
  draft-smyslov-ipsecme-ikev2-compact.

  RFC7427 allows peers to indicate hash algorithms they support, thus
  eliminating ambiguity in selecting a hash function for digital
  signature authentication. However, advances in cryptography lead to a
  situation when some signature algorithms have several signature
  formats. A prominent example is RSASSA-PKCS#1 v 1.5 and RSASSA-PSS; however
  it is envisioned that the same situation may repeat in future with
  other signature algorithms. Currently IKE peers have no explicit way
  to indicate to each other which signature format(s) they support. That
  leads to interoperability problems. The WG will investigate the
  situation and come up with a solution that allows peers to deal with
  the problem in an interoperable way.

  RFC7296 defines a generic notification code that is related to a
  failure to handle an internal address failure. That code does not
  explicitly allow an initiator to determine why a given address family
  is not assigned, nor whether it should try using another address
  family. The Working Group will specify a set of more specific
  notification codes that will provide sufficient information to the
  IKEv2 initiator about the encountered failure. A possible starting
  pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes.

  Some systems support security labels (aka security context) as one of
  the selectors of the SPD. This label needs to be part of the IKE
  negotiation for the IPsec SA. Non-standard implementations exist for
  IKEv1 (formerly abusing IPSEC Security Association Attribute 10, now
  using private space IPSEC Security Association Attribute 32001). The
  work is to standarize this for IKEv2, in a way that will be backwards
  compatible with old implementations, meaning it must not require any
  changes to implementations not supporting this.

  RFC8229, published in 2017, specifies how to encapsulate
  IKEv2 and ESP traffic in TCP.  Implementation experience has
  revealed that not all situations are covered in RFC8229, and that may
  lead to interoperability problems or to suboptimal performance. The WG
  will provide a document to give implementors more guidance about how to use
  reliable stream transport in IKEv2 and clarify some issues that have been
  discovered. A possible starting point is draft-smyslov-ipsecme-tcp-guidelines.

  The demand for Traffic Flow Confidentiality has been increasing in the user
  community, but the current method defined in RFC4303 (adding null
  padding to each ESP payload) is very inefficient in its use of network
  resources. The working group will develop an alternative TFC solution that
  uses network resources more efficiently.

Goals and Milestones:
  Dec 2019 - The internal address failure indication in IKEv2 to IESG
  May 2020 - G-DOI for IKEv2 to IESG
  May 2020 - Postquantum cryptography document for IKEv2 to IESG
  Aug 2020 - The security labels support for IKEv2 to IESG
  Aug 2020 - TCP-encapsulation guidelines document to IESG
  Nov 2020 - Traffic Flow Confidentiality document to IESG
  Jun 2021 - The ESP on contrained network to IESG
  Jun 2021 - Signature algorithm negotiation for IKEv2 to IESG


All charter page changes, including changes to draft-list, rfc-list and milestones:



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