[Swan-dev] can add connection require a private key?

[Andrew Cagney]

On Fri, 18 Sep 2020 at 10:40, Andrew Cagney <andrew.cagney at gmail.com> wrote:

>
>
> On Thu, 17 Sep 2020 at 16:05, Paul Wouters <paul at nohats.ca> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200920/a8cb7c5b/attachment-0001.html>