Subject: [IPsec] Proposed charter text

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Feb 2018 19:55:13 +0200

Here is the current proposed charter text about the items we managed
to agree in the IETF 100 meeting. I have left out the items we didn't
manage to have consensus, and I will send another email after this to
start discussion about them.

If you have comments (or objections) adding these new items to the
charter send your comments as soon as possible. 

----------------------------------------------------------------------

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:

Old items

QR IKEv2 (old)

    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 IKEv2 to have similar quantum resistant
    properties than IKEv1 had.

Split DNS (old, almost done == can be removed)

    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 IKEv2.

Implicit IV (old, almost done == can be removed)

    Currently, widely used counter mode based ciphers send both the
    ESP sequence number and IV in form of 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.

New items

Group DOI for IKEv2 (new)

    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 for IKEv2 (new)

    Postquantum Cryptography brings new key exchange methods. Most of
    these methods that are known to date have much larger public keys
    then conventional Diffie-Hellman public keys. Direct 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.

Diet-ESP/IKE(new)

    A growing number of use cases for constraint network - but not
    limited to - 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.

    draft-mglt-ipsecme-diet-esp and
    draft-mglt-ipsecme-ikev2-diet-esp-extension are expected to be
    good starting points for ESP compression.
    draft-smyslov-ipsecme-ikev2-compression and
    draft-smyslov-ipsecme-ikev2-compact are good starting point for
    IKEv2 compression.

Signature algorithm negotiation (new)

    RFC7427 allows peers to indicate hash algorithms they support,
    thus eliminating ambiguity in selecting a hash function for
    digital signature authentication. However, recent advances in
    cryptography lead to a situation when some signature algorithms
    have several signature formats. A prominent example is
    RSASSA-PKCS#1 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
    each other which signature format(s) the support, that leads to
    ineroperability 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.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 Feb 2018 14:19:53 -0500

Tero Kivinen <[email-masked]> wrote:
    > Here is the current proposed charter text about the items we managed to
    > agree in the IETF 100 meeting. I have left out the items we didn't

    > charter send your comments as soon as possible.

I've read the new charter, and I think it's reasonable.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Fri, 16 Feb 2018 14:59:41 -0500 (EST)

> host-to-host, host-to-network, and network-to-network security.

Can we add "mesh" to this, eg:

 	and as a substrate for host-to-host, host-to-network,
 	network-to-network and mesh security.

>    parallel with (or instead of) the existing Diffie-Hellman key

I think "develop a solution" is a bit too strong here. I think we are
really "developing experiments to gain operational experience" and in
a latter stage "focus on providing a single solution".

I'm fine with all other charter items listed.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Feb 2018 22:22:07 +0200

>  	network-to-network and mesh security.

We could, but I think mesh is just host to host between lots of hosts
pairs. I do not think we currently have anything that would really be
directed for mesh security.

> I think "develop a solution" is a bit too strong here.

We are developing solution to make adding postquantum key exchange
methods easier. That does not necessarely mean we are solving the
whole issue.

> I think we are really "developing experiments to gain operational
> experience" and in a latter stage "focus on providing a single
> solution".

Do you have proposed new text or actual changes for this item?
-- 
[email-masked]