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

Catherine Meadows <catherine.meadows@nrl.navy.mil> Mon, 13 December 2010 23:12 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4DA628C112; Mon, 13 Dec 2010 15:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h6NxL9i9AwF; Mon, 13 Dec 2010 15:12:17 -0800 (PST)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 33BCA3A6E17; Mon, 13 Dec 2010 15:12:17 -0800 (PST)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id oBDNDsj5021399; Mon, 13 Dec 2010 18:13:54 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id oBDNDqGJ011871; Mon, 13 Dec 2010 18:13:52 -0500 (EST)
Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) 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 <catherine.meadows@nrl.navy.mil>
In-Reply-To: <4CFCEDAB.9040909@ieca.com>
Date: Mon, 13 Dec 2010 18:21:10 -0500
Message-Id: <C07A6B54-F379-4854-8565-557709CB1D10@nrl.navy.mil>
References: <8B1C3F0B-07B7-4B48-A2BA-9E8719A49CF9@nrl.navy.mil> <4CFCEDAB.9040909@ieca.com>
To: Sean Turner <turners@ieca.com>
X-Mailer: Apple Mail (2.1082)
Cc: iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-turner-md4-to-historic-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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.

Cathy

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.

OK.
> 
>> 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
email: catherine.meadows@nrl.navy.mil