Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

Jeffrey,

I'm pretty sure that language refers to assertions sent to SPs, not the authentication protocol used by an IdP.  In InCommon's case, those assertions are SAML, not Kerberos, so we don't have a problem here.

David

On Mon, 2013-04-29 at 21:42 +0000, Capehart,Jeffrey D wrote:

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