Project

General

Profile

Issue #3631

Unable to establish a connection w/ECDSA Certs (Follow up #1063)

Added by Jan-Otto K almost 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Tobias Brunner
Category:
ikev1
Affected version:
5.9.1
Resolution:
Won't fix

Description

Hi,

it's a follow up issue from https://wiki.strongswan.org/issues/1063 Since this issue is closed as "No Feedback". I would like to give feedback to this issue.

I don't know if it's safe to respond to closed issues, that why I create a new one.

Like Aiden A, i had exactly the same issue (OSX Client, ECDSA Certificates). I don't know if this issue is related to MacOS.

I tried the patch attach to the issue and modified it for the latest version 5.9.1, then I sucessfully build strongswan in linux using:

./configure --prefix=/usr --sysconfdir=/etc --enable-unity --enable-xauth-eap --enable-eap-radius --enable-eap-identity --enable-openssl

Before the patch I had the same output like in the original issue, now I have this:

Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG] looking for XAuthInitRSA peer configs matching 10.124.4.182...87.146.92.181[CN=jkr]
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   candidate "Roadwarrior", match: 1/1/28 (me/other/ike)
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG] selected peer config "Roadwarrior" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   using certificate "CN=jkr" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   certificate "CN=jkr" key: 521 bit ECDSA
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   using trusted ca certificate "CN=vpn-gateway-test.example.com CA" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG] checking certificate status of "CN=jkr" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG] ocsp check skipped, no ocsp found
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   using trusted certificate "CN=vpn-gateway-test.example.com CA" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   crl correctly signed by "CN=vpn-gateway-test.example.com CA" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   crl is valid: until May 15 01:00:01 2021
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   using cached crl
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG] certificate status is good
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   certificate "CN=vpn-gateway-test.example.com CA" key: 521 bit ECDSA
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   reached self-signed root ca with a path length of 0
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[IKE] signature validation failed, looking for another key
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   using certificate "CN=jkr" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   certificate "CN=jkr" key: 521 bit ECDSA
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   using trusted ca certificate "CN=vpn-gateway-test.example.com CA" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG] checking certificate status of "CN=jkr" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG] ocsp check skipped, no ocsp found
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   using trusted certificate "CN=vpn-gateway-test.example.com CA" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   crl correctly signed by "CN=vpn-gateway-test.example.com CA" 
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   crl is valid: until May 15 01:00:01 2021
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   using cached crl
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG] certificate status is good
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   certificate "CN=vpn-gateway-test.example.com CA" key: 521 bit ECDSA
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG]   reached self-signed root ca with a path length of 0
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[IKE] signature validation failed, looking for another key
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[IKE] no trusted ANY public key found for 'CN=jkr'
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[CFG] no alternative config found
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[IKE] queueing INFORMATIONAL task
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[IKE] activating new tasks
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[IKE]   activating INFORMATIONAL task
Nov 17 03:02:50 ip-10-124-4-182 charon[521117]: 09[ENC] generating INFORMATIONAL_V1 request 4037269220 [ HASH N(AUTH_FAILED) ]
Questions:
  • Is the patch still correct?
  • Is the "signature validation failed" error related to the original issue?
  • If the patch is correct, could this patch summited upstream?

Thanks

search-for-any-key-for-xauthrsa.5.9.1.patch (2.58 KB) search-for-any-key-for-xauthrsa.5.9.1.patch Jan-Otto K, 17.11.2020 11:10

Related issues

Related to Issue #1063: Unable to establish a connection w/ECDSA CertsClosed

History

#1 Updated by Tobias Brunner almost 5 years ago

  • Related to Issue #1063: Unable to establish a connection w/ECDSA Certs added

#2 Updated by Tobias Brunner almost 5 years ago

  • Status changed from New to Feedback

Like Aiden A, i had exactly the same issue (OSX Client, ECDSA Certificates). I don't know if this issue is related to MacOS.

Please note that #1063 was opened over 5 years ago, using IKEv1 with Apple clients makes absolutely no sense nowadays. Use IKEv2 please.

  • Is the patch still correct?

I really don't know if it ever worked (I think I only compile tested it). There are also some issues with the scheme selection as keymat_v1_t::get_hash() can now change it.

  • Is the "signature validation failed" error related to the original issue?

Could be a problem with the actual ECDSA signature, depending on how the client created it.

  • If the patch is correct, could this patch summited upstream?

IKEv1 is dead.

#3 Updated by Jan-Otto K almost 5 years ago

Hi,

using IKEv1 with Apple clients makes absolutely no sense nowadays. Use IKEv2 please.

I tried IKEv2 first. In the current setup, I want to use certificate as primary authentication (pubkey) and user/password trough EAP as secondary auth.

On MacOS using IKEv2, I could use certificate XOR EAP but not both. (See: https://wiki.strongswan.org/projects/strongswan/wiki/AppleIKEv2Profile#Authentication-options). IKEv1 (named Cisco VPN) certificate (pubkey) and EAP auth is possible.

I also tried EAP only with multiple authentications rounds, but it looks like not supported.

Could be a problem with the actual ECDSA signature, depending on how the client created it.

I create the certificates (both ca and client) through easy-rsa v3. In EAP-TLS on IKEv2, the certificates working fine.

IKEv1 is dead.

I wish I could use IKEv2, maybe I miss understand how to integrate certification and user password on IKEv2. The UI or the mobileconfig provides such options.

#4 Updated by Tobias Brunner almost 5 years ago

In the current setup, I want to use certificate as primary authentication (pubkey) and user/password trough EAP as secondary auth.

Why? What do you expect to gain?

IKEv1 (named Cisco VPN) certificate (pubkey) and EAP auth is possible.

It's not EAP, but XAuth. And ECDSA is not really specified for use with XAuth (the XAuth draft predates the ECDSA RFC by nearly a decade), only with regular pubkey authentication, where there are separate identifiers for each curve/hash function. The latter could actually provide a possible explanation for the signature verification error, with a 521-bit key you might have to manually ensure that SHA-512 is negotiated as hash/PRF function for IKE.

I also tried EAP only with multiple authentications rounds, but it looks like not supported.

Depending on the client, you could use a client certificate in EAP-PEAP/TTLS and then use another EAP-method inside. But I guess many clients don't support this.

I create the certificates (both ca and client) through easy-rsa v3. In EAP-TLS on IKEv2, the certificates working fine.

How you created the certificates is not really relevant. And ECDSA signatures in IKEv2 or TLS are also not comparable to IKEv1.

I wish I could use IKEv2, maybe I miss understand how to integrate certification and user password on IKEv2. The UI or the mobileconfig provides such options.

There are only few clients (if any) that support multiple authentication rounds for IKEv2.

#5 Updated by Jan-Otto K almost 5 years ago

with a 521-bit key you might have to manually ensure that SHA-512 is negotiated as hash/PRF function for IKE.

I test it, but no difference, same error.

Nov 17 21:19:00 ip-10-124-4-182 charon[567014]: 11[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048
Nov 17 21:19:00 ip-10-124-4-182 charon[567014]: 11[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048

Anyway, if IKEv1 is dead, we could close this.

#6 Updated by Tobias Brunner almost 5 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Won't fix

with a 521-bit key you might have to manually ensure that SHA-512 is negotiated as hash/PRF function for IKE.

I test it, but no difference, same error.

Yeah, really depends on how the client creates the signature.