Bug 826264 - aes-gcm implementation support for libreswan
aes-gcm implementation support for libreswan
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreswan (Show other bugs)
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Paul Wouters
Ondrej Moriš
Depends On: 839204
Blocks: 1057566 717789 838994
  Show dependency treegraph
Reported: 2012-05-29 17:32 EDT by Avesh Agarwal
Modified: 2015-03-05 05:21 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 839204 (view as bug list)
Last Closed: 2015-03-05 05:21:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Avesh Agarwal 2012-05-29 17:32:42 EDT
Description of problem:
Current openswan codes does not have support for aes-gcm algorithms.

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Avesh Agarwal 2012-05-29 17:34:22 EDT
Created attachment 587532 [details]
openswan patch to support aes-gcm with esp
Comment 2 Avesh Agarwal 2012-05-29 17:37:46 EDT
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:


The attached patch only solves the issues with ESP as kernel has support for aes-gcm.
Comment 4 Eric Paris 2013-11-07 12:14:32 EST
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 16:34:57 EST
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 04:12:14 EST
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 11:50:35 EST
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 12:11:59 EST
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 12:26:34 EDT
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 06:47:36 EST
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

# 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

pluto.log on the <left> contains:

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

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

packet from sending unencrypted notification v2N_INVALID_MESSAGE_ID to
| 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 15:49:57 EST
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 05:21:43 EST
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.


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