On Wed, 23 Sep 2020, Andrew Cagney wrote:
On Wed, 23 Sep 2020 at 02:18, Antony Antony <ant...@phenome.org> wrote:
On Tue, Sep 22, 2020 at 04:14:34PM -0400, Andrew Cagney wrote:
> Regardless of the end, a line like:
> leftrsasigkey=
> leftrsasigkey2=...
> will always add public keys like:
> (generated?) leftid / leftrsasigkey
> (generated?) leftid / leftrsasigkey2
> to the list of raw public keys. Left will then try all raw public keys
> matching <id>.
>
> The problem is that the above aren't tied to "left". Any connection,
provided
> the id matches, will use the raw public key; and sometimes use the
wrong one.
while it might be tempting to see this as a problem that need fix also
consider pluto design of PSK secrets and possibly for certs too? They are
all global. Ah, also xauth secrets, pam... PSK is global for sure. Once it
is there any connection can use it. May be certs and intermediates got
"fixed" they are per connection now. Previously it was not.
Antony is right that the design is a bit strange. Note that local or
remote part for public key depends on whether you have the private key
too. The pluto store of key+id can be seen as a verified store. Kind of
like certificates have their public key and id proven by a CA.
I think the real problem is, we have never been able to use rsasigkey2=
when rsasigkey= fails, so this whole particular construct does not work
and shoud just be removed.
> Are there any ideas on how to extract us from this quirky mis-feature?
I would be careful when attempting to fix it only for leftrsasigkey=.
Consistancy across all authentication methods is good. If you think of
using
PSK per connection, think of backward compaitability too.
Sigh. Including {left,right} yet ignoring it is appalling UI design.
The keys from DNS are really "peer public keys" whether the connection
uses left or right as "remote".
I think I ran into the same when adding IPSECKEY from dns to pluto global
pubkey store. I recollect OE assume the pubkey store is global and not per
connection.
Yes. the DNSSEC PKI is similar to a "certificate CA". It is trusted to
vouch for the DNS name as ID for that public key. There is no reason to
stick the key at a particular orientation. The IKE ID when received is
matched to the public key ID before the public key is used. Again
whether that was left/right does not matter.
> For
> instance:
> - let ipsec.secrets define raw public keys?
The move I was hoping for with removal of : RSA {} requirement is to
never ever use ipsec.secrets for raw/cert pubkeys. ipsec.secrets should
only be for PSKs, PPKs, XAUTH passwords, and perhaps EAP stuff in the
future. On my wanted list was already to have a secret= that is per
conn based. Not so much to be able to specify in a conn secret=foo,
but to allow whack to receive a secret that is only valid for that
specific conn. So that tools like NetworkManager can push a PSK that
is limited to a conn, without using crappy temp files to load a secret
into pluto - and than having a global secret.
> - come up with a syntax that makes it clear that it is shared?
We could allow for an extra parameter that specifies a conn to limit it
to a conn. But I think if we only have PSK/PPK/XAUTH, then having the
IDs limit their scope is good enough. I wouldn't re-engineer that part.
Paul
_______________________________________________
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
