<div dir="ltr"><div><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">Hello Andrew,</span></font></span></div><div><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"><br></span></font></span></div><div><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">The author of the intermediate exchange draft (Valery), confirmed that we always use the last recalculated keys to protect the next </span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"> exchange (whether it is IKE_AUTH or next IKE_INTERMEDIATE). If keys are not recalculated in an IKE_INTERMEDIATE (no KE were exchanged), <br></span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">then they don’t change and are used in the next exchange. Our case is the same, we don't exchange KE, so we use the same keys for both exchanges.</span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"><br></span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">Yes we recalculate the keys the second time, but it should be the same as the first one.</span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">You are right, the recalculation is unnecessary.</span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"> (We did it that way, because we weren't sure how to handle the key calculation.</span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"> It was already being done before we knew we wanted to do intermediate, also we use common</span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">functions in state transitions for both IKE_AUTH and IKE_INT. Perhaps that should change too)</span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"><br></span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">Added Yulia in case I have missed any details.<br></span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif"><br></span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">Thank you,</span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">Regards,</span></font></span></p><p class="MsoNormal" style="margin-left:4.8pt"><span style="color:rgb(0,0,0)"><font size="2"><span style="font-family:arial,sans-serif">Sahana Prasad<br></span></font></span></p></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 9, 2020 at 4:07 PM Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com">andrew.cagney@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">thanks!<br>
<br>
As an aside.  I'm currently cleaning up the crypto code by eliminating<br>
the remaining pcr style crypto helpers.  A likely side effect is that<br>
the memory leak will disappear.  The possibly unnecessary DH<br>
calculation will remain, it just won't leak.<br>
<br>
On Wed, 4 Nov 2020 at 16:22, Sahana Prasad <<a href="mailto:sahana.prasad07@gmail.com" target="_blank">sahana.prasad07@gmail.com</a>> wrote:<br>
><br>
> Hello Andrew,<br>
> Thanks for the analysis.<br>
><br>
> I'll get back to you on this one with more details.<br>
><br>
> Thank you,<br>
> Regards,<br>
> Sahana Prasad<br>
><br>
> On Wed, 4 Nov 2020, 20:56 Andrew Cagney, <<a href="mailto:andrew.cagney@gmail.com" target="_blank">andrew.cagney@gmail.com</a>> wrote:<br>
>><br>
>> 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">Swan-dev@lists.libreswan.org</a><br>
>> <a href="https://lists.libreswan.org/mailman/listinfo/swan-dev" rel="noreferrer" target="_blank">https://lists.libreswan.org/mailman/listinfo/swan-dev</a><br>
</blockquote></div>