WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme)

The IESG <iesg-secretary@ietf.org> Mon, 17 September 2018 21:30 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C48130DFF; Mon, 17 Sep 2018 14:30:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Subject: WG Action: Rechartered IP Security Maintenance and Extensions (ipsecme)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: ipsec@ietf.org, ipsecme-chairs@tools.ietf.org, ipsecme-chairs@ietf.org, The IESG <iesg@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <153721980519.24684.7975791578913292986.idtracker@ietfa.amsl.com>
Date: Mon, 17 Sep 2018 14:30:05 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/1vo9GJPQUpP7ygF1bXHxmKhgaHw>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Sep 2018 21:30:05 -0000

The IP Security Maintenance and Extensions (ipsecme) WG in the Security Area
of the IETF has been rechartered. For additional information, please contact
the Area Directors or the WG Chairs.

IP Security Maintenance and Extensions (ipsecme)
Current status: Active WG

  David Waltermire <david.waltermire@nist.gov>;
  Tero Kivinen <kivinen@iki.fi>;

Assigned Area Director:
  Eric Rescorla <ekr@rtfm.com>;

Security Area Directors:
  Eric Rescorla <ekr@rtfm.com>;
  Benjamin Kaduk <kaduk@mit.edu>;

Mailing list:
  Address: ipsec@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/ipsec
  Archive: https://mailarchive.ietf.org/arch/browse/ipsec/

Group page: https://datatracker.ietf.org/group/ipsecme/

Charter: https://datatracker.ietf.org/doc/charter-ietf-ipsecme/

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.

Split-DNS is a common configuration for VPN deployments in which only
one or a few private DNS domains are accessible and resolvable via the
tunnel. Adding new configuration attributes to IKEv2 for configuring
Split-DNS would allow more deployments to adopt IKEv2. This
configuration should also allow verification of the domains using
DNSSEC. Working group will specify needed configuration attributes for

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

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

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-smyslov-ipsecme-ikev2-compression and

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.


  Apr 2018 - IETF Last Call on Split-DNS Configuration for IKEv2

  Apr 2018 - IETF Last Call on Implicit IV in IPsec

  May 2018 - IETF Last Call on partially quantum resistant IKEv2

  Oct 2018 - The internal address failure indication in IKEv2 to IESG

  Dec 2018 - The ESP on contrained network to IESG

  Dec 2018 - G-DOI for IKEv2 to IESG

  Jan 2019 - The security labels support for IKEv2 to IESG

  Mar 2019 - Signature algorithm negotiation for IKEv2 to IESG

  May 2019 - Postquantum cryptography document for IKEv2 to IESG