[strongSwan] Well, I spoke too soon....

[Karl Denninger]

On 12/17/2016 17:32, Karl Denninger wrote:
>
> EAP-CHAPv2 is working against Win10 with a reloaded machine.
>
> However, user certificate authentication is not.
>
> Strongswan 5.1.1 is built with:
>
>  $ ./configure --enable-kernel-pfkey --enable-kernel-pfroute
> --disable-kernel-netlink --disable-tools --disable-scripts
> --with-group=wheel --enable-eap-gtc --enable-xauth-pam
> --enable-eap-mschapv2 --enable-md4 --enable-eap-identity --enable-curl
> --enable-eap-tls
>
> The config file fragment is:
>
> conn %default
>         keyingtries=3
>         keyexchange=ikev2
>
> conn WinUserCert
>         left=%any
>         leftsubnet=0.0.0.0/0
>         leftcert=genesis.denninger.net.crt
>         leftauth=pubkey
>         right=%any
>         rightsourceip=192.168.2.0/24
>         rightsendcert=never
>         rightauth=eap-tls
>         eap_identity=%identity
>         auto=add
>         dpdaction=clear
>         dpddelay=300s
>
> The user certificate checks against the CA:
>
> openssl verify -CAfile CudaSystems.new.crt ksd.ocsp.crt
> ksd.ocsp.crt: OK
>
> The CA file is in cacerts (and is working to self-verify the machine
> certificate for the gateway, which is signed by the same CA)
>
> The user certificate is:
>
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number: 41 (0x29)
>     Signature Algorithm: sha256WithRSAEncryption
>         Issuer: C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC,
> CN=Cuda Systems LLC CA/emailAddress=Cuda Systems LLC CA
>         Validity
>             Not Before: Apr 21 02:21:59 2015 GMT
>             Not After : Apr 19 02:21:59 2020 GMT
>         Subject: C=US, ST=Florida, O=Cuda Systems LLC, CN=Karl
> Denninger (OCSP)
>         Subject Public Key Info:
>             Public Key Algorithm: rsaEncryption
>                 Public-Key: (4096 bit)
>                 Modulus:
>                     00:b9:84:58:f8:40:76:98:6b:59:de:0a:e5:54:ef:
>                     13:9a:71:2f:76:e5:45:03:f2:18:5d:c0:a6:35:23:
>                     82:d6:af:a9:4d:58:f2:96:c8:dc:1c:a0:5c:38:f6:
>                     fd:4c:fd:4a:2f:17:56:3f:e4:35:b2:84:8e:44:61:
> ......
>
>                 Exponent: 65537 (0x10001)
>         X509v3 extensions:
>             Authority Information Access:
>                 OCSP - URI:http://cudasystems.net:8888
>
>             X509v3 Basic Constraints:
>                 CA:FALSE
>             Netscape Cert Type:
>                 SSL Client, S/MIME
>             X509v3 Key Usage:
>                 Digital Signature, Non Repudiation, Key Encipherment
>             Netscape Comment:
>                 OpenSSL Generated Certificate
>             X509v3 Subject Key Identifier:
>                
> C5:1C:94:2D:E9:C9:68:5C:17:46:D4:FB:F5:A3:66:20:1F:EE:E5:59
>             X509v3 Authority Key Identifier:
>                
> keyid:24:71:9B:9D:85:7D:FC:DD:DD:BD:B0:CA:92:94:03:A1:FA:D3:6D:35
>
>             X509v3 Subject Alternative Name:
>                 email:karl at denninger.net
>     Signature Algorithm: sha256WithRSAEncryption
>          4f:7f:77:18:b6:62:a8:c2:61:88:62:c9:ba:78:18:a7:26:ee:
>          d0:55:6b:f1:8b:5b:ea:9c:1c:f7:28:4f:87:6a:9a:a8:21:94:
>          bc:fc:fa:25:07:f8:70:89:8d:14:00:4d:51:b2:30:49:ef:21:
>          23:8a:15:51:c2:e9:a6:48:1b:e4:a0:ec:9f:1b:7d:2e:3e:7e:
>          32:83:8b:db:26:44:7d:95:3c:fc:77:6d:5f:3e:c8:56:11:36:
> .....
>
>
> But StrongSwan rejects verification with:
>
> Dec 17 16:53:55 NewFS charon: 14[NET] received packet: from
> 192.168.1.19[500] to 70.169.168.7[500] (880 bytes)
> Dec 17 16:53:55 NewFS charon: 14[ENC] parsed IKE_SA_INIT request 0 [
> SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
> Dec 17 16:53:55 NewFS charon: 14[IKE] received MS NT5 ISAKMPOAKLEY v9
> vendor ID
> Dec 17 16:53:55 NewFS charon: 14[IKE] received MS-Negotiation
> Discovery Capable vendor ID
> Dec 17 16:53:55 NewFS charon: 14[IKE] received Vid-Initial-Contact
> vendor ID
> Dec 17 16:53:55 NewFS charon: 14[ENC] received unknown vendor ID:
> 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
> Dec 17 16:53:55 NewFS charon: 14[IKE] 192.168.1.19 is initiating an IKE_SA
> Dec 17 16:53:55 NewFS charon: 14[ENC] generating IKE_SA_INIT response
> 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
> Dec 17 16:53:55 NewFS charon: 14[NET] sending packet: from
> 70.169.168.7[500] to 192.168.1.19[500] (308 bytes)
> Dec 17 16:53:55 NewFS charon: 12[NET] received packet: from
> 192.168.1.19[4500] to 70.169.168.7[4500] (1628 bytes)
> Dec 17 16:53:55 NewFS charon: 12[ENC] parsed IKE_AUTH request 1 [ IDi
> CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]
> Dec 17 16:53:55 NewFS charon: 12[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"
> Dec 17 16:53:55 NewFS charon: 12[IKE] received 57 cert requests for an
> unknown ca
> Dec 17 16:53:55 NewFS charon: 12[CFG] looking for peer configs
> matching 70.169.168.7[%any]...192.168.1.19[192.168.1.19]
> Dec 17 16:53:55 NewFS charon: 12[CFG] selected peer config 'WinUserCert'
> Dec 17 16:53:55 NewFS charon: 12[IKE] initiating EAP_IDENTITY method
> (id 0x00)
> Dec 17 16:53:55 NewFS charon: 12[IKE] peer supports MOBIKE
> Dec 17 16:53:56 NewFS charon: 12[IKE] authentication of 'C=US,
> ST=Florida, O=Cuda Systems LLC, CN=genesis.denninger.net,
> E=postmaster at denninger.net' (myself) with RSA signature successful
> Dec 17 16:53:56 NewFS charon: 12[IKE] sending end entity cert "C=US,
> ST=Florida, O=Cuda Systems LLC, CN=genesis.denninger.net,
> E=postmaster at denninger.net"
> Dec 17 16:53:56 NewFS charon: 12[ENC] generating IKE_AUTH response 1 [
> IDr CERTAUTH EAP/REQ/ID ]
> Dec 17 16:53:56 NewFS charon: 12[NET] sending packet: from
> 70.169.168.7[4500] to 192.168.1.19[4500] (2420 bytes)
> Dec 17 16:53:56 NewFS charon: 16[NET] received packet: from
> 192.168.1.19[4500] to 70.169.168.7[4500] (84 bytes)
> Dec 17 16:53:56 NewFS charon: 16[ENC] parsed IKE_AUTH request 2 [
> EAP/RES/ID ]
>
> Looks ok up to here -- the gateway authenticated itself against the CA
> and sent down the gateway certificate.
>
> Dec 17 16:53:56 NewFS charon: 16[IKE] received EAP identity 'Karl
> Denninger (OCSP)'
>
> (Uh, why didn't I get the SAN back?  It IS set; the CN is worthless on
> a S/MIME & VPN cert allegedly....  I can't set it anyway, and )
>
> Dec 17 16:53:56 NewFS charon: 16[IKE] initiating EAP_TLS method (id 0x44)
> Dec 17 16:53:56 NewFS charon: 16[ENC] generating IKE_AUTH response 2 [
> EAP/REQ/TLS ]
> Dec 17 16:53:56 NewFS charon: 16[NET] sending packet: from
> 70.169.168.7[4500] to 192.168.1.19[4500] (68 bytes)
> Dec 17 16:53:56 NewFS charon: 16[NET] received packet: from
> 192.168.1.19[4500] to 70.169.168.7[4500] (244 bytes)
> Dec 17 16:53:56 NewFS charon: 16[ENC] parsed IKE_AUTH request 3 [
> EAP/RES/TLS ]
> Dec 17 16:53:56 NewFS charon: 16[TLS] negotiated TLS 1.2 using suite
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> Dec 17 16:53:56 NewFS charon: 16[TLS] sending TLS server certificate
> 'C=US, ST=Florida, O=Cuda Systems LLC, CN=genesis.denninger.net,
> E=postmaster at denninger.net'
> Dec 17 16:53:56 NewFS charon: 16[TLS] sending TLS cert request for
> 'C=US, ST=Florida, L=Niceville, O=Cuda Systems LLC, CN=Cuda Systems
> LLC CA, E=Cuda Systems LLC CA'
> Dec 17 16:53:56 NewFS charon: 16[ENC] generating IKE_AUTH response 3 [
> EAP/REQ/TLS ]
> Dec 17 16:53:56 NewFS charon: 16[NET] sending packet: from
> 70.169.168.7[4500] to 192.168.1.19[4500] (1084 bytes)
> Dec 17 16:53:56 NewFS charon: 16[NET] received packet: from
> 192.168.1.19[4500] to 70.169.168.7[4500] (68 bytes)
> Dec 17 16:53:56 NewFS charon: 16[ENC] parsed IKE_AUTH request 4 [
> EAP/RES/TLS ]
> Dec 17 16:53:56 NewFS charon: 16[ENC] generating IKE_AUTH response 4 [
> EAP/REQ/TLS ]
> Dec 17 16:53:56 NewFS charon: 16[NET] sending packet: from
> 70.169.168.7[4500] to 192.168.1.19[4500] (1084 bytes)
> Dec 17 16:53:56 NewFS charon: 05[NET] received packet: from
> 192.168.1.19[4500] to 70.169.168.7[4500] (68 bytes)
> Dec 17 16:53:56 NewFS charon: 05[ENC] parsed IKE_AUTH request 5 [
> EAP/RES/TLS ]
> Dec 17 16:53:56 NewFS charon: 05[ENC] generating IKE_AUTH response 5 [
> EAP/REQ/TLS ]
> Dec 17 16:53:56 NewFS charon: 05[NET] sending packet: from
> 70.169.168.7[4500] to 192.168.1.19[4500] (1012 bytes)
> Dec 17 16:54:11 NewFS charon: 11[NET] received packet: from
> 192.168.1.19[4500] to 70.169.168.7[4500] (1460 bytes)
> Dec 17 16:54:11 NewFS charon: 11[ENC] parsed IKE_AUTH request 6 [
> EAP/RES/TLS ]
> Dec 17 16:54:11 NewFS charon: 11[ENC] generating IKE_AUTH response 6 [
> EAP/REQ/TLS ]
> Dec 17 16:54:11 NewFS charon: 11[NET] sending packet: from
> 70.169.168.7[4500] to
>  192.168.1.19[4500] (68 bytes)
> Dec 17 16:54:11 NewFS charon: 11[NET] received packet: from
> 192.168.1.19[4500] to 70.169.168.7[4500] (1180 bytes)
> Dec 17 16:54:11 NewFS charon: 11[ENC] parsed IKE_AUTH request 7 [
> EAP/RES/TLS ]
> Dec 17 16:54:11 NewFS charon: 11[TLS] received TLS peer certificate
> 'C=US, ST=Florida, O=Cuda Systems LLC, CN=Karl Denninger (OCSP)'
> Dec 17 16:54:11 NewFS charon: 11[TLS] no trusted certificate found for
> 'Karl Denninger (OCSP)' to verify TLS peer
>
> What is it looking for here and not finding?  If an entry in
> ipsec.secrets, what's the syntax (the obvious doesn't work)
>
> Dec 17 16:54:11 NewFS charon: 11[TLS] sending fatal TLS alert
> 'certificate unknown'
> Dec 17 16:54:11 NewFS charon: 11[ENC] generating IKE_AUTH response 7 [
> EAP/REQ/TLS ]
> Dec 17 16:54:11 NewFS charon: 11[NET] sending packet: from
> 70.169.168.7[4500] to 192.168.1.19[4500] (76 bytes)
> Dec 17 16:54:11 NewFS charon: 13[NET] received packet: from
> 192.168.1.19[4500] to 70.169.168.7[4500] (68 bytes)
> Dec 17 16:54:11 NewFS charon: 13[ENC] parsed IKE_AUTH request 8 [
> EAP/RES/TLS ]
> Dec 17 16:54:11 NewFS charon: 13[IKE] EAP method EAP_TLS failed for
> peer 192.168.1.19
> Dec 17 16:54:11 NewFS charon: 13[ENC] generating IKE_AUTH response 8 [
> EAP/FAIL]
>
> Incidentally this same cert works on Android against the same server
> using the StrongSwan client...
>
> I'm obviously missing something.... thanks in advance!
>
> -- 
> Karl Denninger
> karl at denninger.net <mailto:karl at denninger.net>
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

If I set eip_identity=user at host.domain explicitly in the config file to
my SAN then it finds the cert in the valid set and connects.

But shouldn't Windows be sending that back?  Or do it do so only if CN
is blank (if so, BARF -- shouldn't it PREFER the SAN if that's set over
the CN?!)

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20161217/bfb738bd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20161217/bfb738bd/attachment-0001.bin>