Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Hopefully you can find my replies amongst the inline text…

 

They seemed to show up fine.

 

***I understood the Kerberos Armoring to be the “FAST” update to the Kerberos protocol.

 

Me too, but I thought AES was also part of Armoring/FAST. J Sorry for my confusion. Brief Googling confirms your comments. I do note that the original nor the updated Cookbook recommend requiring AES.

 

*** This goes back to SP 800-63-1 where Kerberos is deemed acceptable for password-based-key-derivation if sufficient entropy is employed specifically related to brute-force off-line guessing i.e. “When Kerberos authentication is based on passwords, the protocol is known to be vulnerable to off-line dictionary attacks by eavesdroppers who capture the initial user-to- KDC exchange. Longer password length and complexity provide some mitigation to this vulnerability, although sufficiently long passwords tend to be cumbersome for users. ”  --- per our discussions we had said perhaps 12 character would meet “on the order of 2⁸⁰ resistance”.  That leaves some question about 8 or 9 characters, which can meet Silver entropy.

 

I’ve seen the “2^80” language before, but I think it came from a misread of the entropy table; and the juxtaposition of the Kerberos “offline guessing” language and the 2^80 language in the new 800-63-1 make it easier to misread.

 

According to the entropy discussion (Table A.1, pg 107), a 12 character, RANDOMLY CHOSEN password from a 94 character alphabet has 79 bits of entropy.

 

According to the same table, a 12 character, user chosen password subjected to dictionary and composition rules has ~34 bits of entropy. To get the 80ish bits of entropy required for this requirement, you’d need a ~58 character, user chosen password. My assertion does assume a 1 pass encryption process, but even a 1000 pass encryption process (increasing the encryption operations by 2^10) only cuts ~10 characters off the required password; i.e., you’d need a 48 character password in that case. (According to https://en.wikipedia.org/wiki/Advanced_Encryption_Standard, AES requires up to 14 cycles/rounds, depending on key size).

 

I presume that when people were recommending 12 character passwords they weren’t really intending distributing truly random, gibberish passwords to the user populations.

 

--- Eric

 

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Monday, June 17, 2013 2:19 PM
To:
Subject: [AD-Assurance] RE: Cookbook items - RC4-HMAC and Kerberos

 

Hopefully you can find my replies amongst the inline text…

 

From: [] On Behalf Of Eric Goodman
Sent: Monday, June 17, 2013 4:54 PM
To:
Subject: [AD-Assurance] RE: Cookbook items - RC4-HMAC and Kerberos

 

The Kerberos encryption types can be configured for AES, but the problem comes in when the RC4-HMAC (or ARCFOUR-HMAC) encryption type is used.  I don’t really know if it can be safely removed or if that would break something. See note at bottom for an example.

 

Right, AES (which I interpret as equivalent to “Kerberos Armoring”) is an approved algorithm; however, it requires a uniformity of OS levels (I thought it was Win8+, but your statements below imply Vista+) that may or may not be realistic at each campus. This is an open question for discussion with Microsoft.

 

***I understood the Kerberos Armoring to be the “FAST” update to the Kerberos protocol.

 

For securing the authentication traffic, with sufficiently high entropy (at the Silver level) the Kerberos protocol may be resistant to the eavesdropping and replay attacks. 

 

I still object to using entropy (or at least entropy at the order of magnitude required by Silver) as an argument of resistance to anything but brute forcing passwords. With encryption mechanisms that are attackable through non-brute force methods (i.e., statistical attacks; which is where my understanding* is that RC4 is weak), I’m not clear entropy of the password has any direct impact on the security of the password.

 

I’m not arguing whether it is sufficiently resistant to the attacks, just about the use of 2^30ish level of entropy as justifying resistance in this case.

      

*** This goes back to SP 800-63-1 where Kerberos is deemed acceptable for password-based-key-derivation if sufficient entropy is employed specifically related to brute-force off-line guessing i.e. “When Kerberos authentication is based on passwords, the protocol is known to be vulnerable to off-line dictionary attacks by eavesdroppers who capture the initial user-to- KDC exchange. Longer password length and complexity provide some mitigation to this vulnerability, although sufficiently long passwords tend to be cumbersome for users. ”  --- per our discussions we had said perhaps 12 character would meet “on the order of 2⁸⁰ resistance”.  That leaves some question about 8 or 9 characters, which can meet Silver entropy.

                                  

As a side note, I am not sure AD:DS even complies with InCommon Bronze because 4.2.3.4 is applicable for Bronze AND Silver.  However, we don’t mention anything about Bronze in the cookbook.

 

I believe you’re looking at an older IAP/IAAF here. In v1.2, 4.2.3.4 and 4.2.3.6 are Silver only. The only Bronze requirement here is:

 

4.2.3.5 (B) BASIC PROTECTION OF AUTHENTICATION SECRETS

1. Authentication Secrets shall not be stored as plaintext. Access to stored Secrets and to plaintext copies shall be protected by discretionary access controls that limit access to administrators and applications that require access.

2. Plaintext passwords or Secrets shall not be transmitted across a network.

 

*** I should have checked first.  Good catch!  That means someone is paying attention.  J  I must have been thinking of 4.2.5 (Authentication Process) that applies to both.

 

Which is arguably met even by LMHASHES.

 

--- Eric

 

*Beware reading too much accuracy into my understanding of cipher suites.

 

From: [] On Behalf Of Capehart,Jeffrey D
Sent: Monday, June 17, 2013 12:03 PM
To:
Subject: [AD-Assurance] Cookbook items - RC4-HMAC and Kerberos

 

Some of the recommendations in the revised cookbook are for configuring to meet, and some require an alternative means proposal.

 

We have been looking at the stored authentication secrets as not meeting the criteria because of no variable salting and not using approved algorithms.

 

Although I don’t think it would be possible to eliminate the NTLM “hash” from Active Directory, the Kerberos V5 side of AD:DS seems capable of meeting the requirements.  The Kerberos encryption types can be configured for AES, but the problem comes in when the RC4-HMAC (or ARCFOUR-HMAC) encryption type is used.  I don’t really know if it can be safely removed or if that would break something. See note at bottom for an example.

 

There had been some discussion about doing a Kerberos section that could apply perhaps to both MIT-Kerberos V5 and AD:DS Kerberos V5 for both Encrypting Passwords at Rest (4.2.3.4 etc.) and Securing Authentication Traffic (4.2.3.6 etc).  According to the V5 protocol, each key is variable salted, and encryption types can be controlled to restrict them to only approved algorithms.  This would meet the stored authentication secrets requirement without requiring encrypting the hard drive with Bitlocker.  For securing the authentication traffic, with sufficiently high entropy (at the Silver level) the Kerberos protocol may be resistant to the eavesdropping and replay attacks.  However, the cookbook says that Kerberos armoring is needed.

 

As a side note, I am not sure AD:DS even complies with InCommon Bronze because 4.2.3.4 is applicable for Bronze AND Silver.  However, we don’t mention anything about Bronze in the cookbook.

- Jeff

 

Vista and Windows Server 2008 clients are unable to access cluster names with AES-encrypted Kerberos tickets

http://support.microsoft.com/kb/961302

·         Windows Vista introduced support for AES-encrypted Kerberos tickets, 128-bit and 256-bit

·         AES encryption cannot be used for Kerberos negotiation with cluster names; only up to RC4-HMAC is supported.

 

 

 

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

http://oia.ufl.edu