<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
Hello,<br>
<br>
I came across this problem when migrating a L2L VPN (VTI) from PSK
to Digital Certificates, between Strongswan 5.9.7 and Cisco
Firepower 7.0.4<br>
<br>
Problem:<br>
After switching to certificate (auth=pubkey, ...) this error showed
up in Strongswan:<br>
signature validation failed, looking for another key<br>
<br>
During troubleshooting I found this issue:<br>
<a class="moz-txt-link-freetext" href="https://wiki.strongswan.org/issues/3059">https://wiki.strongswan.org/issues/3059</a><br>
===<br>
Don't know what that is, but maybe you configured something
incorrectly there or the implementation does something wrong when it
produces the signature value. One possible cause could be if it
doesn't use SHA-1 for the signature (it's the only hash algorithm
strongSwan uses for the legacy IKEv2 RSA authentication, i.e. if RFC
7427 is not supported/used by the peer)<br>
===<br>
<br>
And also, in Cisco:<br>
<a class="moz-txt-link-freetext" href="https://bst.cisco.com/quickview/bug/CSCuw01249">https://bst.cisco.com/quickview/bug/CSCuw01249</a> (Enhancement request
to support RFC 7427). Still open (not implemented).<br>
<a class="moz-txt-link-freetext" href="https://bst.cisco.com/quickview/bug/CSCvb21927">https://bst.cisco.com/quickview/bug/CSCvb21927</a><br>
===<br>
Cisco Adaptive Security Appliance (ASA) Software<br>
Symptom:<br>
3rd party IKEv2 client will fail to validate authentication response
from the ASA when certificates are being used.<br>
For example, Strongswan will return:<br>
"signature validation failed, looking for another key"<br>
Windows native IKEv2 client will return:<br>
"Error 13826: Failed to verify signature"<br>
<b>Conditions:</b><b><br>
</b><b>- PRF SHA2 (SHA256 or SHA512) is in use under "crypto ikev2
policy"</b><br>
<b>Workaround:</b><b><br>
</b><b>- Use PRF SHA1</b><b><br>
</b>- Apple iOS built-in client works with SHA-256 but fails with
SHA512<br>
Further Problem Description:<br>
With PRF SHA2 ASA uses SHA2 to sign authentication payload. The
rfc7427 say <b>SHA-1 should be used, but it is not mandatory</b>.<br>
For the sake of interoperability with 3rd party implementations
unable to use SHA2 the following command was introduced:<br>
tunnel-group TUN-GROUP ipsec-attributes<br>
ikev2 rsa-sig-hash sha1<br>
===<br>
<br>
<u><b>In my tests I found out that Cisco uses the same algorithm for
RSA Digital Signature than the one agreed PRF in proposal</b></u>.<br>
So, if Strongswan uses proposals = aes256gcm128-prfsha512-ecp521 and
Cisco Firepower is using defaults, SHA2-512 is used in PRF and in
RSA authentication. <br>
===<br>
charon-systemd[3442731]: received proposals:
IKE:AES_GCM_16_256/AES_GCM_16_192/AES_GCM_16_128/PRF_HMAC_SHA2_512/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/ECP_521/ECP_384/ECP_256/MODP_4096/MODP_3072/MODP_2048<br>
charon-systemd: charon-systemd[3442731]: configured proposals:
IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/ECP_521<br>
charon-systemd: charon-systemd[3442731]: selected proposal:
IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/ECP_521<br>
...<br>
charon-systemd: charon-systemd[3442731]: using cached ocsp
response<br>
charon-systemd: charon-systemd[3442731]: certificate status is good<br>
charon-systemd: charon-systemd[3442731]: certificate "C=ES, O=XXX,
CN=XXXX" key: 2048 bit RSA<br>
charon-systemd: charon-systemd[3442731]: reached self-signed root
ca with a path length of 0<br>
charon-systemd: charon-systemd[3442731]: signature validation
failed, looking for another key<br>
===<br>
This is because Strongswan is using SHA-1 but Cisco is sending
SHA2-512.<br>
<br>
Actually, it is the rfc7296 the one mentioning SHA-1.<br>
<a class="moz-txt-link-freetext" href="https://www.rfc-editor.org/rfc/rfc7296#section-3.8">https://www.rfc-editor.org/rfc/rfc7296#section-3.8</a><br>
===<br>
RSA Digital Signature 1<br>
Computed as specified in Section 2.15 using an RSA private key<br>
with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1]<br>
(implementers should note that IKEv1 used a different method
for<br>
RSA signatures). To promote interoperability, implementations<br>
that support this type <b>SHOULD</b> support signatures that
use SHA-1<br>
as the hash function and <b>SHOULD</b> use SHA-1 as the
default hash<br>
function when generating signatures. Implementations can use
the<br>
certificates received from a given peer as a hint for
selecting a<br>
mutually understood hash function for the AUTH payload
signature.<br>
Note, however, that the hash algorithm used in the AUTH
payload<br>
signature doesn't have to be the same as any hash algorithm(s)<br>
used in the certificate(s).<br>
===<br>
<br>
Without RFC 7427 we only have a recommendation (SHOULD), as per RFC
2119<br>
===<br>
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there<br>
may exist valid reasons in particular circumstances to ignore a<br>
particular item, but the full implications must be understood and<br>
carefully weighed before choosing a different course.<br>
===<br>
<br>
So, considering all this, I have made a patch to try SHA2-512,
SHA2-384, SHA2-256 if SHA1 fails. It is more a "quick and dirty"
patch, sorry, my knowledge of Strongswan internals is limited.<br>
Another approach could be to use the pre-agreed PRF algorithm for
RSA Auth, if SHA-1 fails.<br>
<br>
With this patch the VPN between Strongswan and Cisco Firepower is
successful with any proposal I tested.<br>
===<br>
charon-systemd: charon-systemd[3523065]: using certificate "C=XX,
O=XXXX, CN=XXXX"<br>
charon-systemd: charon-systemd[3523065]: certificate "C=XX,
O=XXXX, CN=XXXX" key: 4096 bit RSA<br>
charon-systemd: charon-systemd[3523065]: using trusted ca
certificate "C=XX, O=XXXX, CN=CAXXXX"<br>
charon-systemd: charon-systemd[3523065]: checking certificate status
of "C=XX, O=XXXX, CN=XXXX"<br>
charon-systemd: charon-systemd[3523065]: ocsp response correctly
signed by "C=XX, O=XXXX, CN=OCSPXXXX"<br>
charon-systemd: charon-systemd[3523065]: ocsp response is valid:
until Sep 23 15:54:09 2022<br>
charon-systemd: charon-systemd[3523065]: using cached ocsp
response<br>
charon-systemd: charon-systemd[3523065]: certificate status is good<br>
charon-systemd: charon-systemd[3523065]: certificate "C=XX,
O=XXXX, CN=CAXXXX" key: 2048 bit RSA<br>
charon-systemd: charon-systemd[3523065]: reached self-signed root
ca with a path length of 0<br>
charon-systemd: charon-systemd[3523065]: <b>authentication of
'C=XX, O=XXXX, CN=XXXX' with RSA_EMSA_PKCS1_SHA1 failed. Retrying
with RSA_EMSA_PKCS1_SHA2_512</b><br>
charon-systemd: charon-systemd[3523065]: using certificate "C=XX,
O=XXXX, CN=XXXX"<br>
charon-systemd: charon-systemd[3523065]: certificate "C=XX,
O=XXXX, CN=XXXX" key: 4096 bit RSA<br>
charon-systemd: charon-systemd[3523065]: using trusted ca
certificate "C=XX, O=XXXX, CN=CAXXXX"<br>
charon-systemd: charon-systemd[3523065]: checking certificate status
of "C=XX, O=XXXX, CN=XXXX"<br>
charon-systemd: charon-systemd[3523065]: ocsp response correctly
signed by "C=XX, O=XXXX, CN=OCSPXXXX"<br>
charon-systemd: charon-systemd[3523065]: ocsp response is valid:
until Sep 23 15:54:09 2022<br>
charon-systemd: charon-systemd[3523065]: using cached ocsp
response<br>
charon-systemd: charon-systemd[3523065]: certificate status is good<br>
charon-systemd: charon-systemd[3523065]: certificate "C=XX,
O=XXXX, CN=CAXXXX" key: 2048 bit RSA<br>
charon-systemd: charon-systemd[3523065]: reached self-signed root
ca with a path length of 0<br>
charon-systemd: charon-systemd[3523065]: <b>authentication of
'C=XX, O=XXXX, CN=XXXX with RSA_EMSA_PKCS1_SHA2_512 successful</b><br>
===<br>
<br>
Patch is attached.<br>
<br>
Regards,<br>
Carlos Velasco<br>
<br>
</body>
</html>