[strongSwan] Win7 and Window10Mobile: IKE authentication credentials are unacceptable

[Arne Schmid]

Hi Tobias,

So its an issue with the cipher in the certificate vs. the cipher used to decrypt?

Do I configure the ciphers in strongswan.conf or ipsec.conf (via ike, esp)?

I wonder if switching to eap-mschapv2 would be more easy... (would like to get it running before I'm behind the great red firewall next week)

I use following certificats and the corresponding config:

Looking at the certificates in windows:

*** CA certificate: *** 
    Signature algorithm: sha1RSA
    Signature hash algorithm: sha1
    Issuer: CN = pointcode ca, O = pointcode, C = CN
    Subject: CN = pointcode ca, O = pointcode, C = CN
    Public key: RSA (2048 bytes)
    Basic Constraints: Subject Type=CA, Path Length Constraint=None
    Key Usage: Certificate Signing, Off-line CRL Signing, CRL Signing (06)
    Thumbprint algorithm: sha1
    Subject Key Identifier: 83 a4 70 f7 88 fd 53 70 ac 4b 32 35 23 af 33 e7 03 3a c7 ed

Both "Basic Constraints" and "Key Usage" have a yellow exclamation mark. Not sure, if this is relevant...


*** Server certificate: *** 
    Signature algorithm: sha1RSA
    Signature hash algorithm: sha1
    Issuer: CN = pointcode ca, O = pointcode, C = CN
    Subject: CN = vpn.pointcode.de, O = pointcode, C = CN
    Public key: RSA (2048 bytes)
    Basic Constraints: Subject Type=CA, Path Length Constraint=None
    Key Usage: Certificate Signing, Off-line CRL Signing, CRL Signing (06)
    Thumbprint algorithm: sha1
    Authority Key Identifier: KeyID=83 a4 70 f7 88 fd 53 70 ac 4b 32 35 23 af 33 e7 03 3a c7 ed
    Subject Alternative Name: DNS Name=vpn.pointcode.de
    Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1)

The Authority Key Identifier is the Subject KeyID of the CA cert


*** Client certificate (inside .p12): *** 
    Signature algorithm: sha1RSA
    Signature hash algorithm: sha1
    Issuer: CN = pointcode ca, O = pointcode, C = CN
    Subject: CN = client at vpn.pointcode.de, O = pointcode, C = CN
    Public key: RSA (2048 bytes)
    Basic Constraints: Subject Type=CA, Path Length Constraint=None
    Key Usage: Certificate Signing, Off-line CRL Signing, CRL Signing (06)
    Thumbprint algorithm: sha1
    Authority Key Identifier: KeyID=83 a4 70 f7 88 fd 53 70 ac 4b 32 35 23 af 33 e7 03 3a c7 ed
    Subject Alternative Name: RFC822 Name=client at vpn.pointcode.de
    Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2)

The Authority Key Identifier is the Subject KeyID of the CA cert


*** strongswan.conf ***
    plugins {
        eap-tls {
            fragment_size = 512
        }
    }
    libtls {
        suites = TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    }

** ipsec.conf ***
conn %default
    keyexchange=ikev2
    dpdaction=clear
    #ike=aes256-sha1-modp1024!
    #esp=aes256-sha1!
    ike=aes128-sha1-modp1024,aes128-sha1-modp2048,aes256-sha1-modp1024,aes128-sha256-ecp256,aes256-sha384-ecp384
    esp=aes128-sha1,aes256-sha1,aes128gcm128-ecp256,aes256gcm128-ecp384

thanks,
Arne




----------------------------------------
> To: arne.j.schmid at outlook.com; users at lists.strongswan.org
> From: tobias at strongswan.org
> Date: Tue, 3 May 2016 17:52:10 +0200
> Subject: Re: [strongSwan] Win7 and Window10Mobile: IKE authentication credentials are unacceptable
>
> Hi Arne,
>
>> Did a lot of searching to no avail.
>> I'm on OpenSSL 1.0.1e 11 Feb 2013 if that helps.
>
> That's not really relevant as strongSwan has its own TLS stack (only
> libcrypto is used from OpenSSL, e.g. ECDH here).
>
>> May 2 15:11:50 09[TLS] <winCert|1> processing TLS Handshake record (64 bytes)
>> May 2 15:11:50 09[TLS] <winCert|1> TLS record MAC verification failed
>
> This indicates the message couldn't be verified correctly. Since the
> TLS message is sent in an authenticated IKEv2 messages we can be sure it
> didn't get corrupted on the network. So it was either already sent
> corrupted or the two peers don't use the same keys or algorithms.
>
> In the other email you sent the error now is:
>
>> May 3 14:01:20 05[TLS] processing TLS Handshake record (64 bytes)
>> May 3 14:01:20 05[TLS] TLS record too short to verify MAC
>
> This is strange as the cipher suite is the same in both cases
> (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) and the record is the same length
> too. The only reason it could be too short when verifying the integrity
> is if the decryption produced a result that caused the removal of too
> much data as padding. Which again would indicate the two peers don't
> use the same keys/algorithms.
>
> It's difficult to tell what exactly the problem is without detailed
> debugging. You could try to use different cipher suites (see [1] for
> the configuration options). It might also be an issue with Windows 10
> Mobile because with Windows 7 (TLS 1.0, x86) and with Windows 10 EDU
> (TLS 1.2, x64) I don't have any problems using EAP-TLS with this exact
> same cipher suite.
>
> Regards,
> Tobias
>
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/Eaptls
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users