Looks good to me. Section 1 says: "Doubled the preferred key size of KMAC128 and KMAC256" This was only done for PRF_ not AUTH_
>We could put in an explicit notice saying "we don't recommend using the AUTH >transforms alongside encryption where an AEAD algorithm could be used >instead", if that would be preferable? I don't think that should be added for two reasons: 1. Like 3G/4G/5G and unlike TLS and SSH, ESP has secure composition of ENCR and AUTH algorithms. 2. AUTH_KMAC_128 offers stronger integrity than the registered AEAD algorithms. As far as we know, the integrity of AUTH_KMAC is only limited by the key size and otherwise behaves like an ideal MAC. This is not true for the registered AEADs: -- Poly1305 provides 103 bit - log(l) bits integrity -- GCM only provides tag length - log(l) bits integrity and 0 bits integrity after a forgery. Also, GCM in IPSEC is not referring to SP 800-38D, so some implementations might not be following all NIST requirements. -- CCM_16 has an integrity advantage that is cubic in the number of queries. -- CCM_8 only provides 64-bit integrity, but otherwise behaves like an ideal MAC (up to key size). Cheers, John From: Ben S3 <[email protected]> Date: Thursday, 29 January 2026 at 09:54 To: [email protected] <[email protected]> Subject: [IPsec] Re: I-D Action: draft-ietf-ipsecme-sha3-01.txt OFFICIAL Hi IPsec! We've just published draft-ietf-ipsecme-sha3-01. This version aligns the draft more closely with draft-ietf-ipsecme-ikev2-prf-plus-00: * Rather than integrating KMAC into prf+, we've replaced prf+ entirely with a single KMAC call, which simplifies the design. * We've doubled KMAC's preferred key sizes to be the same as the default PRF output length, hence aligning it with the corresponding HMAC of the same strength (but see point 2 below) There are a couple of points we'd like the WG's opinion on - these are highlighted as EDNOTEs in the draft, but are elaborated below: 1) KMAC supports use of customisation strings, and this draft makes use of them to provide separation between the IKE context and the ESP/AH context. There seemed to be some interest in the room at IETF 123 for this approach. The concern is that without use of customisation strings, the same PRF output could be derived in different contexts. For instance, consider the following derivations of SKEYSEED (following a rekey), and of KEYMAT (generated in a CREATE_CHILD_SA): SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr) When using KMAC, prf and prf+ are identical, hence if asking for the same amount of key material, given the same inputs these would produce the same outputs. This is unlikely to manifest as an actual problem since the second input should be different, but it feels prudent to try to prevent this sort of thing entirely. As it stands, this is a deviation from draft-ietf-ipsecme-ikev2-prf-plus. Do we want to keep the customisation strings? 2) We've doubled the KMAC key sizes when used as a PRF, again to align with draft-ietf-ipsecme-ikev2-prf-plus which specifies that the preferred key size must match the output length of the PRF. It may be possible to halve both the output length and key size, and instead have KMAC128 use a 128-bit key and output 128 bits, though we'd need to check that IKE/IPsec never rely on the PRF having collision resistance. 3) We've included the option to use KMAC/SHAKE as an AUTH transform. Typically, the preferable thing to do would be to use an AEAD algorithm instead of having separate encryption and authentication algorithms, but there are some use cases for authenticated communication without encryption via ENCR_NULL (or AH, but ENCR_NULL is preferred by RFC 8221). RFC 8221 also alludes to IoT use cases where AEAD algorithms might be undesirable if they need to track state to prevent nonce reuse. We could put in an explicit notice saying "we don't recommend using the AUTH transforms alongside encryption where an AEAD algorithm could be used instead", if that would be preferable? Best, Ben, Adam, and Jonathan OFFICIAL -----Original Message----- From: [email protected] <[email protected]> Sent: 29 January 2026 08:46 To: [email protected] Cc: [email protected] Subject: [IPsec] I-D Action: draft-ietf-ipsecme-sha3-01.txt Internet-Draft draft-ietf-ipsecme-sha3-01.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: Use of SHA-3 in the Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec Authors: Ben Salter Adam Raine Jonathan Cruickshanks Name: draft-ietf-ipsecme-sha3-01.txt Pages: 32 Dates: 2026-01-29 Abstract: This document specifies the use of KMAC128 and KMAC256 within the Internet Key Exchange Version 2 (IKEv2), Encapsulating Security Payload (ESP), and Authentication Header (AH) protocols. These algorithms can be used as integrity protection algorithms for ESP, AH and IKEv2, and as Pseudo-Random Functions (PRFs) for IKEv2. Requirements for supporting signature algorithms in IKEv2 that use SHA3-256, SHA3-384, SHA3-512, SHAKE128 and SHAKE256 are also specified. The IETF datatracker status page for this Internet-Draft is: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ipsecme-sha3%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C77e40c7d571147e75dc708de5f13f27f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639052736436648092%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OMx42sCDd9xUhBKrpBFaYjg5dVNNHYstI61ow%2FmsK9w%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-ipsecme-sha3/> There is also an HTMLized version available at: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ipsecme-sha3-01&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C77e40c7d571147e75dc708de5f13f27f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639052736436661772%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Tabbs2Nu9%2BDnvPdklXE5HdORkHUgR8HwsXgEY%2BftBwM%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-sha3-01> A diff from the previous version is available at: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-ipsecme-sha3-01&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C77e40c7d571147e75dc708de5f13f27f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639052736436671030%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0mMGBVDZqQtfVXFykPUC9jujjI7ylwmx2tRz%2BfSQ%2BEU%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-sha3-01> Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
