Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

These seem reasonable conclusions. (Though I must say I’m put off by the glaring typos in the flowchart describing how RC4 works in the last paper!)

 

While looking at the RFCs, I also ran across RFC 6649 – a “Best Current Practices” RFC – which deprecates the use of DES and RC4-HMAC-EXP (export strength, or small key size variant of RC4-HMAC) as “weak”, but not RC4-HMAC.

 

We may want to add this one to the list of references. 6649’s endorsement of RC4-HMAC is notably less “ringing” than the 6150’s, but the RFC appears to be about 15 months newer (July 2012 vs Mach 2011), so may be good just to reiterate the currency of the recommendation.

 

“This document does not add any sort of requirement for conforming implementations to implement RC4-HMAC(23).

[….]

“The main reason to not actively discourage the use of RC4-HMAC is that it is the only encryption type that interoperates with older versions of Microsoft Windows once DES and RC4-HMAC-EXP are removed. These older versions of Microsoft Windows will likely be in use until at least 2015.”

 

--- Eric

 

 

 

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Friday, April 05, 2013 12:00 PM
To:
Subject: [AD-Assurance] RC4 - some positive references

 

Although NIST has not approved RC4 as a cryptographic algorithm, and yet it is widely used in industry, surely there must be something that gives 128-bit RC4 some quality of “secure” that would be equivalent to the approved algorithms.

 

I found three authoritative references on RC4:

 

#1:  CISCO – Next Generation Encryption

http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html

 

(Their “Recommendations for Cryptographic Algorithms” refers to RC4 as legacy, with mitigation being “key schedule is important”.  Note:  They also refer to 3DES, SHA-1, and HMAC-MD5 as legacy with mitigation.  The key here is that although they are legacy, they are not on the AVOID list.)

 

#2: Internet Engineering Task Force RFC on MD4, MD5                  http://www.ietf.org/rfc/rfc6150.txt

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.                                                                       

 

#3:  Academic Evaluation of RC4 Algorithm for Networks (See excerpts below)

http://www.academia.edu/450208/EVALUATION_OF_THE_RC4_ALGORITHM_AS_A_SOLUTION_FOR_CONVERGED_NETWORKS

 

The conclusion is good news.  The testing appears to be sound.  And, it happens to also be another .EDU which may or may not matter.  Consider a “converged” network to just be a network.  I do not think the qualification is restrictive for the security evaluation.                                       

                                                                               

I offer these for your consideration in defining an Alternative Means for RC4 to be at least equivalent to an approved algorithm.  I would encourage others to read through and see if there is agreement on the points I made. 

 

If this is sufficient to give RC4 alternative means (either on its own, in limited situations, or in combination with Active Directory alternative means) it would probably be very helpful.  I have mostly seen the RC4-HMAC cipher suites with Kerberos, but RC4 is also used in

(RC4 128, RC4-HMAC, ARCFOUR-HMAC).  The 40-bit key RC4 algorithms should be considered weak and not equivalent.  Perhaps a time-limited approval such as 3 years with re-evaluation, or removed if cracked?

-Jeff

 

[EXCERPTS for EVALUATION_OF_THE_RC4_ALGORITHM]

“We will apply the NIST suite of statistical tests to RC4 output to test its randomness and security. The testing results illustrates that RC4 is secure and random enough to be used within the converged network.”

 

“In this paper we discussed the security problems of the converged networks. RC4 algorithm was introduced as a solution for converged networks security problems. NIST statistical test suite was used to test the security of RC4 algorithm running over converged networks, all traffic types that are running over converged networks (video, audio, image and text) were tested after encrypting them with RC4, the resulted sequences passed all the statistical tests with high values, which indicates high statistical properties for all of them.  As a result RC4 sequences are random and can’t be predicted. Hence RC4 is applicable with converged networks traffic, and can work as a security solution for them, with a very fast performance and strong degree of security.”

 

“Many papers have been published analyzing methods of attacking RC4. None of these approaches is practical against RC4 with a reasonable key length, such as 128 bits. A more serious problem is reported in [8].”

[8] Weakness in the Key Scheduling Algorithm of RC4, in Proceedings, Workshop in Selected Areas of Cryptography, 2001

 

 

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu