Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 928351[details]
pcap file
Description of problem:
RFC 5996, Section 2.6:
In the first message of an initial IKE exchange, the initiator will
not know the responder's SPI value and will therefore set that field
to zero. When the IKE_SA_INIT exchange does not result in the
creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN,
or COOKIE (see Section 2.6), the responder's SPI will be zero also in
the response message. However, if the responder sends a non-zero
responder SPI, the initiator should not reject the response for only
that reason.
Version-Release number of selected component (if applicable):
# ipsec --version
Linux Libreswan U3.8/K(no kernel code presently loaded) on 3.10.0-123.el7.x86_64
# rpm -qa | grep libreswan
libreswan-3.8-4.el7.x86_64
How reproducible:
every time
Steps to Reproduce:
NUT TN1
(End-Node) (End-Node)
| |
|<-------------------| IKE_SA_INIT request (HDR, SAi1(DH#2, DH#14), KEi(DH#14), Ni)
| | (Packet #1)
|------------------->| IKE_SA_INIT response (HDR, N(INVALID_KE_PAYLOAD(DH#2)))
| | (Judgement #1)
| |
1. TN1 starts to negotiate with NUT by sending IKE_SA_INIT request including a SA payload which contains a D-H Group transform proposes using D-H Group 2 and D-H Group 14, and a Key Exchange payload which contains 14 (D-H Group 14) as DH Group # field and the Key Exchange Data.
2. Observe the messages transmitted on Link A.
Actual results:
responder sends a non-zero responder SPI when receive invalid KE payload
IKE Header
OK initSPI: (received: cbb40ba41794a233, expected: cbb40ba41794a233, comp: eq)
NG respSPI: (received: 0fe7a96d1fca0587, expected: 0000000000000000, comp: eq)
Expected results:
responder sends a zero responder SPI when receive invalid KE payload
Additional info:
http://10.66.13.78/IKEv2/IKEv2_ENODE_RESPONDER_54_none_zero_spi/2-EN-R/IKEv2-EN-R-1-1-6-8-A.htmlhttp://10.66.13.78/IKEv2/IKEv2_ENODE_RESPONDER_54_none_zero_spi/54.html
The observed behaviour matches my expectation.
It seems like a silly corner case to support. I'm sure we don't do that right now. Will talk with other upstream developers to see if it should be fixed.
The patch for this fixes more than just the responder SPI needing to be zero. Libreswan did not handle INVALID_KE properly at all. The patch includes:
1 On receiving unacceptable KE, send INVALID_KE (with zero SPI) instead of NO_PROPOSAL_CHOSEN
2 When sending INVALID_KE, add NOTIFY DATA containing the suggested DH group
3 When receiving INVALID_KE, retry IKE_INIT with the suggested DH group provided that DH group is allowed by configuration.
Test case for this can be done using two libreswan machines, simple host-host PSK connection, using ikev2=insist
configure initiator with ike=aes128-sha1;modp1536,aes128-sha1;modp2048 and responder with ike=aes128-sha1;modp2048
Look for the string:
Received unauthenticated INVALID_KE with suggested group MODP2048; resending with updated modp group
followed by a successful tunnel setup.
(see upstream test case ikev2-21-invalid-ke)
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2015-0431.html