Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs
Tero Kivinen <kivinen@iki.fi> Wed, 28 October 2009 11:43 UTC
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161E228C10D for <ipsec@core3.amsl.com>; Wed, 28 Oct 2009 04:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.407
X-Spam-Level:
X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VW7e6eOmTPg for <ipsec@core3.amsl.com>; Wed, 28 Oct 2009 04:43:19 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A9DE228C0FE for <ipsec@ietf.org>; Wed, 28 Oct 2009 04:43:17 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n9SBhPRg012902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 13:43:25 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n9SBhOY1012066; Wed, 28 Oct 2009 13:43:24 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19176.11868.510064.595988@fireball.kivinen.iki.fi>
Date: Wed, 28 Oct 2009 13:43:24 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Frankel, Sheila E." <sheila.frankel@nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930789878B74@MBCLUSTER.xchange.nist.gov>
References: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org> <D7A0423E5E193F40BE6E94126930C4930789878B74@MBCLUSTER.xchange.nist.gov>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 9 min
X-Total-Time: 10 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>
Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 28 Oct 2009 11:43:21 -0000
Frankel, Sheila E. writes: > Additional text: > Some of these algorithms generate a fixed-length ICV, which is truncated > when it is included in an IPsec-protected packet. For example, standard > HMAC-SHA-1 generates a 160-bit ICV, which is truncated to 96 bits when it > is used to provide integrity-protection to an ESP or AH packet. The > individual RFC descriptions mention those algorithms that are truncated. > When these algorithms are used to protect IKEv1 SAs, they are not > truncated. 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 to > protect IKEv2 and/or IPsec-v3 SAs. This is not completely correct. The non-truncated versions are not meant to be used with normal IPsec-v2/v3. They are meant to be used with Fibre Channel Security (RFC4595). The AUTH_HMAC_MD5_128 and AUTH_HMAC_MSHA1_160 are really only specified when used with Fibre Channel CT_Authentication format instead of ESP format. Even when using fibre channel if ESP format is used then I think you must use the truncated versions. Here is some cut & paste parts of RFC4595 to explain situation: ---------------------------------------------------------------------- 2. Overview Fibre Channel defines two security protocols that provide security services for different portions of Fibre Channel traffic: the ESP_Header defined in [FC-FS] and CT_Authentication defined in [FC-GS-4]. The ESP_Header protocol is a transform applied to FC-2 Fibre Channel frames. It is based on the IP Encapsulation Security Payload [RFC4303] to provide origin authentication, integrity, anti-replay protection, and optional confidentiality to generic fibre channel frames. The CT_Authentication protocol is a transform that provides the same set of security services for Common Transport Information Units, which are used to convey control information. As a result of the separation of Fibre Channel data traffic from control traffic, only one protocol (either ESP_Header or CT_Authentication) is applicable to any FC Security Association (SA). ... Since IP is transported over Fibre Channel [RFC4338] and Fibre Channel/SCSI are transported over IP [RFC3643], [RFC3821] there is the potential for confusion when IKEv2 is used for both IP and FC traffic. This document specifies identifiers for IKEv2 over FC in a fashion that ensures that any mistaken usage of IKEv2/FC over IP will result in a negotiation failure due to the absence of an acceptable proposal (and likewise for IKEv2/IP over FC). This document gives an overview of the security architecture defined by the FC-SP standard, including the security protocols used to protect frames and to negotiate SAs, and it specifies the entities for which new identifiers have been assigned. ... 3.2. CT_Authentication Protocol CT_Authentication is a security protocol for Common Transport FC-4 Information Units that provides origin authentication, integrity, and anti-replay protection. The CT_Authentication protocol is carried in the optional extended CT_IU preamble ... The Authentication Hash Block is computed as an HMAC keyed hash of the CT_IU, as defined in [RFC2104]. The entire output of the HMAC computation is included in the Authentication Hash Block, without any truncation. Two transforms are defined: HMAC-SHA1-160 that is based on the cryptographic hash function SHA1 [NIST.180-1.1995], and HMAC-MD5-128 that is based on the cryptographic hash function MD5 [RFC1321]. ... 4.3. CT_Authentication Protocol Transform Identifiers The CT_Authentication Transform IDs defined for Transform Type 3 (Integrity Algorithm) are: Name Number Defined in ---- ------ ---------- AUTH_HMAC_MD5_128 6 FC-SP AUTH_HMAC_SHA1_160 7 FC-SP These transforms differ from the corresponding _96 transforms used in IPsec solely in the omission of the truncation of the HMAC output to 96 bits; instead, the entire output (128 bits for MD5, 160 bits for SHA-1) is transmitted. MD5 support is required due to existing usage of MD5 in CT_Authentication; SHA-1 is RECOMMENDED in all new implementations. ... ---------------------------------------------------------------------- So AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 cannot be used in IPsec, but they have the numbers in the IKEv2 registry, as they are negotiated for their CT_Authentication use using IKEv2. > 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. > > NOTE to Tero, Paul, Yaron: do we want to expand the IKEv2 IANA > registry to include non-truncated AES-XCBC-MAC, > HMAC-SHA-256/384/512, AES-CMAC and HMAC-RIPEMD? Not for IPsec use. I do not know if the Fibre Channel people want to use non-truncated versions of them in their CT_Authentication format, but for IPsec if you want to have longer MAC, use longer HMAC-SHA-2 variant... -- kivinen@iki.fi
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Frankel, Sheila E.
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Scott C Moonen
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Frankel, Sheila E.
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Tero Kivinen
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Black_David