[strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
Jafar Al-Gharaibeh
jafar at atcorp.com
Mon Aug 20 23:20:59 CEST 2018
On 08/20/2018 02:35 PM, Binarus wrote:
> However, since I was absolutely sure that nobody at my client's site had changed their router's configuration, I have done further research. Among others, I have studied my /etc/strongswan.d/charon.conf again and came across a setting which looked highly suspicious to me:
>
> signature_authentication_constraints = yes
>
> Entering "signature_authentication_constraints" into Google immediately lead to this article:
>
> https://www.strongswan.org/blog/2015/03/30/strongswan-5.3.0-released.html
>
> After having read the second section of that article, I turned off the setting mentioned above (i.e. set it to no), and now it works as before.
>
> So it seems that the issue didn't have anything to do with non-matching proposals, but with that setting, which seems to have been introduced (or seems to have been assigned another default value) with version 5.3.0. This explains why my old configuration with the old version 5.2.1 worked, but the same configuration with the new version 5.5.1 didn't.
The issue does have something to do with non-matching proposals. It
is just that for signature schemes prior to version 5.3 the signature
constraints were not enforced. In your configuration you have :
leftauth=rsa-4096-sha512
rightauth=rsa-4096-sha512
That means you expect the certificates at both ends to use use at
least 4096 RSA keys and sha512 for signature schemes. You had the
setting all the time but it wasn't being enforced prior to 5.3, but now
it is. Instead of fixing it by turning
signature_authentication_constraints
off, I would generate new certificates with that strength if you want it
that strong, or just lower your constraints in left/rightauth to match
your existing certs. see left/rightauth at [1].
Regards,
Jafar
[1] https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
>
> While my urgent and immediate problem is solved now, I still have a hard time actually understanding what that article section is talking about. I would be grateful if somebody could explain the issue for people who are not full-time professional cryptographers. Specifically, I have not fully understood the following sentences yet:
>
> "Key types and hash algorithms specified in rightauth are now also checked against IKEv2 signature schemes. If such constraints are used for certificate chain validation in existing configurations, in particular with peers that don't support RFC 7427, it may be necessary to disable this feature with the charon.signature_authentication_constraints setting, because the signature scheme used in classic IKEv2 public key authentication may not be strong enough."
>
> I believe I have configured the strongest rightauth and leftauth scheme the router at the client's site supports, which probably is the strongest scheme commonly used with RSA (at least, I haven't heard of SHA768 or SHA1024 yet, or that SHA3 or RSA8192 are currently being supported by more than a few exotic router / VPN devices). Furthermore, when initially configuring the VPN between me and my client (about 2 years ago), I have newly created *all* certificates involved from scratch, using RSA 4096 and SHA-512.
>
> So what exactly does StrongSwan (charon) expect here (i.e. what would it consider strong enough), and how do I configure it (in case I decide to re-enable signature_authentication_constraints)? A simple explanation would be very nice; otherwise, probably we (I assume that I am not the only person who hasn't fully understood that section) will have to study RFC 7427, which we'd like to avoid :-).
>
> Thank you very much in advance,
>
> Binarus
>
>
>
>> --Jafar
>>
>>
>>
>>
>> On 08/18/2018 10:26 AM, Binarus wrote:
>>> Dear all,
>>>
>>> I am getting the error message mentioned above when trying to connect to
>>> a client's site. Of course, I have tried to research if there already
>>> has been a similar problem, and have found exactly one appropriate thread:
>>>
>>> https://lists.strongswan.org/pipermail/users/2018-March/012351.html
>>>
>>> Unfortunately, my situation is different; in my case, something else
>>> seems to cause the problem. Having said this:
>>>
>>> - It happened after the upgrade from Debian jessie (Debian 8) to Debian
>>> stretch (Debian 9), i.e. after the upgrade from StrongSwan 5.2.1 to
>>> StrongSwan 5.5.1)
>>>
>>> - I definitely have copied the whole configuration (including
>>> certificates and so on) from the old system to the new one (AFTER having
>>> installed the new StrongSwan version in the new system). I have double
>>> checked multiple times (applying different methods) that nothing is missing.
>>>
>>> - With the old system, I definitely could connect to the client's site
>>> without any problem with exact that configuration.
>>>
>>> If it matters, the VPN Gateway at the client's side is a Lancom router
>>> (I don't know the exact type, but it is newer one, and I am absolutely
>>> sure that they didn't any changes to it while I was upgrading my system,
>>> and to stress it again, the old system / StrongSwan version could
>>> connect to that device without problems).
>>>
>>> This is my /etc/ipsec.conf (sensitive data has been changed, and lines
>>> which are commented out have been left away):
>>>
>>>
>>> config setup
>>>
>>> conn %default
>>> mobike=no
>>>
>>> conn myclient
>>> ikelifetime=10800s
>>> keylife=3600s
>>> rekeymargin=9m
>>> keyingtries=1
>>> type=tunnel
>>> keyexchange=ikev2
>>> mobike=no
>>> ike=aes256-sha512-modp4096!
>>> esp=aes256-sha512-modp4096!
>>> left=xxxxxxxxxxxxxxxx.hopto.org
>>> leftauth=rsa-4096-sha512
>>> leftid="/CN=xxxxxxxxxxxxxxxx.hopto.org"
>>> leftsubnet=192.168.20.0/24
>>> leftfirewall=no
>>> leftcert=mycompany-client.crt
>>> right=yyyyyyyyyyyyyyyy.zapto.org
>>> rightauth=rsa-4096-sha512
>>> rightid="/CN=yyyyyyyyyyyyyyyy.zapto.org"
>>> rightsubnet=192.168.0.0/24
>>> auto=add
>>>
>>>
>>> This is the error message (sensitive data changed in the same way as
>>> with ipsec.conf):
>>>
>>> root at charon:/etc# /etc/init.d/ipsec restart
>>> [ ok ] Restarting ipsec (via systemctl): ipsec.service.
>>> root at charon:/etc# ipsec up myclient
>>> initiating IKE_SA myclient[3] to 79.192.42.125
>>> generating 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) ]
>>> sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (714 bytes)
>>> received packet: from 79.192.42.125[500] to 87.185.83.87[500] (713 bytes)
>>> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ ]
>>> received 1 cert requests for an unknown ca
>>> sending cert request for "CN=ca.clientsite.local"
>>> authentication of 'CN=xxxxxxxxxxxxxxxx.hopto.org' (myself) with RSA
>>> signature successful
>>> sending end entity cert "CN=xxxxxxxxxxxxxxxx.hopto.org"
>>> establishing CHILD_SA myclient
>>> generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr
>>> AUTH SA TSi TSr N(EAP_ONLY) ]
>>> sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (2048 bytes)
>>> received packet: from 79.192.42.125[500] to 87.185.83.87[500] (1984 bytes)
>>> parsed IKE_AUTH response 1 [ IDr CERT AUTH TSi TSr N(INIT_CONTACT) SA ]
>>> received end entity cert "CN=yyyyyyyyyyyyyyyy.zapto.org"
>>> using certificate "CN=yyyyyyyyyyyyyyyy.zapto.org"
>>> using trusted ca certificate "CN=ca.clientsite.local"
>>> checking certificate status of "CN=yyyyyyyyyyyyyyyy.zapto.org"
>>> certificate status is not available
>>> reached self-signed root ca with a path length of 0
>>> authentication of 'CN=yyyyyyyyyyyyyyyy.zapto.org' with RSA signature
>>> successful
>>> IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
>>> selected peer config 'myclient' inacceptable: constraint checking failed
>>> no alternative config found
>>> generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
>>> sending packet: from 87.185.83.87[500] to 79.192.42.125[500] (96 bytes)
>>> establishing connection 'myclient' failed
>>> root at charon:/etc#
>>>
>>>
>>> Does anybody have an idea?
>>>
>>> Thank you very much in advance,
>>>
>>> Binarus
>>>
>>>
More information about the Users
mailing list