Subject: Meeting the InCommon Assurance profile criteria using Active Directory
- From: "Capehart,Jeffrey D" <>
- To: "" <>
- Subject: [AD-Assurance] Man-in-the-middle resistance
- Date: Fri, 29 Mar 2013 21:52:30 +0000
- Accept-language: en-US
- Authentication-results: sfpop-ironport01.merit.edu; dkim=neutral (message not signed) header.i=none
This is quite an insightful realization. In much the same way, the 126.96.36.199 “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 188.8.131.52 or maybe 184.108.40.206? 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?
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.
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.
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.
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
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.
- [AD-Assurance] Man-in-the-middle resistance, Capehart,Jeffrey D, 03/29/2013
Archive powered by MHonArc 2.6.16.