Bug 444166 - [IPv6-DoD] openswan IKEv2 crashes when interoperating with racoon2
[IPv6-DoD] openswan IKEv2 crashes when interoperating with racoon2
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openswan (Show other bugs)
5.2
x86_64 All
urgent Severity high
: rc
: ---
Assigned To: Avesh Agarwal
GSSApproved
: OtherQA, ZStream
: 444167 (view as bug list)
Depends On: 441588
Blocks: 253764 450129
  Show dependency treegraph
 
Reported: 2008-04-25 11:52 EDT by Linda Wang
Modified: 2009-09-03 10:15 EDT (History)
12 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:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Linda Wang 2008-04-25 11:52:25 EDT
+++ This bug was initially created as a clone of Bug #441588 +++

=Comment: #0=================================================
TYLER C. HICKS <tchicks@us.ibm.com> - 2008-04-07 20:43 EDT
---Problem Description---
openswan IKEv2 crashes when interoperating with racoon2
 
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 elm3b138 2.6.18-87.el5PAE #1 SMP Tue Mar 25 17:42:32 EDT 2008 i686 i686
i386 GNU/Linux

Machine Type = Xseries 335
 
---Debugger---
A debugger is not configured
 
---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-racoon2
        left=9.3.190.198
        right=9.47.67.138
        #ike=3des-sha1-modp2048
        ikev2=insist
        authby=secret
        auto=add
-----------------------------------------------------------------

Commands to recreate:
-----------------------------------------------------------------
[root@eal5 ~]# pidof pluto; ipsec auto --verbose --up openswan-racoon2; pidof pluto
15623 15622 15620 15610
002 "openswan-racoon2" #1: initiating v2 parent SA
133 "openswan-racoon2" #1: STATE_PARENT_I1: initiate
002 "openswan-racoon2" #1: transition from state STATE_IKEv2_START to state
STATE_PARENT_I1
133 "openswan-racoon2" #1: STATE_PARENT_I1: sent v2I1, expected v2R1

[root@eal5 ~]#
-----------------------------------------------------------------

Uncommenting the "ike=..." line in /etc/ipsec.conf results in the SA's being
negotiated properly.  Without that line, openswan crashes, as can be seen above.

Please note that the first patch proposed by Paul Wouters in RH bug 438826 was
applied to the openswan package prior to this testing.
 
---Security Component Data---
Userspace tool common name: openswan

The userspace tool has the following bit modes: 32

Userspace rpm: openswan-2.6.09-1
=Comment: #1=================================================
TYLER C. HICKS <tchicks@us.ibm.com> - 2008-04-07 20:51 EDT

Logs from eal5 (initiator)

=Comment: #2=================================================
TYLER C. HICKS <tchicks@us.ibm.com> - 2008-04-07 20:52 EDT

Debug output from spmd on elm3b138 (responder)

=Comment: #3=================================================
TYLER C. HICKS <tchicks@us.ibm.com> - 2008-04-07 20:52 EDT

Debug output from iked on elm3b138 (responder)

=Comment: #4=================================================
TYLER C. HICKS <tchicks@us.ibm.com> - 2008-04-07 20:54 EDT

<prefix>/etc/racoon2/ contents on elm3b138 (responder)

=Comment: #5=================================================
TYLER C. HICKS <tchicks@us.ibm.com> - 2008-04-07 21:06 EDT

I performed a back trace with gdb and got the following results:
------------------
Program received signal SIGABRT, Aborted.
0x00c25402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00c25402 in __kernel_vsyscall ()
#1  0x00dedc50 in raise () from /lib/libc.so.6
#2  0x00def561 in abort () from /lib/libc.so.6
#3  0x0037d8dc in passert_fail (pred_str=0x416eec "pbs != NULL", 
    file_str=0x416ac4
"/usr/src/redhat/BUILD/openswan-2.6.09/programs/pluto/ipsec_doi.c", line_no=222)
    at /usr/src/debug/openswan-2.6.09/programs/pluto/log.c:623
#4  0x003896b0 in accept_KE (dest=0x89046c4, val_name=0x419334 "Gr", 
    gr=0x44906c, pbs=0x0)
    at /usr/src/debug/openswan-2.6.09/programs/pluto/ipsec_doi.c:222
#5  0x0039bb2e in ikev2parent_inR1outI2 (md=0x89050c8)
    at /usr/src/debug/openswan-2.6.09/programs/pluto/ikev2_parent.c:830
#6  0x0039959f in process_v2_packet (mdp=0x4526c0)
    at /usr/src/debug/openswan-2.6.09/programs/pluto/ikev2.c:448
#7  0x003ae8f1 in process_packet (mdp=0x4526c0)
    at /usr/src/debug/openswan-2.6.09/programs/pluto/demux.c:167
#8  0x003aece7 in comm_handle (ifp=0x8902148)
    at /usr/src/debug/openswan-2.6.09/programs/pluto/demux.c:212
#9  0x00384b28 in call_server ()
    at /usr/src/debug/openswan-2.6.09/programs/pluto/server.c:760
#10 0x00381a6a in main (argc=1146766671, argv=0x7d544d7e)
    at /usr/src/debug/openswan-2.6.09/programs/pluto/plutomain.c:828
------------------

It looks like the same problem that was discussed in RH Bugzilla 438826.

-- Additional comment from bugproxy@us.ibm.com on 2008-04-08 16:35 EST --
Created an attachment (id=301705)
Debug output from iked on elm3b138 (responder)


-- Additional comment from bugproxy@us.ibm.com on 2008-04-08 16:35 EST --
Created an attachment (id=301706)
Logs from eal5 (initiator)


-- Additional comment from bugproxy@us.ibm.com on 2008-04-08 16:35 EST --
Created an attachment (id=301707)
Debug output from spmd on elm3b138 (responder)


-- Additional comment from bugproxy@us.ibm.com on 2008-04-08 16:35 EST --
Created an attachment (id=301708)
&lt;prefix&gt;/etc/racoon2/ contents on elm3b138 (responder)


-- Additional comment from bugproxy@us.ibm.com on 2008-04-08 16:57 EST --
------- Comment From emachado@br.ibm.com 2008-04-08 16:49 EDT-------
Red Hat,

I was not sure about the component related to this bug, feel free to choose a
properly one.

Thanks.

-- Additional comment from paul@xelerance.com on 2008-04-08 16:59 EST --
This has been addressed - please use 2.6.11 and re-test.

-- Additional comment from bugproxy@us.ibm.com on 2008-04-09 18:01 EST --
------- Comment From tchicks@us.ibm.com 2008-04-09 17:56 EDT-------
2.6.11 did take care of the crash, but the negotiation wasn't successful.

------------
[root@eal5 ~]# ipsec auto --verbose --up openswan-racoon2
002 "openswan-racoon2" #1: initiating v2 parent SA
133 "openswan-racoon2" #1: STATE_PARENT_I1: initiate
002 "openswan-racoon2" #1: transition from state STATE_IKEv2_START to state
STATE_PARENT_I1
133 "openswan-racoon2" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
214 "openswan-racoon2" #1: STATE_PARENT_I1: NO_PROPOSAL_CHOSEN
010 "openswan-racoon2" #1: STATE_PARENT_I1: retransmission; will wait 20s for
response
214 "openswan-racoon2" #1: STATE_PARENT_I1: NO_PROPOSAL_CHOSEN
010 "openswan-racoon2" #1: STATE_PARENT_I1: retransmission; will wait 40s for
response
214 "openswan-racoon2" #1: STATE_PARENT_I1: NO_PROPOSAL_CHOSEN
031 "openswan-racoon2" #1: max number of retransmissions (2) reached
STATE_PARENT_I1.  No response (or no acceptable response) to our first IKE message
000 "openswan-racoon2" #1: starting keying attempt 2 of at most 3, but releasing
whack
------------

-- Additional comment from paul@xelerance.com on 2008-04-09 19:21 EST --
that's right. It is not working because of:

https://bugzilla.redhat.com/show_bug.cgi?id=439985


-- Additional comment from bugproxy@us.ibm.com on 2008-04-15 16:57 EST --
------- Comment From tchicks@us.ibm.com 2008-04-15 16:55 EDT-------
Hi Paul - I think there is a little more to this bug than what is described in
439985.  If openswan is the initiator, I have to apply all of Herbert's patch
from 439771, otherwise the keys are switched.

I also have to add modp1536 to racoon2's  kmp_dh_group.  This is because
openswan sends a KE Payload with a DH Group # of 5 (1536 bits) in the
IKE_SA_INIT.  The attached racoon2 config only includes the IKEv2
mandatory-to-implement DH Group numbers of 2 and 14 (1024 and 2048 bits), so
racoon2 responds back with an INVALID_KE_PAYLOAD notification and includes
0x0002 in its notification data, indicating that it wants to use DH Group # 2.
When openswan resends the IKE_SA_INIT, it still uses DH Group # 5 in the KE
Payload and the process repeats a few times until openswan gives up.

Here's the blurb about this in RFC 4306:
-------------
If in the initial exchange the
initiator offers to use one of several Diffie-Hellman groups, it
SHOULD pick the one the responder is most likely to accept and
include a KE corresponding to that group.  If the guess turns out to
be wrong, the responder will indicate the correct group in the
response and the initiator SHOULD pick an element of that group for
its KE value when retrying the first message.  It SHOULD, however,
continue to propose its full supported set of groups in order to
prevent a man-in-the-middle downgrade attack.
-------------

So openswan is technically RFC 4306 compliant with the way it handles the
INVALID_KE_PAYLOAD, but it obviously may pose a problem with any responders
which don't use modp1536.

Should openswan be using modp1536 in the IKE_SA_INIT for IKEv2 when it isn't a
mandatory-to-implement DH Group for IKEv2 or should it acknowledge the
Notification Data field of the INVALID_KE_PAYLOAD and adjust the next KE_PAYLOAD
field accordingly?

-- Additional comment from bugproxy@us.ibm.com on 2008-04-18 14:24 EST --
------- Comment From tchicks@us.ibm.com 2008-04-18 14:21 EDT-------
Hi Paul - I wanted to clarify why I thought that most IKEv2 implementations
would be using modp1024 or modp2048, as opposed to modp1536.  RFC 4307,
"Cryptographic Algorithms for Use in the Internet Key Exchange Version 2
(IKEv2)", defines a set of "mandatory-to-implement algorithms to ensure that
there is at least one algorithm that all implementations will have available."

This RFC can be found at http://www.apps.ietf.org/rfc/rfc4307.html

On page 3, in section 3.1.2, the following DH Groups are listed:

-----------
3.1.2 Diffie-Hellman Groups

There are several Modular Exponential (MODP) groups that are defined for use
in IKEv2. They are defined in both the [IKEv2] base document and in the MODP
extensions document. They are identified by group number. Any groups not listed
here are considered as "MAY be implemented".

Group Number        Bit Length            Status     Defined
2                   1024 MODP Group       MUST-      [RFC2409]
14                  2048 MODP Group       SHOULD+    [RFC3526]

-----------

Based off of the section above, I assumed that either of the above 2 groups
would be more widely used than modp1536, which is why I questioned openswan's
default use of modp1536.

-- Additional comment from bugproxy@us.ibm.com on 2008-04-18 14:32 EST --
------- Comment From tchicks@us.ibm.com 2008-04-18 14:29 EDT-------
I was mainly concerned that a responder which was locked down to only use
modp1024 and modp2048 would not be able to interoperate with an openswan
initiator, since no different DH Group was used after a INVALID_KE_PAYLOAD
notification.  If openswan acknowledges the INVALID_KE_PAYLOAD notification data
(which specifies the responder's selected DH Group) and uses that DH Group in
the following IKE_SA_INIT message, I don't believe there is really a problem
with defaulting to modp1536.

-- Additional comment from paul@xelerance.com on 2008-04-18 14:35 EST --
Hi "tchicks" (what is your name? :)

You are absolutely right. I looked at RFC4306 and 4718 and could not find it. I
missed 4307.

Michael Richardson wanted to stick to 1536, but looking at this RFC, we will
switch the default for IKEv2 to 2048 in openswan 2.6.12.

Thanks for the pointer!

-- Additional comment from bugproxy@us.ibm.com on 2008-04-18 15:16 EST --
------- Comment From tchicks@us.ibm.com 2008-04-18 15:13 EDT-------
Hi Paul - My name is Tyler Hicks.  I forget that my name doesn't show up in RH
Bugzilla. :)

I think this is the best way to correct this bug.  Thanks!

-- Additional comment from lwang@redhat.com on 2008-04-22 09:27 EST --
fixed in 2.6.12

http://www.openswan.org/download/development/openswan-2.6.12.tar.gz
http://www.openswan.org/download/development/openswan-2.6.12.tar.gz.asc

From the CHANGES file:

v2.6.12
* Add aes-*-modp1024 proposals to default responder policy db [antony]
  This is bug https://bugzilla.redhat.com/show_bug.cgi?id=439985
* Fix for ikev1 continuation segfault (only the first helper's continuations
  were cleaned up properly (eg. on dpd, sa expires..) [Anthony Tong]
* Redid fix for leftsourceip/rightsourceip getting deleted [paul]
  This is bug https://bugzilla.redhat.com/show_bug.cgi?id=432821
* As per RFC 4309, use modp2048 as default for PSK with IKEv2 [paul]
  Relates to https://bugzilla.redhat.com/show_bug.cgi?id=441588
* Added workaround for INITIATOR/RESPONDER keys being swapped [herbert]
* Preliminary work to support IKEv2_ENCR_AES_CCM__* algos [paul]
* modprobe the AES ccm kernel module on startup [paul]

-- Additional comment from rousseau@redhat.com on 2008-04-22 12:15 EST --
ack

-- Additional comment from syeghiay@redhat.com on 2008-04-22 12:18 EST --
From Apr 22 RHEL meeting:

REPORTER: lwang
STATUS:   Fixed by openswan-2.6.12.
DECISION: Approved blocker-rc for Snapshot 7.
          Please respin advisory by 5PM Eastern Apr 23.


-- Additional comment from sgrubb@redhat.com on 2008-04-22 14:36 EST --
openswan-2.6.12-1.el5 was built to address this problem.

-- Additional comment from bugproxy@us.ibm.com on 2008-04-22 18:01 EST --
------- Comment From tchicks@us.ibm.com 2008-04-22 17:59 EDT-------
When acting as an initiator, openswan-2.6.12 successfully negotiates with
racoon2.  However, when acting as a responder, openswan-2.6.12 fails.  This is
due to the same problem as described in 439771.  I will repost the explanation
here for completeness.

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.
------

Racoon2 attaches a key-length transform attribute to the ENCR transform to
specify the key length when using aes.  When openswan responds, it fails to
include the key-length attribute and racoon2 does the correct thing and rejects
the modified 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.

-- Additional comment from errata-xmlrpc@redhat.com on 2008-04-23 15:34 EST --
Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2008:8131-01
http://errata.devel.redhat.com/errata/show/6906
Comment 1 Linda Wang 2008-04-25 11:53:25 EDT
Clone from bug 439771.

open this bug to track the validation of RFC4306.
Comment 2 Linda Wang 2008-04-25 12:17:44 EDT
*** Bug 444167 has been marked as a duplicate of this bug. ***
Comment 3 Paul Wouters 2008-05-14 12:03:00 EDT
This is addressed in openswan-2.6.13.
Comment 5 Steve Grubb 2008-06-04 13:24:56 EDT
2.6.14rc7-1 was built to address the problem being reported.
Comment 8 Jakub Hrozek 2008-06-10 10:22:55 EDT
Tyler, have you had a chance to try the new openswan 2.6.14 with racoon2? I 
can't seem to get neither opeswan-2.6.12 (which was supposed to be working as 
initiator) nor 2.6.14 working with racoon2..

---
# ipsec auto --verbose --up swan-racoon
002 "swan-racoon" #1: initiating v2 parent SA
133 "swan-racoon" #1: STATE_PARENT_I1: initiate
002 "swan-racoon" #1: transition from state STATE_IKEv2_START to state 
STATE_PARENT_I1
133 "swan-racoon" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
010 "swan-racoon" #1: STATE_PARENT_I1: retransmission; will wait 20s for 
response
010 "swan-racoon" #1: STATE_PARENT_I1: retransmission; will wait 40s for 
response
---
Comment 9 Tyler Hicks 2008-06-10 12:24:51 EDT
Hi Jakub - I can't seem to get to openswan.org in order to fetch the final
2.6.14 sources and I don't think that I have access to the RH rpm yet.  But I
have openswan-2.6.14rc7 and racoon2-20071227e (both built from source) working
great, no matter which one is the initiator.

As soon as I see openswan.org back up, I will give 2.6.14 a try and let you know.
Comment 10 Paul Wouters 2008-06-10 12:34:42 EDT
www.openswan.org should be back shortly, once xend starts giving the xenu some
networking again :P
Comment 11 Tyler Hicks 2008-06-10 16:25:35 EDT
Jakub, I built openswan-2.6.14 and I have no problem negotiating with racoon2. 
It must be a problem with your configs.  Include some info from /var/log/secure
and maybe I'll remember running into the same problem in the past. :)
Comment 14 Chris Ward 2009-07-03 14:02:29 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 15 Chris Ward 2009-07-10 15:04:36 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 17 Chris Ward 2009-08-03 11:44:10 EDT
~~ Attention Partners - RHEL 5.4 Snapshot 5 Released! ~~

RHEL 5.4 Snapshot 5 is the FINAL snapshot to be release before RC. It 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 issue. Please test and report 
back your results here, at your earliest convenience.

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. If it is urgent, escalate the issue to your partner manager as soon as possible. There is /very/ little time left to get additional code into 5.4 before GA.

Partners, after you have verified, 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 19 errata-xmlrpc 2009-09-02 07:18:43 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.