IETF Logo Mail Archive

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

"Frankel, Sheila E." <sheila.frankel@nist.gov> Tue, 27 October 2009 15:45 UTC

Return-Path: <sheila.frankel@nist.gov>
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 5270428C0F0 for <ipsec@core3.amsl.com>; Tue, 27 Oct 2009 08:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.413
X-Spam-Level:
X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 dR58XB398K8d for <ipsec@core3.amsl.com>; Tue, 27 Oct 2009 08:45:54 -0700 (PDT)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 0B8C028C0D6 for <ipsec@ietf.org>; Tue, 27 Oct 2009 08:45:53 -0700 (PDT)
Received: from WSXGHUB2.xchange.nist.gov (wsxghub2.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9RFjm5O026636; Tue, 27 Oct 2009 11:45:48 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([2002:8106:1213::8106:1213]) with mapi; Tue, 27 Oct 2009 11:45:44 -0400
From: "Frankel, Sheila E." <sheila.frankel@nist.gov>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: Tue, 27 Oct 2009 11:43:56 -0400
Thread-Topic: [ipsecme] #112: Truncation of SHA-1 ICVs
Thread-Index: AcpOwGbAVkrZyzZSQZGKZLAJ1o3RqgIW+ROR
Message-ID: <D7A0423E5E193F40BE6E94126930C4930789878B74@MBCLUSTER.xchange.nist.gov>
References: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org>
In-Reply-To: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: sheila.frankel@nist.gov
Cc: Tero Kivinen <kivinen@iki.fi>, Paul Hoffman <paul.hoffman@vpnc.org>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>
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: Tue, 27 Oct 2009 15:45:55 -0000

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

v2.23.0 | Report a Bug | By Email