Re: [apps-discuss] APPSDIR review of draft-ietf-krb-wg-des-die-die-die-04

[Sean Turner <[e-mail]>]

On 4/18/12 2:02 PM, Tom Yu wrote:
> Tobias Gondrom<[e-mail]>  writes:
>
>> Major Comment:
>> Agree that we should/must deprecate the weak cryptographic algorithms
>> in Kerberos.
>> However IMHO, I do not agree with the reasoning "to not actively
>> discourage the use of RC4-HMAC" in section 7.
>> I understand that interoperability is of major importance, but at some
>> point a very weak algorithm will give users a false sense of security
>> while exposing them to malicious attacks. And keeping RC4-HMAC
>> supported does also expose the majority of the community (who is not
>> using the deprecated Windows Versions) at possible risks to downgrade
>> attacks.
>
> I believe RC4-HMAC (note: _not_ the 56-bit RC4-HMAC-EXP, which we
> _are_ deprecating) is stronger than the DES enctypes that we are
> deprecating.  It has a 128-bit keysize, but might be somewhat weaker
> than AES of the same keysize.  I know of no reason yet to characterize
> RC4-HMAC as "very weak"; it might very well be stronger than
> triple-DES, which we are not deprecating at this time.
>
> Do you believe that RC4-HMAC poses anywhere near the level of risk
> that single-DES does?  If not, I prefer to handle deprecating RC4-HMAC
> separately so that we avoid confusing the issues.
>
>> I believe even though the support of the complete Internet community
>> is vital for standards, the support of deprecated (and AFAIK no longer
>> supported OS versions) should not be the deciding argument behind our
>> decisions here. Even old OS can be patched or fixed by the vendor or
>> other service providers and it should not justify to keep a weak
>> algorithm.
>
> Extended support is still available for some of the Windows operating
> systems in question, but I believe Microsoft finds it uneconomical to
> implement support for new crypto algorithms in these older versions of
> Windows (which could very well still be around until 2015).
>
> RFC 4757 already mentions known weaknesses of RC4-HMAC, and we refer
> to that RFC in the document's Security Considerations.  Do you believe
> that there should be a stronger warning?

I'm *NOT* a cryptographer.

While authoring RFC 6150 (https://datatracker.ietf.org/doc/rfc6150/), we 
had to come up with some text about RC4-HMAC.  Here's what we ended up with:

  o The RC4-HMAC is supported in Microsoft's Windows 2000 and later
    versions of Windows 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 [RFC6151], key recovery attacks on HMAC-MD5
    are not yet practical.

*If* you really need some more text, pointing to RFC 6150/6151 might be 
enough for this particular point.

spt