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

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:smoonen@us.ibm.com]
Sent: Tuesday, October 27, 2009 12:17 PM
To: Frankel, Sheila E.
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; Tero Kivinen; Paul Hoffman; suresh.krishnan@ericsson.com
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.

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:

"Frankel, Sheila E." <sheila.frankel@nist.gov>

To:

"ipsec@ietf.org" <ipsec@ietf.org>

Cc:

Tero Kivinen <kivinen@iki.fi>, Paul Hoffman <paul.hoffman@vpnc.org>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>

Date:

10/27/2009 11:46 AM

Subject:

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

________________________________

#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 [trac@tools.ietf.org]
Sent: Friday, October 16, 2009 8:25 PM
To: paul.hoffman@vpnc.org; 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/>

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