[Swan-commit] Changes to ref refs/heads/main
Andrew Cagney
cagney at vault.libreswan.fi
Sat Sep 19 01:52:02 UTC 2020
New commits:
commit c49aae0e0108181a9bb3fdf520a70a8d3a1b9a01
Author: Andrew Cagney <cagney at gnu.org>
Date: Fri Sep 18 16:56:24 2020 -0400
crypto: during "whack add", save the rsasigkey's CKAID and then, later, use that to find the private key
Follow-up 1bc63884ed4a71a531217c51a045e0ce971b172d which fixed
selecting a raw private key using the CKAID.
This code:
- modifies whack so that the "connection add" message includes the raw
key specified by {left,right}rsasigkey=
Previously this information was only sent later.
- modifies pluto to capture {left,right}rsasigkey='s CKAID and save it
in the connection's end
Provided the raw key's type (RSA ECDSA) is specified, the code is
generic.
- code added by 1bc63884ed4a71a531217c51a045e0ce971b172d then uses the
CKAID to find the private key during IKE_AUTH (i.e., on demand).
Previously the (possibly generated) left/right id was used
This means a config file containing just:
conn west-rsasigkey-east-rsasigkey
also=west-leftrsasigkey
also=east-rightrsasigkey
# other stuff
left=192.1.2.45
leftsubnet=192.0.1.0/24
right=192.1.2.23
rightsubnet=192.0.2.0/24
works (no, there's no smoke and mirrors aka ipsec.secrets).
Open issues ....
(Keep in mind that this change only affects config files containing
*rsasigkey=. It can't affect keys loaded explicitly using whack
and/or ipsec.secrets. It isn't even possible to specify rsasigkey=
from the command line.)
- given a config file containing both rsasigkey= and rsasigkey2=, this
code always uses the former's raw key to generate the CKAID and,
thence, find the private key
- given a config file containing rsasigkey= and/or rsasigkey2=, whack
will still send messages to add these raw public keys to the public
key list; this means code trying to verify using both public keys
will still work
However, being able to specify two rsasigkeys in the config file,
doesn't appear to be tested. Can the feature be dropped and,
instead support this using ipsec.secrets?
- pluto will use the first of: cert=, rsasigkey= and ckaid=, any
latter fields are warned but ignored (whack might also reject some
combinations making this mute)
- because the end's private key is pinned down using the config files
rsasigkey='s CKAID, selecting the wrong private key isn't possible
Hmm, this is sounding a lot like "`pluto` chooses wrong raw RSA key
#352"?
- because the end's private key is pinned down using the config file's
rsasigkey='s CKAID, it isn't possible to roll over the private key
I don't think this has ever worked with raw keys - they get loaded
once and are then stuck. The reload feature only works with
certifiates.
Anyone wanting to roll over keys should probably use ipsec.secrets
or real PKI.
- this new code does not check that a private key matching the CKAID
exists; that happens much much later when the code tries to use the
key during IKE_AUTH
See the discussion "can add connection require a private key?" for
why (short answer: connection isn't oriented). The current working
theory is that any code checking for the private key should go in
orient().
More information about the Swan-commit
mailing list