Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

Upcoming for Friday’s discussion on the matrix are:

 

4.2.5.1 - Resist Replay Attack (B, S)	Ensure it's impractical to achieve authentication by recording and replaying a previous authentication message.
4.2.5.2 - Resist Eavesdropper Attack (B, S)	Ensure it's impractical* to learn the password or otherwise obtain information that would allow impersonation of a subject by network eavesdropping.

 

Assuming protected channels are not being used and the NTLM hash, token, or secret is all we have to work with…

 

For background, see the reference on “impractical” per NIST SP 800-63-1: (Dec. 2011)

 

*“Impractical” is used here in the cryptographic sense of nearly impossible, that is there is always a small chance of success, but even the Attacker with vast resources will nearly always fail. For off-line attacks, impractical means that the amount of work required to “break” the protocol is at least on the order of 2⁸⁰ cryptographic operations. For on-line attacks impractical means that the number of possible on-line trials is very small compared to the number of possible key or password values.

 

OK time for some math!

 

Now, 2 to the 80^th power is a very large number, about 1.2 x 10^24, roughly a “million-billion-billion”.  If “break the protocol” refers to deriving the user’s password from the NTLM hash, then the usual method is to try an exhaustive brute-force going through all possible passwords, hashing, and checking for a match.  Therefore, with a 95-character set for passwords, how long (N) would the password need to be such that 95^N is “at least on the order of 2^80”?

 

Solving for N, the result is log(2^80)/log(95) = 12.17 which means either a 12 or 13 character length password.  Technically, 12 characters yields only 2^78.8, but does that qualify per “at least on the order of” or would 13 be the minimum?

 

So, think about if longer length meets the “resist eavesdropper”.  Technically, that is supposed to work for Kerberos too?  And the NTLMv2 is supposed to have a fine-grained time value to help resist replay.

 

Check the matrix:

LM - Does not resist replay attacks*
NTLMv1 - Does not resist replay attacks*
NTLMv2 - Does not resist replay attacks well
LDAP - Does not resist replay attacks if unsigned binds are performed
Kerberos - Vulnerable to man-in-the-middle attacks

 

LM - Vulnerable to eavesdropping*
NTLMv1 - Vulnerable to eavesdropping*
NTLMv2 - Resists eavesdropping (strength of encryption)
LDAP - Vulnerable to eavesdropping if unsigned binds are performed
Kerberos - Not vulnerable to eavesdropping unless man-in-the-middle
* Not allowed per AD Silver Cookbook

 

Think about alternative means, and any configurations that would meet the spec.  One AM posted is to use a VPN for everything (to get the protected channel).

 

We had also thought about replay for purely AD:DS sessions not being in-scope if Shibboleth/SAML2.0 was being used for the session with the Silver assertion.

 

Consider NTLMv2 while reading the background on resisting replay from NIST SP 800-63-1:

 

•                      Protocols that use nonces or challenges to prove the “freshness” of the transaction are resistant to replay attacks since the Verifier will easily detect that the old protocol messages replayed do not contain the appropriate nonces or timeliness data related to the current authentication session.

 

Jeff

 

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

http://oia.ufl.edu