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

From: "Frankel, Sheila E." <[email-masked]>
Date: Tue, 27 Oct 2009 11:43:56 -0400

#112: Truncation of SHA-1 ICVs

Proposed change to Roadmap doc:

Add text to Section 5.3 (Integrity-Protection Algorithms)

Current text:
   The integrity-protection algorithm RFCs describe how to use these
   algorithms to authenticate IKE and/or IPsec traffic, providing
   integrity protection to the traffic.  This protection is provided by
   computing an Integrity Check Value (ICV), which is sent in the
   packet.  The RFCs describe any special constraints, requirements, or
   changes to packet format appropriate for the specific algorithm.  In
   general, they do not describe the detailed algorithmic computations;
   the reference section of each RFC includes pointers to documents that
   define the inner workings of the algorithm.  Some of the RFCs include
   sample test data, to enable implementors to compare their results
   with standardized output.

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

________________________________________
From: ipsecme issue tracker [[email-masked]]
Sent: Friday, October 16, 2009 8:25 PM
To: [email-masked]; Frankel, Sheila E.
Subject: [ipsecme] #112: Truncation of SHA-1 ICVs

#112: Truncation of SHA-1 ICVs
-----------------------------------+----------------------------------------
 Reporter:  paul.hoffman@…         |       Owner:  sheila.frankel@…
     Type:  defect                 |      Status:  new
 Priority:  normal                 |   Milestone:
Component:  roadmap                |    Severity:  -
 Keywords:                         |
-----------------------------------+----------------------------------------
 In RFC 2404, it mentions that SHA-1 ICVs are truncated to 96 bits for
 IPsec.  We should also mention in Section 5.3 that this truncation is done
 for IKEv2 as well. Same for RFC 2403. Text is needed.

--
Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/112>
ipsecme <http://tools.ietf.org/ipsecme/>

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 27 Oct 2009 12:17:26 -0400

Hi Sheila,

1) I don't think we can expand the registry to include non-truncated 
versions of HMAC-SHA2-*.  RFC 4868 stipulates for IKE and IPsec in general 
that the authenticator length "is always half the output length of the 
underlying hash algorithm."

2) RFCs 3566, 4494 are worded a bit more permissively for AES-XCBC and 
AES-CMAC, so perhaps there's some wiggle room there.

3) I'm not sure if HMAC-RIPEMD is defined for use in IKE (there is not 
even an algorithm identifier for IKEv2), but its use for AH and ESP (RFC 
2857) currently only defines a truncated form of the algorithm.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
"Frankel, Sheila E." <[email-masked]>
To:
"[email-masked]" <[email-masked]>
Cc:
Tero Kivinen <[email-masked]>, Paul Hoffman <[email-masked]>, 
"[email-masked]" <[email-masked]>
Date:
10/27/2009 11:46 AM
Subject:
Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs

Current text:

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.  For the other algorithms (AES-XCBC, 

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?

 IPsec.  We should also mention in Section 5.3 that this truncation is 
done

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Frankel, Sheila E." <[email-masked]>
Date: Tue, 27 Oct 2009 13:30:45 -0400

Thanks, Scott. So is the general consensus that we should just leave HMAC-SHA-1 and HMAC-MD5 as the only algs for which IKEv2 can negotiate either a truncated or non-truncated version?

Your comment also reminded me that RFCs 2404 (HMAC-SHA-1) and 2403 (HMAC-MD5) require truncated ICVs for IPsec. So I guess I should change the new text to only allow IKEv2 to use both versions for its own SAs, but not for IPsec SAs.

Sheila

________________________________
From: Scott C Moonen [mailto:[email-masked]]
Sent: Tuesday, October 27, 2009 12:17 PM
To: Frankel, Sheila E.
Cc: [email-masked]; [email-masked]; Tero Kivinen; Paul Hoffman; [email-masked]
Subject: Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs

Hi Sheila,

1) I don't think we can expand the registry to include non-truncated versions of HMAC-SHA2-*.  RFC 4868 stipulates for IKE and IPsec in general that the authenticator length "is always half the output length of the underlying hash algorithm."

2) RFCs 3566, 4494 are worded a bit more permissively for AES-XCBC and AES-CMAC, so perhaps there's some wiggle room there.

3) I'm not sure if HMAC-RIPEMD is defined for use in IKE (there is not even an algorithm identifier for IKEv2), but its use for AH and ESP (RFC 2857) currently only defines a truncated form of the algorithm.

From:

To:

Cc:

Tero Kivinen <[email-masked]>, Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>

Date:

10/27/2009 11:46 AM

Subject:

________________________________

Current text:

Additional text:

Reporter:  paul.hoffman@...         |       Owner:  sheila.frankel@...

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Oct 2009 13:43:24 +0200

Frankel, Sheila E. writes:
>    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, 
> 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... 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Wed, 28 Oct 2009 13:33:25 -0400

Tero and Sheila,

> The AUTH_HMAC_MD5_128 and
> AUTH_HMAC_SHA1_160 are really only specified when used with Fibre

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.

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

> but for IPsec if you want to have longer MAC, use longer HMAC-SHA-2

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tero Kivinen
> Sent: Wednesday, October 28, 2009 7:43 AM
> To: Frankel, Sheila E.
> Cc: [email-masked]; Paul Hoffman; [email-masked]
truncated 
truncated. 

contains