Re: [Cfrg] Integration of OPAQUE in IKEv2

["Valery Smyslov" <[e-mail]>]

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