I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt

HUGO@watson.ibm.com Fri, 01 November 1996 00:59 UTC

Received: from relay.hq.tis.com by neptune.TIS.COM id aa12016; 31 Oct 96 19:59 EST
Received: by relay.hq.tis.com; id UAA13696; Thu, 31 Oct 1996 20:03:46 -0500
From: HUGO@watson.ibm.com
MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM
Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma013692; Thu, 31 Oct 96 20:03:18 -0500
Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id UAA06870 for <IPSEC@tis.com>; Thu, 31 Oct 1996 20:05:03 -0500 (EST)
Received: by relay.hq.tis.com; id UAA13686; Thu, 31 Oct 1996 20:03:16 -0500
Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma013682; Thu, 31 Oct 96 20:03:13 -0500
Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id UAA16524; Thu, 31 Oct 1996 20:05:28 -0500
Received: from yktvmv.watson.ibm.com (yktvmv.watson.ibm.com [9.117.33.29]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id UAA586175; Thu, 31 Oct 1996 20:05:16 -0500
Message-Id: <199611010105.UAA586175@mailhub1.watson.ibm.com>
Received: from YKTVMV by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6616; Thu, 31 Oct 96 20:05:13 EST
Date: Thu, 31 Oct 1996 19:52:21 -0500
To: IPSEC@TIS.COM
cc: rob.glenn@nist.gov, shu-jen.chang@nist.gov
Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-03.txt
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

Ref:  Your note of Thu, 31 Oct 1996 19:06:38 -0500

I insist with my previous recommendation.
Define hmac-sha to output 128 bits (out of the final 160 bits result).
It most probably help security and saves up to 64 bits
in 64-bit alignments.

Hugo

PS: I am appending a message that I sent to the list a couple of months
ago on this issue. If anyone has a good reason against this recommendation
please send it to the list.


> Thus, I am proposing that instead of padding the 160 bits of SHA output
> to 192 bits, truncate the result to 128 bits.
>
> Beyond the advantage for bandwidth, this truncation is plausible to
> add to the security.
>
> In general, it is an old practice to truncate MACs. In the context
> of keyed-hash this has been explicitely proposed by Preneel and van
> Oorschot (Crypto'95). I do not know of any *proof* that
> truncating adds to the security. However, there are examples of attacks where
> this is the case. And as long as you do not truncate "too much"
> then everything indicates that it helps. In particular, I know of no
> reason how or why truncating HMAC-SHA to 128 bits would hurt in any scenario.
>
> Note: Be careful not to get confused with the unkeyed uses of SHA.
> There, collision resistance is usually the sacred goal and truncating the
> output HURTS HURTS HURTS (because of birthday attacks).
> For keyed-hash for message authentication the story is very different.
> Actually, the justification for truncation in [PV] is *exactly*
> because it helps *against* birthday attacks.
> (Yes, I know it sounds confusing but that's the way it is...)
> Still in the application of HMAC the 160 bits in the definition of SHA help
> as the length of the *intermediate* results of the compression function,
> but not as the final result.
>
> ANyway, truncation as a general method has an advantage (less information
> available to the adversary) and a disadvantage (less bits to predict for the
> attacker). When truncating 160 to 128 the advatage is far more significant
> than the disadvantage (It would be different if we truncated to 64 bits;
> that would make me uncomfortable -- 80 bits for SHA or even for MD5 are my
> "personal minimum".)
>
> BTW, in the RFC on HMAC that I am submitting to the IETF there is a section
> on truncation of HMAC output.
>
> ----------
>
> The patent issue:
>
> There is a patent by Novell (US 5349642) that claims keyed hash functions
> for message authentication. Such claim would cover (I am not a lawyer!)
> all hash based schemes that have ever been suggested in this WG, including HMA
> Fortunately, the filing date of that patent is Nov 3 1992, while
> Gene Tsudik's paper proposing such functions appeared in Infocom in May 1992.
> (This work is also part of Gene's UCLA's PhD dissertation of May 1991).
>
> The one element that does not appear in Tsudik's work is truncation.
> However, truncating the output of MAC functions is an old and very well
> known practice in cryptography. For example,
>
> [MM]    Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982.
>
> [ANSI]  ANSI X9.9, ``American National Standard for Financial
>         Institution Message Authentication (Wholesale),'' American
>         Bankers Association, 1981.   Revised 1986.
>
> and therefore a hard to defend claim (I'm not a lawyer!!).
>
> After consulting with Jeff Schiller and the WG chairs, it became clear
> to me that the existence of Novell's patent shouldn't be an obstacle to
> include a section on truncation in the HMAC rfc, and more significantly,
> to propose it for adoption for AH-HMAC-SHA.
>
> Hugo
>

Date: 31 Oct 1996 15:55:40 -0400
From: WaterhouseR <WaterhouseR@mail.ndhm.gtegsc.com>
Subject: One Last Comment
To: IPSEC Working Group <ipsec@TIS.COM>
X-Mailer: Mail*Link SMTP-MS 3.0.2
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID:  <9611010756.aa00194@neptune.TIS.COM>

4. The timer/retry logic is incompletely specified. Consider the second (last)
message sent by the Responder to the Initiator in the Base Exchange.  The
criterion the Rwesponder is to use in this case for turning off his
timer/retry is not specified.

Also no criterion is provided for the receiving Protocol Machine to clear his
states and return to IDLE when nothing is received.