Subject: [CFRG] comments on opaque-06 and voprf-07 drafts

From: "Gajcowski, Nicholas H" <[email-masked]>
Date: Wed, 25 Aug 2021 14:05:56 +0000

Hi Folks,

I've read through the opaque-06 and voprf-07 drafts and noticed a few minor typos/errors.

First, a question for opaque-06:  Does the client authenticate the server based on the server_public_key provided to it in the ke2 portion of the AKE exchange? This seems to undermine the KCI protection afforded to the client by the AKE in the event the client's password is compromised.  With knowledge of the password, an attacker can essentially act as both the server and client in a faux registration phase.  Moreover, he can pick his own OPRF key, create his own server_public_key, and use the password to create a valid record with the appropriate auth_tag, etc.  When the client sends his ke1 message, the attacker can include his constructed record in the ke2 response which then would be accepted by the client.  If this correct, perhaps consider making a note of this feature as it may partially undermines an expected property of the AKE.

Below are a list of some minor errors/typos:

opaque-06:

pg 18 1st paragraph:  ... "The private-public keys (client_private_key, client_public_key) may be randomly generated." 
  Should read "The client_private_key may be randomly generated" as the client_public_key is a function of the client_private_key.

pg 27 step 7 of RecoverCredentials function:  "Output (client_private_key, response.server_public_key, export_key)."
  Should read "Output (client_private_key, server_public_key, export_key)."  While the server_public_key is a member of RegistrationRespone
  (section 5.1), it is not a member of CredentialResponse (6.1.1).  However, server_public_key is derived in step 5.

pg 32 outputs of ClientInit function: "ke1, blind, client_secret"
   The function does not return blind or client_secret as an output per se.  Rather, it updates the value for state.blind and the
   value state.client_secret is updated by the start function.  

pg 33 outputs of Start function:  "ke1 client_secret".
   Return of client-secret is unnecessary as the state is updated in step 4.  Further, the start function is only invoked by ClientInit
   which only expects the output of ke1.

pg 34 step 2 of ClientFinalize
   Preamble has an input of state.ke1 which was never updated by either ClientInit or Start functions.  Should the ClientInit function also 
   update the value for state.ke1, rather than return ke1, to be consistent with how it handles blind and client_secret?  

pg 36 step 9 of Response:  "Populate state with ServerState(expected_client_mac, session_key)"
   Syntax is a little confusing as expected_client_mac and session_key can be mistaken as inputs to the function ServerState.

pg 41 second to last paragraph of section 10.1:  "...Then, the client can verify that the client_identity and server_identity contained in its envelope..."
   The client_identity and server_identity are contained in CleartextCredentials which is not included as part of the envelope.  However, the auth_tag
   is computed over the nonce, innner_env, and CleartextCredentials in step 7 of the CreateEnvelope function. 

voprf-07:

pg 2 first paragraph of the introduction:  "...K(_) = F(K, _)"
   The secound K should be lowecase, i.e., "K(_) = F(k, _ )".

pg 12 VerifyFinalize function:  "issuedElement = Evaluate(skS, [element])"
   Unclear why square braces appear.  Should it be just "issuedElement = Evaluate( sks, element )"?

pg 12 VerifyFinalize function:  "E = GG.SerializeElement(issuedElement)"
   The function Evaluate in the previous step returns issuedElement as a SerializeElement so this step should result in error.

Best,

Nick Gajcowski

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 25 Aug 2021 17:18:17 -0400

Hi Nicholas, in regards to your first question: The server authenticates
using the server_public_key included and authenticated in the envelope. The
attack you describe is unavoidable if all the client has for authentication
and verification is the user's password, in particular, this applies to all
aPAKE protocols. As you say, the attacker can always simulate a
registration using the user's password and there is no way the user can
distinguish this fake registration from the real one just using the
password. Note that this also allows the attacker to mount a guessing
attack on a password, namely, an online dictionary attack, also unavoidable.

The important (and achievable) KCI property for an aPAKE is that if the
attacker gets the server's public key (but not the password), it still
cannot authenticate as the user.

If you run OPAQUE over TLS, where in addition to the authentication via
OPAQUE you have authentication via a server's TLS certificate then you
prevent the above attacks but it is not a "password only" protocol anymore
(as in addition to the password, the client also needs the authentic
server's TLS key).

Using the server's TLS certificate, if available and verifiable by the
client , has the added advantage that it protects the user's account
information from eavesdroppers.

I hope this answers your first question (I leave it to others to respond to
your other editorial comments).

Hugo

On Wed, Aug 25, 2021 at 10:06 AM Gajcowski, Nicholas H <nhgajco=
[email-masked]> wrote:

> First, a question for opaque-06:  Does the client authenticate the server
> based on the server_public_key provided to it in the ke2 portion of the AKE
> exchange? This seems to undermine the KCI protection afforded to the client
> by the AKE in the event the client's password is compromised.  With
> knowledge of the password, an attacker can essentially act as both the
> server and client in a faux registration phase.  Moreover, he can pick his
> own OPRF key, create his own server_public_key, and use the password to
> create a valid record with the appropriate auth_tag, etc.  When the client
> sends his ke1 message, the attacker can include his constructed record in
> the ke2 response which then would be accepted by the client.  If this
> correct, perhaps consider making a note of this feature as it may partially
> undermines an expected property of the AKE.
>
> pg 18 1st paragraph:  ... "The private-public keys (client_private_key,
> client_public_key) may be randomly generated."
>   Should read "The client_private_key may be randomly generated" as the
> client_public_key is a function of the client_private_key.
>
> pg 27 step 7 of RecoverCredentials function:  "Output (client_private_key,
> response.server_public_key, export_key)."
>   Should read "Output (client_private_key, server_public_key,
> export_key)."  While the server_public_key is a member of
> RegistrationRespone
>   (section 5.1), it is not a member of CredentialResponse (6.1.1).
> However, server_public_key is derived in step 5.
>
>    The function does not return blind or client_secret as an output per
> se.  Rather, it updates the value for state.blind and the
>    Return of client-secret is unnecessary as the state is updated in step
> 4.  Further, the start function is only invoked by ClientInit
>    Preamble has an input of state.ke1 which was never updated by either
> ClientInit or Start functions.  Should the ClientInit function also
>    update the value for state.ke1, rather than return ke1, to be
> consistent with how it handles blind and client_secret?
>
> pg 36 step 9 of Response:  "Populate state with
> ServerState(expected_client_mac, session_key)"
>    Syntax is a little confusing as expected_client_mac and session_key can
> be mistaken as inputs to the function ServerState.
>
> pg 41 second to last paragraph of section 10.1:  "...Then, the client can
> verify that the client_identity and server_identity contained in its
> envelope..."
>    The client_identity and server_identity are contained in
> CleartextCredentials which is not included as part of the envelope.
> However, the auth_tag
>    The function Evaluate in the previous step returns issuedElement as a
> SerializeElement so this step should result in error.
>
>
> Best,
>
> Nick Gajcowski
>
>
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>