Subject: [IPsec] Charter items

From: Tero Kivinen <[email-masked]>
Date: Thu, 2 Nov 2017 18:04:20 +0200

I have now received following items for consideration for charter
(includes old items not finished in the current charter):

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

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

MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from
one IP address to another. However, in MOBIKE it is the initiator of
the IKE SA (i.e. remote access client) that controls this process. If
there are several responders each having own IP address and acting
together as a load sharing cluster, then it is desirable for them to
have ability to request initiator to switch to a particular member.
The working group will analyze the possibility to extend MOBIKE
protocol or to develop new IKE extension that will allow to build load
sharing clusters in an interoperable way.

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.

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

There was also some other suggestions but there was no suitable text
for charter for them, so if people want them to be considered, provide
text.

Did I catch everything else properly?

We will be working on these items in the mailing list next week and
most likely during signapore session too.
-- 
[email-masked]

---

From: Cen Jung Tjhai <[email-masked]>
Date: Thu, 2 Nov 2017 16:18:21 +0000

Hi Valery,

Many thanks for providing the charter text on making IKEv2 post quantum key ready.

Could we add another sentence to it so that it reads as follows:

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 the existing Diffie-Hellman key 
exchange. 

Best regards,
CJ

> On 2 Nov 2017, at 16:04, Tero Kivinen <[email-masked]> wrote:
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 2 Nov 2017 20:55:45 +0300

Hi Cen Jung,

I'd rather avoid focusing on hybrid key exchange only. 
In my understanding hybrid key exchange will (should?) eventually
become PQ-only key exchange. That's why I'd rather express
charter in more generic way, so that it is applicable for
both hybrid and PQ-only cases, since both have the same problem 
with large public keys.

How about the followingy last sentence:

The solution will allow post quantum key exchange to be 
performed in parallel with (or instead of) the existing Diffie-Hellman key 
exchange.

Regards,
Valery.

---

From: Cen Jung Tjhai <[email-masked]>
Date: Thu, 2 Nov 2017 18:25:01 +0000

Hi Valery,

Yes, In the future (after NIST process is completed or general purpose quantum computers are available), one may want to use post quantum key exchange only.

Happy with your last sentence.

Cheers,
CJ

> On 2 Nov 2017, at 17:55, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Cen Jung,
> 
> I'd rather avoid focusing on hybrid key exchange only. In my understanding hybrid key exchange will (should?) eventually
> both hybrid and PQ-only cases, since both have the same problem with large public keys.
> 
> The solution will allow post quantum key exchange to be performed in parallel with (or instead of) the existing Diffie-Hellman key exchange.
> 
> Regards,
> Valery.
> 
>> Hi Valery,
>> exchange methods more easy. The solution will allow post quantum key exchange to be performed in parallel with the existing Diffie-Hellman key exchange. Best regards,
>> CJ
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Nov 2017 03:55:42 +0200

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

Updated to match to that.
-- 
[email-masked]