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 protected]> wrote: > > 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 protected] > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
