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

From: Tobias Gondrom <[email-masked]>
Date: Wed, 18 Apr 2012 11:39:41 +0800

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see  
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-krb-wg-des-die-die-die-04
Title: Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic 
algorithms in Kerberos
Reviewer: Tobias Gondrom
Review Date: April-17

Summary: The document is ok for publication.

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 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.

Best regards, Tobias

---

From: Tom Yu <[email-masked]>
Date: Wed, 18 Apr 2012 14:02:17 -0400

Tobias Gondrom <[email-masked]> writes:

> Major Comment:
> Agree that we should/must deprecate the weak cryptographic algorithms
> in Kerberos.
> 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

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?

---

From: Sean Turner <[email-masked]>
Date: Wed, 18 Apr 2012 17:51:54 -0400

On 4/18/12 2:02 PM, Tom Yu wrote:
> Tobias Gondrom<[email-masked]>  writes:
>
>> Major Comment:

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