Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

The argument around 2^30.6 is around attack surface, not around normal usage. Whether forcing a system to generate the login challenges that many times would equate to things you could audit from the logs is unknown to me. This is similar to the WEP attack, though more sophisticated, and I have no idea how well one could detect the (presumedly as yet unwritten) attacks that would take advantage of this vulnerability using normal monitoring tools.

 

Which still leaves us, I think, in the same boat; namely evaluating cryptographic strength of the cipher and likely attack vectors.

 

FWIW, ARC4 is a generic RC4 implementation that was created just to avoid copyright issues back when RC4 was reverse engineered but before it was released widely. ARC4 is “Allegedly RC4” (“RC4” is “Rivest Cipher 4”). So RC4 and ARC4 should be pretty much identical.

 

--- Eric

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Monday, April 29, 2013 2:43 PM
To:
Subject: [AD-Assurance] RC4-HMAC and Kerberos

 

A note on Kerberos and one more consideration for Alternative Means on RC4-HMAC:

 

In SP800-63-1 (and also in the draft -2 version), there is a sentence in the last paragraph of 9.3.2.2 that says “All assertion protocols used at Level 2 and above require the use of Approved cryptographic techniques. As such, the use of Kerberos keys derived from user generated passwords is not permitted at Level 2 or above.”

 

Should we infer that the reason password based Kerberos is not permitted is related to not using Approved cryptographic techniques?  If the encryption type can be configured such that the weak protocols are not included, then would Kerberos be OK for Level 2?

 

I assume the non-approved encryption algorithms used in Kerberos might be DES and/or RC4-HMAC (perhaps also named ARCFOUR-HMAC).

 

In a 2005 draft fix for Arcfour, here’s something that was mentioned under security considerations:

   Given about 2^30.6 bytes of Arcfour keystream, it is possible to

   distinguish it from a random byte sequence [FMcG].  These 2^30.6

   bytes need not all be from the same Arcfour stream, with the

   consequence that if the same plaintext (for instance a password) is

   encrypted 2^33.6 times with different Arcfour keys, it might be

   possible to deduce its content.  It is thus RECOMMENDED that Arcfour

   (either in the form described here or that described in

   [I-D.ietf-secsh-architecture]) not be used for high-volume

   password-authenticated connections.

http://tools.ietf.org/html/draft-harris-ssh-arcfour-fixes-01

 

Similar language made it into the final RFC 4345 and RFC 4757* on RC4-HMAC Kerberos, but without a specific definition of “high-volume”. 

 

Does anyone think it likely that InCommon Silver Federated Identity authentications will be anywhere near on the order of 2^33 (8.5 Billion) such that they would come close to being high-volume authentications?   Even if we include all of our internal network and other authentications, over a one year period, there would have to be nearly a million authentications per hour to get close to this number.

 

For the alternative means, perhaps recognizing that authentications will not be “high-volume” would suffice for consideration of good enough?

 

*8.  Security Considerations

   Care must be taken in implementing these encryption types because

   they use a stream cipher.  If a different IV is not used in each

   direction when using a session key, the encryption is weak.  By using

   the sequence number as an IV, this is avoided.

   There are two classes of attack on RC4 described in [MIRONOV].

   Strong distinguishers distinguish an RC4 keystream from randomness at

   the start of the stream.  Weak distinguishers can operate on any part

   of the keystream, and the best ones, described in [FMcG] and

   [MANTIN05], can exploit data from multiple, different keystreams.  A

   consequence of these 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.

 

http://tools.ietf.org/html/rfc4757#section-8

 

Jeff

 

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