[Swan-dev] Regarding ikev2-03-basic-rawrsa-ckaid

[Andrew Cagney]

On Tue, 8 Sep 2020 at 11:25, Andrew Cagney <andrew.cagney at gmail.com> wrote:

> So, I was going to post a thread to discuss these bugs; might as well
> hijack this one ...
>
> updated ikev2-03-basic-rawrsa-ckaid/description.txt:
>
> Querks when specifying the CKAID of a raw RSA key in a basic IKEv2
> connection.
>
> Connections involving rsasigkey are performed using two whack messages
> which:
>
> 1. add the connection _without_ the raw key
> 2. add the raw key
>
> This breaks "ipsec auto --add east-ckaid-rsasigkey":
>
> - the first whack message tries to add the connection; since it
>   specifies ..ckaid=..., but rsasigkey hasn't yet been added, it fails
>
> But there's a work-around:
>
> 1. "ipsec auto --add east-rsasigkey"
>
>    this adds east'ts rsasigkey to the database
>
> 2. "ipsec auto --add east-ckaid"
>
>    loads because the command above loaded the RSASIGKEY
>
> I suspect the first thing to fix here is to change the code attaching a
> pubkey identified by its CKAID to a connection so it mimics the ID code
> below - be lazy.
>
> This should fix the immediate problem of not finding east's pubkey.  But
> I'm sure we'll then hit another issue ...
>

Perhaps not.

The old version of this test documented how needing to preload east's
pubkey was only the first of several problems.  West's pubkey needed to
also be preloaded so that the lookup CKAID -> PUBKEY -> SECRET worked.  I
suspect my recent crypto/ckaid changes fixed that - the test seems to only
need to preload east's pubkey.


> commit dffc14bdb3dd3f0b0dfb0cd4a64718b558f732bb
> > Author: Andrew Cagney <cagney at gnu.org>
> > Date:   Mon Sep 7 21:33:08 2020 -0400
> >
> >      testing: fix basic-pluto-01-nosecrets's description
>
> ikev1 test with keyid+rsasigkey+raw key
>
> This is kind of the converse of ikev2-03-basic-rawrsa-ckaid.
>
> - the NSS db contains west's raw private key
>
> - a connection specifying:
>   -- east/west's IDs
>   -- east/west's RSASIGKEY (i.e., raw signatures)
>   is loaded.
>
> - trying to up the connection fails because the private key can't be
>   found:
>
> I'm guessing the correct behaviour is:
> | looking connection westnet-eastnet's RSA private key
> | lsw_get_secret() using IDs for @west->@east of kind PKK_RSA
> | concluding with best_match=000 best=(nil) (lineno=-1)
> | connection westnet-eastnet's RSA private key not found
> "westnet-eastnet" #1: unable to locate my private key for RSA Signature
>
> It should try the public key's ckaid instead?
>
> Like the comment says, should this use the CKAID.  The raw private key is
> in the nss DB so trying to use the ID isn't going to get very far.
>
>
> > Before yesterday's commit, it had the standard basic-pluto-01 text
> > because it was literally a copy of basic-pluto-01 without the "no
> > longer needed" secrets entry for raw RSA keys. Which got broken.
> >
> > The test case shows an important bug. When you run "ipsec newhostkey"
> > without capturing the output, you cannot use it for any authenitcation
> > because keys no longer load on the connection. This has been a bug since
> > 3.1x ? I even had to revert the documentation on the wiki and the RHEL
> > guide to re-document the command to "ipsec newhostkey >
> /etc/ipsec.d/some.secret"
> > because of this. To me, this is a very important bug tht should get
> > fixed.
>
> Plenty of discussion on the internet about how marking tests people wan't
> fixed as "good" backfires.
> My previous suggestion has been to give it a name other than wip.  We
> could even add numbers for ranking these by urgency.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200908/440a339f/attachment.html>