<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 18 Sep 2020 at 10:40, 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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 17 Sep 2020 at 16:05, Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</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, 17 Sep 2020, Andrew Cagney wrote:<br>
<br>
> Currently the code just warns when trying to add a connection with no private key. Instead much much later - during the auth exchange - the<br>
> code tries to find the private key.<br>
> Presumably this is because the end may not need the private key.<br>
<br>
Yes. that is:<br>
<br>
conn test<br>
left=%defaultroute<br>
right=%any<br>
leftcert=somecert<br>
rightrsasigkey=%fromcert # implied as default<br>
</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When loading this conn, pluto does not know if it is left or right. The<br>
smae config could be used on both endpoints, and somecert would only be<br>
on one endpoint. whether this is worth supporting is something else. I<br>
could see where we just always try to load the leftcert= / rightcert=<br>
and throw an error when we can't load it. The idea behind re-using the<br>
same config on both sides is slowly vanishing anyway. And if I get to<br>
do some kind of rewrite with a new config format, then I think I would<br>
be tempted to use [inifile] type syntax anyway.<br>
<br>
But, if currently the only issue is a "late failure" vs "early failure"<br>
than I suggest to just leave it as "late failure".<br>
<br></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Ah, so there are now 4 places where the check could be made:</div><div class="gmail_quote"><br></div><div class="gmail_quote">-> decode_end()</div><div class="gmail_quote">-- this is where the cert is currently being checked so, to your point, it is technically wrong; it does help explain why the code seems so wishy washy</div><div class="gmail_quote"><br></div><div class="gmail_quote">-> orient()</div><div class="gmail_quote">-- which could be during "whack add", "whack listen", or even triggered by ifconfig</div><div class="gmail_quote"><br></div><div>-> "whack up" (i.e., the trigger for the IKE SA init request/response)</div><div>-- this is the lazy case</div><div>-- during IKE_AUTH - this is where private keys sometimes get loaded</div><div>-- in the responder this would mean accepting connections only to toss them; seems wrong<br></div><div><div><div><br></div><div>So here's the next question.</div><div><br></div><div>- if orient() tries to load a cert and fails, should the connection be tossed or left unoriented?</div><div><br></div><div class="gmail_quote">For "whack listen" and ifconfig, the answer is probably yes - having a connection magically disappear would be confusing. However, for "whack add" when oriented? I guess leave it unoriented (which is arguably better then having it added, enabled, but unusable).<br></div><div class="gmail_quote"><br></div></div></div></div></blockquote><div><br></div><div>First, it looks like message generated by "<span style="color:rgb(0,0,0);white-space:pre-wrap">ipsec whack --label 'SAwest-east leftrsasigkey' --keyid "@west" --pubkeyrsa ..." should trigger an attempt to load the corresponding private key (but ignore failure). Both of these:</span><br></div><div><a href="https://testing.libreswan.org/v3.30-1714-gcab2172733-main/delete-sa-01/OUTPUT/west.console.txt">https://testing.libreswan.org/v3.30-1714-gcab2172733-main/delete-sa-01/OUTPUT/west.console.txt</a></div><div><a href="https://testing.libreswan.org/v3.30-1714-gcab2172733-main/ikev2-55-ipseckey-02/OUTPUT/east.console.diff">https://testing.libreswan.org/v3.30-1714-gcab2172733-main/ikev2-55-ipseckey-02/OUTPUT/east.console.diff</a><br></div><div>were relying on *.secrets triggering an attempt to load the private key.</div><div><br></div><div>and this leads to a potential refinement:</div><div><br></div><div>- "add" triggers a lazy attempt at loading the private key - this already happens with certificates (it warns when the private key is missing)</div><div>- orient() can then check that the public / private key is available</div><div><br></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"><div dir="ltr"><div><div><div class="gmail_quote"></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I'm wondering if there's enough information available to determine that the private key is required when the connection is being added. If a<br>
> connection can specify multiple optional auth methods then probably not?<br>
<br>
Perhaps after orienting there is. Before that, I think it is a littly<br>
tricky?<br>
<br>
> (a case when there isn't is with rsasigkey - that only arrives after the connection is added; grrrr)<br>
<br>
I'm fine with that failing to load, provided we would be sure we had<br>
oriented properly ?<br>
<br>
Paul<br>
</blockquote></div></div></div></div>
</blockquote></div></div>