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

[Sean Turner <[e-mail]>]

On 12/13/10 6:21 PM, Catherine Meadows wrote:
> 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.

No worries.  We still got time ;)  Hope you've been backing up all along.

> My response are also inline.

I'll make the modifications to the paragraph as you suggest.

Cheers,

spt

> 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: [phone]
> fax: [phone]
> email: [e-mail]
> <mailto:[e-mail]>
>