Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

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. A Protected Channel uses cryptographic methods that implement an Approved Algorithm to 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?]

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?]

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?]

 

-Jeff

From: [mailto:] 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 for 4.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
2. 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.