Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Hi Jeff,

 

For LM and NTLMv1, my understanding is that these protocols both split the user’s actual key into 7 character blocks when responding to the actual challenge/response [1]. So my assumption is that given a 13 character password, from the point of view of offline cracking LM/NTLMv1 it’s really two separate passwords; a 7 character and a 6 character one , making the cracking more like a 2^46 (or I guess with two 7 character passwords, a 2^47) cryptographic operation process.

 

Now that I explain my logic there, it sure sounds like my assessment was more a description of bad “eavesdropper protection” rather than “replay protection”, and so may be in the wrong section. From what I understand, Windows would protect against true replay of the un-cracked response, since each login has its own distinct challenge, and Windows appears to track what challenges have already been used in previous authentication events.

 

Beyond that, the rating I put in for LM, NTLMv1 and NTLMv2 was also based on the language in the previously quoted papers that equated “man-in-the-middle” attacks with “replayability”.  Even though I think of those as separate attack types, I listed all three as vulnerable because as I understand it they are all vulnerable to MITM.

 

I’m not at all wedded to my rankings; please correct them as appropriate. I just wanted to share the logic behind them since I missed the last call and will also miss the next one due to vacation.

 

--- Eric

 

[1] See: http://www.defenceindepth.net/2011/04/attacking-lmntlmv1-challengeresponse.html

 

 

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Monday, April 01, 2013 7:27 AM
To:
Subject: [AD-Assurance] Resistance levels for AD/NTLM on replay/eavesdropper

 

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