Subject: Meeting the InCommon Assurance profile criteria using Active Directory
- From: "Capehart,Jeffrey D" <>
- To: "" <>
- Subject: [AD-Assurance] RC4-HMAC and Kerberos
- Date: Mon, 29 Apr 2013 21:42:40 +0000
- Accept-language: en-US
- Authentication-results: sfpop-ironport01.merit.edu; dkim=neutral (message not signed) header.i=none
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 184.108.40.206 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
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?
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
- [AD-Assurance] RC4-HMAC and Kerberos, Capehart,Jeffrey D, 04/29/2013
Archive powered by MHonArc 2.6.16.