[Swan-dev] {left,right}rsasigkey2=...

[Paul Wouters]

On Wed, 23 Sep 2020, Andrew Cagney wrote:

> On Wed, 23 Sep 2020 at 02:18, Antony Antony <antony at 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