[strongSwan] IKE signature scheme RSA_EMSA_PKCS1_SHA1 not acceptable
Jafar Al-Gharaibeh
jafar at atcorp.com
Mon Aug 20 23:31:16 CEST 2018
Binarus, BTW, that was my quick assessment, so there might be more to
the story :-).
--Jafar
On 2018-08-20 16:20, Jafar Al-Gharaibeh wrote:
> 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