Bug 439771 - [IPv6-DoD] openswan and strongswan fail to interoperate with IKEv2
[IPv6-DoD] openswan and strongswan fail to interoperate with IKEv2
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openswan (Show other bugs)
5.2
All All
urgent Severity high
: rc
: ---
Assigned To: Avesh Agarwal
Martin Jenner
: OtherQA, ZStream
Depends On:
Blocks: 253764 450125
  Show dependency treegraph
 
Reported: 2008-03-31 07:17 EDT by IBM Bug Proxy
Modified: 2009-09-03 10:11 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:18:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Openswan responder logs (44.11 KB, text/plain)
2008-03-31 07:17 EDT, IBM Bug Proxy
no flags Details
Openswan initiator Security Association Database (1.05 KB, text/plain)
2008-03-31 07:17 EDT, IBM Bug Proxy
no flags Details
Strongswan initiator logs (2.76 KB, text/plain)
2008-03-31 07:17 EDT, IBM Bug Proxy
no flags Details
Openswan initiator logs (106.29 KB, text/plain)
2008-03-31 07:18 EDT, IBM Bug Proxy
no flags Details
Strongswan responder Security Association Database (1.04 KB, text/plain)
2008-03-31 07:18 EDT, IBM Bug Proxy
no flags Details
Strongswan responder logs (3.50 KB, text/plain)
2008-03-31 07:18 EDT, IBM Bug Proxy
no flags Details
Fix child SA key generation (1.31 KB, patch)
2008-04-04 12:30 EDT, Herbert Xu
no flags Details | Diff
pcap of openswan not honoring racoon2's INVALID_KE_PAYLOAD (5.26 KB, application/octet-stream)
2008-04-22 19:33 EDT, IBM Bug Proxy
no flags Details
Add AES key length to SADB. (7.97 KB, patch)
2008-04-27 03:27 EDT, Herbert Xu
no flags Details | Diff
Transmit IKEv2 key length attribute (5.31 KB, patch)
2008-04-27 03:28 EDT, Herbert Xu
no flags Details | Diff
Receive IKEv2 key length attribute (8.14 KB, patch)
2008-04-27 03:29 EDT, Herbert Xu
no flags Details | Diff
Transmit IKEv2 key length attribute (5.86 KB, patch)
2008-04-28 07:57 EDT, Herbert Xu
no flags Details | Diff
Receive IKEv2 key length attribute (8.12 KB, patch)
2008-04-28 07:57 EDT, Herbert Xu
no flags Details | Diff
Handle fixed-length keys correctly. (1.07 KB, patch)
2008-05-03 04:57 EDT, Herbert Xu
no flags Details | Diff
Openswan (initiator) logs (65.56 KB, text/plain)
2008-05-16 16:25 EDT, IBM Bug Proxy
no flags Details
Strongswan (responder) logs (105.33 KB, text/plain)
2008-05-16 16:25 EDT, IBM Bug Proxy
no flags Details
Use the correct algorithm for ID hashing (3.90 KB, patch)
2008-05-19 09:22 EDT, Herbert Xu
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 43611 None None None Never

  None (edit)
Description IBM Bug Proxy 2008-03-31 07:17:53 EDT
=Comment: #0=================================================
TYLER C. HICKS <tchicks@us.ibm.com> - 2008-03-28 18:47 EDT
---Problem Description---
openswan and strongswan fail to negotiate a valid Security Association when
using IKEv2.
 
Contact Information = Tyler Hicks <tyhicks@linux.vnet.ibm.com>
 
---uname output---
Linux eal5.ltc.austin.ibm.com 2.6.18-86.el5 #1 SMP Tue Mar 18 18:19:47 EDT 2008
i686 i686 i386 GNU/Linux
Linux elm3a68.beaverton.ibm.com 2.6.18-86.el5PAE #1 SMP Tue Mar 18 18:34:45 EDT
2008 i686 i686 i386 GNU/Linux
 
--Machine Types---
eal5: 335 Xseries
elm3a68: 345 Xseries
 
--IP Addresses---
eal5.ltc.austin.ibm.com has address 9.3.190.198
elm3a68.beaverton.ibm.com has address 9.47.66.68

 
---Steps to Reproduce---
openswan /etc/ipsec.conf
-----------------------------------------------------------------
# /etc/ipsec.conf - Openswan IPsec configuration file
#
# Manual:     ipsec.conf.5
#
# Please place your own config files in /etc/ipsec.d/ ending in .conf

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        # klipsdebug=none
        plutodebug="all"
        # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
        protostack=netkey
        nat_traversal=yes

conn openswan-strongswan
        left=9.3.190.198
        right=9.47.66.68
        ikev2=insist
        authby=secret
        auto=add
-----------------------------------------------------------------

strongswan /etc/ipsec.conf
-----------------------------------------------------------------
# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
        # plutodebug=all
        charondebug=dmn4,mgr4,ike4,chd4,job4,cfg4,knl4,net4,enc4,lib4
        # crlcheckinterval=600
        # strictcrlpolicy=yes
        # cachecrls=yes
        # nat_traversal=yes
        # charonstart=no
        plutostart=no

# Add connections here.

conn openswan-strongswan
        left=9.3.190.198
        right=9.47.66.68
        keyexchange=ikev2
        authby=secret
        auto=add
-----------------------------------------------------------------

global /etc/ipsec.secrets
-----------------------------------------------------------------
9.3.190.198 9.47.66.68 : PSK "psk"
-----------------------------------------------------------------

When using openswan as the initiator
-----------------------------------------------------------------
[root@eal5 ~]# ipsec auto --verbose --up openswan-strongswan
002 "openswan-strongswan" #1: initiating v2 parent SA
133 "openswan-strongswan" #1: STATE_PARENT_I1: initiate
002 "openswan-strongswan" #1: transition from state STATE_IKEv2_START to state
STATE_PARENT_I1
133 "openswan-strongswan" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
002 "openswan-strongswan" #2: transition from state STATE_PARENT_I1 to state
STATE_PARENT_I2
134 "openswan-strongswan" #2: STATE_PARENT_I2: sent v2I2, expected v2R2
{auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1 prf=oakley_sha group=modp1536}
002 "openswan-strongswan" #2: transition from state STATE_PARENT_I2 to state
STATE_PARENT_I3
002 "openswan-strongswan" #2: negotiated tunnel [9.3.190.198,9.3.190.198] ->
[9.47.66.68,9.47.66.68]
004 "openswan-strongswan" #2: STATE_PARENT_I3: PARENT SA established tunnel mode
{ESP=>0xcd833241 <0xe746ed33 xfrm=3DES_192-HMAC_SHA1 NATOA=none NATD=none DPD=none}
[root@eal5 ~]# ping -nc 10 9.47.66.68
PING 9.47.66.68 (9.47.66.68) 56(84) bytes of data.

--- 9.47.66.68 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 8998ms
-----------------------------------------------------------------

When using strongswan as the initiator:
-----------------------------------------------------------------
[root@elm3a68 ~]# ipsec up openswan-strongswan
initiating IKE_SA 'openswan-strongswan' to 9.3.190.198
IKE_SA 'openswan-strongswan' state change: CREATED => CONNECTING
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_D_IP) N(NATD_S_IP) ]
sending packet: from 9.47.66.68[500] to 9.3.190.198[500]
retransmit 1 of request with message ID 0
sending packet: from 9.47.66.68[500] to 9.3.190.198[500]
received packet: from 9.3.190.198[500] to 9.47.66.68[500]
parsed IKE_SA_INIT response 0 [ SA KE No V ]
peers proposal selection invalid
-----------------------------------------------------------------
 
---Security Component Data---
Userspace tool common name: openswan

The userspace tool has the following bit modes: 32

Userspace rpm: openswan-2.6.09-1.el5

---Notes---
Snapshot 2 was used on both machines.  I compiled the latest stable strongswan
realease (4.1.11) from source.  The only flag passed to configure was
--sysconfdir=/etc

When openswan acts as the initiator, SA's are negotiated, but different keys are
generated on each end of the SA.  When strongswan acts as the initiator, SA's
are not negotiated because strongswan complains that openswan's proposal
selection was invalid.

After worrying that I may have missed an important flag when compiling
strongswan, I installed Ubuntu Gutsy (7.10) to another Xseries machine and used
apt-get to install strongswan-4.1.4-1ubuntu1.  This setup had the same problems
as the source install on snapshot 2.  As expected, the two strongswan setups
were able to negotiate valid SA's.
Comment 1 IBM Bug Proxy 2008-03-31 07:17:56 EDT
Created attachment 299701 [details]
Openswan responder logs
Comment 2 IBM Bug Proxy 2008-03-31 07:17:58 EDT
Created attachment 299702 [details]
Openswan initiator Security Association Database
Comment 3 IBM Bug Proxy 2008-03-31 07:17:59 EDT
Created attachment 299703 [details]
Strongswan initiator logs
Comment 4 IBM Bug Proxy 2008-03-31 07:18:01 EDT
Created attachment 299704 [details]
Openswan initiator logs
Comment 5 IBM Bug Proxy 2008-03-31 07:18:03 EDT
Created attachment 299705 [details]
Strongswan responder Security Association Database
Comment 6 IBM Bug Proxy 2008-03-31 07:18:05 EDT
Created attachment 299706 [details]
Strongswan responder logs
Comment 7 Herbert Xu 2008-04-03 10:52:59 EDT
Is strongswan able to negotiate with racoon2 using this configuration?
Comment 8 IBM Bug Proxy 2008-04-03 11:57:41 EDT
------- Comment From tchicks@us.ibm.com 2008-04-03 11:51 EDT-------
I've never tested with racoon2.  I've actually never used it either, I will look
into this.
Comment 9 Paul Wouters 2008-04-03 12:37:18 EDT
Same yourself a LOT of trouble (that we went through) in configuring racoon2,
and look at openswan-2.6.x/testing/pluto/interop-ikev2-racoon2-* for valid
configurations

Comment 10 Herbert Xu 2008-04-04 12:28:56 EDT
For the case where Openswan is the initiator, I've determined that Openswan is
at fault for generating bogus keys.  First of all, it's starting the prf+
counter from 0 instead of 1, then it's not cloning the st_ni/st_nr values from
the parent SA so the seed for the prf+ is null, finally the SA key order is the
wrong way around.
Comment 11 Herbert Xu 2008-04-04 12:30:30 EDT
Created attachment 300892 [details]
Fix child SA key generation
Comment 12 IBM Bug Proxy 2008-04-07 20:33:05 EDT
------- Comment From tchicks@us.ibm.com 2008-04-07 20:30 EDT-------
Hi Herbert - I have gotten strongswan to act as the initiator and successfully
negotiate with racoon2 using the same config that I posted earlier.

I also was able to get openswan to act as the initiator and negotiate with
racoon2.  The only change I had to make to the previous openswan config was to
add a "ike=ENCR-HASH-PRF" line to ipsec.conf.

While performing these tests, I have discovered a bug with openswan initiating
with racoon2, but I am not sure that it is related to this bug.  Upon receiving
v2R1, Pluto has a hard crash whenever there is no "ike=ENCR-HASH-PRF" line in
the ipsec.conf.  I don't see any obvious errors in the logs, either.  I will
create a new bug for this.
Comment 13 Paul Wouters 2008-04-07 22:03:23 EDT
Please try that last situation against openswan 2.6.10
Comment 14 Paul Wouters 2008-04-08 00:54:50 EDT
Herbert: Thanks for the patch.

I applied the first and the last bit. When I set ike=3des and esp=3des on
strongswan, the interop now works.

The middle bit of your patch seems wrong to me:

- if(role == INITIATOR) {
+ if(role != INITIATOR) {
[...]
        st->st_esp.our_keymat = ikeymat.ptr;
        st->st_esp.peer_keymat= rkeymat.ptr;

Your patch would mean that if we are NOT initiator, we would set
st->st_esp.our_keymat to ikeymat.ptr instead of rkeymat.ptr.

I think what remains of the interop issue now, is Openswan not recognising
"aes-XXX" and strongswan not sending "aes".
Comment 15 Paul Wouters 2008-04-08 00:57:54 EDT
(In reply to comment #13)
> Please try that last situation against openswan 2.6.10

That should be 2.6.11, which should make it to the ftp servers in a few hours
Comment 16 Herbert Xu 2008-04-08 01:33:39 EDT
> I applied the first and the last bit. When I set ike=3des and esp=3des on
> strongswan, the interop now works.

Did you pass any data through it?

> The middle bit of your patch seems wrong to me:
>
> - if(role == INITIATOR) {
> + if(role != INITIATOR) {
> [...]
>         st->st_esp.our_keymat = ikeymat.ptr;
>         st->st_esp.peer_keymat= rkeymat.ptr;
>
> Your patch would mean that if we are NOT initiator, we would set
> st->st_esp.our_keymat to ikeymat.ptr instead of rkeymat.ptr.

Well I'm travelling right now so I can't do a detailed examination
but the reason I made the change is that without it the keys were
the wrong way around and when I compared the RFC to the code I found
that the if statement was the wrong way around too.  Of course I
might have been wrong.

If you can pass data through it then it should be fine.  Otherwise
you may still need this.
Comment 17 Paul Wouters 2008-04-08 02:52:36 EDT
Yes I do, see:
openswan-2.6.11/testing/interop-ikev2-strongswan-03-psk-initiator/east-console.txt

westinit sets a firewall rule for plaintext traffic to be blocked.
east-console.txt shows a ping reply after the tunnel is up.
Comment 18 Paul Wouters 2008-04-08 03:16:33 EDT
interop-ikev2-strongswan-02-psk-responder shows the packet is lost through....

On the -03 test case I also see on the strongswan side:

 received netlink error: File exists (17)
 unable to install source route for 192.0.2.254

Comment 19 Paul Wouters 2008-04-08 03:36:18 EDT
Re: #17 - I am not sure if I trust that the ping packet actually initiated the
connection. tcpdump does not seem to work with our netkey based kernel required
for this interop test.

Re:#16 - I've tested the 4 PSK interop cases, and I see no difference before and
after I apply the middle bit of your patch, so I have not applied it. It will
take some more testing to find the real issue and the real fix.
Comment 20 Paul Wouters 2008-04-08 03:37:27 EDT
Also, ip xfrm state shows nothing for these test cases, so I don't think we
actually got a tunnel setup. Probably has to do with the netlink error
strongswan gives?
Comment 21 Herbert Xu 2008-04-08 09:04:24 EDT
Paul, you need to pass data with a peer other than Openswan to prove that
Openswan is correct.  When I tested with strongswan (its stable version) with
Openswan as the initiator, I was able to get the SAs established as was visible
through ip xfrm state.  However, the key ordering was the wrong way around on
Openswan's side without the middle bit.

So if you can pass data say with racoon then it should be fine.  Otherwise I
still think this patch is needed.
Comment 22 Paul Wouters 2008-04-08 10:43:44 EDT
(In reply to comment #21)
> Paul, you need to pass data with a peer other than Openswan to prove that
> Openswan is correct.

I understand. Hence our 5 interop tests for racoon and 5 interop tests for
strongswan.

>  When I tested with strongswan (its stable version) with Openswan as the 
> initiator, I was able to get the SAs established as was visible
> through ip xfrm state.  However, the key ordering was the wrong way around on
> Openswan's side without the middle bit.

I was not able to reproduce that, as can be seen with the output of the interop
testcases in testing/pluto/interop-*

> So if you can pass data say with racoon then it should be fine.  Otherwise I
> still think this patch is needed.

It did not pass data in either way. I will do more testing today to see if I can
determine the full issue.
Comment 23 Paul Wouters 2008-04-08 23:45:10 EDT
It also clearly breaks the key material for klips. Our tests are using klips,
not netkey, and also use firewall rules to determine test results that won't
work using netkey.

I did reproduce data flowing with your INITIATOR modification, but I do think
you fixed it at the wrong spot. (which may be fine for now for Red Hat, as they
do not use klips.

I'm still looking into this bug and where to address the issue properly
Comment 24 Paul Wouters 2008-04-21 20:39:43 EDT
We applied Herbert'x workaround for 2.6.12.....
Comment 27 IBM Bug Proxy 2008-04-22 16:49:30 EDT
------- Comment From tchicks@us.ibm.com 2008-04-22 16:41 EDT-------
openswan-2.6.12 fixes interop problems when openswan is the initiator.  However,
the negotiation still fails when strongswan is the initiator.  It looks to me
that openswan is violating the "Attribute Negotiation" section of RFC 4306:

------
3.3.6.  Attribute Negotiation

During security association negotiation, initiators present offers to
responders.  Responders MUST select a single complete set of
parameters from the offers (or reject all offers if none are
acceptable).  If there are multiple proposals, the responder MUST
choose a single proposal number and return all of the Proposal
substructures with that Proposal number.  If there are multiple
Transforms with the same type, the responder MUST choose a single
one.  Any attributes of a selected transform MUST be returned
unmodified.  The initiator of an exchange MUST check that the
accepted offer is consistent with one of its proposals, and if not
that response MUST be rejected.
------

Strongswan's first proposal is aes128-sha1-modp2048 and openswan agrees to it.
However, strongswan attaches a key-length transform attribute to the ENCR
transform to specify aes128.  When openswan responds, it fails to include the
key-length attribute and strongswan does the correct thing and rejects the
proposal selection.

By configuring openswan to only use 3des in parent and child SA's, the
negotiation is handled correctly, since no key-length attributes are used.

Here's the tcpdump output showing the failure to include the attribute:
------
15:22:52.225909 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17
), length: 616) eal1.ltc.austin.ibm.com.isakmp > eal5.ltc.austin.ibm.com.isakmp:
[bad udp cksum 80d9!] isakmp 2.0 msgid 00000000 cookie 3a0a591d2f674290->000000
0000000000: parent_sa ikev2_init[I]:
(sa: len=216
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0080))
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp2048 ))
(p: #2 protoid=isakmp transform=19 len=172
(t: #1 type=encr id=aes (type=keylen value=0080))
(t: #2 type=encr id=aes (type=keylen value=00c0))
(t: #3 type=encr id=aes (type=keylen value=0100))
(t: #4 type=encr id=3des )
(t: #5 type=integ id=#12 )
(t: #6 type=integ id=hmac-sha )
(t: #7 type=integ id=hmac-md5 )
(t: #8 type=integ id=#13 )
(t: #9 type=integ id=#14 )
(t: #10 type=prf id=#5 )
(t: #11 type=prf id=hmac-sha )
(t: #12 type=prf id=hmac-md5 )
(t: #13 type=prf id=#6 )
(t: #14 type=prf id=#7 )
(t: #15 type=dh id=modp2048 )
(t: #16 type=dh id=modp1536 )
(t: #17 type=dh id=modp1024 )
(t: #18 type=dh id=modp4096 )
(t: #19 type=dh id=modp8192 )))
(v2ke: len=256 group=modp2048)
(nonce: len=16 nonce=(c7c3c2a54518c49f8f0f6b4cccc26e81) )
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
15:22:52.243445 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17
), length: 400) eal5.ltc.austin.ibm.com.isakmp > eal1.ltc.austin.ibm.com.isakmp:
[udp sum ok] isakmp 2.0 msgid 00000000 cookie 3a0a591d2f674290->55d1b8608c0a579
a: parent_sa ikev2_init[]:
(sa: len=40
(p: #1 protoid=isakmp transform=4 len=40
(t: #1 type=encr id=aes )
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce[C]: len=16 nonce=(391c53b548a10bbcdcf688b282e28c08) )
(v2vid: len=12 vid=OEw[[^[pTC@N)
------
Comment 28 IBM Bug Proxy 2008-04-22 19:33:23 EDT
------- Comment From tchicks@us.ibm.com 2008-04-22 19:26 EDT-------
After taking a closer look at this bug, I don't think openswan-2.6.12 was fixed
correctly when openswan is acting as the initiator, either.

The default DH group was switched to modp2048 for IKEv2, but openswan still
doesn't pay attention to the Notification Data field in an INVALID_KE_PAYLOAD
notification.

If modp2048 is removed from the possible DH groups in the racoon2 config
(leaving only modp1024), openswan cannot negotiate with racoon2.  This is
because racoon2 rejects openswan's KE_PAYLOAD (which uses modp2048 now) and
tells openswan that it wants to use modp1024.  Openswan continues to try to get
racoon2 to use modp2048.

If openswan doesn't take the INVALID_KE_PAYLOAD Notification Data into account
on it's next IKE_SA_INIT, then I guess we should be defaulting to modp1024 since
it is a MUST- and modp2048 is a MUST+.
Comment 29 IBM Bug Proxy 2008-04-22 19:33:26 EDT
Created attachment 303405 [details]
pcap of openswan not honoring racoon2&apos;s INVALID_KE_PAYLOAD

Racoon2 is trying to let openswan know that it wants to use modp1024, but
openswan ignores the request.  0x0002 can be seen in the INVALID_KE_PAYLOAD's
Notification Data field specifying modp1024.
Comment 32 Herbert Xu 2008-04-25 03:26:37 EDT
OK Openswan is definitely in the wrong here.  It is violating section 5.3 of RFC
3602 by omitting the key length attribute with both IKEv1 and IKEv2.  I'm
looking into this issue.
Comment 33 Herbert Xu 2008-04-27 03:27:35 EDT
Created attachment 303894 [details]
Add AES key length to SADB.
Comment 34 Herbert Xu 2008-04-27 03:28:10 EDT
Created attachment 303895 [details]
Transmit IKEv2 key length attribute
Comment 35 Herbert Xu 2008-04-27 03:29:03 EDT
Created attachment 303896 [details]
Receive IKEv2 key length attribute

With these three patches I'm able to interoperate with Strongswan in both
directions.
Comment 36 Herbert Xu 2008-04-28 07:57:08 EDT
Created attachment 303963 [details]
Transmit IKEv2 key length attribute

This update fixes a crash with debugging enabled.
Comment 37 Herbert Xu 2008-04-28 07:57:43 EDT
Created attachment 303964 [details]
Receive IKEv2 key length attribute

As above.
Comment 38 IBM Bug Proxy 2008-04-29 12:49:53 EDT
------- Comment From tchicks@us.ibm.com 2008-04-29 12:42 EDT-------
Hi Herbert - I'm not able to interop with strongswan if openswan is the
initiator and is using aes192.

openswan connection:
--------
conn openswan-strongswan
left=9.3.190.198
right=9.3.190.194
ike=aes192
phase2alg=aes192
ikev2=insist
authby=secret
auto=add
--------

strongswan connection:
--------
conn openswan-strongswan
left=9.3.190.198
right=9.3.190.194
keyexchange=ikev2
authby=secret
auto=add
--------

output (from openswan side):
--------
[root@eal5 ~]# ipsec auto --verbose --up openswan-strongswan
002 "openswan-strongswan" #1: initiating v2 parent SA
133 "openswan-strongswan" #1: STATE_PARENT_I1: initiate
002 "openswan-strongswan" #1: transition from state STATE_IKEv2_START to state
STATE_PARENT_I1
133 "openswan-strongswan" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
002 "openswan-strongswan" #2: transition from state STATE_PARENT_I1 to state
STATE_PARENT_I2
134 "openswan-strongswan" #2: STATE_PARENT_I2: sent v2I2, expected v2R2
{auth=IKEv2 cipher=aes_192 integ=sha1 prf=oakley_md5 group=modp1536}
218 "openswan-strongswan" #2: STATE_PARENT_I2: INVALID_ID_INFORMATION
--------

error in /var/log/secure:
--------
eal5 pluto[4131]: packet from 9.3.190.194:500: IKEv2 mode no peer ID (hisID)
--------

If I change the ike line in the openswan ipsec.conf to "ike=aes192-sha1" to not
send a proposal with a prf of md5, the negotiation works fine.

So I tried configuring a connection from openswan to racoon2.  I got the error
above when "ike=aes192".  Then I changed it to "ike=aes192-sha1" which worked
with strongswan, but it results in the error above, too.
Comment 39 IBM Bug Proxy 2008-04-30 15:01:52 EDT
------- Comment From tchicks@us.ibm.com 2008-04-30 14:58 EDT-------
Hello again Herbert - It looks like these patches also break the ability to
negotiate SA's when using 3des.

connection:
------------
conn openswan_i386-openswan_i386
left=fc00:0:0:105::22
right=fc00:0:0:105::24
ikev2=insist
ike=3des
phase2alg=3des
authby=secret
auto=add
------------

bringup:
------------
[root@eal5 i386]# ipsec auto --verbose --up openswan_i386-openswan_i386
002 "openswan_i386-openswan_i386" #1: initiating v2 parent SA
133 "openswan_i386-openswan_i386" #1: STATE_PARENT_I1: initiate
002 "openswan_i386-openswan_i386" #1: transition from state STATE_IKEv2_START to
state STATE_PARENT_I1
133 "openswan_i386-openswan_i386" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
002 "openswan_i386-openswan_i386" #2: transition from state STATE_PARENT_I1 to
state STATE_PARENT_I2
134 "openswan_i386-openswan_i386" #2: STATE_PARENT_I2: sent v2I2, expected v2R2
{auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1 prf=oakley_sha group=modp1536}
------------

interesting part in log of responder:
------------
Apr 30 13:52:52 eal3 pluto[28031]: ASSERTION FAILED at /usr/src/redhat/BUILD/ope
nswan-2.6.12/programs/pluto/crypt_utils.c:56: space->start + howbig < space->len
Apr 30 13:52:52 eal3 pluto[28018]: closing helper(2) pid=28031 fd=9 exit=6
------------
Comment 40 Paul Wouters 2008-04-30 15:50:23 EDT
That's right. That's why we hadn't yet merged in this patch.

The problem seems to be that the patch sets the key length to -1, combined with
an if(!keylen). It causes the key size to be set to -1 which is then cast into
an unsigned variable, causing the keysize to become 65535. You can see this in
the debug information in out_attr(). The assert you see is openswan complaining
it cannot build such a huge packet.

Also, out_attr is an ikev1 function and should not be called from ikev2.

I think this problem only happens when one side is not setting any esp/keysize,
so herbert never saw the problem with strongswan, which always sends the
attribute key length.
Comment 41 IBM Bug Proxy 2008-04-30 17:18:59 EDT
------- Comment From tchicks@us.ibm.com 2008-04-30 17:12 EDT-------
Red Hat - Can we get confirmation that a fix for this bug is targeted for the
zstream release?  Thanks!
Comment 42 Herbert Xu 2008-05-03 04:57:37 EDT
Created attachment 304445 [details]
Handle fixed-length keys correctly.

Indeed, I'd only tested AES :)

Actually the first version did handle this correctly, but somewhere along the
line I changed it to use the value -1 and forgot to update the exit code to
turn it back to zero.  This patch fixes the problem for me with 3DES.

I couldn't reproduce the AES192 problem though.  Could you double-check that
you've got my second set of patches in this bug report, and not the first?
Thanks!
Comment 43 IBM Bug Proxy 2008-05-06 15:01:55 EDT
------- Comment From tchicks@us.ibm.com 2008-05-06 14:59 EDT-------
I verified the fixed key length patch between an i386 and ppc machine.
Everything looks good there.

As for the aes192 problem, I double checked to make sure that I didn't grab any
of the obsoleted patches.  I'm still getting that error, though.  When you use
the aes192 configs that I have above, you get a successful negotiation?
Comment 44 Herbert Xu 2008-05-08 03:32:58 EDT
Did you also apply the patch in BZ442955? That could explain the problem.
Comment 45 Paul Wouters 2008-05-14 12:07:16 EDT
openswan 2.6.13 fixes all issues in this bug (except aes192 being a valid cipher)
Comment 46 IBM Bug Proxy 2008-05-14 14:34:10 EDT
------- Comment From tchicks@us.ibm.com 2008-05-14 14:31 EDT-------
I have tried building with and without the patch in BZ442955, on x86 and x86_64,
and still have the aes192 problem.
Comment 47 Herbert Xu 2008-05-15 09:52:38 EDT
Hmm, what version of strongswan are you using?

Could you enable debugging on both sides and attach the result? Thanks!
Comment 48 IBM Bug Proxy 2008-05-16 16:18:00 EDT
------- Comment From tchicks@us.ibm.com 2008-05-16 16:13 EDT-------
strongswan-4.1.11
openswan-2.6.12-2.el5.src.rpm built with these patches applied:

From RH439771:
add_aes_key_length_to_sadb.patch
transmit_ikev2_key_length_attribute.patch
receive_ikev2_key_length_attribute.patch
handle_fixed_length_keys_correctly.patch

From RH442955:
add_conf_only_esp_support.patch

openswan config:
------------------------
version 2.0     # conforms to second version of ipsec.conf specification

config setup
# Debug-logging controls:  "none" for (almost) none, "all" for lots.
# klipsdebug=none
plutodebug="all"
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
protostack=netkey
nat_traversal=yes

conn openswan-strongswan
left=9.3.190.198
right=9.3.190.194
ike=aes192
phase2alg=aes192
ikev2=insist
authby=secret
auto=add
------------------------

strongswan config:
------------------------
config setup
# plutodebug=all
charondebug="dmn 4, mgr 4, ike 4, chd 4, job 4, cfg 4, knl 4, net 4, enc
2, lib 4"
# crlcheckinterval=600
# strictcrlpolicy=yes
# cachecrls=yes
# nat_traversal=yes
# charonstart=no
plutostart=no

conn openswan-strongswan
left=9.3.190.198
right=9.3.190.194
keyexchange=ikev2
authby=secret
auto=add
------------------------

I couldn't turn on full debugging on the strongswan (responder) side, because
there were some timing issues due to writing so much data to the log that would
cause the negotiation to hang before hitting this problem.

secrets shared by both:
------------------------
9.3.190.198 9.3.190.194 : PSK "psk"
------------------------

command:
------------------------
[root@eal5 ~]# ipsec auto --verbose --up openswan-strongswan
002 "openswan-strongswan" #1: initiating v2 parent SA
133 "openswan-strongswan" #1: STATE_PARENT_I1: initiate
002 "openswan-strongswan" #1: transition from state STATE_IKEv2_START to state
STATE_PARENT_I1
133 "openswan-strongswan" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
010 "openswan-strongswan" #1: STATE_PARENT_I1: retransmission; will wait 20s for
response
002 "openswan-strongswan" #2: transition from state STATE_PARENT_I1 to state
STATE_PARENT_I2
134 "openswan-strongswan" #2: STATE_PARENT_I2: sent v2I2, expected v2R2
{auth=IKEv2 cipher=aes_192 integ=md5 prf=oakley_sha group=modp1536}
218 "openswan-strongswan" #2: STATE_PARENT_I2: INVALID_ID_INFORMATION
------------------------

I will attach the logs.
Comment 49 IBM Bug Proxy 2008-05-16 16:25:50 EDT
Created attachment 305744 [details]
Openswan (initiator) logs
Comment 50 IBM Bug Proxy 2008-05-16 16:25:52 EDT
Created attachment 305745 [details]
Strongswan (responder) logs
Comment 51 Paul Wouters 2008-05-16 16:48:28 EDT
You can try logging to a tmpfs mount.

We put up an openswan-2.6.13rc1.tar.gz, but we're still running tests on it
before doing a full release. We did see strongswan-openswan interops work on
this release though.
Comment 52 Herbert Xu 2008-05-19 09:22:15 EDT
Created attachment 305940 [details]
Use the correct algorithm for ID hashing

Doh! I was looking at the child SA but you're having a problem with the parent
SA.

In fact, the bug was rather obvious since there is even a comment which says
that it's wrong :) This patch makes it work for me.  Thanks!
Comment 53 Paul Wouters 2008-05-19 12:00:59 EDT
Confirmed will be in 2.6.14.

I remember putting in the comment with Antony.... Grrr
Comment 54 Steve Grubb 2008-06-04 13:21:32 EDT
2.6.14rc7 was built to address the bug reported.
Comment 57 IBM Bug Proxy 2008-06-05 15:18:13 EDT
------- Comment From tchicks@us.ibm.com 2008-06-05 15:08 EDT-------
I have verified these bug fixes between openswan-2.6.14rc7 on ppc and i386 and
strongswan-4.1.11 on i386.  I built openswan-2.6.14rc7 from source available at
openswan.org.  I haven't been able to find the rpm built by Red Hat.
Comment 58 Paul Wouters 2008-06-05 15:41:52 EDT
note that 2.6.14rc10 is on there now.
Comment 59 IBM Bug Proxy 2008-06-18 18:18:15 EDT
------- Comment From tchicks@us.ibm.com 2008-06-18 18:11 EDT-------
Changing status to FIXEDAWAITINGTEST on IBM's side.

------- Comment From tchicks@us.ibm.com 2008-06-18 18:12 EDT-------
Changing status to TESTED on IBM's side.

------- Comment From tchicks@us.ibm.com 2008-06-18 18:13 EDT-------
Changing status to ACCEPTED on IBM's side.

------- Comment From tchicks@us.ibm.com 2008-06-18 18:14 EDT-------
Changing status to CLOSED on IBM's side.
Comment 62 Chris Ward 2009-06-14 19:14:47 EDT
~~ Attention Partners RHEL 5.4 Partner Alpha Released! ~~

RHEL 5.4 Partner Alpha has been released on partners.redhat.com. There should
be a fix present that addresses this particular request. Please test and report back your results here, at your earliest convenience. Our Public Beta release is just around the corner!

If you encounter any issues, please set the bug back to the ASSIGNED state and
describe the issues you encountered. If you have verified the request functions as expected, please set your Partner ID in the Partner field above to indicate successful test results. Do not flip the bug status to VERIFIED. Further questions can be directed to your Red Hat Partner Manager. Thanks!
Comment 63 Chris Ward 2009-06-14 19:18:09 EDT
Partners, 

This particular request is of a notably high priority. In order to prepare make the most of this Alpha release, please report back initial test results before the scheduled Beta drop. That way if you encounter any issues, we can work to get additional corrections in before we launch our Public Beta release. Speak with your Partner Manager for additional dates and information. Thank you for your cooperation in this effort.
Comment 64 Eduard Benes 2009-07-03 09:30:41 EDT
Is there any response about retesting the bug with latest openswan packages?
There is a NSS support in new openswan-2.6.21-4.el5, which requires the bug to be retested to in order verify that we got no regression.
Comment 65 Chris Ward 2009-07-03 11:44:48 EDT
IBM, could you please retest for this issue, using the latest Beta bits?
Comment 66 Chris Ward 2009-07-03 14:01:46 EDT
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.
Comment 67 IBM Bug Proxy 2009-07-09 18:02:43 EDT
------- Comment From tyhicks@linux.vnet.ibm.com 2009-07-09 17:51 EDT-------
Sorry for the lag - this bug is closed on the IBM side and I wasn't giving any attention.   Unfortunately, it isn't very likely that I'll have the bandwidth to recreate the environment and verify this for 5.4.
Comment 68 Chris Ward 2009-07-10 07:21:49 EDT
IBM, understandable. By chance, do you know if there is any remaining openswan testing planned for execution by anyone other than yourself? 

Please update this bug if you do eventually find the cycles to re-test. Thanks.
Comment 71 Chris Ward 2009-07-10 15:04:06 EDT
~~ Attention Partners - RHEL 5.4 Snapshot 1 Released! ~~

RHEL 5.4 Snapshot 1 has been released on partners.redhat.com. If you have already reported your test results, you can safely ignore this request. Otherwise, please notice that there should be a fix available now that addresses this particular request. Please test and report back your results here, at your earliest convenience. The RHEL 5.4 exception freeze is quickly approaching.

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue. 

Further questions can be directed to your Red Hat Partner Manager or other appropriate customer representative.
Comment 74 errata-xmlrpc 2009-09-02 07:18:16 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1350.html

Note You need to log in before you can comment on or make changes to this bug.