explicit auth necessary for opaque security?

[stef]

doing my full re-read of the doc, for the rglc, i noticed this sentence in section 6:

KE3 provides explicit client authentication and full forward security (without it, forward secrecy is only achieved against eavesdroppers, which is insufficient for OPAQUE security)

skipping KE3 and using the session_key for a protected channel successfully provides implicit authentication, does the above quote mean that with implicit auth OPAQUE security would be reduced? if so how? as the original paper states this implicit auth possibility, it makes sense to describe this deviation and reduced opaque security in the document.

[hugokraw]

OPAQUE with a key exchange that is not forward secure is not a secure aPAKE. The first version of the OPAQUE paper did not identify this issue (forward secrecy was implicit in the formalization of key exchange but not identified as an explicit requirement). This was corrected in subsequent eprint publication (and in the CFRG mailing list). The issue is that if the server sends information encrypted under the session key immediately after the server's (single) OPAQUE message (without waiting for authentication from the user) then the following attack is possible. The attacker opens a session with the server in the name of some user for whom the attacker does not know the password but where the attacker chooses the ephemeral private key. When the server responds with its OPAQUE message and encrypts information under the session key, the attacker cannot decrypt it as it does not know the password. However, the attacker will be able to decrypt it if it learns the password in the future. The forward secrecy model of aPAKE is that once an attacker learns a password, all future sessions may be insecure, but past sessions should remain secure.

[stef]

Thank you very much for this insightful answer!

So the attack only applies if the server sends data encrypted with it's opaque response. right? if it doesn't then the implicit authentication should be enough? I think this is a very interesting and important detail. I'm not sure if this needs to be mentioned explicitly in the document though, what do you think @kevinlewi @chris-wood ?

[kevinlewi]

I think it's ok to not add this explicitly to the document, since references to this are already present in multiple locations. In addition to the one cited above, under the ServerFinish section:

The AuthServerFinalize function takes KE3 as input and MUST verify the client authentication material it contains before the session_key value can be used. This verification is necessary to ensure forward secrecy against active attackers.

Closing this issue but feel free to re-open if anyone thinks we should add more verbiage to the document