Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 ICVs
Scott C Moonen <smoonen@us.ibm.com> Tue, 27 October 2009 16:17 UTC
Return-Path: <smoonen@us.ibm.com>
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 5CAC53A6A2D; Tue, 27 Oct 2009 09:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kORTEuz1sc5C; Tue, 27 Oct 2009 09:17:25 -0700 (PDT)
Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id DA9D53A6843; Tue, 27 Oct 2009 09:17:24 -0700 (PDT)
Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e38.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9RGDCPV018476; Tue, 27 Oct 2009 10:13:12 -0600
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9RGHR0t059142; Tue, 27 Oct 2009 10:17:28 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9RGG5rv026417; Tue, 27 Oct 2009 10:16:05 -0600
Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9RGG4Mm026409; Tue, 27 Oct 2009 10:16:04 -0600
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930789878B74@MBCLUSTER.xchange.nist.gov>
References: <063.b5b9a33677a51644c2c934555b3fe9c6@tools.ietf.org> <D7A0423E5E193F40BE6E94126930C4930789878B74@MBCLUSTER.xchange.nist.gov>
To: "Frankel, Sheila E." <sheila.frankel@nist.gov>
MIME-Version: 1.0
X-KeepSent: 45C3484B:96202337-8525765C:00579ABF; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
From: Scott C Moonen <smoonen@us.ibm.com>
X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 10/27/2009 12:07:27 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 10/27/2009 12:07:27 PM, Serialize complete at 10/27/2009 12:07:27 PM, S/MIME Sign failed at 10/27/2009 12:07:27 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1|September 28, 2009) at 10/27/2009 10:17:27, Serialize complete at 10/27/2009 10:17:27
Message-ID: <OF45C3484B.96202337-ON8525765C.00579ABF-8525765C.00597C1A@us.ibm.com>
Date: Tue, 27 Oct 2009 12:17:26 -0400
Content-Type: multipart/alternative; boundary="=_alternative 005892EC8525765C_="
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, ipsec-bounces@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>, Tero Kivinen <kivinen@iki.fi>, "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 16:17:26 -0000
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
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Frankel, Sheila E.
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Scott C Moonen
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Frankel, Sheila E.
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Tero Kivinen
- Re: [IPsec] [ipsecme] #112: Truncation of SHA-1 I… Black_David