[strongSwan] AH Transport AES-128 GMAC
gyula.kovacs.kkb.tech at gmail.com
Fri Nov 11 08:28:21 CET 2016
Thank you very much for your help and detailed description.
I checked the responder's daemon.log, and found the the same error
messages you've mentioned.
I think, our customer will accept this fact and will choose a different
integrity algorithm or switch to ESP.
On 2016.11.10. 19:08, Tobias Brunner wrote:
> Hi Gyula,
>> I'm running the test between two identical Debian 8.6 VMs.
>> Both have the same version of strongSwan (v5.5.1), compiled withe the
>> same switches.
> I was able to reproduce this in our testing environment. On the
> responder you should have seen the following messages:
>> [CHD] no keylength defined for AES_128_GMAC
>> [IKE] unable to install inbound and outbound IPsec SA (SAD) in kernel
> These are caused because for AES-GMAC the key length is not explicitly
> encoded in the proposal, instead each length has its own identifier
> (compared to ESP with AES-GCM or NULL-AES-GMAC where there is only one
> identifier and the key length is transmitted). But when deriving keys
> we currently don't map these identifiers back to the required key length.
> Another issue is that the kernel-netlink plugin currently doesn't map
> these identifiers to algorithm names either, so the plugin isn't able to
> install the SAs after deriving the keys.
> However, as it turns out, the Linux kernel can't actually be configured
> to use AES-GMAC with AH, only with ESP. So what you want to do is
> currently not possible at all.
> If you are not dead set on using AH you could use esp=aes128gmac
> instead, to configure ESP with NULL encryption and AES-GMAC authentication.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users