Re: [secdir] Secdir review of draft-turner-md4-to-historic-08

Catherine Meadows <> Mon, 13 December 2010 23:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4DA628C112; Mon, 13 Dec 2010 15:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5h6NxL9i9AwF; Mon, 13 Dec 2010 15:12:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 33BCA3A6E17; Mon, 13 Dec 2010 15:12:17 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.6) with ESMTP id oBDNDsj5021399; Mon, 13 Dec 2010 18:13:54 -0500 (EST)
Received: from (sun1 []) by (8.13.8/8.13.6) with SMTP id oBDNDqGJ011871; Mon, 13 Dec 2010 18:13:52 -0500 (EST)
Received: from ([]) by (SMSSMTP with SMTP id M2010121318135108118 ; Mon, 13 Dec 2010 18:13:51 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary="Apple-Mail-6-442658475"
From: Catherine Meadows <>
In-Reply-To: <>
Date: Mon, 13 Dec 2010 18:21:10 -0500
Message-Id: <>
References: <> <>
To: Sean Turner <>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [secdir] Secdir review of draft-turner-md4-to-historic-08
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Dec 2010 23:12:19 -0000

Hi Sean:

My apologies for my late response.  I've been doing a lot of traveling and, due to an accident with my laptop,
not checking my email as much as I should have.

My response are also inline.


On Dec 6, 2010, at 9:05 AM, Sean Turner wrote:

> Catherine,
> Thanks for the review.  Responses inline.
> spt
> On 12/3/10 5:37 PM, Catherine Meadows wrote:
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should treat
>> these comments just like any other last call comments.
>> This document recommends that the MD4 hash algorithm be retired and moved to historic status and gives
>> the rationale for doing this, namely its known vulnerability to collision and pre-image attacks. The impact is mostly minimal, except
>> for three Microsoft RFCs that are still supported in various versions of  Windows and the RADIUS and EAP RFCs .  It would be helpful to learn what other algorithms
>> these OSs and RFCs support.  This would give a better idea of the effect of dropping MD4; if there are other alternatives supported by the OS's
>> the impact should be minimal here as well.
> I it might be hard to explain what alternatives are in each of the OS's because it depends a lot on what version/release/path combo is being used.  I think RFC 4757 hints pretty strongly that aes256-cts-hmac-sha1-96 is supported because it says to use that alg instread of RC4-HMAC.

>> Other than that, I have no problems with the decision or rationale.  I agree, as I am sure that everyone else does, that MD4
>> should be retired.
>> Some nits:
>> 1.  "Section 6 also discussed" should be "Section 6 also discusses"   This occurs in several places.
> Fixed
>> 2. " The RC4-HMAC is supported in Microsoft's Windows 2000 and
>>            later for backwards compatibility with Windows 2000. "
>> later supported by what?  I assume later versions of Windows, but it is probably a good idea to make this clear.
> r/later/later versions of Windows
>> 3. When you say that with one exception the impact of retiring MD4 would be minimal, it would be a good idea to mention that exception upfront.
>> It is fairly clear after you read the whole impact section  that the exception is the Microsoft RFCs, but nowhere where is that  said explicitly.
> How about:
> The impact of moving MD4 to Historic is minimal with the one exception of Microsoft's use of MD4 as part of RC4-HMAC in Windows, the as described below.

Sounds good.  
>> 4.  I'm not sure wether or not   the discussion of MD4's resistance against key recovery attack really belongs in the impacts section (in the discussion
>> of RC4-HMAC).  It might give the impression that RC4-HMAC is secure against key recovery, and, given the other attacks found against MD4, it is reasonable
>> to believe that this security is only temporary.  I would suggest putting this discussion in the security considerations section, and also, wherever it does end up, adding the appropriate
>> caveats.
> I'm hesitant to move the text because it's in there specifically to address a comment by Sam Hartman.

OK, the location of the text is not that big a deal.
> My understanding of MD4's use in RC4-HMAC is that MD4 is used to generate a key from a password and then that key is used as input to HMAC-MD5.  So I am actually saying that RC4-HMAC is secure against key recovery attacks but this is entirely because HMAC-MD5 is used.  In other words, when HMAC-MD5 is broken then RC4-HMAC is broken.

OK, I misunderstood.  If I'd read the text a little more carefully I might  have figured it out, but the text is a little ambiguous at first glance.  It could be interpreted to mean
that RC4-HMAC uses MD4 for key protection, but relies on some other property than collision resistance, which perhaps eventually also be broken.  Here is my suggestion for
a clarification, based on what you said:

The RC4-HMAC is supported in Microsoft's Windows 2000 and
           later for backwards compatibility with Windows 2000.  As
           [RFC4757] stated, RC4-HMAC doesn't rely on the collision
           resistance property of MD4, but uses it to generate a key from a password, which is then
           used as input to HMAC-MD5.   For an attacker to recover the
           password from RC4-HMAC, the attacker first needs to recover
           the key that is used with HMAC-MD5.  As noted in
           [ID.turner-md5-seccon-update], key recovery attacks on HMAC-
           MD5 are not yet practical.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942