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

[stef <[e-mail]>]

On Thu, May 23, 2024 at 01:46:08PM -0700, Kevin Lewi wrote:
> Hmm, I don't think I would characterize the situation you describe as an
> undetectable online dictionary attack, or a security concern, for the
> OPAQUE protocol itself. This would only be an attack surface if an
> application server built on top of OPAQUE chooses not to track password
> authentication attempts, and optimistically assumes that a client not
> responding after the second message means that they "dropped out". But, if
> the server treats all incomplete message exchanges as authentication
> failures, then there is no attack; only the risk of legitimate users being
> locked out.
> 
> However, for this latter concern, there are a bunch of things that the
> server can do to mitigate this risk. For instance, the server can raise the
> threshold of allowed password attempts from a single IP address/device to a
> larger number (say, 20) before the client is locked out. It might be very
> unlikely that a legitimate user attempts to connect 20 times, successfully
> receiving the second message but failing to transmit the third message each
> time, though of course this depends on the application setting. For servers
> that wish to tolerate a smaller threshold (say, 5): if the client drops out
> after the second message, they can cache the first message and replay the
> first message again to the server. If the server also caches their response
> to the first message, then this allows the server to simply return the
> cached second message without having to regenerate it. Now of course this
> may not apply to some application scenarios if it is not possible for the
> client or server to keep these caches around. But I wanted to highlight
> some of these options as they provide alternatives that can be addressed by
> the application layer.
> 
> At any rate, we do not think that this requires changing any part of the
> OPAQUE protocol (for example by adding a fourth message) to handle this.
> Hope that makes sense!

i think it would make sense to actually mention this in the "security
considerations" section. something along the lines:

  Online bruteforce attacks against the password are undistinguishable from
  network failures by the server if the attacker aborts the protocol after
  receiving the servers KE2 message. Any concrete deployment of OPAQUE must
  decide if the server uses a counter-based mechanism, or some other
  ratelimiting to mitigate or increase costs for an attacker.

I also think that this is not limited to OPAQUE, in fact other OPRF-based
protocols where the server provides additional information in the server-reply
to an attacker to check against the correctness of the guessed input are all
affected. And thus maybe this security consideration would also make sense in
the OPRF specification (which i know is already finished, so it's i guess too
late for this, but i thought to mention this anyway)

s

> On Thu, May 23, 2024 at 12:36 AM Hao, Feng <Feng.Hao=
> [e-mail]> wrote:
> 
> >
> >
> > 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]> 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]>
> > *Sent:* 21 May 2024 17:24
> > *To:* Hao, Feng <[e-mail]>
> > *Cc:* IRTF CFRG <[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]> wrote:
> >
> >
> >
> > That makes the server subject to an undetectable online dictionary attack.
> >
> >
> >
> >
> >
> > *From:* Hugo Krawczyk <[e-mail]>
> > *Sent:* 21 May 2024 14:21
> > *To:* Hao, Feng <[e-mail]>
> > *Cc:* IRTF CFRG <[e-mail]>
> > *Subject:* Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13
> >
> >
> >
> > Yes.
> >
> > On Tue, May 21, 2024, 04:01 Hao, Feng <[e-mail]> wrote:
> >
> >
> >
> > Does OPAQUE send any key confirmation string in the second message?
> >
> >
> >
> > *From:* Hugo Krawczyk <[e-mail]>
> > *Sent:* 21 May 2024 04:02
> > *To:* Hao, Feng <[e-mail]>
> > *Cc:* IRTF CFRG <[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]> 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]>
> > *Sent:* 17 May 2024 04:16
> > *To:* Hao, Feng <[e-mail]>
> > *Cc:* IRTF CFRG <[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]> 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 4
> > th 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
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > CFRG mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> >

---end quoted text---