Subject: [IPsec] New charter proposal

From: Tero Kivinen <[email-masked]>
Date: Wed, 20 Jul 2016 15:45:54 +0300

As we discussed in the meeting yesterday, we need to update the
charter and we are making following changes to it:

- Removing the opportunistic use case as null authentication has
  already been published as RFC7619.

- Keep the DDoS case, but change the milestone from Mar 2016 to Aug
  2016 for IETF LC.

- Add Mandatory to implement algorithms RFCs (4307bis, 7321bis) with
  milestone as Sep 2016 for IETF LC.

- Add new algorithm drafts (curve25519, curve448) with milestone as
  Sep 2016 for IETF LC of Diffie-Hellman, and Dec 2016 for EdDSA.

- Add Quantum Resistance for IKEv2 as new work item with milestone as
  Feb 2017 for IETF LC.

- Add TCP Encapsulation for IKEv2 as new work item with milestone as
  Dec 2016 for IETF LC.

- Add Split DNS as new work item with milestone as Dec 2016 for IETF
  LC.

- Add Implicit IV as new work item with milestone as Dec 2016 for IETF
  LC. 

Here is the new proposed charter. Note, that I did edit and clean up
some of the charter items from the ones we had on slides in meeting,
and there is two new items we agreed in the meeting (split dns and
implicit IV). 

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

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs), 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
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:

IKEv2 contains the cookie mechanism to protect against denial of
service attacks. However this mechanism cannot protect an IKE
end-point (typically, a large gateway) from "distributed denial of
service", a coordinated attack by a large number of "bots". The
working group will analyze the problem and propose a solution, by
offering best practices and potentially by extending the protocol.

IKEv2 utilizes a number of cryptographic algorithms in order to
provide security services. To support interoperability a number of
mandatory-to-implement (MTI) algorithms are defined in RFC4307 for
IKEv2 and in RFC7321 for ESP/AH. There is interest in updating the
MTIs in RFC4307 and RFC7321 based on new algorithms, changes to the
understood security strength of existing algorithms, and the degree of
adoption of previously introduced algorithms. The group will revise
RFC4307 and RFC7321 proposing updates to the MIT algorithms used by
IKEv2 and IPsec to address these changes.

There is interest in supporting Curve25519 and Curve448 for ephemeral
key exchange and EdDSA for authentication in the IKEv2 protocol. The
group will extend the IKEv2 protocol to support key agreement using
these curves and their related functions.

IKEv1 using shared secret authentication was partially resistance 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.

There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, IKE packets need to be
encapsulated in a TCP tunnel. The group will define a mechanism to
tunnel IKE and IPsec over a TCP-based connection. This method is
intended to be used as a fallback when IKE cannot be negotiated over
UDP. The group will create a method where IKEv2 and IPsec packets can
be encapsulated in the TCP connection.

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. 

Currently widely used counter mode based ciphers send both ESP
sequence number and the IV in form of counter, and as they are very
commonly same there has been interest to work on document that will
compress the packet and derive IV from the sequnce 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.

This charter will expire in December 2017. If the charter is not
updated before that time, the WG will be closed and any remaining
documents revert back to individual Internet-Drafts.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Jul 2016 14:52:46 +0200

Sent from my iPhone

> On Jul 20, 2016, at 2:45 PM, Tero Kivinen <[email-masked]> wrote:
> 

Looks good

Paul

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 20 Jul 2016 17:06:42 +0200

Looks good to me as well. Thanks!

Tommy

Sent from my iPhone

> On Jul 20, 2016, at 2:52 PM, Paul Wouters <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 20 Jul 2016 18:12:43 +0300

Hi, 

> - Add Quantum Resistance for IKEv2 as new work item with milestone as

This milestone looks a bit optimistic for me. 
Otherwise the updated chapter looks good.

Regards,
Valery.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 20 Jul 2016 18:25:27 +0200

> On Jul 20, 2016, at 5:12 PM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi, 
> This milestone looks a bit optimistic for me. Otherwise the updated chapter looks good.

The issue seems fairly urgent in people’s minds right now, and the initial goal was expressed to be a fairly minimal level of changes to get basic QR properties (add support for a PPK to protect ESP traffic). The goal is optimistic, but hopefully achievable! There will probably be more ongoing QR work after that time.

Tommy

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 20 Jul 2016 16:43:35 +0000

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Tommy Pauly
> Sent: Wednesday, July 20, 2016 12:25 PM
> To: Valery Smyslov
> Cc: [email-masked]; Tero Kivinen
> Subject: Re: [IPsec] New charter proposal
> 
> 
> The issue seems fairly urgent in people’s minds right now, and the initial goal
> was expressed to be a fairly minimal level of changes to get basic QR
> properties (add support for a PPK to protect ESP traffic). The goal is
> optimistic, but hopefully achievable!

How quickly achievable it is would depend on the requirements that the WG agrees upon.  If we assume minimal requirements (such as "we need to protect only IPsec traffic from a QC" and "a static shared secret (PPK) is sufficient"), then it's straightforward (the current draft is overkill for those requirements; IIRC, Tero outlined one such solution a while back).  If we insist on maximal requirements (such as "we need complete anonymity, even if the attacker has a QC", and "we need a complete PPK management solution"), well, Feb 2017 would be a bit on the optimistic side.

> There will probably be more ongoing QR
> work after that time.

I would certainly hope so; the current work assumes that there is some out-of-band quantum resistant mechanism for distributing (possibly static) secrets to the IKE endpoints; that's an acceptable solution in some situations, but not in others.  Eventually, we'll need a replacement that'll work everywhere; it's just that currently the crypto technology isn’t there quite yet (as McEliece has impractically large public keys, NTRU isn't universally trusted, and everything else is too new to bet the farm on...)

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Wed, 20 Jul 2016 16:45:02 +0000

If needed we could have some virtual meetings between IETF 96, 97, and 98 to work through issues. This could help increase bandwidth to make these milestones.

Dave

-------- Original Message --------
From: Tommy Pauly <[email-masked]>
Date: Wed, July 20, 2016 6:25 PM +0200
To: Valery Smyslov <[email-masked]>
CC: [email-masked], Tero Kivinen <[email-masked]>
Subject: Re: [IPsec] New charter proposal

Tommy

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 20 Jul 2016 19:56:13 +0300

> Otherwise the updated chapter looks good.

The limited resistance we are talking about is in the same level of
protection which IKEv1 has, i.e., PPK. We are not yet talking about
doing using any quantum resistant protocols to generate the PPK, we
just assume that the PPK comes through some out of band method and we
can want to make sure we use it in the protocol in the way that makes
IKEv2 quantum resistant in a way that traffic stored now using this
extension cannot be decrypted after the quantum computers are there,
and attackers can break Diffie-Hellman done in IKEv2.

I.e., the actual work item is:

and I think we should be able to finish that in WG in the next 6
months.  
-- 
[email-masked]

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 20 Jul 2016 21:58:59 +0000

+1 

Tero, 
Waiting for your IKEv2 quantum resistance slides to become available, as a great summary of the potential requirements.

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Tero Kivinen
Sent: Wednesday, July 20, 2016 12:56 PM
To: Valery Smyslov <[email-masked]>
Cc: [email-masked]
Subject: Re: [IPsec] New charter proposal

Valery Smyslov writes:
> > - Add Quantum Resistance for IKEv2 as new work item with milestone 
> > as  Feb 2017 for IETF LC.
> 

The limited resistance we are talking about is in the same level of protection which IKEv1 has, i.e., PPK. We are not yet talking about doing using any quantum resistant protocols to generate the PPK, we just assume that the PPK comes through some out of band method and we can want to make sure we use it in the protocol in the way that makes
IKEv2 quantum resistant in a way that traffic stored now using this extension cannot be decrypted after the quantum computers are there, and attackers can break Diffie-Hellman done in IKEv2.

IKEv1 using shared secret authentication was partially resistance 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.

and I think we should be able to finish that in WG in the next 6 months.  
--
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 21 Jul 2016 02:28:15 +0300

Panos Kampanakis (pkampana) writes:
> Waiting for your IKEv2 quantum resistance slides to become
> available, as a great summary of the potential requirements. 

All the slides we presented in the IPsecME meeting was uploaded to the
meeting materials site before the meeting started, i.e.,

https://datatracker.ietf.org/meeting/96/materials/#ipsecme

contains ipsecme slides, minutes etc, and my slides can be found from
following url:

https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-1.pdf

We will most likely make start talking about requirements on the
mailing list and then collect list of the final requirements somewhere
(not sure if we need draft for that, we might use wiki page to keep
track of them, or just collect the feedback from the list, and send
summary of them to the mailint list).

I think I will wait until next week before starting that process, so
we can get the charter discussion out before that.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Jul 2016 03:35:41 -0400

New charter seems fine.

(I am pessimistic about the milestones, but I suggest changing them as needed
rather than planning to take longer.)

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

---

From: Yoav Nir <[email-masked]>
Date: Fri, 22 Jul 2016 09:59:12 +0200

+1

> On 22 Jul 2016, at 9:35 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> New charter seems fine.
>