Created attachment 587532 [details]
openswan patch to support aes-gcm with esp

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.

We are shipping libreswan, not openswan, in RHEL7.  Moving component.  Switching back to ASSIGNED.  Paul, can you verify and attach to RHEL7 errata?

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.

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.

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.

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.

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).

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@10.34.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.

Yes, you are hitting the AES_GCM kernel bug https://bugzilla.redhat.com/show_bug.cgi?id=1176266

please use kernel package -224.el7

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