<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 6/30/2017 12:09, Karl Denninger wrote:<br>
<blockquote type="cite"
cite="mid:d2dbe042-2987-1b95-7fce-95d0f20a01bf@denninger.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 6/26/2017 10:46, Tobias Brunner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6b4d4df3-62ab-ca25-48c1-ae0b9242d1eb@strongswan.org">
<pre wrap="">Hi Karl,
</pre>
<blockquote type="cite">
<pre wrap="">StrongSwan never gets this packet. I assume the problem here is the
length mismatch, but not certain. What is certain is that StrongSwan
never sees it; no matter how far up I turn the logging I never see any
evidence of it being logged.
</pre>
</blockquote>
<pre wrap="">Sounds like an IP fragmentation issue (message is too large -> gets
fragmented -> fragments get dropped on the way to the server -> server
never sees the complete message). Unfortunately, you can't do much
about that on Windows if you want to use certificates as the built-in
client does not support IKEv2 fragmentation, ECDSA certificates (which
are significantly smaller than RSA certificates), or omit the client
certificate, and the certificate requests can't be controlled either
(since a Windows system has more and more CA certificates installed over
time that list gets longer and longer the older a system is). The only
option to reduce the size of the IKE_AUTH message is to use EAP
authentication with username/password.
Regards,
Tobias
</pre>
</blockquote>
I've been unable to get an ECDSA certificate to import on my
Android phone (BlackBerry DTEK60, Android 6.01) -- the same error
occasionally bites me on the phone too during initial negotiation
*some* of the time (looks like I got 3 fragments that have to be
passed and one of them gets dropped often enough that the initial
keying fails, which has to succeed before Ikev2 frag support
helps.)<br>
</blockquote>
<font size="-2"></font><br>
I got that sorted (don't include the curve parameters in the
certificate!) and now Android will import it.<br>
<br>
But now, when that certificate is selected, StrongSwan doesn't seem
to want to *find* the certificate, even though it *does* verify as
ok against the CA that issued it, and it's in the "certs"
directory..... I get this:<br>
<br>
<tt>Jul 1 15:19:24 NewFS charon: 16[NET] received packet: from
172.56.21.156[19485] to 192.168.10.100[500] (746 bytes)<br>
Jul 1 15:19:24 NewFS charon: 16[ENC] parsed IKE_SA_INIT request 0
[ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG)
N(REDIR_SUP) ]<br>
Jul 1 15:19:24 NewFS charon: 16[IKE] 172.56.21.156 is initiating
an IKE_SA<br>
Jul 1 15:19:24 NewFS charon: 16[IKE] local host is behind NAT,
sending keep alives<br>
Jul 1 15:19:24 NewFS charon: 16[IKE] remote host is behind NAT<br>
Jul 1 15:19:24 NewFS charon: 16[IKE] DH group ECP_256
inacceptable, requesting CURVE_25519<br>
Jul 1 15:19:24 NewFS charon: 16[ENC] generating IKE_SA_INIT
response 0 [ N(INVAL_KE) ]<br>
Jul 1 15:19:24 NewFS charon: 16[NET] sending packet: from
192.168.10.100[500] to 172.56.21.156[19485] (38 bytes)<br>
Jul 1 15:19:24 NewFS charon: 16[NET] received packet: from
172.56.21.156[19485] to 192.168.10.100[500] (714 bytes)<br>
Jul 1 15:19:24 NewFS charon: 16[ENC] parsed IKE_SA_INIT request 0
[ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG)
N(REDIR_SUP) ]<br>
Jul 1 15:19:24 NewFS charon: 16[IKE] 172.56.21.156 is initiating
an IKE_SA<br>
Jul 1 15:19:24 NewFS charon: 16[IKE] local host is behind NAT,
sending keep alives<br>
Jul 1 15:19:24 NewFS charon: 16[IKE] remote host is behind NAT<br>
Jul 1 15:19:24 NewFS charon: 16[IKE] sending cert request for
"C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda
Systems LLC CA, E=Cuda Systems LLC CA"<br>
Jul 1 15:19:24 NewFS charon: 16[ENC] generating IKE_SA_INIT
response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ
N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]<br>
Jul 1 15:19:24 NewFS charon: 16[NET] sending packet: from
192.168.10.100[500] to 172.56.21.156[19485] (267 bytes)<br>
Jul 1 15:19:25 NewFS charon: 16[NET] received packet: from
172.56.21.156[47709] to 192.168.10.100[4500] (1364 bytes)<br>
Jul 1 15:19:25 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [
EF(1/2) ]<br>
Jul 1 15:19:25 NewFS charon: 16[ENC] received fragment #1 of 2,
waiting for complete IKE message<br>
Jul 1 15:19:25 NewFS charon: 16[NET] received packet: from
172.56.21.156[47709] to 192.168.10.100[4500] (756 bytes)<br>
Jul 1 15:19:25 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [
EF(2/2) ]<br>
Jul 1 15:19:25 NewFS charon: 16[ENC] received fragment #2 of 2,
reassembling fragmented IKE message<br>
Jul 1 15:19:25 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [
IDi CERT N(INIT_CONTACT) CERTREQ AUTH CPRQ(ADDR ADDR6 DNS DNS6)
N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR)
N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]<br>
Jul 1 15:19:25 NewFS charon: 16[IKE] received cert request for
"C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda
Systems LLC CA, E=Cuda Systems LLC CA"<br>
Jul 1 15:19:25 NewFS charon: 16[LIB] building CRED_CERTIFICATE -
X509 failed, tried 3 builders<br>
Jul 1 15:19:25 NewFS charon: 16[CFG] looking for peer configs
matching 192.168.10.100[%any]...172.56.21.156[C=US, ST=Florida,
O=Cuda Systems LLC, <a class="moz-txt-link-abbreviated" href="mailto:CN=karl.ecdsa@denninger.net">CN=karl.ecdsa@denninger.net</a>]<br>
Jul 1 15:19:25 NewFS charon: 16[CFG] selected peer config
'StrongSwan'<br>
<b>Jul 1 15:19:25 NewFS charon: 16[IKE] no trusted ECDSA public
key found for 'C=US, ST=Florida, O=Cuda Systems LLC,
<a class="moz-txt-link-abbreviated" href="mailto:CN=karl.ecdsa@denninger.net">CN=karl.ecdsa@denninger.net</a>'</b><br>
Jul 1 15:19:25 NewFS charon: 16[IKE] received
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding<br>
Jul 1 15:19:25 NewFS charon: 16[IKE] peer supports MOBIKE<br>
Jul 1 15:19:25 NewFS charon: 16[ENC] generating IKE_AUTH response
1 [ N(AUTH_FAILED) ]<br>
Jul 1 15:19:25 NewFS charon: 16[NET] sending packet: from
192.168.10.100[4500] to 172.56.21.156[47709] (80 bytes)<br>
<br>
<br>
</tt>The certificate IS there in the "certs" directory as a trusted
certificate, AND it validates when checked. I can't find a log
setting that will tell me why the scan of the directory where the
certificate is fails to find it (or if it does find it, why it would
load and validate it.)<br>
<br>
The peer config is also known to be correct and (when I don't get
hit with a frag problem) it works with an RSA certificate:<br>
<br>
<tt>Jul 1 15:24:32 NewFS charon: 16[NET] received packet: from
172.56.21.156[19562]<br>
to 192.168.10.100[500] (746 bytes)<br>
Jul 1 15:24:32 NewFS charon: 16[ENC] parsed IKE_SA_INIT request 0
[ SA KE No N(<br>
NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]<br>
Jul 1 15:24:32 NewFS charon: 16[IKE] 172.56.21.156 is initiating
an IKE_SA<br>
Jul 1 15:24:32 NewFS charon: 16[IKE] local host is behind NAT,
sending keep ali<br>
ves<br>
Jul 1 15:24:32 NewFS charon: 16[IKE] remote host is behind NAT<br>
Jul 1 15:24:32 NewFS charon: 16[IKE] DH group ECP_256
inacceptable, requesting<br>
CURVE_25519<br>
Jul 1 15:24:32 NewFS charon: 16[ENC] generating IKE_SA_INIT
response 0 [ N(INVA<br>
L_KE) ]<br>
Jul 1 15:24:32 NewFS charon: 16[NET] sending packet: from
192.168.10.100[500] t<br>
o 172.56.21.156[19562] (38 bytes)<br>
Jul 1 15:24:32 NewFS charon: 16[NET] received packet: from
172.56.21.156[19562]<br>
to 192.168.10.100[500] (714 bytes)<br>
Jul 1 15:24:32 NewFS charon: 16[ENC] parsed IKE_SA_INIT request 0
[ SA KE No N(<br>
NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]<br>
Jul 1 15:24:32 NewFS charon: 16[IKE] 172.56.21.156 is initiating
an IKE_SA<br>
Jul 1 15:24:32 NewFS charon: 16[IKE] local host is behind NAT,
sending keep ali<br>
ves<br>
Jul 1 15:24:32 NewFS charon: 16[IKE] remote host is behind NAT<br>
Jul 1 15:24:32 NewFS charon: 16[IKE] sending cert request for
"C=US, ST=Florida<br>
, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA, E=Cuda
Systems LLC CA<br>
"<br>
Jul 1 15:24:32 NewFS charon: 16[ENC] generating IKE_SA_INIT
response 0 [ SA KE<br>
No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG)
N(MULT_AUTH) ]<br>
Jul 1 15:24:32 NewFS charon: 16[NET] sending packet: from
192.168.10.100[500] t<br>
o 172.56.21.156[19562] (267 bytes)<br>
Jul 1 15:24:33 NewFS charon: 16[NET] received packet: from
172.56.21.156[51342]<br>
to 192.168.10.100[4500] (1364 bytes)<br>
Jul 1 15:24:33 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [
EF(1/3) ]<br>
Jul 1 15:24:33 NewFS charon: 16[ENC] received fragment #1 of 3,
waiting for com<br>
plete IKE message<br>
Jul 1 15:24:33 NewFS charon: 16[NET] received packet: from
172.56.21.156[51342]<br>
to 192.168.10.100[4500] (1364 bytes)<br>
Jul 1 15:24:33 NewFS charon: 16[ENC] parsed IKE_AUTH request 1 [
EF(2/3) ]<br>
Jul 1 15:24:33 NewFS charon: 16[ENC] received fragment #2 of 3,
waiting for com<br>
plete IKE message<br>
Jul 1 15:24:33 NewFS charon: 13[NET] received packet: from
172.56.21.156[51342]<br>
to 192.168.10.100[4500] (212 bytes)<br>
Jul 1 15:24:33 NewFS charon: 13[ENC] parsed IKE_AUTH request 1 [
EF(3/3) ]<br>
Jul 1 15:24:33 NewFS charon: 13[ENC] received fragment #3 of 3,
reassembling fr<br>
agmented IKE message<br>
Jul 1 15:24:33 NewFS charon: 13[ENC] parsed IKE_AUTH request 1 [
IDi CERT N(INI<br>
T_CONTACT) CERTREQ AUTH CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N)
SA TSi TSr N(<br>
MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY)
N(MSG_ID_SYN_SUP) ]<br>
Jul 1 15:24:33 NewFS charon: 13[IKE] received cert request for
"C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda
Systems LLC CA, E=Cuda Systems LLC C<br>
A"<br>
Jul 1 15:24:33 NewFS charon: 13[IKE] received end entity cert
"C=US, ST=Florida<br>
, O=Cuda Systems LLC, CN=Karl Denninger (OCSP)"<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] looking for peer configs
matching 192.168.<br>
10.100[%any]...172.56.21.156[C=US, ST=Florida, O=Cuda Systems LLC,
CN=Karl Denni<br>
nger (OCSP)]<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] selected peer config
'StrongSwan'<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] using certificate "C=US,
ST=Florida, O=C<br>
uda Systems LLC, CN=Karl Denninger (OCSP)"<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] using trusted ca
certificate "C=US, ST=F<br>
lorida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems LLC CA,
E=Cuda Systems<br>
LLC CA"<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] checking certificate status
of "C=US, ST=F<br>
lorida, O=Cuda Systems LLC, CN=Karl Denninger (OCSP)"<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] ocsp response correctly
signed by "C=US,<br>
ST=Florida, O=Cuda Systems LLC, CN=ocsp.cudasystems.net,
<a class="moz-txt-link-abbreviated" href="mailto:E=info@cudasystems.net">E=info@cudasystems.net</a><br>
"<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] ocsp response contains no
status on our<br>
certificate<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] requesting ocsp status
from '<a class="moz-txt-link-freetext" href="http://cuda">http://cuda</a><br>
systems.net:8888' ...<br>
Jul 1 15:24:33 NewFS charon: 13[LIB] libcurl request failed [52]:
Empty reply f<br>
rom server<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] ocsp request to
<a class="moz-txt-link-freetext" href="http://cudasystems.net:888">http://cudasystems.net:888</a><br>
8 failed<br>
Jul 1 15:24:33 NewFS charon: 13[CFG] requesting ocsp status
from '<a class="moz-txt-link-freetext" href="http://cuda">http://cuda</a><br>
systems.net:8888' ...<br>
Jul 1 15:24:43 NewFS charon: 13[LIB] libcurl request failed [28]:
Connection ti<br>
med out after 10032 milliseconds<br>
Jul 1 15:24:43 NewFS charon: 13[CFG] ocsp request to
<a class="moz-txt-link-freetext" href="http://cudasystems.net:888">http://cudasystems.net:888</a><br>
8 failed<br>
Jul 1 15:24:43 NewFS charon: 13[CFG] ocsp check failed, fallback
to crl<br>
Jul 1 15:24:43 NewFS charon: 13[CFG] certificate status is not
available<br>
Jul 1 15:24:43 NewFS charon: 13[CFG] reached self-signed root
ca with a path<br>
length of 0<br>
Jul 1 15:24:43 NewFS charon: 13[IKE] authentication of 'C=US,
ST=Florida, O=Cud<br>
a Systems LLC, CN=Karl Denninger (OCSP)' with
RSA_EMSA_PKCS1_SHA2_384 successful</tt><br>
<br>
.... and it comes up (I have to run down why the OCSP responses
aren't always working as the responder appears to be dying after
sending the first response, but that's not what's killing it here)<br>
<br>
<br>
<div class="moz-signature">-- <br>
Karl Denninger<br>
<a href="mailto:karl@denninger.net">karl@denninger.net</a><br>
<i>The Market Ticker</i><br>
<font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
</div>
</body>
</html>