Re: [IPsec] IANA ikev2 registry and FC values

Tero Kivinen <> Thu, 17 January 2013 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16C7321F866D for <>; Thu, 17 Jan 2013 09:38:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Ll-3J2ylwyZ for <>; Thu, 17 Jan 2013 09:38:46 -0800 (PST)
Received: from ( [IPv6:2001:1bc8:100d::2]) by (Postfix) with ESMTP id 38FFE21F8798 for <>; Thu, 17 Jan 2013 09:38:46 -0800 (PST)
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id r0HHceur002971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 19:38:40 +0200 (EET)
Received: (from kivinen@localhost) by (8.14.5/8.12.11) id r0HHcdPF026125; Thu, 17 Jan 2013 19:38:39 +0200 (EET)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Thu, 17 Jan 2013 19:38:39 +0200
From: Tero Kivinen <>
To: Yaron Sheffer <>
In-Reply-To: <>
References: <> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 14 min
X-Total-Time: 14 min
Subject: Re: [IPsec] IANA ikev2 registry and FC values
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Jan 2013 17:38:47 -0000

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

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.