Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

FWIW, it’s HMAC_MD5 used in NTLMv2, not HMAC_RC4 [1]. (I think I’ve been saying that wrong.) (Kerberos does frequently use HMAC_RC4)

 

Both Kerberos[2] and NTLMv2[1] use the user password as the key for encrypting/hashing (respectively) other data used for user authentication, and this encrypted/hashed data is what’s on the wire. So again, the password is not itself included or encrypted/hashed in the communication, but brute force password guessing against the information on the network may be possible. Given that the data being encrypted in the on-the-wire packet is known, and you have the ciphertext, you can repeat the encryption/hashing operation with all possible passwords looking to get a match to the credentials that are online in an offline attack. (This is where the 2^80 operations language probably applies – how many operations does it take to brute force one password, times the entropy of the password).

 

So re-reading everything, I believe the concern calling out Kerberos in 800-63-2 is NOT the encryption algorithm (though that may be a separate problem) but that the authentication information itself is encrypted directly with the user’s password in a known manner. That is, even if AES was used, it’s used in a known way that’s brute-forceable.

 

I also read a bunch about Kerberos Armoring/FAST [3], and it’s clear that this technology is intended to protect Kerberos somewhat against offline brute-forcing of credentials, but as I read it (and here I’m very unclear whether I’ve read it right), Armoring/FAST protects against TGT-request-based attacks and not eavesdropping.

 

In normal Kerberos, any client can request a TGT for a user, which is delivered encrypted by the user’s password. In this way, Kerberos allows any attacker to request attackable credentials (i.e., they don’t have to eavesdrop on a client, just ask for credentials)[4]. When Armoring/FAST is used, the KDC will not return a TGT to the client unless the TGT request itself is successfully encrypted with the user password. That implies to me that an attacker cannot just ask the KDC for a ticket and mount an attack, but should an attacker eavesdrop on the FAST-TGT request, they still have a packet they can brute force attack.

 

Don’t know that any of this helps us, but the more I read this, the more I think this isn’t an “approved algorithm” for protecting the password issue, but is instead an issue of whether the protocol itself exposes the password in a way that is practical/impractical to attack.

 

--- Eric

 

[1] http://en.wikipedia.org/wiki/NTLM#NTLMv2

[2] http://tools.ietf.org/html/rfc4120

[3] http://tools.ietf.org/html/rfc6113

[4] http://tools.ietf.org/html/rfc4120#section-10 (search for the text “off-line” in this section)

 

 

 

 

From: [] On Behalf Of David Walker
Sent: Monday, June 24, 2013 2:41 PM
To:
Subject: Re: [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call

 

Thanks, Jeff.  Regarding...

Other places where RC4 are used would be for syskey (protecting the password store) and in some cases HTTPS where the protocol is using the RC4 cipher.

I think we've decided that RC4 is not strong enough for encryption of the password store (hence the BitLocker recommendation), but its use in NTLMv2, Kerberos (and HTTPS?) is still in question.

David

On Mon, 2013-06-24 at 21:30 +0000, Capehart,Jeffrey D wrote:

Regarding:

There was continued discussion of the "practicality" of cracks against RC4. We will need to resolve those issues after a discussion with Microsoft to explore the likely effectiveness of their response to a "practical" attack.

 

I did not think the eavesdropping/hash capture/offline cracking attacks were limited to RC4, but if we are strictly speaking of NTLMv2 and RC4-HMAC (used in Kerberos) then I can see those as concerns.

 

Here’s what Microsoft says on the MSDN regarding NTLM:

5.1 Security Considerations for Implementers

http://msdn.microsoft.com/en-us/library/cc236715.aspx

 

Implementers should be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check (CRC) or message digest algorithms ([RFC1321]) for integrity, and it uses RC4 for encryption. Deriving a key from a password is as specified in [RFC1320] and [FIPS46-2]. Therefore, applications are generally advised not to use NTLM.

 

Other places where RC4 are used would be for syskey (protecting the password store) and in some cases HTTPS where the protocol is using the RC4 cipher.

 

Jeff C.

From: [] On Behalf Of David Walker
Sent: Monday, June 24, 2013 3:58 PM
To: InCommon AD Assurance Group
Cc: DHW
Subject: [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call

 

Everyone,

I've posted quick notes from last Friday's call on the wiki:  https://spaces.internet2.edu/x/DBFOAg .

When I sat down to do this today, I found that my notes from Friday were pretty sketchy, so please enhance the notes as you see fit.

David