[Swan-dev] Postquantum Preshared Keys for IKEv2

Vukasin Karadzic vukasin.karadzic at gmail.com
Sat Jun 3 20:57:42 UTC 2017


Hi guys!

I am going to work this summer on implementing the Postquantum Preshared
Keys (PPK) in libreswan. You can read the IETF draft that discusses this
new IKEv2 feature here
<https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-04>.

The goal of this PPKs is to enable security of IPsec communication against
attacker in possession of quantum computer. That is achieved by adding one
more input, PPK, to pseudo-random function when deriving keys for IKE SAs.
Currently the only to an adversary unknown value that is used for initial
key derivation is Diffie-Hellman value, and Diffie-Hellman exchange is weak
against quantum computer.

Paul suggested that I present you here the project summary and get some
feedback. If you have any suggestions/requests/questions please say/ask
them.

The following would be done:
- There would be new connection configuration option, named *ppk*. The
accepted values would be:
*insist*, *never *and *permit. *The default value would be *permit*. The
result of trying to negotiate usage of PPK can be: aborting IKE negotation,
continue without using PPK, continue using PPK. The logic that leads to
this can be found in draft.
- There would exist two types of PPKs. Dynamic and static. Dynamic means
that PPK will be a one time pad and every time we would use some offset.
Every time a different offset and thus every time different (sub)key.
Static means that we will have one key that will be used for more than one
time for setup of IKE SA.
- .secrets file for dynamic PPK would look like:
ip.address.1 FQDN2 ip.address.2 : *PPK* PPK_id, where ip addresses and FQDN
would be IDs of the peers that are preconfigured to use this PPK (like in
PSK secrets), *PPK *would be an constant string that indicates which type
of secret it is, and PPK_id would be a name of the file where PPK is
stored. We would "deal" with offsets inside the PPK file.
- .secrets file for static PPK would look like:
ip.address.1 FQDN2 ip.address.2 : *PPK "*0fb4edd9...1daa", where the string
after *PPK *would be the PPK itself (in hex format in example)
- Every time after the peers have agreed on using PPKs, the IKE SA REKEY
would be automatically initiated, because the PPK would be incorporated in
SKEYSEED after the first rekey (see draft for details).

I think this outlines all of the "interface" that will be added to
libreswan. One more time, please feel free to ask any question, add a
suggestion or propose some addition.

Kind regards,
Vukasin Karadzic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20170603/7121044d/attachment.html>


More information about the Swan-dev mailing list