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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
