Re: [IPsec] IANA ikev2 registry and FC values

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 17 January 2013 17:48 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5B221F8611 for <ipsec@ietfa.amsl.com>; Thu, 17 Jan 2013 09:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaP7oVgCQ87C for <ipsec@ietfa.amsl.com>; Thu, 17 Jan 2013 09:48:10 -0800 (PST)
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4521F85AF for <ipsec@ietf.org>; Thu, 17 Jan 2013 09:48:10 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id gw10so2112904lab.41 for <ipsec@ietf.org>; Thu, 17 Jan 2013 09:48:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NfNaAiO2ApVK/o7nk84Hujeqr+TLbL01ygjP7v/JlnY=; b=u2WVK3yi3KyQf7KwAnk8cfjHRlcpRo/yhkUnQxtMQsWEmTv5sk6HyuZkiDl2DoLomg 0ZS6z3RZnhExO+mnwqevB9irVWUnlcYnHqfKOYNH4yEeqfsWtV45FuLH34KQaT/J4FkF oltE5K7tbss1GFzwuBB4zBMRMnGqWNgRrJJLfZVzKaOfvIgeT/FIckRxie3XiZd3zDYr vdgFyJG/XACHG0UEH/WS8b/QJQl64MKXZvPWhn8TfOv1853hbgnl8NFsjnTzAZaISc/Q XL3+lHuUSvF5Ino/f5XEyBtXQAdAx4bxwwJKUIbmqa1flnHRdiUKPj1gJHWle0Ru2nu+ Vr9g==
X-Received: by 10.152.113.6 with SMTP id iu6mr5695637lab.43.1358444889182; Thu, 17 Jan 2013 09:48:09 -0800 (PST)
Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id b3sm1140318lbl.0.2013.01.17.09.48.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 09:48:07 -0800 (PST)
Message-ID: <50F83953.9060003@gmail.com>
Date: Thu, 17 Jan 2013 19:48:03 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
References: <20728.12021.834751.712756@fireball.kivinen.iki.fi> <50F8313C.60204@gmail.com> <20728.14111.293749.62984@fireball.kivinen.iki.fi>
In-Reply-To: <20728.14111.293749.62984@fireball.kivinen.iki.fi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ipsec@ietf.org
Subject: Re: [IPsec] IANA ikev2 registry and FC values
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jan 2013 17:48:11 -0000

Hi Tero,

please see below.

Thanks,
	Yaron

On 01/17/2013 07:38 PM, Tero Kivinen wrote:
> 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.

Whether they're adding anything or not is for cryptographers to say. 
Sec. 5 of RFC 2104 is very equivocal about this.

OTOH your proposal would mean one more difference between "regular" 
IPsec implementations and FC-specific ones. I don't think that would be 
a good thing.

>
> 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).

See above.

>
>> 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 :-).
>

This text is simply describing the existing situation. It is not at all 
normative.

>> 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.
>

Yes, but people have good reasons to add algorithms, which is (part of 
the reason) why we negotiate them in the protocol. Thus "Tiger", 
"camellia" and the like, and I'm sure the FC folks had a good reason for 
the untruncated algorithms, too.