<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 12, 2020 at 9:00 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">On Thu, 12 Nov 2020 at 13:16, Sahana Prasad <<a href="mailto:sahana.prasad07@gmail.com" target="_blank">sahana.prasad07@gmail.com</a>> wrote:<br>
><br>
> Hello Andrew,<br>
><br>
> The author of the intermediate exchange draft (Valery), confirmed that we always use the last recalculated keys to protect the next<br>
><br>
> exchange (whether it is IKE_AUTH or next IKE_INTERMEDIATE). If keys are not recalculated in an IKE_INTERMEDIATE (no KE were exchanged),<br>
><br>
> 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.<br>
<br>
I'm not sure I follow.<br>
<br>
When the IKE_SA_INIT response comes back two calculations are performed:<br>
- the shared DH secret using the local DH secret and remote KE (aka<br>
.st_gr) - see calc_dh_shared_secret()<br>
- the the keying material using shared DH secret and a key derivation<br>
function (KDF/PRF+) - see (the new) calc_v2_keymat()<br>
these keys are then used to protect the next message - either an<br>
IKE_AUTH or IKE_INTERMEDIATE request.<br>
<br>
I gather that, after each intermediate exchange, the keying material<br>
needs to be recomputed ready for the next exchange?<br></blockquote><div>yes <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
However, what's the calculation used? Is it a variation on the above<br>
or something else specified by the RFC?<br></blockquote><div>It is the same as above.</div><div>This section in the draft confirms that - <br></div><div><a href="https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04#section-3.3.1">https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04#section-3.3.1</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Yes we recalculate the keys the second time, but it should be the same as the first one.<br>
><br>
> You are right, the recalculation is unnecessary.<br>
<br>
My puzzlement is more that when the IKE_INTERMEDIATE response comes<br>
back the code calculates:<br>
<br></blockquote><div><br></div><div>I'm puzzled too now :) The current code on main, looks very different from what I used to look at. <br></div><div> It is missing a couple of things from ikev2_parent.c? <br></div><div><br></div><div><a href="https://github.com/yulia-kuz/libreswan/commit/db53cc9352fa58e9525b84f7641a8db95c3420da#diff-ed770c143a1a1ef20fac4bb54fc2cd4a14b16fe06822d65752b03e3181713647">https://github.com/yulia-kuz/libreswan/commit/db53cc9352fa58e9525b84f7641a8db95c3420da#diff-ed770c143a1a1ef20fac4bb54fc2cd4a14b16fe06822d65752b03e3181713647</a></div><div><br></div><div>This was the code I was familiar with<br></div><div>(<a href="https://github.com/yulia-kuz/libreswan/commits/ike_int">https://github.com/yulia-kuz/libreswan/commits/ike_int</a>)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- the shared DH secret using the local DH secret and remote KE (aka<br>
.st_gr) - see calc_dh_shared_secret()<br>
<br>
but then completely ignores the result -> the re-computed shared DH<br>
secret isn't used<br>
<br>
(I can understand the code doing some sort of NOP as a placeholder for<br>
the real intermediate key derivation calculation, but only when the<br>
result is used).<br>
<br>
><br>
> (We did it that way, because we weren't sure how to handle the key calculation.<br>
><br>
> It was already being done before we knew we wanted to do intermediate, also we use common<br>
><br>
> functions in state transitions for both IKE_AUTH and IKE_INT. Perhaps that should change too)<br>
><br>
><br>
> Added Yulia in case I have missed any details.<br>
><br>
><br>
> Thank you,<br>
><br>
> Regards,<br>
><br>
> Sahana Prasad<br>
><br>
><br>
> On Mon, Nov 9, 2020 at 4:07 PM Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com" target="_blank">andrew.cagney@gmail.com</a>> wrote:<br>
>><br>
>> 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></div>