<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">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 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>