<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 23 Sep 2020 at 02:18, Antony Antony <<a href="mailto:antony@phenome.org">antony@phenome.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Sep 22, 2020 at 04:14:34PM -0400, Andrew Cagney wrote:<br>
> Regardless of the end, a line like:<br>
>    leftrsasigkey=<br>
>    leftrsasigkey2=...<br>
> will always add public keys like:<br>
>    (generated?) leftid / leftrsasigkey<br>
>    (generated?) leftid / leftrsasigkey2<br>
> to the list of raw public keys.  Left will then try all raw public keys<br>
> matching <id>.<br>
> <br>
> The problem is that the above aren't tied to "left".  Any connection, provided<br>
> the id matches, will use the raw public key; and sometimes use the wrong one.<br>
<br>
while it might be tempting to see this as a problem that need fix also <br>
consider pluto design of PSK secrets and possibly for certs too? They are <br>
all global. Ah, also xauth secrets, pam... PSK is global for sure. Once it <br>
is there any connection can use it. May be certs and intermediates got <br>
"fixed" they are per connection now. Previously it was not.<br>
<br></blockquote><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Are there any ideas on how to extract us from this quirky mis-feature?  <br>
<br>
I would be careful when attempting to fix it only for leftrsasigkey=.  <br>
Consistancy across all authentication methods is good. If you think of using <br>
PSK per connection, think of backward compaitability too.<br>
<br></blockquote><div><br></div><div><div>Sigh.  Including {left,right} yet ignoring it is appalling UI design.</div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think I ran into the same when adding IPSECKEY from dns to pluto global <br>
pubkey store. I recollect OE assume the pubkey store is global and not per <br>
connection.<br>
<br>
> For<br>
> instance:<br>
> - let ipsec.secrets define raw public keys?<br>
> - come up with a syntax that makes it clear that it is shared?<br>
> - tie it to the connection's end somehow?<br>
> - drop it?<br>
> <br>
<br>
</blockquote></div></div>