On Fri, 18 Sep 2020 at 10:40, Andrew Cagney <[email protected]> wrote:
> > > On Thu, 17 Sep 2020 at 16:05, Paul Wouters <[email protected]> wrote: > >> On Thu, 17 Sep 2020, Andrew Cagney wrote: >> >> > Currently the code just warns when trying to add a connection with no >> private key. Instead much much later - during the auth exchange - the >> > code tries to find the private key. >> > Presumably this is because the end may not need the private key. >> >> Yes. that is: >> >> conn test >> left=%defaultroute >> right=%any >> leftcert=somecert >> rightrsasigkey=%fromcert # implied as default >> > > When loading this conn, pluto does not know if it is left or right. The >> smae config could be used on both endpoints, and somecert would only be >> on one endpoint. whether this is worth supporting is something else. I >> could see where we just always try to load the leftcert= / rightcert= >> and throw an error when we can't load it. The idea behind re-using the >> same config on both sides is slowly vanishing anyway. And if I get to >> do some kind of rewrite with a new config format, then I think I would >> be tempted to use [inifile] type syntax anyway. >> >> But, if currently the only issue is a "late failure" vs "early failure" >> than I suggest to just leave it as "late failure". >> >> > Ah, so there are now 4 places where the check could be made: > > -> decode_end() > -- 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 > > -> orient() > -- which could be during "whack add", "whack listen", or even triggered by > ifconfig > > -> "whack up" (i.e., the trigger for the IKE SA init request/response) > -- this is the lazy case > -- during IKE_AUTH - this is where private keys sometimes get loaded > -- in the responder this would mean accepting connections only to toss > them; seems wrong > > So here's the next question. > > - if orient() tries to load a cert and fails, should the connection be > tossed or left unoriented? > > 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). > > First, it looks like message generated by "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: 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/ikev2-55-ipseckey-02/OUTPUT/east.console.diff were relying on *.secrets triggering an attempt to load the private key. and this leads to a potential refinement: - "add" triggers a lazy attempt at loading the private key - this already happens with certificates (it warns when the private key is missing) - orient() can then check that the public / private key is available > > 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 >> > connection can specify multiple optional auth methods then probably not? >> >> Perhaps after orienting there is. Before that, I think it is a littly >> tricky? >> >> > (a case when there isn't is with rsasigkey - that only arrives after >> the connection is added; grrrr) >> >> I'm fine with that failing to load, provided we would be sure we had >> oriented properly ? >> >> Paul >> >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
