What authentication protocol to use for BB84 and other QKD protocols?

Just like other classical and quantum key distribution protocols, BB84 is vulnerable to "man"-in-the-middle attacks, where Eve pretends to be Bob to Alice, and Eve pretends to be Alice to Bob. The countermeasure against this potential "man"-in-the-middle attack is to implement authentication and data integrity checks on the Alice-Bob classical channel. ^{[1] [2] [4] [5]}

My question is: what authentication protocol should we use for BB84 and other QKD protocols?

I can think of the following candidates:

1. We could use pre-shared keys as suggested in [1]. But that feels problematic to me for two reasons.

   1.1. The whole point of having a key distribution protocol is to avoid the need for pre-shared keys. If the pre-shared key is ever leaked, authentication and hence the QKD protocol itself is compromised.

   1.2. A client can only connect to a server if the client and server already have agreed on a pre-shared key. In many use cases (e.g. web browser connecting to a web server) this is a very unreasonable requirement.

2. Start with a pre-shared key for the first key agreement. But during that first key agreement, generate some extra key bits that are used for authentication during the next key agreement, etc. This is suggested in [3] and [6]. However, if one of the devices loses its state (e.g. due to a power cycle or field replacement after a failure) we have to revert back to the first pre-shared key. Thus, the first pre-shared key will always be a vector of attack.

3. In classical key distribution protocols problem, both 1.1 and 1.2 are solved by using authentication protocols such as RSA or DSA that rely on PKI and on the use of certificates and trusted CAs. However, we cannot use RSA or DSA for QKD authentication because both RSA and DSA are quantum-unsafe (they assume discrete logs are hard).

So, to reiterate my question in another way, is there an authentication protocol that achieves both of the following goals?

A. It allows a client to authenticate any server without assuming that the client and server have a pre-shared key.

B. It is quantum-safe.

---

^References:

^{[1] [Is quantum key distribution safe against MITM attacks too?](https://crypto.stackexchange.com/questions/2719/is-quantum-key-distribution-safe-against-mitm-attacks-too#2721)}

^{[2] Van Meter, Rodney. Quantum Networking (Networks and Telecommunications). Wiley. Kindle Edition. Section 5.2: “A true man-in-the-middle attack is foiled by (and explains the need for) authentication and data integrity checks on the classical channel.”}

^{[3] Reis, André. Quantum Key Distribution Post Processing – A study on the Information Reconciliation Cascade Protocol. Section 1.1 footnote: “Specially important, those [extra key] bits can be used to generate Message Authentication Codes for future QKD executions to extend the length of the shared key”}

^{[4] Reis, André. Quantum Key Distribution Post Processing – A study on the Information Reconciliation Cascade Protocol. Section 2.2: “the classical phase uses a public classical authenticated channel (using Digital Signatures or Message Authentication Codes)”}

^{[5] ETSI GS QKD 002 V1.1.1 “Quantum Key Distribution; Use Cases”. Section 4.1.2: “Quantum key distribution, too, requires authentication of the parties to rule out man-in-the-middle attacks. This is done by public discussion on the classical channel which uses a message authentication primitive to guarantee message integrity.”}

^{[6] ETSI GS QKD 002 V1.1.1 “Quantum Key Distribution; Use Cases”. Section 4.1.3: “In QKD, a small fraction of the continuously generated key can be used for information theoretically secure message
authentication, but when a link is taken into operation, a pre-distributed initial secret is necessary to authenticate the
public channel before the first quantum keys become available. This is comparable to digital signature schemes, where
the public key (mostly in the form of identity certificates) of the sender, or the public key of a trusted third party, when
transitive trust relations are applied, must be pre-distributed (e.g. with the web browser). Insofar the necessity of a
pre-distributed secret constitutes no principal disadvantage of information theoretically secure authentication schemes,
as opposed to signature based or MAC based authentication systems, as this is claimed e.g. in [i.21].”}