Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

Eric,

 

Thank you for the additional links, references, and explanations.

 

The guide from US-CERT recommended secure password storage (encryption), so I think as far as NTLMv2, they were talking about authentication method over the network.  Storage may have been implied, so I can understand the confusion as we have to address each separately.

 

If there are some things that we can rule out as “not good enough”, that might help others trying to find wiggle room or a path to success.

 

For example, if an internal network were all IPSEC, that should be good enough for secure communications, assuming an approved algorithm, or perhaps, equivalent or better for strong encryption.

 

For storage, if an admin does not want Bitlocker or a Level 2/3/4 hardware encrypted drive, is there any path to success using SYSKEY with alternative means to meet the 4.2.3.4 criteria to protect stored password secrets (particularly ones like NTLM that don’t use variably salted hash or approved encryption).

 

The challenging part here is that both Bronze and Silver require 4.2.3.4 (secure storage) but only Silver requires 4.2.3.6 (secure transmission).  In the case of Bronze, transmission over a network is OK as long as the secret is not plain-text.

 

Jeff

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Wednesday, May 15, 2013 9:28 PM
To:
Subject: [AD-Assurance] RE: US-CERT as an authority on security - for alternative means - on NTLMv2

 

Actually, I should perhaps rescind some of the comments here.

 

I equated the NTLM password hash (bad security on pw storage) with the MSCHAP challenge protocol (bad security on the wire). It’s the latter which was broken in the link I sent. The NTLM challenge protocols are different things than the NTLM password hash. So I think I conflated things.

 

End result (if I’m not still confused!):

 

·         MSCHAP challenge protocol = bad security on the wire

o   eduroam: Does MSCHAP inside a TLS tunnel, so maybe not so bad on the wire

·         NTLMv2 challenge protocol

o   Better than LM, NTLMv1, NTLMv1 with session security, all of which are basically broken on the wire (and are all roughly equivalent to MSCHAP)

o   Possibly still unbroken on the wire, I’m honestly unclear at this point!

o   Requiring NTLMv2 (and not LM or NTLMv1) is already in the AD cookbook; i.e., we could go with Jeff’s original suggestion

·         NTLM hashes of passwords = bad security on passwords at rest

o   NTLM password hashes are used in support of MS-CHAP challenges and, I believe, NTLMv2 challenges.

o   Enabling NTLMv2 (and certainly MS-CHAP) may not invalidate “on the wire security”, but does appear to affect “passwords at rest” security.

o   Does BitLocker address this this case? We may have said that it does.

 

Sorry for adding confusion with my previous post.

 

--- Eric

 

From: [] On Behalf Of Eric Goodman
Sent: Wednesday, May 15, 2013 4:34 PM
To:
Subject: [AD-Assurance] RE: US-CERT as an authority on security - for alternative means - on NTLMv2

 

I still am concerned that storing the NTLMv2 hash is itself a problem, as it is unsalted MD4 (as I understand it) and not really strong enough. The NTLM challenge protocol over the wire any other protection is pretty broken; see https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ to get some warm fuzzies.

 

Cloudcracker came out in 2012, so was since the document you note below.

 

 

Side note related to eduroam in particular:

 

I had a back and forth with our networking folks about NTLMv2 use for eduroam. I was unaware that when used in eduroam, the NTLM challenge actually occurs within an encrypted channel (TLS tunnel). Given that, even though NTLMv2 itself is problematic its specific use in eduroam is not particularly vulnerable to eavesdropping on the wire. (I’m also ignoring that several PPTP clients store the plaintext password locally for purposes of generating the NTLM challenge, as that’s more a client than a server issue).

 

--- Eric

 

From: [] On Behalf Of Capehart,Jeffrey D
Sent: Wednesday, May 15, 2013 2:37 PM
To:
Subject: [AD-Assurance] US-CERT as an authority on security - for alternative means - on NTLMv2

 

Here’s a fairly recent (2011) document from the US CERT Cyber Alert System which says (in addition to following NIST SP800-53) that administrators should…

 

Consider adding the following measures to your password and account protection plan.

·         Use a two factor authentication method for accessing privileged root level accounts.

·         Use minimum password length of 15 characters for administrator accounts.

·         Require the use of alphanumeric passwords and symbols.

·         Enable password history limits to prevent the reuse of previous passwords.

·         Prevent the use of personal information as password such as phone numbers and dates of birth.

·         Deploy NTLMv2 as the minimum authentication method and disable the use of LAN Managed passwords.

·         Use minimum password length of 8 characters for standard users.

·         Disable local machine credential caching if not required through the use of Group Policy Object (GPO). For more information on this topic see Microsoft Support articles 306992 and 555631.

·         Deploy a secure password storage policy that provides password encryption.

 

http://www.us-cert.gov/ncas/alerts/TA11-200A

 

OK, so when CERT says “LAN Managed passwords” we’re savvy enough to know that means LM HASH.

 

CERT recommends using NTLMv2 and disabling LM hash. Both agree with the AD Cookbook.

 

The password composition, history, length, and dictionary-type checks speak to the entropy requirement in both Bronze and Silver profiles.

 

I think we have already determined that even for Bronze level passwords, the minimum entropy should be sufficient for Kerberos protocol to meet the Resist Replay, Resist Eavesdropper, Resist Hijack, weak MitM, etc.

 

US CERT has many more recommendations for general security, but the above may be reasonable as an authoritative reference to say that US CERT recommends NTLMv2 as a minimum, which should help in an alternative means proposal when developing the specific text to use for the assertion, or for the documentation for why and how regarding comparable or superior.

 

I can see that it may be challenging to claim that NTLMv2 is comparable or superior to Kerberos, and probably even tougher compared with Kerberos keys in the AES ciphers.  The RC4-HMAC issue comes up here too, as well as MD5.  Comparable in terms of being encrypted, yes.  Can a claim be made for strong enough encryption at 8 characters?  9?  12?  15?  It is clear that the algorithm is not approved.  Are there any comparable terms such as comparably strong cryptographic hashing?

 

Again, this is just one authority to reference when developing an alternative means proposal.  But it is one that actually says “Deploy NTLMv2 as the minimum.”

 

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

http://oia.ufl.edu