Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

The cookbook can be quite a bite to chew which may impact how many assurance list members take time to review it for comments.

 

If we had a brief overview of key points and then anyone who had questions could refer to the cookbook for details, that might help stir interest in taking a look.

 

For example, the nutshell version could be just pulling out section 3, which is still quite a bit for an email message.  Even this could be modified or reduced to get the message across and stimulate discussion and feedback.

Jeff

3. Approach and Overview of Findings

We found that the following sections in the IAP 1.2 sections involve impacts that are technology-specific to the use of Active Directory Domain Services:

• 4.2.3.4 Stored Authentication Secrets
• 4.2.3.6 Strong Protection of Authentication Secrets
• 4.2.5.1 Resist Replay Attack
• 4.2.5.2 Resist Eavesdropper Attack
• 4.2.8.2.1 Network Security

The most common issue we identified in achieving compliance with these sections when using AD-DS is the requirement that systems use "Approved Algorithms" and "Protected Channels" for all authentication interactions. This requirement limit the allowable encryption mechanisms to those that conform to a specified published list of algorithms (see FIPS 140-2, Security Requirements for Cryptographic Modules). AD-DS is capable of supporting several protocols that are not on the Approved Algorithms list. At a very high level the recommendations in this document aim to achieve a compliant configuration through the following methods:

• Eliminating, restricting or monitoring the use of Windows-supported non-Approved Algorithms by methods such as:

       Disabling support of certain protocols domain-wide

       Limiting support of certain protocols to accounts that are not authenticated to the IdP

       Monitoring for use of non-Approved Algorithms by specific account holders and responding to such use by removing Silver certification for that account. (Credit to David Langenberg, University of Chicago, for proposing this method)

• Strictly limit the methods used to interactively authenticate with the IdP, to reduce the number of protocols that could be leveraged by an attacker monitoring or manipulating network traffic

       E.g., not relying on NTLMv2 or Kerberos tickets for authentication to the IdP, while allowing use of those protocols for non-IdP applications.

• Identify mechanisms that layer "Approved Algorithms" for encryption "on top of" the non-Approved Algorithms supported by AD

       E.g., encrypting the volume on which the AD-DS stores its passwords, given that AD-DS' default encryption method is a non-Approved Algorithm

Much more detail is provided in the sections below, but this outlines the general approach taken in seeking to define and describe an InCommon Silver-compliant AD-DS environment.

 

 

From: [mailto:] On Behalf Of Ann West
Sent: Tuesday, January 28, 2014 5:19 PM
To:
Subject: [AD-Assurance] update

 

Hi all,

 

As you may have noticed, I extended the comment deadline until Friday. We have not (AFAIK) received any feedback. Nick mentioned that he would provide some information tho.

 

As David mentioned, if you'd like to get the AAC to weigh in on the interpretation section, it would be good to let them know.

 

I pinged Microsoft again today regarding their review and all things look positive. My sincerest hope is that "they" (meaning y'all on the list) will work with us on this effort. ;)

 

Best,

Ann