Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

This is quite an insightful realization.  In much the same way, the 4.2.5.5 “Session Hijack” seems to apply only to web-based single-signon like Shibboleth/cookies/HTTP requests.

 

The details of where the MITM risks come from are actually better described in the NIST SP 800-63-1 E-Auth document in chapter 8.   (portion included below)

 

For Level 2 Assurance, only need “weak” MITM resistance is required.  Note the specific part in example 1 about “The Claimant is tricked into encrypting his or her password so that the Attacker can decrypt it.”

 

Would that apply to Active Directory?  If you can decrypt the password, that is a much higher risk than if you can just take over the session or replay the hash.

 

I did not see MITM specifically listed in the IAP, but perhaps it would fit under 4.2.8.2 or maybe 4.2.4.5?  The IAAF mentions MITM threat as being covered by a Protected Channel, so if you don’t have a protected channel, the only other ways listed are zero-knowledge password protocols which NTLM is not, but Kerberos is pretty close?

 

-Jeff

 

Man-in-the-middle

(Short) Description:

The Attacker positions himself or herself in between the Claimant and Verifier so that he or she can intercept and alter the content of the authentication protocol messages. The Attacker typically impersonates the Verifier to the Claimant and simultaneously impersonates the Claimant to the Verifier. Conducting an active exchange with both parties simultaneously may allow the Attacker to use authentication messages sent by one legitimate party to successfully authenticate to the other.

 

Example 1

An Attacker breaks into a router that forwards messages between the Verifier and a Claimant. When forwarding messages, the Attacker substitutes his or her own public key for that of the Verifier. The Claimant is tricked into encrypting his or her password so that the Attacker can decrypt it.

 

Example 2

An Attacker sets up a fraudulent website impersonating the Verifier. When an unwary Claimant tries to log in using his or her one-time password device, the Attacker’s website simultaneously uses the Claimant’s one-time password to log in to the real Verifier.

 

LONG DESCRIPTION

Man-in-the-middle resistance – Authentication protocols are resistant to a man-in-the-middle attack when both parties (i.e., Claimant and Verifier) are authenticated to the other in a manner that prevents the undetected participation of a third party. There are two levels of resistance:

            Weak man-in-the-middle resistance – A protocol is said to be weakly resistant to man-in-the-middle attacks if it provides a mechanism for the Claimant to determine whether he or she is interacting with the real Verifier, but still leaves the opportunity for the non-vigilant Claimant to reveal a token authenticator (to an unauthorized party) that can be used to masquerade as the Claimant to the real Verifier. For example, sending a password over server authenticated TLS is weakly resistant to man-in the middle attacks. The browser allows the Claimant to verify the identity of the Verifier; however, if the Claimant is not sufficiently vigilant, the password will be revealed to an unauthorized party who can abuse the information. Weak man-in-the-middle resistance can also be provided by a zero-knowledge password protocol, such as Encrypted Key Exchange (EKE), Simple Password Exponential Key Exchange (SPEKE), or Secure Remote Password Protocol (SRP), which enables the Claimant to authenticate to a Verifier without disclosing the token secret. However, it is possible for the Attacker to trick the Claimant into passing his or her password into a less secure protocol, thereby revealing the password to the Attacker. Furthermore, if it is unreasonably difficult for the Claimant to verify that the proper protocol is being used, then the overall authentication process does not even provide weak man-in-the-middle resistance (for example, if a zero-knowledge password protocol is implemented by an unsigned java applet displayed on a plaintext HTTP page).

 

Special Publication 800-63-1 Electronic Authentication Guideline

 

From: [mailto:] On Behalf Of Brian Arkills
Sent: Friday, March 29, 2013 5:02 PM
To:
Subject: RE: [AD-Assurance] RE: Questions for Microsoft?/Matrix updates

 

This is an interesting stance, and one I could imagine we'd be able to claim as well. One thing that helps insulate against this is that in our environment there is no ability to change an account's password (the account at our IdP or even the Windows account itself) with a Windows logon token, i.e. passwords flow in only one direction to AD-DS in our environment.

 

From: [] On Behalf Of Ron Thielen
Sent: Friday, March 29, 2013 1:00 PM
To:
Subject: RE: [AD-Assurance] RE: Questions for Microsoft?/Matrix updates

 

I’ll belatedly weigh in with my 2 cents specifically regarding MITM and replay attacks.  A man in the middle attack is only relevant to the resist replay requirement if the man in the middle attack allows the attacker to obtain credentials that can then be replayed.  If the MITM attack allows the attacker to grab a credential which is then brute forced with “John the Ripper” or some other such tools, that  doesn’t make it a replay attack.  A replay attack would be something like a “pass the hash” attack where all you have to do is hand the hash to the service to which you want to gain access.  So, I think I am more or less with Eric on this.

 

However, I think that it is likely that in many of our Silver implementations a successful replay of a user’s NTLM hash wouldn’t necessarily compromise their Silver credentials.  In our case, all of our services that compromise the IdP and verifier are based on Shibboleth and our LDAP service.  AD/DS is part of the IdMS but not part of the IDP.  Successfully stealing someone’s NTLM hash and using it to access any of our Windows based services would not affect the validity of the userid and password for accessing services using LDAP as the verifier.  I realize that your mileage may vary, but that’s the stance I am taking.  Each organization would have to conduct their own risk assessment in this regard.

 

Ron