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

[Andrew Cagney]

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

> 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/3a6129e4/attachment.html>