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 <[email protected]> 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, <[email protected]> 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 >> [email protected] >> https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
