160 Need to be able to negotiate for SHA384 as part of GDOI

Created: 12 Mar 2026

Status: Analysis Of Compatibility

Part: Part 9 (2023, Edition2)

Links:

Page: 92

Clause: 8.5.7

Paragraph: b

Issue

With SHA256 being deprecated in the near future, we need to add the ability to negotiate and provide HASH/Signature functions based on SHA384.

Note: SHA384 is already supported in TransferSets per RFC 6407 but not in RFC 8052. RFC 8052 does not list SHA384 as a valid authentication mechanism (clause 2.2.2).

Proposal

Add SHA384 to the allowed list and add a note that it is being added in addition to the Authentication Algorithms identified in RFC 8052.

Discussion	Created	Status
No compatibility issues expected, as new registered values are used to signal SHA384 and SHA512	22 Sep 26	Analysis Of Compatibility
Additional Hash values for SHA384 (6) and SHA512 (7) enabled as defined in IANA registry: https://www.iana.org/assignments/gdoi-payloads#iec62351-9-authentication-values	22 Sep 26	Verify Draft Implementation
Proposed update to the description in clause 8.5.7 bullet b) (see attachment)	16 Jul 26	Drafting Implementation
RFC 6407, Section 5.6.1.2 states: "HMAC-SHA2 and AES-GMAC keys will have a key length equal to the output length of the hash functions [RFC4868] [RFC4543]." This appears to support AUTH_KEY lengths of 48 octets for HMAC-SHA-384 and 64 octets for HMAC-SHA-512.	09 Jul 26	Drafting Implementation
Going forward with draft implementation to better foster support in implementations. Assumption is that future improvement may delay adoption although the technical approach is clear. I case of disagreement we can go back to discussion.	07 Jul 26	Drafting Implementation
I agree with draft implementation. I don't believe our process allows skipping the step.	07 Jul 26	Discussion (red)
I contacted IANA regarding the addition of the two authentication values in the IANA registry on July 3, 2026. The two values - HMAC-SHA-384=6 - HMAC-SHA-512=7 have been added in July 07 after expert review: https://www.iana.org/assignments/gdoi-payloads/gdoi-payloads.xhtml#iec62351-9-authentication-values. Do we close this tissue as future improvement or do we proceed to draft implementation? I would propose draft implementation.	07 Jul 26	Discussion (red)
Yes, independence of AUTH and ENCR key lengths was one intent. The additional intent is deterministic AUTH_KEY sizing tied to the selected HMAC algorithm to avoid interoperability differences and silent reduction of authentication strength relative to the selected algorithm.	23 Jun 26	Discussion (red)
I understand the proposal as clarification of the independence of the key length values for authentication and encryption. We do not have that for current possible combinations like AS-CBC-128 and HAMC-SHA-256. So if necessary we should add it to avoid interoperability problems. The question regarding the specification of the OIDs (RFC 8052 update or IEC 62351-9) still remains open and needs clarification. Possibilities have been identified by Brian Weiss (one RFC 8052 author) regarding IANA registration, but the final determination is pending.	19 Jun 26	Discussion (red)
That should have read as HMAC-SHA-256 -> 32 octets and the same for the other "?" in the comment	19 Jun 26	Discussion (red)
Proposed Tissue 160 Clarification – Authentication Key Length For HMAC-based authentication algorithms, the AUTH_KEY length shall be independent of the selected encryption algorithm and shall be determined solely by the selected HMAC hash algorithm. The AUTH_KEY length shall match the output length of the selected hash function: * HMAC-SHA-256 ? AUTH_KEY = 32 octets * HMAC-SHA-384 ? AUTH_KEY = 48 octets * HMAC-SHA-512 ? AUTH_KEY = 64 octets The ENCR_KEY length remains determined by the selected encryption algorithm (e.g. AES-CBC-128 ? 16 octets, AES-CBC-256 ? 32 octets) and shall not constrain or determine the AUTH_KEY length. This clarification is intended to ensure interoperable behavior when combining AES-CBC-128/256 with HMAC-SHA-384/512 and to avoid implementations deriving authentication key sizes from encryption key sizes.	19 Jun 26	Discussion (red)
By double checking RFC 8052, section 4 (IANA considerations), there are tables defining values for authentication and confidentiality protection. These values may be enhanced in two different ways: Updating RFC 8052 would allow to add authentication values for - HMAC-SHA-384=6 - HMAC-SHA-512=7 This requires to do a revision of the RFC, so best to engage the previous authors. Alternatively, IEC 62351-9 could use the private number space to add authentication values for - HMAC-SHA-384=61440 - HMAC-SHA-512=61441 As RFC 8052 may not be used outside our domain a clash in the private number space is not likely. Note that PQC algorithms may not be added as GDOI is not further developed and implementers are asked to utilize G-IKEv2 (which bases on IKEv2), which is further advanced in the IPSECME WG of the IETF.	27 Apr 26	Discussion (red)
Yes, would be fine from my understanding. The question would be if this is to be handled as future improvement as it does not fix an interop problem	07 Apr 26	Discussion (red)
For the addition of 384 and 512, I recommend that the values of HMAC-SHA-384=6, HMAC-SHA-512=7 and we note these additions in 62351-9 as extensions to RFC 8052	07 Apr 26	Discussion (red)
To be more future proof, in addition also SHA-512 may be added. The text for "f" in the numbered list in section 8.5.7 would then be enhanced from "Auth Alg (2 octets) – Authentication Algorithm ID. Valid values are defined in RFC 8052, section 2.2.2. HMAC-SHA256-128 is mandatory. In addition, this document also requires support for HMAC-SHA256, AES-GMAC-128, and AES-GMAC-256." to "Auth Alg (2 octets) – Authentication Algorithm ID. Valid values are defined in RFC 8052, section 2.2.2. HMAC-SHA256-128 is mandatory. In addition, this document also requires support for HMAC-SHA256, AES-GMAC-128, and AES-GMAC-256. In addition to the values defined for Authentication Algorithms in RFC 8052 the following additional algorithms shall be supported: HMAC-SHA-384 and HMAC-SHA-512."	12 Mar 26	Discussion (red)
Accepted to be addressed	12 Mar 26	Accepted

Privacy | Contact | Disclaimer

Tissue DB v. 25.7.7.1