Re: [Cfrg] Integration of OPAQUE in IKEv2

[Hugo Krawczyk <[e-mail]>]

Hi Valery,

Thanks for the clarifications.

If IKEv2 requires full rounds Initiator-Responder then one needs to add one
round trip to the original IKEv2 as you propose. I am ok with AUTH in the
last flow.
Finally, regarding the definition of AUTH, I now see that the signed
stream <InitiatorSignedOctets>
is defined to include the nonce and prf(SK_pi, IDi') - and similarly for
the responder, so this is indeed *exactly* how IKEv2 works. This shows the
advantage of the modular composition: you get security directly by the
(already analyzed) security of the underlying AKE protocol, in this case
IKEv2 (no need to re-analyze). In case of OPAQUE you also get security
against pre-computation attacks.

The added cost in the case of IKEv2 (due to the OPRF computation)  is one
additional round, a single 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 for the client.  There is also the hardening on the
client side (iterated hashing, Argon2, scrypt, etc.) against offline
attacks at the server and online attacks at the client (hardening should be
mandatory for all proposals).

 Thanks again Valery.

Hugo

On Thu, Sep 12, 2019 at 2:57 AM Valery Smyslov <[e-mail]>
wrote:

> HI Hugo,
>
>
>
> 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.
>
>
>
>           I did this for the purpose. IKEv2 is a strict request-response
> protocol,
>
>           so that initiator sends a request message and responder
>
>           sends a response. It is the initiator who is responsible for
>
>           any retransmission in case request or response get lost.
>
>          This is a core principle of IKEv2 and for this reason non-integer
>
>          RTTs are non-applicable for IKEv2. In your example the proper
> sequence
>
>          would be:
>
>
>
>    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       -->
>
>                                 <--  HDR, SK{}
>
>
>
>       which, in my opinion, is no better than my proposal,
>
>        because it also changes the order AUTH payloads are
>
>        computed by initiator and responder (I prefer the
>
>        initiator authenticates itself first to decrease possible DoS
> attacks surface).
>
>
>
> 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).
>
>
>
>           Here I’m confused. Actually, the above AUTH payload calculation
>
>           is exactly as it is done in IKEv2 (or in SIGMA) with the
> assumption
>
>           that once the OPAQUE is complete each peer can use its private
>
>           key Priv[U|S] for signing. I believed I didn’t change AUTH
> calculation
>
>           in case of OPAQUE at all. From RFC7296, Section 2.15:
>
>
>
> 2.15.  Authentication of the IKE SA
>
>
>
>    When not using extensible authentication (see Section 2.16), the
>
>    peers are authenticated by having each sign (or MAC using a padded
>
>    shared secret as the key, as described later in this section) a block
>
>    of data.
>
>
>
>      Later in this section this block of data is depicted as
> InitiatorSignedOctets
>
>           for initiator and as ResponderSignedOctets for responder.
>
>
>
>           So, I failed to understand where I changed the way AUTH payload
>
>           is calculated for the OPAQUE. Am I missing something?
>
>
>
>           Thank you,
>
>           Valery.
>
>
>
> 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
>
>
>
>
>
>