Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

>Nice find on RFC 6649, Eric!  The 2015 date also fits in with a time-limited exception to approved algorithm (2-3 years).

 

I’m forced to sheepishly note that on further review you actually quoted the same line I quote before in your first email to this group on RC4-HMAC, it just didn’t make it into your summary document. So really, it was your original nice find, I just refound it later in the conversation. J

 

> I was also bothered by the “lack of spell checking” in the academic document, but hopefully

> that isn’t an indictment on the quality of the testing, evaluation, and conclusion.

 

It was the flowchart step that checked for “1 < 256?” that bothered me more than spell checking, but I digress…

 

>Is there a place where someone can document RC4 and/or RC4-HMAC?  It is not just Microsoft/AD that could benefit.  I’ve seen RC4 in SSL. 

>Kerberos might use RC4-HMAC.  There could be many reasons to give RC4 temporary alternative means.

>…

>A brief table of these excerpts, sources, and strength of statement, would give a great summary of the alternative means proposal.

> 

>Any takers?

 

### RC4

 

I’m not sure that I’m fully understanding the use of RC4/RC4-HMAC in Kerberos/Windows, so am hesitant to “document” in any authoritative way (i.e., on the wiki), but after much Googling, and gaining a waaaay more in depth understanding of RC4 encryption (and to some extent the –HMAC variant) it seems that there are two main issues:

 

(1)    RC4 initial key generation is flawed. There’s lots of clear documentation here, and this is basically what broke WEP. By discarding the first many (hundred or thousand) key permutations you can avoid this flaw. See http://en.wikipedia.org/wiki/RC4#Security and http://en.wikipedia.org/wiki/Fluhrer,_Mantin_and_Shamir_attack

(2)    Even if you discard the first many key permutations, the algorithm is biased in ways that make it less random than a cryptographic algorithm should be. This allows information about the plaintext to leak out of every version of ciphertext you receive. Attackers observing multiple encryptions of the same plaintext to determine sufficient information about the plaintext to partially reconstruct it. This leads to more feasible attacks on RC4, including SSL/TLS, especially recently (since March of this year). See http://www.isg.rhul.ac.uk/tls/

 

Both vulnerabilities seem to rely on forcing a client to repeatedly encrypt data – on the order of 2^24 generated ciphertexts – and then using weaknesses in the algorithms to reconstruct the plaintext from the observed changes. (Different reported attack types require different numbers of ciphertexts)

 

 

### -HMAC

 

A different(?) kind of attack takes a single real ciphertext and submits it to a service making small changes on each submission. By tracking how each modification affects what error messages the service returns, an attacker can eventually uncover the plaintext. The purpose of the -HMAC addition to RC4 (or any cipher) is to protect against this kind of attack by authenticating that the cyphertext received by a service is a real ciphertext from the correct client and has not been faked/modified.

 

The message authentication code (the “MAC” in “HMAC”) is used to validate the actual ciphertext (or the decoded plaintext) of the message it accompanies, which – as far as I can infer – is why the collision attack is not relevant. That is, in this context the client provides a ciphertext *and* the hash of the MAC of that text; if the attacker generates a collision (based on the –HMAC hash being MD5) it doesn’t help, they could send a completely different ciphertext with the same MD5 HMAC hash, but it wouldn’t help them decipher the original ciphertext of interest.

 

 

### So is Windows safe?

 

All of which I found very interesting, but what it still doesn’t answer is whether Windows is vulnerable to the RC4 “multiple re-encryption” attacks. Our oft-quoted friend RFC 4757 (“The RC-4-HMAC Kerberos Encryption Types Used by Microsoft Windows”, http://tools.ietf.org/html/rfc4757) says:

 

   A consequence of these [weaknesses/replay* attack vulnerabilities]

   is that encrypting the same data (for instance,

   a password) sufficiently many times in separate RC4 keystreams can be

   sufficient to leak information to an adversary.  The encryption types

   defined in this document defend against these by constructing a new

   keystream for every message.  However, it is RECOMMENDED not to use

   the RC4 encryption types defined in this document for high-volume

   connections.

 

(again, my emphasis). So it “defend[s] against” the common attacks, which is perhaps good enough to meet the requirements we’re looking for, but doesn’t clearly mean that. I’d definitely defer to someone with more academic background on RC4. Because it uses different key streams, it MAY be the case that the –HMAC part is a red herring; I’m not sure here.

 

*In this context “replay” refers to “making multiple service requests involving the same data”, not “capturing the request off the wire and resubmit” (a la section 4.2.5.1 of the IAP).

 

 

So in closing, I’m just not sure how we evaluate the strength of this defense. I think this would be a good question for the NASA people (assuming they’ve asked it at this level); I’m not quite sure where else I’d go with that question if they haven’t evaluated it.

 

--- Eric

 

 

 

From: [] On Behalf Of Eric Goodman
Sent: Wednesday, April 10, 2013 4:16 PM
To:
Subject: [AD-Assurance] RE: RC4 - some positive references

 

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: [] 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