[Cfrg] Integration of OPAQUE in IKEv2

[Hugo Krawczyk <[e-mail]>]

Hi Yoav and Valery,

thanks for your extensive analysis of the different PAKE candidates.
I would like to clarify some issues regarding the way you
envision the integration of OPAQUE in the context of IKEv2.

Let me first refer to Yoav's analysis
https://mailarchive.ietf.org/arch/msg/cfrg/PWhIOQKBHapZ1Rpbd7Brr_JFIg8
where he says:

> OPAQUE spends one round-trip on sending IDi and receiving EnvU and vU.
> OPAQUE spends another round-trip on the OPRF protocol.
> OPAQUE spends yet another round-trip for a KE exchange.
> The final IKE_AUTH flow uses the generated key for the AUTH payloads.
> Altogether 5 round-trips (or IKE_AUTH exchanges) are needed for user
> authentication.

This mimics the modular description in the OPAQUE draft that shows the
different
logical components. However, these components need not be run sequentially
but
rather in parallel, namely, piggybacking the OPRF to any existing AKE
protocol.
This is exemplified in the OPAQUE draft for any AKE with 3 flows as follows:

   Generic OPAQUE with 3-message KE:

   o  C to S: Uid, alpha=H'(PwdU)*g^r, KE1

   o  S to C: beta=alpha^kU, vU, EnvU, KE2

   o  C to S: KE3

Thus, one can integrate OPAQUE with IKEv2 at the cost of a single additional
message from C to S, and no change to the AUTH mechanics.

Here is how it would look (I keep Yoav's notation and add the OPAQUE
elements in
< ... >). The only changes to regular IKEv2 are piggybacking the elements
alpha, beta, vU, EnvU to the existing IKEv2 flows and adding the last
client-to-server flow with the AUTH value.


   User                              Server
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni  -->
                                <--  HDR, SAr1, KEr, Nr,
   HDR, SK {IDi,
       [IDr,] SAi2,
       TSi, TSr
       <alpha>}     -->
                                <--  HDR, SK {IDr, AUTH, <beta, vU, EnvU>}
   HDR, AUTH       -->


Server's AUTH needs no change, except that the signature is computed with
the server's key authenticated under EnvU, and client's AUTH in the added
flow is computed under the user's key under EnvU.

The first two flows don't change (except maybe for a HDR type indicating
password authentication). The value IDi is used to transfer user's account
information (whose privacy is protected against passive adversaries by
virtue of
the DH exchange (KEi, KEr)).

As you can see, my depiction above is quite similar to the way Valery
Smyslov
https://datatracker.ietf.org/doc/html/draft-smyslov-ikev2-pake
integrates OPAQUE with IKEv2, with two notable differences.
Valery's version (top of page 10 in the draft) takes three round trips
(instead
of 2.5) as he delays the server's AUTH to an additional sixth flow. In
contrast, I include this information in the fourth flow.
More significantly, Valery re-defines the AUTH values as
               AUTHi = sig(PrivU, <InitiatorSignedOctets>)
               AUTHr = sig(PrivS, <ResponderSignedOctets>)
This is not necessary. One can keep IKEv2's AUTH unchanged (as I said, only
the
public keys change from certificate-based to EnvU-based). Actually, defining
AUTH i/r as above would not be secure (it departs from the necessary logic
of
SIGMA-R underlying IKEv2).

Finally, responding to one of the points of Yoav, the password registration
procedure only takes 3 flows (C to S, S to C, C to S).

The common point to the above comments is that integrating OPAQUE into an
existing protocol should be quite painless. You just need to piggyback the
two
OPRF messages and EnvU to the existing key exchange flows. Assuming
extensibility of the protocol to accommodate the above elements, the cost
would
be at most one additional flow for user's explicit authentication.
Computation-wise it's just one exponentiation for the server and two for the
client (with one or both of these exponentiations using a fixed base), plus
a
hash into the curve by the client.

Let me know if the above makes sense to you and whether I missed something
significant about the way IKEv2 works.

Thanks again!

Hugo


>