ipsec October 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs

Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs

From: Tero Kivinen <kivinen_at_nospam>
Date: Wed Oct 28 2009 - 11:43:24 GMT
To: "Frankel, Sheila E." <sheila.frankel@nist.gov>


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