<div dir="ltr">Hi guys!<div><br></div><div>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 <a href="https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-04">here</a>.</div><div><br></div><div>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.</div><div><br></div><div><div>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.</div></div><div><br></div><div>The following would be done:</div><div>- There would be new connection configuration option, named <b>ppk</b>. The accepted values would be:</div><div><i>insist</i>, <i>never </i>and <i>permit. </i>The default value would be <i>permit</i>. 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.</div><div>- 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.</div><div>- .secrets file for dynamic PPK would look like:</div><div>ip.address.1 FQDN2 ip.address.2 : <b>PPK</b> PPK_id, where ip addresses and FQDN would be IDs of the peers that are preconfigured to use this PPK (like in PSK secrets), <b>PPK </b>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.</div><div>- .secrets file for static PPK would look like:</div><div>ip.address.1 FQDN2 ip.address.2 : <b>PPK "</b>0fb4edd9...1daa", where the string after <b>PPK </b>would be the PPK itself (in hex format in example)</div><div>- 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). </div><div><br></div><div>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.</div><div><br></div><div>Kind regards,<br>Vukasin Karadzic</div></div>