+++ 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) <prefix>/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
Clone from bug 439771. open this bug to track the validation of RFC4306.
*** Bug 444167 has been marked as a duplicate of this bug. ***
This is addressed in openswan-2.6.13.
2.6.14rc7-1 was built to address the problem being reported.
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 ---
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.
www.openswan.org should be back shortly, once xend starts giving the xenu some networking again :P
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. :)
~~ 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.
~~ 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.
~~ 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.
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