ad-assurance - RE: [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call
Subject: Meeting the InCommon Assurance profile criteria using Active Directory
List archive
- From: Eric Goodman <>
- To: "" <>
- Subject: RE: [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call
- Date: Wed, 26 Jun 2013 17:27:13 +0000
- Accept-language: en-US
- Authentication-results: sfpop-ironport02.merit.edu; dkim=neutral (message not signed) header.i=none
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 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.
Regarding:
|
- [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call, David Walker, 06/24/2013
- RE: [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call, Capehart,Jeffrey D, 06/24/2013
- Re: [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call, David Walker, 06/24/2013
- RE: [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call, Eric Goodman, 06/26/2013
- Re: [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call, David Walker, 06/24/2013
- RE: [AD-Assurance] Notes from last Friday's (6/21/2013) AD Assurance call, Capehart,Jeffrey D, 06/24/2013
Archive powered by MHonArc 2.6.16.