Red Hat Bugzilla – Bug 524191
openswan doesn't support HMAC-SHA1-96
Last modified: 2014-03-26 21:01:12 EDT
Description of problem: From this link(http://www.openswan.org/docs/feature_comparison.php), we can see openswan 2.2* support HMAC-SHA1-96, but current openswan doesn't Version-Release number of selected component (if applicable): OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga) openswan: openswan-2.6.21-5.el5 and openswan-2.6.23 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
have reported a same bug on bugs.openswan.org, the link: https://gsoc.xelerance.com/issues/1064
Hi, Avesh It's not a request from customer, just because we want to go through the IPv6 certification of IKEV2. As you known, we must use the test suite((http://cert.v6pc.jp/ikev2/) from TAHI to get the certification, it means we use the test suite from TAHI on the tester node, and openswan on the testee node, which is a RHEL5.4. now caused by openswan doesn't support the message digest algorithm the test suite from TAHI uses, which is HMAC-SHA1-96, so the testing can't be processed, and we can't get the certification of IKEV2 for RHEL5.4 thanks.
Hi, Avesh. I have setup two virtual machines, both are RHEL5.4, and updated the openswan to latest version (openswan-2.6.21-6.el5). with the configuration listed as follows, and I have two questions. ======================================== config setup crlcheckinterval="180" strictcrlpolicy=no protostack=netkey plutodebug=all nat_traversal=yes conn %default ikelifetime="60m" keylife="20m" rekeymargin="3m" keyingtries=1 ike=3des-sha1-modp1024 esp=3des-sha1 authby=secret ikev2=yes rekey=yes conn host-host connaddrfamily=ipv6 left=3ffe:501:ffff:100:216:3eff:fe76:b919 right=3ffe:501:ffff:100:216:3eff:fe4f:60a leftid=3ffe:501:ffff:100:216:3eff:fe76:b919 rightid=3ffe:501:ffff:100:216:3eff:fe4f:60a type=transport compress=no auto=add ======================================== [QUESTION 1]: I got these messages when start the connection "host-host": [root@dhcp-66-70-173 Desktop]# ipsec auto --up host-host 133 "host-host" #1: STATE_PARENT_I1: initiate 133 "host-host" #1: STATE_PARENT_I1: sent v2I1, expected v2R1 134 "host-host" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=oakley_sha group=modp1024} 004 "host-host" #2: STATE_PARENT_I3: PARENT SA established transport mode {ESP=>0x169b183d <0x8662c352 xfrm=3DES_192-HMAC_SHA1 NATOA=none NATD=none DPD=none} that means "ike=3des-sha1-modp1024" in ipsec.conf is parsed into " {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=oakley_sha group=modp1024}", right? moreover, it means "sha1" is translated into "sha1_96". and in the next line of ipsec.conf, "esp=3des-sha1", is parsed into "{ESP=>0x169b183d <0x8662c352 xfrm=3DES_192-HMAC_SHA1 NATOA=none NATD=none DPD=none}", we can see here the "sha1" is translated into "sha1", but not "sha1_96". so my question is if I want to use sha1 but not sha-96 instead. how could I write the value of "ike"? because as you see, in "ike=3des-sha1-modp1024", sha1 is translated into sha1-96. and it make the user very confused because just in the next line (esp="3des-sha1"), "sha1" is translated into "sha1". [QUESTION 2]. could you please take a look at the 23th page of http://www.ipv6ready.org/docs/Phase2_IKEv2_Conformance_Latest.pdf, you can see both it has requirements of the value of both "ike" and "esp". thanks very much. [QUESTION 3] how could we config the ipsec.conf to be consistent with the message digest algrithom the TAHI test suite use, just as "ike=3des-sha1-modp1024" and "esp=3des-sha1"? because I didn't see update of the documents of openswan to tell the user how to config the ipsec.conf to support sha1-96. And actullay, I use the same config to test using TAHI test suite, the cases didn't pass.
Hi, Avesh Thanks for your explaination, clear about those questions now. but I have another question, :) I have downgrade openswan to (openswan-2.6.21-5.el5) on one of the virtual machine, and using the same ipsec.conf. the tunnel could also be setup successfully, and it looks like works well too. on virtual machine A: [root@dhcp-66-70-173 Desktop]# rpm -qa | grep openswan openswan-2.6.21-6.el5 openswan-doc-2.6.21-6.el5 openswan-debuginfo-2.6.21-6.el5 on virtual machine B: [root@dhcp-66-70-136 ~]# rpm -qa | grep openswan openswan-2.6.21-5.el5 openswan-doc-2.6.21-5.el5 on virtual machine A: [root@dhcp-66-70-173 Desktop]# !ser service ipsec restart /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled ipsec_setup: Stopping Openswan IPsec... /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled ipsec_setup: Starting Openswan IPsec U2.6.21/K2.6.18-164.el5PAE... ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled [root@dhcp-66-70-173 Desktop]# ipsec auto --up host-host 133 "host-host" #1: STATE_PARENT_I1: initiate 133 "host-host" #1: STATE_PARENT_I1: sent v2I1, expected v2R1 134 "host-host" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=oakley_sha group=modp1024} 004 "host-host" #2: STATE_PARENT_I3: PARENT SA established transport mode {ESP=>0xbb6f8e03 <0x2fbbc90e xfrm=3DES_192-HMAC_SHA1 NATOA=none NATD=none DPD=none} on virtual machine B: [root@dhcp-66-70-136 ~]# !ser service ipsec restart /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled ipsec_setup: Stopping Openswan IPsec... /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled ipsec_setup: Starting Openswan IPsec U2.6.21/K2.6.18-164.el5PAE... ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in /proc/sys/crypto/fips_enabled [root@dhcp-66-70-136 ~]# !ipsec ipsec auto --up host-host 133 "host-host" #1: STATE_PARENT_I1: initiate 133 "host-host" #1: STATE_PARENT_I1: sent v2I1, expected v2R1 134 "host-host" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1 prf=oakley_sha group=modp1024} 004 "host-host" #2: STATE_PARENT_I3: PARENT SA established transport mode {ESP=>0x73cfaee7 <0xa4a14abb xfrm=3DES_192-HMAC_SHA1 NATOA=none NATD=none DPD=none} on virtual machine A: [root@dhcp-66-70-173 Desktop]# !ping6 ping6 3ffe:501:ffff:100:216:3eff:fe4f:60a PING 3ffe:501:ffff:100:216:3eff:fe4f:60a(3ffe:501:ffff:100:216:3eff:fe4f:60a) 56 data bytes 64 bytes from 3ffe:501:ffff:100:216:3eff:fe4f:60a: icmp_seq=0 ttl=64 time=0.558 ms 64 bytes from 3ffe:501:ffff:100:216:3eff:fe4f:60a: icmp_seq=1 ttl=64 time=0.688 ms on virtual machine B: [root@dhcp-66-70-173 ~]# tcpdump -i eth0 ip6 -vv tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 10:49:22.733185 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ESP(spi=0xa4a14abb,seq=0x7), length 140 10:49:22.737937 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ICMP6, echo request, length 64, seq 0 10:49:22.737974 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe4f:60a > 3ffe:501:ffff:100:216:3eff:fe76:b919: ESP(spi=0x73cfaee7,seq=0x7), length 140 10:49:23.930796 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ESP(spi=0xa4a14abb,seq=0x8), length 140 10:49:23.930796 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ICMP6, echo request, length 64, seq 1 10:49:23.930898 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe4f:60a > 3ffe:501:ffff:100:216:3eff:fe76:b919: ESP(spi=0x73cfaee7,seq=0x8), length 140 10:49:25.082251 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ESP(spi=0xa4a14abb,seq=0x9), length 140 10:49:25.082251 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ICMP6, echo request, length 64, seq 2 10:49:25.082379 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe4f:60a > 3ffe:501:ffff:100:216:3eff:fe76:b919: ESP(spi=0x73cfaee7,seq=0x9), length 140 10:49:26.306730 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ESP(spi=0xa4a14abb,seq=0xa), length 140 10:49:26.306730 IP6 (hlim 64, next-header: ICMPv6 (58), length: 64) 3ffe:501:ffff:100:216:3eff:fe76:b919 > 3ffe:501:ffff:100:216:3eff:fe4f:60a: ICMP6, echo request, length 64, seq 3 10:49:26.306835 IP6 (hlim 255, next-header: ESP (50), length: 140) 3ffe:501:ffff:100:216:3eff:fe4f:60a > 3ffe:501:ffff:100:216:3eff:fe76:b919: ESP(spi=0x73cfaee7,seq=0xa), length 140 As you can see, A and B use the diffrent integ algorithom, A use sha1_96, B use sha1, but the tunnel was setup successfully, and works well.
Hi, Avesh. thanks for your suggestion, I'm always in #eng-china, and the time zone is "Asia -> China -> Chongqing", and available from 9am to 7pm in the week days. Jiabo Wang will help to test the TAHI, because I'm busy in other work. but may be I can help to provide some information you need. thanks.
comment #18 we did the test, but still have failed, we can not get SPD and SAD, I think the problem from Remote files. we will focus on remote files writing. thanks Avesh and Jyang.
Hi, Avesh. the attachments are the log of pluto and TAHI, you can take reference if have time, because I'm not very farmiliar with the IKEV2, so may be you can detect what exactly the problem is. thanks.
Created attachment 365670 [details] the log generated by TAHI test suite
Created attachment 365671 [details] the log generated by testee machine(RHEL5.4 with the latest openswan)
Hi, Avesh the TAHI using perl script to constuct the packet. there is no configuration file on TAHI side. this is the ipsec.conf on openswan side, actually it's generated by remote files which are perl scripts called by TAHI test suite. config setup crlcheckinterval="180" strictcrlpolicy=no protostack=netkey interfaces=%defaultroute plutostderrlog=/var/log/pluto.log conn %default ikelifetime="60m" keylife="20m" rekeymargin="3m" keyingtries=1 phase2=esp ike=3des-sha1-modp1024 phase2alg=3des-sha1 authby=secret ikev2=yes rekey=yes keyexchange=ike conn host-host connaddrfamily=ipv6 left=2001:0db8:0001:0001::1234 right=2001:0db8:000f:0001::1 leftid=2001:0db8:0001:0001::1234 rightid=2001:0db8:000f:0001::1 type=transport compress=no auto=start
Hi Avesh. seems klips is obselete? remeber that I saw in some document. Osier Thanks and Regards
Hi, Avesh please wait a little while. the case is running.
Created attachment 365710 [details] the output on openswan side of ipsec barf
Hi Avesh have uploaded the output of "ispec barf", unlucky the machine I logined IRC is down. Thanks Osier
Created attachment 365720 [details] the newer barf out
Created attachment 365722 [details] newer pluto.log
Created attachment 365727 [details] tahi document to show the algrithom
Hi, Avesh. the error msg "bind: Address already in use" may be caused by the connection wasn't closed correctly. % netstat -ant .................... .................... .................... .................... Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr c6c35000 stream 0 0 0 c6c352d0 0 0 c6c352d0 stream 0 0 0 c6c35000 0 0 c6c356c0 stream 0 0 c6c2e880 0 0 0 /var/run/devd.pipe c6c35480 dgram 0 0 0 c6c35120 0 c6c35090 c6c35240 dgram 0 0 0 c6c351b0 0 0 c6c35090 dgram 0 0 0 c6c35120 0 0 c6c35120 dgram 0 0 c6c24220 0 c6c35480 0 /var/run/logpriv c6c351b0 dgram 0 0 c6e30110 0 c6c35240 0 /var/run/log
Hi Avesh "sendMessagesSync: never got /sbin/setkey -D" "sendMessagesSync: never got /sbin/setkey -FP" "sendMessagesSync: never got /bin/ps -ax | /bin/grep -e pluto" the messages like so is caused by TAHI always checks echo back from the remote system with the serial line, and it seems the echo back is disabled on NUT. I asked Jiabo Wang before, he said that this will influnce the test result. because the dhcp and other protocal test suite also print that messages. whatever, I didn't find a way to enable the echo back of the serial line. Could Jiabo Wang please help us setup an enthenet connection instead of serial line to see what will happen? thanks Osier Thanks and Regards
Created attachment 366534 [details] tcpdump info please look the attachment from 373 line. NUT(RHEL5.4) is 1:db8:1:1::1234, TN(Freebsd) is 1:db8:1:1::f. 1:db8:1:1::1(I'm no sure the ip from where) can ping 1:db8:1:1::1234(NUT). NUT can send IKE_SA_INIT, but 1:db8:1:1::1 report port unreachable. another thing: TN can send NS to NUT, and NUT can send NA to TN so the problem maybe from configuration. I will check with Jyang
Hi Jiabo, Avesh that's caused by avesh modified /usr/ipv6_test/IKEv2_Self_Test_1-0-3/config.pl, avesh, is it right? ======diff of the original config.pl and modified config.pl========= testcore# diff config.pl /usr/ipv6_test/IKEv2_Self_Test_1-0-3/config.pl 55c55 < $ikev2_prefixA = '2001:0db8:0001:0001'; --- > $ikev2_prefixA = '1:0db8:0001:0001'; 62c62 < $ikev2_prefixB = '2001:0db8:0001:0002'; --- > $ikev2_prefixB = '1:0db8:0001:0002'; 71c71 < $ikev2_prefixX = '2001:0db8:000f:0001'; --- > $ikev2_prefixX = '1:0db8:000f:0001'; 78c78 < $ikev2_prefixY = '2001:0db8:000f:0002'; --- > $ikev2_prefixY = '1:0db8:000f:0002';
Hi, Avesh It's so great. have seen you sent a patch to TAHI, hope they can give the feedback quickly, thanks very much. :) Thanks and Regards Osier
Hi Avesh As you known, our work is blocked by some problem of TAHI test suite currently. What we can do is just waiting for their response. And now we will say your patch works well, just because with other test methods like openswan-to-openswan, it's okay. Hope this won't block your work process anymore. Thanks and Regards Osier
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0211.html