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?
If they're both well-defined and secure, I don't see any reason to add
this limitation.
After all, we do have much weirder algorithms in the registry.
Thanks,
Yaron
On 01/17/2013 07:03 PM, Tero Kivinen wrote:
I got question now about the values allocated for the "IKEv2 in the
Fibre Channel Security Association Management Protocol" and their use
in the normal IPsec use over IP. This question was about support for
AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 for IPsec over IP, instead of
using the normal AUTH_HMAC_MD5_96 and AUTH_HMAC_SHA1_96 values
everybody in IP world are using. When those values were allocated it
was assumed that they were only to be used in the FC world.
I noticed that when all other RFC4595 allocated numbers have FC_ in
their names, but these AUTH_* does not have those. Also there is
nothing that explictly forbid their use in the IKEv2/ESP over IP, it
has been implicit because there is nothing that says they can be used
in the IP world either.
One of the reasons for these is that this allocation happened when we
had this process flaw and those drafts never came to the IANA expert
for review (i.e. to me), so I only did some early comments to their
-00 draft, and then later noticed that the values had been added to
the registry.
To clear up this confusion, I would like to add note to the IANA table
saying "Only for Fibre Channel use" for those two values.
Does anybody have any objections for doing that?
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
