%% You should probably cite draft-ietf-ipsecme-ikev2-qr-alt instead of this I-D.
@techreport{smyslov-ipsecme-ikev2-qr-alt-09,
    number =    {draft-smyslov-ipsecme-ikev2-qr-alt-09},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-qr-alt/09/},
    author =    {Valery Smyslov},
    title =     {{Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security}},
    pagetotal = 11,
    year =      2023,
    month =     oct,
    day =       19,
    abstract =  {An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting it later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way to get protection against quantum computers, which is similar to the solution defined in RFC8784, but protects the initial IKEv2 SA too. Besides, RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 Security Association (SA) is created. If a fresh PPK is available before the IKE SA is expired, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification also defines a way to use PPKs in active IKEv2 SA for creating additional IPsec SAs and for rekeys operations.},
}