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
From:
[mailto:] On Behalf Of David Walker
Sent: Wednesday, March 27, 2013 6:33 PM
To:
Subject: Re: [AD-Assurance] RE: Questions for Microsoft?/Matrix updates
A couple of comments...
On Wed, 2013-03-27 at 22:26 +0000, Capehart,Jeffrey D wrote:
Regarding “I’ve assumed that the man-in-the-middle attack *is* relevant to the “resist replay” requirement. “
I have been keeping both the IAAF and the IAP up to cross-reference and refer back to these types of “does it apply here” questions. Here’s my color commentary.
Referring to IDMS operations, the framework (IAAF) says:
[on page 7] The security of communications between system components (IdP, IdMS, Verifier, etc.) is important. AProtected Channeluses cryptographic methods that implement anApproved Algorithmto provide integrity and confidentiality protection,
resistance to replay and man-in-the-middle attacks, and mutual authentication. For example, typical SSL/TLS implementations provide these protections.
[on page 9] For shared secret Credentials, e.g., userID/password, the IAP might address how the Authentication Secret must be sufficiently difficult for a person other than the Subject to determine through trial and error, or other means and must be protected
from illicit capture or replay.
Referring to the criteria, the assurance profile (IAP) covers protected channel in many places, but specific to Active Directory and authenticating by password see section:
4.2.5 AUTHENTICATION PROCESS
The Subject interacts with the IdP to prove that he or she is the holder of a Credential, enabling the subsequent issuance of Assertions.
4.2.5.1(S) (B)RESIST REPLAY ATTACK
The authentication process must ensure that it is impractical to achieve successful authentication by recording and replaying a previous authentication message.
4.2.5.2(S) (B)RESIST EAVESDROPPER ATTACK
The authentication protocol must resist an eavesdropper attack. Any eavesdropper who records all the messages passing between a Subject and a Verifier or relying party must find that it is impractical to learn the Authentication Secret or to otherwise obtain
information that would allow the eavesdropper to impersonate the Subject.
4.2.5.3(S) (B)SECURE COMMUNICATION
Communication between Subject and IdP must use a Protected Channel. [Q: If you do this for all authentications, then isn’t everything in 4.2.5 covered?]
Hmmm... Yes, that does seem right. As I remember, this section was revised during the FICAM negotiations; maybe some redundancy crept in.
4.2.5.4(S) (B)PROOF OF POSSESSION
The authentication process shall prove the Subject has possession of the Authentication Secret or Token. [Q: Does just knowing the right password count?]
Yes.
4.2.5.5(S) (B)RESIST SESSION HIJACKING THREAT
Session maintenance methods implemented by the IdP shall resist session hijacking.
And, if you have to LOGON to change your password, then this may come into play too?
4.2.4 CREDENTIAL ISSUANCE AND MANAGEMENT
4.2.4.5(S) (B)RESIST TOKEN ISSUANCE TAMPERING THREAT
The process or processes used by the IdPO in 4.2.4.1, 4.2.4.2, and 4.2.4.3*** must enable the Subject to verify that the IdPO is the source of any token or Credential data they receive.
***(ISSUANCE, REVOCATION OR EXPIRATION, RENEWAL OR RE-ISSUANCE)
And don’t forget Bronze…
4.2.3.5 […] Plaintext passwords or Secrets shall not be transmitted across a network.
And one more Silver…
4.2.3.6 […] Whenever Authentication Secrets used by the IdP (or the IdP’s Verifier) are sent between services for verification purposes (for example, an IdP to a Verifier, or some non-IdP application to a Verifier), Protected Channels should be used, but Protected
Channels without client authentication may be used. [Q: So what are protected channels without client authentication… IPSec? SSL?]
I assume this means use of Protected Channels, but without caring if the client does not authenticate properly. There are certainly plenty of SSL deployments that do this. I've never
really thought about IPsec, though; does anybody know? I could imagine that it would depend on what options you select in your IPsec deployment.
-Jeff
From:
[]
On Behalf Of Eric Goodman
Sent: Wednesday, March 27, 2013 5:32 PM
To:
Subject: [AD-Assurance] RE: Questions for Microsoft?/Matrix updates
I’ve been looking at the documents Brian sent as background for my task of updating the last three IAP elements in the Requirments and Gaps chart, especially for4.2.5.1 - Resist Replay Attack (B, S)
It looks like the main Kerberos authentication vulnerability in a Windows-native environment is man-in-the-middle attacks. Quoting:
“This [Windows’ caching of used credentials to prevent replay] makes replay attacks more difficult…the attacker must now use an active man-in-the-middle attack”
To my way of thinking, a man-in-the-middle attack is a completely different kind of attack than a replay attack; prior to reading this I would not have put any “man in the middle” attacks in the risk column for “resist replay attacks”. Should I include man-in-the-middle
attacks here? Once you’ve got a man in the middle attack scenario, you’re at risk for more than just replay attacks….
The second link describing Kerb armoring/FAST settings make it sound like it’s only reliably relevant to security when there are Windows 2012 domain controllers in the domain AND the clients are running Windows 8, which is no doubt an uncommon combination at
the current time. So I’m not clear this is a viable configuration recommendation at this point. Either way, I don’t think it’s an Alternate Means, and so it would go in the base AD Silver cookbook.
Finally, all of the links refer to authentication based on Kerberos. Brief Googling finds many papers that indicate that NTLMv2 (and of course the other less secure authentication models) are all susceptible to replay and reflection attacks, so likely fail
that test without further mitigation (e.g., protected channel, or some such).
In any case, I’ve made some notes in the matrix. In doing so, I’ve assumed that the man-in-the-middle attack *is* relevant to the “resist replay” requirement.
--- Eric
From:
[]
On Behalf Of Brian Arkills
Sent: Monday, March 25, 2013 9:00 AM
To: ''
Subject: [AD-Assurance] RE: Questions for Microsoft?
Ah, I stuck some of those links in the original InCommon AD cookbook:
-
http://technet.microsoft.com/en-us/library/cc784130(WS.10).aspx
-
http://users.tkk.fi/u/autikkan/kerberos/AIWSC03_kerberos_replay_attacks.pdf
But it looks like the 2nd link I had included--which describes how one could execute a MITM replay against Kerberos--is now dead. A replacement link for that is at:
http://csis.bits-pilani.ac.in/faculty/sundarb/courses/old/spr06/netsec/evals/project/projrefs/kerb/AIWSC03_kerberos_replay_attacks.pdf
The paper suggests several possible mitigations. And note that the 1st link is one of the usual suggested mitigations, which the paper says is insufficient to protect against these attacks.
RFC 4120 describes a Kerberos pre-auth framework which can be used to protect the initial session key exchange. Microsoft implements this in WS12:
http://technet.microsoft.com/en-us/library/hh831747.aspx, and conveniently turning that support on is required for many of the WS12 features.
From: Brian Arkills
Sent: Sunday, March 24, 2013 7:28 PM
To:
Subject: RE: Questions for Microsoft?
From:
[]
On Behalf Of Capehart,Jeffrey D
Sent: Thursday, March 21, 2013 12:19 PM
To:
Subject: [AD-Assurance] Questions for Microsoft?
Is there a list of questions for Microsoft prepared yet?
Kerberos Authentication for Microsoft Active Directory
http://technet.microsoft.com/en-us/library/cc780469(v=ws.10).aspx
· Kerberos Authenticator Prevents Packet Replay
[BA] Windows domain controller issued Kerberos tickets can be subjected to man-in-the-middle replay attacks, unless you've deployed WS12 domain controllers and turned on the FAST feature, sometimes also called Kerberos armoring. Somewhere I've got a link
that explains how to exploit this. And it should be easy enough to find the RFC and MS documentation that talks about this mitigating new feature/extension.
