[Swan-dev] does basic-pluto-01-nosecrets have a usecase?

[Andrew Cagney]

On Thu, 17 Sep 2020 at 16:13, Paul Wouters <paul at nohats.ca> wrote:

> On Wed, 16 Sep 2020, Andrew Cagney wrote:
>
> > First, I believe ikev2-03-basic-rawrsa-ckaid is fixed.  It uses
> the CKAID to directly locate the raw key in the NSS DB.  To confirm it is
> > working, look in west.pluto.log for "CKAID".The use case for this test
> is pretty easy:- generate the raw key
> > - use certutil to find the ckaid
> > - add ...ckaid= to the config file
> > (how does the other end get the pubkey?)
>
> To me this is not a real solution. It is a hack of loading multiple
> partial conns to get one working conn out of it. You created this
> test case, but I don't see the point in it. You are basically
> re-arranging the deck chairs from : RSA {} into a partial conn.


To quote "I believe ikev2-03-basic-rawrsa-ckaid is fixed".

The rsasigkey skulduggery you're referring to is gone.  To Antony's point,
the first thing the test does is delete ipsec.secrets.
West has one connection specifying:
   <east>rsasigkey - so west can verify what east signed
   <west>ckaid - so west can sign using its raw private key
(I think I have that round the right way)

> So what's the use case for basic-pluto-01-nosecrets?
>
> It is the simple one conn case real humans would configure. It shows a
> need for the : RSA {} section in ipsec.secrets or else it fails to load
> and work. Ideally, this : RSA {} is not needed and it can just load the
> connection and find the private key once it oriented and requires the
> private key.
>

Which is no different to ikev2-03-basic-rawrsa-ckaid (it just went on to
demonstrate one of the ways to work around this).

So to go back to my question: what is the expected usecase?  That is, in
the real world, and assuming that the RSA{} crock wasn't needed:
- what commands would be used to generate east/west's keying material?
- what would east/west's config files look like?


> > For what it is worth, the fix means either a double lookup at "up" time:
> > -> using @west find the raw rsapubkey
> > -> using the raw rsapubkey's ckaid find the raw private key in the NSS DB
> > or, like basic-pluto-01, an attempt to load the raw key during "add" time
>
> loading a conn is a sufficiently rare event that doing a double lookup
> does not seem to be a big impact?
>
>
Per my post "can add connection require a private key?".  This is more
about usability, not performance.  Being told that the connection won't
work when adding it is better than getting an obscure failure while trying
to up it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200917/4a9bf59c/attachment.html>