Re: [strongSwan] strongswan and FIPS
Thank you Kaleb for the response. We plan to use rhel 8 or canonical's ubuntu that are fips certified and comes with a compliant openssl library. Will reach out to wolfssl if that does not work out. -sk > Date: Mon, 19 Apr 2021 10:53:44 -0600 > From: kaleb himes > To: users@lists.strongswan.org > Subject: Re: [strongSwan] strongswan and FIPS > Message-ID: <0f55242d-a4cf-4e78-8fda-af232e4af...@wolfssl.com> > Content-Type: text/plain; charset="utf-8" > > In response to sk post regarding FIPS and strongswan, Please find > responses inline below: > > >> > >> Hello, > >> > >> I had a few questions about strongswan and FIPs mode. Some of the > earlier discussions and threads on the subject have been great help, but I > need help with some clarifications. Your help would be greatly appreciated. > >> > >> 1. We use version 5.1.3 of strongswan with a few patches from later. > Would there be any advantages (related to FIPs compliance) by moving to a > more recent version? I understand moving to higher versions is better for > general sense, but for FIPs - would it matter? > > Upgrading to wolfCrypt FIPS certificate 3389 is another option. See this > blog post for more info: https://www.wolfssl.com/strongswan-wolfssl-fips/ > > >> 2. I was able to get our version to compile with FIPS mode 2, and was > able to replace the ALG usage in ike (as seen in ipsec listalgs) to use > openssl plugin. This plugin would use the underlying openssl library on the > system and that openssl library is fips compatible and has the fips object > module for openssl installed. Would that be sufficient to say we are > running strongswan in fips mode? The strongswan libraries that implement > crypto and hmac are not compiled and packaged. We want to get everything > from openssl. > > Your FIPS lab should make the decision on this question, this is not > something the mailing list could likely address. Oh, by the way, just be > aware OpenSSL FIPS certificates are both expired (links provided below) and > according to OpenSSL’s FIPS page (https://www.openssl.org/docs/fips.html < > https://www.openssl.org/docs/fips.html>) OpenSSL is no longer planning on > doing FIPS so you’ll need to validate OpenSSL on your own or use an > alternate crypto library that has an up-to-date certificate! > > > https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/1747 > < > https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/1747> > - Historical List > > https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2398 > < > https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2398> > - Historical List > > > >> > >> 3. Are there any other crypto implementations in strongswan that cannot > be turned off by autoconf compile flags? > >> > >> 4. Even when compiled in FIPS mode, I noticed that MD4, MD5, modp768 > and such are listed in ipsec stroke listalgs. To disable them, I had to > pass in the appropriate OPENSSL #ifdef compile flags via CFLAGS during > compilation. Is there a better way to do this, if I want to turn off the > non-fips compliant weaker algs? > > Your FIPS lab will probably ask you to prove through profiling that these > algos are not being called during operational testing and code-review phase > of a FIPS validation effort. > > >> > >> 5. Is there a difference between IKEv1 and IKEv2 compliance when it > comes to FIPS? Canonical's FIPs document for strongswan at NIST only > mentions IKEv2. I read that FIPS needs 128 bit keys and such, and since > IKEv1 can support 8 bytes (64 bits) nonces, would IKEv1 be considered > incompatible? Since strongswan uses 32 byte nonces, would that be > considered compliant for FIPS? > > FIPS is clear about banned algos. They are banned for good reasons. > > >> > >> Thank you for reading this. Any help with the answers would be greatly > appreciated. > >> > >> regards, > >> sk > > If you have any other questions wolfSSL employs a few FIPS experts and > would be happy to address any questions if you email "fips [at] wolfssl > [dot] com”. > > Warmest Regards, > > Kaleb Himes > Software Engineer > www.wolfssl.com > > If you appreciate your experience with wolfSSL > please leave us a star at https://github.com/wolfSSL/wolfssl! > > TLS1.3 IS AVAILABLE in wolfSSL! > > > > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://lists.strongswan.org/pipermail/users/attachments/20210419/f0bd7320/attachment-0001.html > > > > End of Users Digest, Vol 135, Issue 9 > * >
[strongSwan] strongswan and FIPS
Hello, I had a few questions about strongswan and FIPs mode. Some of the earlier discussions and threads on the subject have been great help, but I need help with some clarifications. Your help would be greatly appreciated. 1. We use version 5.1.3 of strongswan with a few patches from later. Would there be any advantages (related to FIPs compliance) by moving to a more recent version? I understand moving to higher versions is better for general sense, but for FIPs - would it matter? 2. I was able to get our version to compile with FIPS mode 2, and was able to replace the ALG usage in ike (as seen in ipsec listalgs) to use openssl plugin. This plugin would use the underlying openssl library on the system and that openssl library is fips compatible and has the fips object module for openssl installed. Would that be sufficient to say we are running strongswan in fips mode? The strongswan libraries that implement crypto and hmac are not compiled and packaged. We want to get everything from openssl. 3. Are there any other crypto implementations in strongswan that cannot be turned off by autoconf compile flags? 4. Even when compiled in FIPS mode, I noticed that MD4, MD5, modp768 and such are listed in ipsec stroke listalgs. To disable them, I had to pass in the appropriate OPENSSL #ifdef compile flags via CFLAGS during compilation. Is there a better way to do this, if I want to turn off the non-fips compliant weaker algs? 5. Is there a difference between IKEv1 and IKEv2 compliance when it comes to FIPS? Canonical's FIPs document for strongswan at NIST only mentions IKEv2. I read that FIPS needs 128 bit keys and such, and since IKEv1 can support 8 bytes (64 bits) nonces, would IKEv1 be considered incompatible? Since strongswan uses 32 byte nonces, would that be considered compliant for FIPS? Thank you for reading this. Any help with the answers would be greatly appreciated. regards, sk
Re: [strongSwan] enforcement of rightca2 for eap-tls connections
Hi Tobias, Thank you for your reply. Rightca does not work either. If I use rightca, the authentication seems to fail always, even though the certificate hierarchy is correct. Rightca works when I dont use eap-tls. The constraint is correctly enforced. -sk On Wed, Feb 6, 2019 at 5:10 AM Tobias Brunner wrote: > Hi, > > > Is > > righhtca2 supposed to work with eap-tls and eap-identity connections? > > rightca2 is for a second authentication round. Which is not what > happens with EAP-TLS (unless you actually use it in a second round after > e.g. a regular pubkey authentication). So maybe try rightca instead. > > Regards, > Tobias >
[strongSwan] using strongswan to create eap-tls connection like windows 10
Hi, I am trying to create a test setup that will simulate a windows 10 client connecting using eap-identity and certs. I am hitting an error that I cannot figure out after running down the usual suspects. The same certs used on a windows client works. I have copied my config below, and also the error seen. I am hoping someone can point me in the right direction. Responder config: conn eapvpn leftauth=pubkey keyexchange=ikev2 eap_identity=%any left=a.b.c.d leftsubnet=0.0.0.0/0 leftcert=servercrt.pem leftsendcert=always right=%any rightsourceip= rightauth=eap-tls rightsendcert=never auto=add Initiator config: conn eap-rw leftauth=eap-tls rightauth=pubkey keyexchange=ikev2 rightid=%any leftcert=clientcrt.pem right=a.b.c.d leftsourceip=%config leftfirewall=yes rightsubnet=0.0.0.0/0[icmp] eap_identity="test-client" auto=add The error I see on the responder is *signature verification failed, trying another key* *no trusted certificate found for 'test-client' to verify TLS peer* I have checked the following: 1. ca cert present on both sides in the cacert directory. They show up in "ipsec stroke listcacerts" output on both sides. 2. client cert has proper key. The output of "ipsec stroke listcerts" shows that the client crt has a private key. The private key is listed in the ipsec.secrets file. 3. The eap-identity appears in the DNS of the client cert. I am using strongswan-5.1.2 . I must have messed up some config, but I can't figure out what. I checked the certs and keys. What am I missing? thanx in advance, sk
[strongSwan] peer config match
Hi, I had a question about how peer configs are matched by Strongswan. I have two connection definitions in my ipsec.conf, one for road-warriors and one for site2site. They are roughly defined as shown at the end of thie email. As can be seen the rw only accept ikev1, but any right-id. The site2site accept any ike version, but specific right-id that matches the peer's cert DN. What I see is that the perfect match of ike version is given preference over the perfect match of ID when choosing connection. When a site connects with IKEv1, and the proper cert, the "conn rw" is chosen, even though "conn site2site" has a perfect match of the ID, and also matches the ike version (since that connection definition can accept IKEv1/IKEv2). Shouldn't the site2site connection definition be chosen because it has the perfect match of the ID and accepts the ike version? We are using strongswan version 5.1.2 (+selective patches) conn *rw* authby=rsasig *keyexchange=ikev1* rightid=%any conn *site2site* authby=rsasig *keyexchange=ike* rightid="DN from the peer's cert" The log lines for the match show candidate "site2site", match: 1/20/1048 (me/other/ike) candidate "rw", match: 1/1/1052 (me/other/ike) .Candidate "rw" has higher ike match (1052) resulting in "rw" being chosen. -sk
[strongSwan] ksoftirq thread reaching 100%
Hi, In our setup we see a problem with ksoftirq thread reaching 100% on CPU 0. The box is running strongswan 4.6 version and acts as the responder to IPSEC connections from other firewalls. The number of sites connecting to this box is around 140. The cipher suite chosen is AES-128. The firewalls connect using ikev1. This does not happen always, but when this happens, all ipsec connections slow down. We have seen often enough for us to be concerned. I have checked to see that irqbalance is running. I have seen this on boxes with aes-ni enabled and also disabled. The box has a gig ethernet card (a Broadcom NetExtreme II), and is handling maybe around half its capacity. Has anyone else seen this problem with the ksoftirq thread reaching 100%? Is there anything that can be done to alleviate this problem? thanx skmat. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] cookies check in DPD packets
Hi, Has strongswan 5.x removed the check for invalid cookies in DPD requests. I see that only the sequence number check is done. In 4.6.x, this check was done (and logged as a Broken Cisco in ipsec_doi.c). I have a scenario where I have a setup with strongswan 4.6.x and run into this condition. Is it safe to remove this check (compiling strongswan with APPLY_CRISCO). I cannot upgrade strongswan to 5.x yet. regards, matt. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
