[strongSwan] [EXTERN] Re: eap-dynamic (eap-tls, eap-mschapv2) and cacerts constraints

[Andreas Weigel]

Hi again,

thanks for the quick relpy.

> but it doesn't have any effect on the trust chain verification of  
> our TLS stack

This, however, is not consistent with my observations. With the same  
swanctl.conf on initiator and responder and two different certificate  
chains, just adding the cacerts parameter at the responder causes a  
difference between successful connection and failed connection:

swanctl.conf (responder):
authorities {
     ca-797 {
         cacert = /etc/strongswan/swanctl/x509ca/ipsectest_root.pem
     }
     ca-801 {
         cacert = /etc/strongswan/swanctl/x509ca/ipsectest_intermediate1.pem
     }
     ca-806 {
         cacert = /etc/strongswan/swanctl/x509ca/hctest_ca.pem
         crl_uris = file:///etc/strongswan/swanctl/x509crl/hctest_ca.crl
     }
}
connections {
     hc_gw_eap {
         version = 2
         local_addrs = 192.168.41.130
         remote_addrs = %any
         local {
             auth = pubkey
             certs = hc_server.pem
         }
         remote {
             auth = eap-tls
             id = %any
             revocation = strict
             # uncommenting the following line leads to unsuccessful  
connections from a client using ipsectest_client02.crt, which is *not*  
signed by hctest_ca.pem (but by ipsectest_intermediate1.pem)
             #cacerts = hctest_ca.pem
         }
         pools = dhcp
         rekey_time=0m
         reauth_time=231m
         over_time=9m
         rand_time=9m
         keyingtries=0
         proposals = aes256-sha2_256-modp4096
         children {
             hc_gw_eap {
                 start_action = none
                 ipcomp = no
                 local_ts = 192.168.182.0/24
                 mode = tunnel
                 life_time=480m
                 rekey_time=471m
                 rand_time=9m
                 esp_proposals = aes256-sha2_256
             }
         }
     }
}
secrets {
}
pools {
}

charon logs (without cacerts parameter):
2022-08-08T14:33:27.204-04:00|charon||10[IKE] <hc_gw_eap|2> CHILD_SA  
hc_gw_eap{1} established with SPIs c29d4c97_i c5b85877_o and TS  
192.168.182.0/24 === 192.168.182.72/32
2022-08-08T14:33:27.206-04:00|charon||10[CHD] <hc_gw_eap|2> CHILD_SA  
hc_gw_eap{1} state change: INSTALLING => INSTALLED

uncommenting cacerts = hctest_ca.pem above, I get:
2022-08-08T14:34:27.609-04:00|charon||07[IKE] <hc_gw_eap|2>  
authentication of 'C=CA, ST=Ontario, L=Ottawa, O=SP, OU=DEV,  
CN=ipsectest_client2' with EAP successful
2022-08-08T14:34:27.609-04:00|charon||07[CFG] <hc_gw_eap|2> constraint  
check failed: peer not authenticated by CA 'C=DE, ST=Niedersachsen,  
L=Lueneburg, O=SP, OU=DEV, CN=hctest_ca,  
E=andreas.weigel at securepoint.de'
2022-08-08T14:34:27.609-04:00|charon||07[CFG] <hc_gw_eap|2> selected  
peer config 'hc_gw_eap' unacceptable: non-matching authentication done

If I add the ipsectest_root.pem certificate (this is the one that  
signed ipsectest_intermediate1.pem, which in turn signed  
ipsectest_client2.pem, which is used by the client), the connection is  
established again. The same behavior I can observe with eap-dynamic on  
the responder (instead of eap-tls).

Long story short, this behavior is exactly what I expected and want,  
however, there should be no checking of cacerts with eap-dynamic if  
the client uses eap-mschapv2 (or whatever mechanism not based on  
certificates), as stated in my original post.

swanctl --version
strongSwan swanctl 5.9.7

(FWIW, I also had the responder on 5.8.4 for exactly the same behavior).

Andreas Weigel

Zitat von Andreas Steffen <andreas.steffen at strongswan.org>:

> Hi Andreas,
>
> as far as I know, the "cacerts" parameter currently applies to the IKEv2
> trust chain verification only (it primarily controls which CAs are
> requested by the CERTREQ payload), but it doesn't have any effect
> on the trust chain verification of our TLS stack.
>
> Best regards
>
> Andreas
>
> On 05.08.22 21:44, Andreas Weigel wrote:
>> Hi everyone,
>>
>> I have a setup in which a gateway uses eap-dynamic to authenticate  
>> clients using either eap-mschapv2 or eap-tls, basically the same as  
>> https://www.strongswan.org/testing/testresults/ikev2/rw-eap-dynamic/.
>>
>> Now, if I try to specify the cacerts parameter in the remote  
>> section of the connection to restrict the accepted certificates for  
>> clients using eap-tls, clients can no longer connect using  
>> eap-mschapv2:
>>
>> 2022-08-05T15:08:29.910-04:00|charon||10[IKE] <hc_gw_eap|1>  
>> authentication of 'test' with EAP successful
>> 2022-08-05T15:08:29.912-04:00|charon||10[CFG] <hc_gw_eap|1>  
>> constraint check failed: peer not authenticated by CA '[...]'
>>
>> With the cacerts parameter removed, the connection works.
>>
>> Is this intended behavior? On first glance, it would make sense to  
>> me to be able to use the cacerts (or certs) constraint to restrict  
>> eap-dynamic->eap-tls clients to that one CA in the presence of  
>> multiple connections on the same device that may use a different CA  
>> or certificates.
>>
>> Kind regards,
>> Andreas
>>
>
> -- 
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> strongSwan - the Open Source VPN Solution!          www.strongswan.org
> strongSec GmbH, 8952 Schlieren (Switzerland)
> ======================================================================