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: <Black_David_at_nospam>
Date: Wed Oct 28 2009 - 17:33:25 GMT
To: <kivinen@iki.fi>, <sheila.frankel@nist.gov>


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



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec