<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 17 Sep 2020 at 16:13, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</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 Wed, 16 Sep 2020, Andrew Cagney wrote:<br>
<br>
> 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<br>
> working, look in west.pluto.log for "CKAID".The use case for this test is pretty easy:- generate the raw key<br>
> - use certutil to find the ckaid<br>
> - add ...ckaid= to the config file<br>
> (how does the other end get the pubkey?)<br>
<br>
To me this is not a real solution. It is a hack of loading multiple<br>
partial conns to get one working conn out of it. You created this<br>
test case, but I don't see the point in it. You are basically<br>
re-arranging the deck chairs from : RSA {} into a partial conn.</blockquote><div><br></div><div>To quote "I believe ikev2-03-basic-rawrsa-ckaid is fixed".</div><div><br></div><div>The rsasigkey skulduggery you're referring to is gone.  To Antony's point, the first thing the test does is delete ipsec.secrets.<br></div><div>West has one connection specifying:</div><div>   <east>rsasigkey - so west can verify what east signed</div><div>   <west>ckaid - so west can sign using its raw private key<br></div><div class="gmail_quote">(I think I have that round the right way)<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> So what's the use case for basic-pluto-01-nosecrets?<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It is the simple one conn case real humans would configure. It shows a<br>
need for the : RSA {} section in ipsec.secrets or else it fails to load<br>
and work. Ideally, this : RSA {} is not needed and it can just load the<br>
connection and find the private key once it oriented and requires the<br>
private key.<br></blockquote><div><br></div><div>Which is no different to ikev2-03-basic-rawrsa-ckaid (it just went on to demonstrate one of the ways to work around this).<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">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:<br></div><div class="gmail_quote">- what commands would be used to generate east/west's keying material?</div><div class="gmail_quote">- what would east/west's config files look like?</div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> For what it is worth, the fix means either a double lookup at "up" time:<br>
> -> using @west find the raw rsapubkey<br>
> -> using the raw rsapubkey's ckaid find the raw private key in the NSS DB<br>
> or, like basic-pluto-01, an attempt to load the raw key during "add" time<br>
<br>
loading a conn is a sufficiently rare event that doing a double lookup<br>
does not seem to be a big impact?<br>
<br></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div></div></div>