Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

David,

 

I do appreciate when we can come up with clear, well thought-out conclusions.  Perhaps we can review these on the call today or others can confirm their understanding or agreement.

 

Point1:  We can’t mitigate weak encryption with greater password entropy. 

Agreed.  That would be something like saying NTLM is OK or RC4 is OK as long as your password is at least 12 characters.  Or 16, or even 30.

 

Point 2: Password entropy is a mitigation for brute force (or intelligent) guessing attacks. 

I would qualify this point as primarily used for online guessing since the min-entropy requirement is what must be met.  IAP Silver v1.2 section 4.2.3.3 calls out online guessing attacks. 

 

The generalized “entropy” used to refer to length/composition rules/dictionary could be used to address the eavesdropper (offline) attacks aspect of Kerberos mentioned in SP-800-63-1, although “sufficiently long” is left for interpretation.

“[Definitions: Kerberos] 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. “

 

Point 3: A successful attack on the encryption itself, on the other hand, will allow the attacker to read a password, independent of how long or complex it is.

I would agree for passwords stored using reversible encryption. 

 

For cryptographic hashing algorithms that generate a one-way function, the approach now is to use dictionaries, combination rules, and video cards (GPU’s) to speed up computations and test candidate plain text passwords against the hashing function for a match.  For these operations, the entropy of “human selected” is a far reduced set of choices compared to the random selection from the available character space.  One other potential method to break the hashing cryptography is using the collision method where “Password” hashes to "161ebd7d45089b3446ee4e0d86dbcf92" and (hypothetically) due to a collision some determinable garbage plain text such as “{s+23f(JrnW?zz-90a$gHQ\@@_” also generates the same hash.  Even if the hash algorithm had a predictable collision, I would think it would have to be generated through repeated tests in which case using the dictionary method would likely produce faster and better results for the time spent.  (Usually collisions are used to exploit the message digest aspect of hashing to prove non-repudiation of a text such as an email or source code where the plain text is available and you change some important text in the email to the attacker’s choice and then cycle through characters at the end until the same message digest is created.)

 

Point 4: Language about Kerberos quoted from the section about the assertions sent to a relying party (section 9.3.2.2) is SAML, so that language doesn't apply to us.

This one needs a few more folks to look at to see if the conclusion is valid. 

 

My first interpretation of 9.3.2.2 was that Kerberos authentication with user created passwords can’t be used at all for any credential at “Level of Assurance 2”.  Looking at section 8.3.2.1 you can see that Kerberos is specifically mentioned as allowed (would meet Bronze).  However, no such call-out is made at Level 2 in section 8.3.2.2 which may call into question whether Kerberos is OK to use elsewhere (like Windows logons) for the same Silver credentials when the password is created by the user.  But, I am leaning towards the interpretation that 9.3.2.2 is talking about Kerberos being used to make the assertion claim by using extensions to the protocol, not just doing authentication.  (See 9.1.3 on Kerberos Tickets.)

 

So, does this sound correct?

1)      When using Shibboleth, a TLS tunnel is created, over which the user enters their ID/password… that ID/password could be configured in Shibboleth to be authenticated via LDAPS to Active Directory, therefore meeting 8.3.2.2 Level 2 authentication.  The assertion is sent via SAML which meets 9.3.2.2 and thus everything is met and aligns with IAP v1.2 Silver.

2)      When using the same Active Directory for normal daily Windows authentication over Kerberos with a Silver ID/password, no assertions are being made or provided, and as long as “Approved Algorithms” are used for storage (4.2.3.4) and transmission (4.2.3.6), the credential store/service would meet the IAP v1.2 Silver spec.

 

Jeff C.

From: [mailto:] On Behalf Of David Walker
Sent: Thursday, June 20, 2013 5:09 PM
To:
Subject: Re: [AD-Assurance] RE: Cookbook items - Entropy and Kerberos

 

I'm starting to have trouble figuring out who said what in this thread, but here are some thoughts.

• I don't think we can mitigate weak encryption with greater password entropy.  Password entropy is a mitigation for brute force (or intelligent) guessing attacks.  A successful attack on the encryption itself, on the other hand, will allow the attacker to read a passwords, independent of how long or complex it is.  I think the confusion comes from the fact that (according to one of the articles I sent yesterday) many (most?) attacks on encrypted passwords are not actually attempts to decrypt the passwords; they're guessing attacks that leverage very fast hardware and software for encrypting the guesses.
• Then language about Kerberos that was quoted is from the section about the assertions sent to a relying party (section 9.3.2.2).  In our case, that's SAML, so that language doesn't apply to us.

David