[strongSwan] AH Transport AES-128 GMAC

[Gyula Kovács]

Hi Tobias,

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.

Best regards,
Gyula


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.
>
> Regards,
> Tobias
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20161111/7cc04dbc/attachment-0001.html>