Re: [IETF-PKIX] mandatory PasswordBasedMac

Bob Jueneman <BJUENEMAN@NOVELL.COM> Tue, 27 January 1998 20:33 UTC

Return-Path: <owner-ietf-pkix@LISTS.TANDEM.COM>
Received: from consensus.com (mail.consensus.com [157.22.240.7]) by sparky.wovenword.com (8.8.5/8.8.5) with ESMTP id MAA12499 for <tim-mail-work-lists@wovenword.com>; Tue, 27 Jan 1998 12:33:29 -0800
Received: from talia.mis.tandem.com (130.252.226.155) by consensus.com with ESMTP (Eudora Internet Mail Server 1.2); Tue, 27 Jan 1998 13:36:52 -0700
Received: from suntan (suntan.tandem.com [192.216.221.8]) by talia.mis.tandem.com (8.8.7/8.8.7) with ESMTP id MAA13315; Tue, 27 Jan 1998 12:32:26 -0800 (PST)
Received: from LISTS.TANDEM.COM by LISTS.TANDEM.COM (LISTSERV-TCP/IP release 1.8c) with spool id 24304 for IETF-PKIX@LISTS.TANDEM.COM; Tue, 27 Jan 1998 12:32:22 -0800
Received: from novell.com (prv-mail20.Provo.Novell.COM [137.65.40.4]) by Tandem.com (8.8.8/2.0.1) with SMTP id MAA16324 for <IETF-PKIX@LISTS.TANDEM.COM>; Tue, 27 Jan 1998 12:32:21 -0800 (PST)
Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Tue, 27 Jan 1998 13:31:51 -0700
X-Mailer: Novell GroupWise 5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by Tandem.com id MAA16325
Message-ID: <s4cde1c7.072@novell.com>
Date: Tue, 27 Jan 1998 13:31:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <IETF-PKIX@LISTS.TANDEM.COM>
Sender: "IETF X.509-based public key infrastructure mailing list" <IETF-PKIX@LISTS.TANDEM.COM>
From: Bob Jueneman <BJUENEMAN@NOVELL.COM>
Subject: Re: [IETF-PKIX] mandatory PasswordBasedMac
Comments: To: dpkemp@MISSI.NCSC.MIL
To: IETF-PKIX@LISTS.TANDEM.COM
Status:

>
>The IANA has registered OIDs for HMAC mechanisms as used by IPSEC:
>
>  ftp://ftp.isi.edu/in-notes/iana/assignments/smi-numbers
>
>iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
>isakmpOakley(1) HMAC-md5(1)  [1.3.6.1.5.5.8.1.1]
>iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
>isakmpOakley(1) HMAC-SHA(2)  [1.3.6.1.5.5.8.1.2]
>
>The reference in the IANA document [Thayer] is missing, but it refers
>to the IPSEC document roadmap, which in turn references "The Use of
>HMAC-SHA-1-96 within ESP and AH",
>
>  ftp://ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt
>
>which in turn references RFC 2104 "HMAC: Keyed Hashing for Message
>Authentication", the actual algorithm description.
>
>Note that these OIDs refer to a truncated HMAC where only the first
>96 bits of the outer hash output are used - this truncation is described
>as a security advantage (it wasn't done solely to cram the MAC into
>the IPSEC packets).


As usual when adopting a standard intended for one purpose for another completely different one, you need to be careful to ensure that the standards are meeting the same needs.

Although I haven't followed the use of HMAC in IPSEC, I would have serious reservations about the use of ANY hash algorithm that is only 96 bits long, unless I had wralked though all of the possible attack scenarios very carefully.

The problem, of course, is that a Birthday Problem attack on a 96 bit hash only requires on the order of 2^48 calculations to defeat it.  Although there may be a security advantage in doing some truncation (e.g., to protect against attempts to extract the secret salt), 96 bits is far too short for comfort.

If we can't find anything else, we should write up and use a varient of HMAC that is somewhere between 128 and 140 bits long, I believe.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."