[CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13

["Hao, Feng" <[e-mail]>]

The counter-based threshold control at the server can get far more complicated than what you describe because of the “undetectable” nature of this online dictionary attack – the server can’t distinguish legitimate drop-outs (say due to network delay or error) and illegitimate ones (say an attack), and hence can’t reliably define what’s meant by an authentication failure.  Legitimate users may be locked out of their accounts, not because of using the wrong password, but because of the data retransmissions in a slow network. I should highlight that SRP-6a is not subject to this attack, and is more secure in this regard.

Cheers,
Feng

From: Hugo Krawczyk <[e-mail]>
Date: Wednesday, 22 May 2024 at 15:07
To: Hao, Feng <[e-mail]>
Cc: IRTF CFRG <[e-mail]>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13
This does not require a 4th message. If the server counts the number of unsuccessful authentication attempts, it will increase the counter for the user upon receiving the first message and decrease it upon receiving a valid third message.

On Wed, May 22, 2024 at 4:04 AM Hao, Feng <[e-mail]<mailto:[e-mail]>> wrote:

This was explained in my first email on this thread and in the FC paper. Apologies if that was not clear.

The key confirmation string in the 2nd message allows the client to check if the password guess is correct. If the malicious client drops out at this stage, the server can’t distinguish whether it’s a drop-out or an authentication failure, hence the online dictionary attack can be undetectable. To prevent this attack, we need to ensure the client is authenticated first. This requires a revision in the OPAQUE protocol: the server can’t send any key confirmation string in the 2nd message. The client sends a key confirmation string in the 3rd message. The server can only send its key confirmation string in the 4th message.

Regards,
Feng

From: Hugo Krawczyk <[e-mail]<mailto:[e-mail]>>
Sent: 21 May 2024 17:24
To: Hao, Feng <[e-mail]<mailto:[e-mail]>>
Cc: IRTF CFRG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13

Care to expand on undetectable online dictionary attacks? And how is any attack on the server resolved by the server sending one more message.

On Tue, May 21, 2024 at 9:31 AM Hao, Feng <[e-mail]<mailto:[e-mail]>> wrote:

That makes the server subject to an undetectable online dictionary attack.


From: Hugo Krawczyk <[e-mail]<mailto:[e-mail]>>
Sent: 21 May 2024 14:21
To: Hao, Feng <[e-mail]<mailto:[e-mail]>>
Cc: IRTF CFRG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13

Yes.
On Tue, May 21, 2024, 04:01 Hao, Feng <[e-mail]<mailto:[e-mail]>> wrote:

Does OPAQUE send any key confirmation string in the second message?

From: Hugo Krawczyk <[e-mail]<mailto:[e-mail]>>
Sent: 21 May 2024 04:02
To: Hao, Feng <[e-mail]<mailto:[e-mail]>>
Cc: IRTF CFRG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13

Sorry Feng. You are wrong about the need for a 4th message in OPAQUE. Full forward secrecy (against passive and active attackers) is provided by the 3-message protocol as documented in the paper's full version and in this draft. The undetectable online attack you refer to in your paper has nothing to do with forward secrecy or the need of a 4th message in OPAQUE.


On Mon, May 20, 2024 at 4:16 AM Hao, Feng <[e-mail]<mailto:[e-mail]>> wrote:
Hi Hugo,

The cases of achieving forward security in TLS 1.3 and OPAQUE are different. Please allow me to elaborate.

You introduced the weak/strong definitions of forward security in your 2005 HMQV paper. For a two-message AKE scheme with weak forward security, strong forward security can be obtained by sending a third message (to complete mutual authentication with explicit key confirmation). By “full forward security” in the updated OPAQUE paper on IACR e-print, I believe you refer to the strong notion since the paper mentions “against active attacks”.

TLS 1.3 provides weak forward security in 1-RTT and requires 3 messages to achieve strong forward security. The OPAQUE paper follows the same.

However, in TLS 1.3, the server holds a strong secret. But in augmented PAKE, the server holds a weak secret. This difference is crucial.

As a result, the 3-message OPAQUE scheme with strong forward security is insecure as it’s vulnerable to an undetectable online dictionary attack. To prevent this attack, OPAQUE needs to be revised to require 3 messages to provide weak forward security, and 4 messages to achieve strong forward security.

Therefore, the change from 2-message OPAQUE to 3-message OPAQUE has nothing to do with forward security (weak or strong). This revision in the protocol spec is necessary to prevent the undetectable online dictionary attack (which is a known attack in the PAKE literature but seems not covered in the original formal model and analysis in the 2018 OPAQUE paper). This attack doesn’t apply to TLS 1.3 because the TLS server holds a strong key (as opposed to a weak one).

PS. We explained the undetectable online dictionary attack in our FC’24 paper (https://eprint.iacr.org/2023/768.pdf) To the best of my knowledge, this attack was not discussed during the PAKE review of OPAQUE.

Regards,
Feng

From: Hugo Krawczyk <[e-mail]<mailto:[e-mail]>>
Sent: 17 May 2024 04:16
To: Hao, Feng <[e-mail]<mailto:[e-mail]>>
Cc: IRTF CFRG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13

The common definition of forward security, and the one followed in the internet draft (and paper), is that session keys remain secure (after being deleted) even upon the compromise of long-term key material in the future. In the case of aPAKEs, forward secrecy applies to the password, namely, a future leakage of the password does not compromise past session keys. This is achieved by OPAQUE in 3 messages (similar to the way that TLS 1.3 achieves forward security in 3 messages).

Hugo

On Thu, May 16, 2024 at 3:49 AM Hao, Feng <[e-mail]<mailto:[e-mail]>> wrote:
Hi Hugo,


>  As for the 3-message issue, to address your concern, we intend to add the following sentence to the noticeable differences (with OPAQUE paper) section:


>  - The AKE describes a 3-message protocol where the third message includes client authentication material that the server is required to verify. This change (from the original 2-message protocol) was made to provide explicit client authentication and full forward security. The 3-message protocol is analyzed in the full version of [JKX18].

Sorry for my delayed response on this. If you want full forward security in the strong sense (with explicit mutual key confirmation), you will need 4 messages for OPAQUE, not 3. You can’t do explicit key confirmation in the 2nd pass. So the client sends its explicit key confirmation in the 3rd pass, and the server can only send its explicit key confirmation in the 4th pass. That takes 4 passes in total. As explained earlier, the reason that we may call OPAQUE a 3-pass scheme is entirely because 3 passes are the minimum required to finish client-to-server authentication for an augmented PAKE in a client-server setting and that the client needs to be authenticated first. At the end of the 3rd pass, the authentication from the server to the client is still implicit. I would suggest you remove the “and full forward security”. The claim of full forward security for the 3-message OPAQUE in the full version of the paper may need to be updated as well.

Regards,
Feng