<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 8 Sep 2020 at 11:25, Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com">andrew.cagney@gmail.com</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"><div dir="ltr"><div><div>So, I was going to post a thread to discuss these bugs; might as well hijack this one ...</div><div><br></div><div>updated ikev2-03-basic-rawrsa-ckaid/description.txt:</div><div><br></div><div><div style="margin-left:40px">Querks when specifying the CKAID of a raw RSA key in a basic IKEv2 connection.<br><br>Connections involving rsasigkey are performed using two whack messages<br>which:<br><br>1. add the connection _without_ the raw key<br>2. add the raw key<br><br>This breaks "ipsec auto --add east-ckaid-rsasigkey":<br><br>- the first whack message tries to add the connection; since it<br>  specifies ..ckaid=..., but rsasigkey hasn't yet been added, it fails<br><br>But there's a work-around:<br><br>1. "ipsec auto --add east-rsasigkey"<br><br>   this adds east'ts rsasigkey to the database<br><br>2. "ipsec auto --add east-ckaid"<br></div><br><div style="margin-left:40px">   loads because the command above loaded the RSASIGKEY</div></div><div><br></div><div>I suspect the first thing to fix here is to change the code attaching a pubkey identified by its CKAID to a connection so it mimics the ID code below - be lazy.</div><div><br></div><div>This should fix the immediate problem of not finding east's pubkey.  But I'm sure we'll then hit another issue ...<br></div></div></div></blockquote><div><br></div><div>Perhaps not.</div><div><br></div><div>The old version of this test documented how needing to preload east's pubkey was only the first of several problems.  West's pubkey needed to also be preloaded so that the lookup CKAID -> PUBKEY -> SECRET worked.  I suspect my recent crypto/ckaid changes fixed that - the test seems to only need to preload east's pubkey.<br></div><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"><div dir="ltr"><div><div></div>> commit dffc14bdb3dd3f0b0dfb0cd4a64718b558f732bb<br>> Author: Andrew Cagney <<a href="mailto:cagney@gnu.org" target="_blank">cagney@gnu.org</a>><br>> Date:   Mon Sep 7 21:33:08 2020 -0400<br>><br>>      testing: fix basic-pluto-01-nosecrets's description<br><div><br></div><div style="margin-left:40px">ikev1 test with keyid+rsasigkey+raw key<br> <br>This is kind of the converse of ikev2-03-basic-rawrsa-ckaid.<br> <br>- the NSS db contains west's raw private key<br> <br>- a connection specifying:<br>  -- east/west's IDs<br>  -- east/west's RSASIGKEY (i.e., raw signatures)<br>  is loaded.<br> <br>- trying to up the connection fails because the private key can't be<br>  found:<br></div><div style="margin-left:40px"><br></div><div style="margin-left:40px">I'm guessing the correct behaviour is:<br></div><div style="margin-left:40px">| looking connection westnet-eastnet's RSA private key<br>| lsw_get_secret() using IDs for @west->@east of kind PKK_RSA<br>| concluding with best_match=000 best=(nil) (lineno=-1)<br>| connection westnet-eastnet's RSA private key not found<br>"westnet-eastnet" #1: unable to locate my private key for RSA Signature<br> <br>It should try the public key's ckaid instead?<br></div><br></div>Like the comment says, should this use the CKAID.  The raw private key is in the nss DB so trying to use the ID isn't going to get very far.<br><div><br><br>> Before yesterday's commit, it had the standard basic-pluto-01 text<br>> because it was literally a copy of basic-pluto-01 without the "no<br>> longer needed" secrets entry for raw RSA keys. Which got broken.<br>><br>> The test case shows an important bug. When you run "ipsec newhostkey"<br>> without capturing the output, you cannot use it for any authenitcation<br>> because keys no longer load on the connection. This has been a bug since<br>> 3.1x ? I even had to revert the documentation on the wiki and the RHEL<br>> guide to re-document the command to "ipsec newhostkey > /etc/ipsec.d/some.secret"<br>> because of this. To me, this is a very important bug tht should get<br>> fixed.<br></div><div><br></div><div>Plenty of discussion on the internet about how marking tests people wan't fixed as "good" backfires.</div><div>My previous suggestion has been to give it a name other than wip.  We could even add numbers for ranking these by urgency.<br></div></div>
</blockquote></div></div>