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

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

Hi Riad,

The factual difference between OPAQUE and SRP-6a is that in OPAQUE, the server is authenticated first, whilst in SRP-6a, the client is authenticated first. The order of authentication has a profound implication in security here. For the case of OPAQUE, the server leaks password verification information via the key confirmation string in the 2nd pass before the client is authenticated. If the client drops out, the server can’t distinguish legitimate drop-outs from online guessing attacks. This means that the server has to deal with false positives (denying legitimate users hence causing the DoS attack to its own users) and false negatives (letting an attacker guess the password without being detected or logged). Managing the false positive and false negative can be complicated in practice.

By comparison, in SRP-6a, the protocol ensures the client be authenticated first. The server doesn’t leak any password verification info in the 2nd pass. If the client drops out after the 2nd pass, it doesn’t learn anything useful about the password stored at the server.  The server can precisely distinguish an online dictionary attack from drop-outs or network errors. An authentication failure is defined entirely based on the fact that the password from the client doesn’t match that on the server. In other words, there is no false positive or false negative regardless of the network conditions.

For your information, the concept of “an undetectable online dictionary attack” is not my invention. It’s an established technical term that has existed in the literature for nearly 30 years. For example, see Ding and Horster’s 1995 paper at ACM SIGOPS [1]. This is a realistic attack. Calling this marketing is not appropriate.

We showed that that the original 2-pass OPAQUE protocol in the 2018 OPAQUE paper was vulnerable to this undetectable online dictionary attack (as well as another problem that the protocol leaks the password update information to a passive attacker). This result was published in a peer-reviewed paper at FC’24. I noticed that the OPAQUE paper had been recently updated, requiring 3 passes instead of 2. I had initially assumed that this changed was motivated by addressing the undetectable online dictionary attack. However, after several rounds of discussions with Hugo (with initial confusion on my part), it has become clear to me that the OPAQUE authors were not aware of this attack, the change from 2-pass to 3-pass was done for a different reason, and that the 3-pass OPAQUE as defined in the latest OPAQUE paper and the current IETF draft remains vulnerable to this attack (because the server still leaks password verification information in the 2nd pass). This issue needs to be addressed.

Last but not least, may I suggest you strictly limit your comments to technical discussions only? I’m here trying to clarify technical facts. Your response and the suggested text for the Security Considerations indicate that you may have misunderstood the technical issue being discussed here.

[1] Ding, Yun, and Patrick Horster. "Undetectable on-line password guessing attacks." ACM SIGOPS Operating Systems Review 29.4 (1995): 77-86.

Cheers,
Feng


From: Riad S. Wahby <[e-mail]>
Date: Friday, 24 May 2024 at 15:52
To: Hao, Feng <[e-mail]>
Cc: Kevin Lewi <[e-mail]>, IRTF CFRG <[e-mail]>
Subject: Re: [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13
Hello Feng,

"Hao, Feng" <[e-mail]> wrote:
> @Riad, please note that the undetectable online dictionary attack is
> different from the (standard) online dictionary attack. The "completely
> standard attack detection heuristic" applies to the latter only.

This is false. Your "undetectable online dictionary attack" is just a
marketing term that's used to make a minor optimization sound important.

Of course it's detectable, and in exactly the same way that all online
attacks are detectable: the server just counts all authentication attempts
against the rate limit, whether they drop out before completion or not.
As I previously argued, that's the correct behavior no matter which PAKE
you use; it completely dispenses with your "undetectable" attack; and by
the way it is already standard practice.

If there's something to be added to the Security Considerations of OPAQUE
(and indeed, any PAKE document), it's just this: authentication attempts
must be strictly rate limited because passwords are subject to guessing.
That's been the completely standard advice roughly forever, but it doesn't
hurt to remind the reader lest they become confused by silly marketing.

Let's please stop flogging this dead horse. The concern trolling over easily
detected "undetectable" attacks has long since become embarrassing.

-=rsw