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