Skip to Content.
Sympa Menu

ad-assurance - RE: [AD-Assurance] RE: Questions for Microsoft?/Matrix updates

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

RE: [AD-Assurance] RE: Questions for Microsoft?/Matrix updates


Chronological Thread 
  • From: Ron Thielen <>
  • To: "" <>
  • Subject: RE: [AD-Assurance] RE: Questions for Microsoft?/Matrix updates
  • Date: Fri, 29 Mar 2013 20:00:05 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport04.merit.edu; dkim=neutral (message not signed) header.i=none

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:

  1. http://technet.microsoft.com/en-us/library/cc784130(WS.10).aspx
  1. 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.

 




Archive powered by MHonArc 2.6.16.

Top of Page