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.
Bug 826264 - aes-gcm implementation support for libreswan
Summary: aes-gcm implementation support for libreswan
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreswan
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Paul Wouters
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On: 839204
Blocks: 717789 838994 1057566
TreeView+ depends on / blocked
 
Reported: 2012-05-29 21:32 UTC by Avesh Agarwal
Modified: 2015-03-05 10:21 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 839204 (view as bug list)
Environment:
Last Closed: 2015-03-05 10:21:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
openswan patch to support aes-gcm with esp (5.70 KB, patch)
2012-05-29 21:34 UTC, Avesh Agarwal
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0431 0 normal SHIPPED_LIVE libreswan bug fix and enhancement update 2015-03-05 14:52:35 UTC

Description Avesh Agarwal 2012-05-29 21:32:42 UTC
Description of problem:
Current openswan codes does not have support for aes-gcm algorithms.

Version-Release number of selected component (if applicable):
2.6.38

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Avesh Agarwal 2012-05-29 21:34:22 UTC
Created attachment 587532 [details]
openswan patch to support aes-gcm with esp

Comment 2 Avesh Agarwal 2012-05-29 21:37:46 UTC
Since Openswan uses NSS crypto library for cryptograhic operation with IKE, NSS should must support aes-gcm too. I have created upstream bug for this:

https://bugzilla.mozilla.org/show_bug.cgi?id=755500 

The attached patch only solves the issues with ESP as kernel has support for aes-gcm.

Comment 4 Eric Paris 2013-11-07 17:14:32 UTC
We are shipping libreswan, not openswan, in RHEL7.  Moving component.  Switching back to ASSIGNED.  Paul, can you verify and attach to RHEL7 errata?

Comment 5 Paul Wouters 2013-12-06 21:34:57 UTC
There are a few issues here worth mentioning/documentating

openswan/libreswan aes_gcm support was for ESP only, not IKE, and with IKEv1 onky. Although I believe Cisco also only supports AES_GCM for ESP only and recommends using AES CBC with the same key size for IKE.

The ESP support was only added to IKEv1, not IKEv2. Support in IKEv2 has been coded and tested with interop to strongswan. However, implementation has changed a bit. AES GCM needs an additional 4 bytes (32bits) of salt that is generated as part of the mutual KEYMAT. The openswan implementation required adding this to the esp= config line (so for aes gcm 128, you had to specify aes_gcm_c-224-null (128+32). This is rather strange and confusing. We changed it in libreswan to use the actual key size and hide the salt keymat from the user altogether. Since some code is shared between v1 and v2, we had to convert that code as well.
It removed a lot of juggling in code where it added and subtracted the 4 bytes to fixup on-the-wire versus internal-code key sizes.

Furthermore, while RFC 4106 specifies ESP for AES_GCM, and IANA registered encryption transforms for three versions of AES_GCM (8/12/16 bit IV) for IKEv2, but it did not register any for IKEv1. Asking the IETF IPsec WG chair this was a mistake. Implementing in with IKEv1 using the same transform IDs as IKEv2 seems to interop with other implementations.

Lastly, there has been some discussion about the ICV variants specified in the RFC (some about TLS, not IPsec but the same issue is present). From RFC 4106:

6. Integrity Check Value (ICV)


   The ICV consists solely of the AES-GCM Authentication Tag.
   Implementations MUST support a full-length 16-octet ICV, and MAY
   support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths.


These variants translate to the openswan implementation as aes_gcm_a, aes_gcm_b and aes_gcm_c.

It seems there is consensus that there is no valid reason to use reduced ICVs. One of the author's of RFC 4106, John Viega, recommended to only implement the 16 octet. Libreswan will do so and allow the esp= name to be "aes_gcm". It will refuse the 12 (aes_gcm_b) and 8 (aes_gcm_a) variants.

Comment 6 Paul Wouters 2014-01-16 09:12:14 UTC
currently in the 3.8 rebase, it allows all variants still. and the alias is not yet allowed. So the suffix _a _b _c is needed.

This is currently still only for ESP, not IKE.

Comment 7 Paul Wouters 2014-01-24 16:50:35 UTC
Can someone clarify whether AES-GCM support is expected as part of IKE as well as ESP? This bug description does not make that clear to me.

Comment 8 Steve Grubb 2014-01-24 17:11:59 UTC
From what I can find, RFC 4106 and RFC 4869 describe the use of GCM in IPsec Encapsulating Security Payload (ESP). RFC 6379 & 6380 cover the IKE aspects of Suite B.

Comment 12 Ann Marie Rubin 2014-09-12 16:26:34 UTC
Bob Relyea's response:

Those are exactly the curves that went into NSS in RHEL 6.5, RHEL 5.9
and RHEL 7.0. You should already have support for ECC certs, and
probably signatures (as long as you aren't hand building any keys), but
any KEA would require extra code on the application's part because that
kind of code is tied to the algorithms (RSA KEA looks completely
different from DH-style KEA's).

Comment 16 Ondrej Moriš 2015-01-26 11:47:36 UTC
I did testing with 3.12-5 and 
 
a) ike works fine with aes_gcm[abc](128|192|256)-(md5|sha1|sha2), but

b) esp (phase2alg) works with 128 bit key length 128 only, ie. all aes_gcm[abc]128-null variants work, but eg. aes_gcm_c256-null does not.

Consider the following configuration:

conn test
    left=<left>
    right=<right>
    authby=secret
    ike=3des-sha1
    ikev2=insist
    phase2=esp
    phase2alg=aes_gcm256-null
    auto=add

# ipsec auto --up test
002 "test" #1: initiating v2 parent SA
133 "test" #1: STATE_PARENT_I1: initiate
002 "test" #1: transition from state STATE_IKEv2_START to state STATE_PARENT_I1
133 "test" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
002 "test" #2: transition from state STATE_PARENT_I1 to state STATE_PARENT_I2
134 "test" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=sha group=MODP2048}
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 10s for response
^C

pluto.log on the <left> contains:

"test" #1: ERROR: netlink response for Add SA esp.f7a178a1.88.23 included errno 22: Invalid argument

pluto.log on the right (initiating connection) is as follows:

packet from 10.34.88.49:500: sending unencrypted notification v2N_INVALID_MESSAGE_ID to 10.34.88.49:500
| processing connection test
| processing connection test
| processing connection test
"test" #1: initiating v2 parent SA
| processing connection test
"test" #1: transition from state STATE_IKEv2_START to state STATE_PARENT_I1
"test" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
| V2 microcode entry (initiate IKE_SA_INIT) has unspecified timeout_event
| processing connection test
| processing connection test
"test" #2: transition from state STATE_PARENT_I1 to state STATE_PARENT_I2
"test" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=oakley_3des_cbc_192 integ=sha1_96 prf=sha group=MODP2048}
| V2 microcode entry (Initiator: process IKE_SA_INIT reply, initiate IKE_AUTH) has unspecified timeout_event
| processing connection test

I tried ikev2=no as well with the same results. Did upstream test [1] passed?

I see this bug is on FIPS 140-2 tracker for RHEL7.1. But I guess we may want to fix this in 7.1.z and say in release notes that phase2alg works with aes_gcm_[abc]128-null only (provided that it really does not work)...?

[1] https://github.com/libreswan/libreswan/tree/master/testing/pluto/ikev2-algo-04-aes-gcm256.

Comment 17 Paul Wouters 2015-01-26 20:49:57 UTC
Yes, you are hitting the AES_GCM kernel bug https://bugzilla.redhat.com/show_bug.cgi?id=1176266

please use kernel package -224.el7

Comment 20 errata-xmlrpc 2015-03-05 10:21:43 UTC
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


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