Bug 444166

+++ This bug was initially created as a clone of Bug #441588 +++

=Comment: #0=================================================
TYLER C. HICKS <tchicks.com> - 2008-04-07 20:43 EDT
---Problem Description---
openswan IKEv2 crashes when interoperating with racoon2
 
Contact Information = Tyler Hicks <tyhicks.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.com> - 2008-04-07 20:51 EDT

Logs from eal5 (initiator)

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

Debug output from spmd on elm3b138 (responder)

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

Debug output from iked on elm3b138 (responder)

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

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

=Comment: #5=================================================
TYLER C. HICKS <tchicks.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.com on 2008-04-08 16:35 EST --
Created an attachment (id=301705)
Debug output from iked on elm3b138 (responder)


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


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


-- Additional comment from bugproxy.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.com on 2008-04-08 16:57 EST --
------- Comment From emachado.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 on 2008-04-08 16:59 EST --
This has been addressed - please use 2.6.11 and re-test.

-- Additional comment from bugproxy.com on 2008-04-09 18:01 EST --
------- Comment From tchicks.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 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.com on 2008-04-15 16:57 EST --
------- Comment From tchicks.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.com on 2008-04-18 14:24 EST --
------- Comment From tchicks.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.com on 2008-04-18 14:32 EST --
------- Comment From tchicks.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 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.com on 2008-04-18 15:16 EST --
------- Comment From tchicks.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 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 on 2008-04-22 12:15 EST --
ack

-- Additional comment from syeghiay 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 on 2008-04-22 14:36 EST --
openswan-2.6.12-1.el5 was built to address this problem.

-- Additional comment from bugproxy.com on 2008-04-22 18:01 EST --
------- Comment From tchicks.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 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