Re: [IPsec] IANA ikev2 registry and FC values

[Tero Kivinen <[e-mail]>]

Yaron Sheffer writes:
> Actually, why? At first sight they look entirely reasonable to me 
> (untruncated versions of MAC, where we usually truncate). Are you saying 
> they are not well defined?

I do not think they offer anything compared to the truncated versions,
i.e. it just adds a 2nd way to do exactly same thing with no clear
reason.

Note that RFC2104 section 5 says that there are some advantages of
truncating the output of the hash-based MAC functions (even though the
results are not absolute).

> If they're both well-defined and secure, I don't see any reason to add 
> this limitation.

They are not defined for IP use at all. None of the IKEv2/ESP over IP
uses those values. Ah, found text from our IPsec/IKE Roadmap:

		   For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry
   contains values for both the truncated version and the standard non-
   truncated version; thus, IKEv2 has the capability to negotiate either
   version of the algorithm.  However, only the truncated version is
   used for IKEv2 SAs and for IPsec SAs.  The non-truncated version is
   reserved for use by the Fibre Channel protocol [RFC4595].  For the
   other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC-
   RIPEMD), only the truncated version can be used for both IKEv2 and
   IPsec-v3 SAs.

which actually says we always use truncated version (so I was wrong
they are not forbidden anywhere, missed this text last time as it uses
SHA-1 spelling not SHA1, which I was searching for :-).

> After all, we do have much weirder algorithms in the registry.

That is true, and I do not consider that as a good thing. It is much
better to have one good way of doing things than two ways of doing
same thing, especially if those two ways are about the same.
-- 
[e-mail]