Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs
<Black_David@emc.com> Wed, 28 October 2009 17:33 UTC
Return-Path: <Black_David@emc.com>
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 E9E313A6A20 for <ipsec@core3.amsl.com>; Wed, 28 Oct 2009 10:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.274
X-Spam-Level:
X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 h8v-82+RtD1c for <ipsec@core3.amsl.com>; Wed, 28 Oct 2009 10:33:26 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 134083A6A25 for <ipsec@ietf.org>; Wed, 28 Oct 2009 10:33:25 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n9SHXeKU012686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 13:33:40 -0400
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 28 Oct 2009 13:33:28 -0400
Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.166.44]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n9SHXPMI024196; Wed, 28 Oct 2009 13:33:27 -0400
Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:33:25 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 28 Oct 2009 13:33:25 -0400
Message-ID: <9FA859626025B64FBC2AF149D97C944A0421E50A@CORPUSMX80A.corp.emc.com>
In-Reply-To: <19176.11868.510064.595988@fireball.kivinen.iki.fi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs
Thread-Index: AcpXw+zWtOIPF675SVaJKzIX42VvzQALvU3A
References: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org><D7A0423E5E193F40BE6E94126930C4930789878B74@MBCLUSTER.xchange.nist.gov> <19176.11868.510064.595988@fireball.kivinen.iki.fi>
From: Black_David@emc.com
To: kivinen@iki.fi, sheila.frankel@nist.gov
X-OriginalArrivalTime: 28 Oct 2009 17:33:25.0617 (UTC) FILETIME=[C1100610:01CA57F4]
X-EMM-EM: Active
Cc: ipsec@ietf.org
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 17:33:28 -0000
Tero and Sheila, > The AUTH_HMAC_MD5_128 and > AUTH_HMAC_SHA1_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. That is correct for Fibre Channel. If someone wants to use the non-truncated versions of these with conventional IPsec, there's no specification barrier to doing so, but I don't think this has or is likely to be implemented. FWIW, I concur with Tero's suggestion to look to the HMAC-SHA2 family for longer IPsec MACs. > 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. I wouldn't say "cannot be used" - "are not used" is more accurate. The potentially related discussion about separate identifiers: > 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). is primarily about the Security Protocol Identifiers and the Traffic Selector Type - RFC 4595 defines FC-only values for these that any IPsec implementation will quickly reject; see the IANA Considerations (Section 6) of RFC 4595. > > 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... I would expect to see at least a non-truncated versions of HMAC-SHA2-256 show up when the Fibre Channel specifications are updated, but I think we (IETF) can wait for that (i.e., no registry changes needed now). Thanks, --David (RFC 4595 co-author) > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Tero Kivinen > Sent: Wednesday, October 28, 2009 7:43 AM > To: Frankel, Sheila E. > Cc: ipsec@ietf.org; Paul Hoffman; suresh.krishnan@ericsson.com > Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs > > 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 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > >
- 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