[Bug 263379] [regression] [ipsec] compatibility broken between stable/12 and stable/13 opencrypto in AEAD mode

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 18 Apr 2022 16:51:58 UTC

--- Comment #1 from John Baldwin <jhb@FreeBSD.org> ---
To be clear, what do you think using AES-GCM with a separate SHA-512 HMAC
should do?  From the RFCs I have read, there is no defined standard for using a
separate MAC with an AEAD cipher.  For example, in the combinations listed in
section 4 of RFC 8221, there is no defined method for combining a distinct MAC
with an AEAD cipher.

About the best I could imagine is that perhaps you intend to use AES-GCM with
an ESP header and then a separate SHA-512 HMAC with an AH header?  I can find
no mention anywhere of such a construct for IPsec, and the closest thing I can
find (using a non-AEAD cipher with ESP and a separate MAC with AH) is
deprecated in RFC 8221 (the recommended approach is to use the non-AEAD cipher
and MAC together as a combined ETA cipher with ESP, e.g. AES-CBC+SHA-512-HMAC).

I suspect the fact that stable/12 does not fail this is probably a weird bug
due to lack of argument validation in stable/12, and it is probably putting
packets on the wire that no other OS can handle (perhaps it is basically using
the AES-CTR side of AES-GCM but with the IV for AES-CTR constructed using
AES-GCM rules and then generating the SHA-512 HMAC using ETA rules).  That is,
I suspect what you kind of have is a broken, non-standard version of AES-CTR +
SHA-512 HMAC (which is a defined combined algorithm you can use).  But really
you are better of just using stock AES-GCM anyway and using GMAC rather than

Your changes to OCF are all incorrect.  If you want to combine AES-GCM with a
separate HMAC, you would need to construct separate crypto sessions and crypto
requests for a given buffer, the first to do AES-GCM and the second to deal
with the HMAC.

You are receiving this mail because:
You are on the CC list for the bug.