[Swan-dev] dh and intermediate exchanges

[Andrew Cagney]

thanks!

As an aside.  I'm currently cleaning up the crypto code by eliminating
the remaining pcr style crypto helpers.  A likely side effect is that
the memory leak will disappear.  The possibly unnecessary DH
calculation will remain, it just won't leak.

On Wed, 4 Nov 2020 at 16:22, Sahana Prasad <sahana.prasad07 at gmail.com> wrote:
>
> Hello Andrew,
> Thanks for the analysis.
>
> I'll get back to you on this one with more details.
>
> Thank you,
> Regards,
> Sahana Prasad
>
> On Wed, 4 Nov 2020, 20:56 Andrew Cagney, <andrew.cagney at gmail.com> wrote:
>>
>> The immediate problem is that the intermediate exchange is leaking the
>> local dh secret.  However there seems to be more going on - someone
>> familiar with intermediate code should probably take a look.
>>
>> - the initiator, on receipt of an IKE_SA_INIT responce calls,
>> ikev2_parent_inR1outI2() which finishes with:
>>
>>     /* If we seen the intermediate AND we are configured to use intermediate */
>>     /* for now, do only one Intermediate Exchange round and proceed
>> with IKE_AUTH */
>>     crypto_req_cont_func (*pcrc_func) = (ike->sa.st_seen_intermediate
>> && (md->pbs[PBS_v2N_INTERMEDIATE_EXCHANGE_SUPPORTED] != NULL) &&
>> !(md->hdr.isa_xchg == ISAKMP_v2_IKE_INTERMEDIATE)) ?
>>             ikev2_parent_inR1outI2_continue : ikev2_parent_inR1outI2_continue;
>>     submit_v2_dh_shared_secret(st, "ikev2_inR1outI2 KE",
>>                    SA_INITIATOR,
>>                    NULL, NULL, &st->st_ike_rekey_spis,
>>                    pcrc_func);
>>     return STF_SUSPEND;
>>
>> so it submits a request to finish the DH calculation and compute
>> dh-shared-secret#1, and then since it is doing an intermediate change
>> chooses to continue with ikev2_parent_inR1out_intermediate().  This
>> presumably will send an encrypted IKE_INTERMEDATE request
>>
>> - the initiator, on receipt of an IKE_INTERMEDIATE response, also
>> calls ikev2_parent_inR1outI2(), which submits a request to compute
>> dh-shared-secret#2, but this time chooses to continue with
>> ikev2_parent_inR1outI2_continue().  This presumably will send an
>> encrypted IKE_AUTH request.
>>
>> It's this second continue that is leaking:
>> - ikev2_parent_inR1out_intermediate() calls
>> finish_v2_dh_shared_secret() unconditionally which saves
>> dh-shared-secret#1 in the state
>> - ikev2_parent_inR1outI2_continue(), only calls
>> finish_v2_dh_shared_secret() when the response isn't IKE_INTERMEDIATE
>> (and here it is) so doesn't save dh-shared-secret#2 leaking it
>> (you'll need to trace through a few calls or sprinkle some debug lines
>> to see this)
>>
>> So, does anyone know the back story, and what should be happening?  Is
>> the DH needed for instance?
>>
>> Andrew
>> _______________________________________________
>> Swan-dev mailing list
>> Swan-dev at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan-dev