Meeting the InCommon Assurance profile criteria using Active Directory

[Brian Arkills <>]

I agree about disagreeing with the prior group. As someone who participated significantly in the prior group, I think we've done our homework more thoroughly this time around, and had quite a bit more participation with a diverse set of skills and experience.

 

I have always thought the structure of the original AD cookbook was not optimal and near the late stages of the prior effort I tried to apply some minor changes to improve the structure, but ultimately, I think the structure wasn't effective, and I lacked enough time to be more aggressive in restructuring. I know Nick Roy, who was a key contributor in the prior effort, was very open to having the document restructured as needed.

 

I think it's far more important to have a well-organized and accurate document, than worry too much about what's come before. So I'd encourage a more drastic restructure, with as much slashing and burning as needed. ;)

 

From: [mailto:] On Behalf Of David Walker
Sent: Friday, May 17, 2013 8:32 AM
To:
Subject: Re: [AD-Assurance] RE: Action Items from May 10

 

Eric,

This is good stuff.  As a general comment, I think it's fine for us to disagree with the earlier cookbook group.  I say we go ahead with the changes we feel are appropriate and ask them to review our version when we get to a point where it's reviewable.

Some further comments below...

David

On Fri, 2013-05-17 at 02:02 +0000, Eric Goodman wrote:

• Eric to take a first cut at reviewing the Cookbook and develop recommendations for what to keep, cut, and edit.

 

So this one turned out to be quite a bit more challenging than I expected. (It didn’t help that I didn’t really get started on it until today).

 

My edits were – probably unwisely – made on a second copy of the original cookbook (Called “Working copy of …” rather than just the AD cookbook title).

 

https://spaces.internet2.edu/display/InCAssurance/Working+copy+of+InCommon+Silver+with+Active+Directory+Domain+Services+Cookbook+-+May+2013

 

This resulted in page to be harder to find, without adding any value since Confluence would have saved the original pre-edit version anyway. If I can figure out how to move my copy back into the original one, I’ll do that and delete this alternate copy.

 

 

In any case, some major disagreement between the AD cookbook analysis and the Alternative Means strategies we identified around stored passwords. Specifically, the AD cookbook states that the specification of the use of salt is over-prescriptive and basically states that the entire requirement (of using a salt, or on access encryption) is unnecessary. Therefore there is no clear “stub” for us to note the need of Bitlocker (though the use of Bitlocker is encouraged). This conclusion is largely due to the Cookbook misapplying (in my estimation) the entropy requirements against brute force password guessing to the protection of passwords at rest (see my comments in the doc).

I agree that password entropy and encryption at rest are not interchangeable.  I think we can state that as a disagreement with the earlier group and make our Bitlocker statement.

Because the risk assessments are so out of phase with one another in the area of stored passwords, I didn’t see how to put in our commentary without completely rewriting (and revising) the original AD cookbook suggestions, which I think bears more discussion – or at least we should alert the original group that we disagree – before actually making any edits of that magnitude.

I think we agreed to keep a copy of the 2012 Cookbook.  We should feel free to make any changes we see as needed.  As I said, we can ask for the earlier group's input.

On the other areas, we mostly agreed; I added a couple of comments, but there’s still lots of room for editing what I added. E.g., I say “add some of Jeff’s references here” rather than actually having selected his best references. I’m willing to do that addition as well, I just didn’t get to it at this point.

 

I’d like to see the document better formatted to clarify what sections are background info, what are specific operating configuration recommendations, and what is language to use to assert (non-AM) compliance, but I haven’t quite sussed out how to do that yet. For now, I squeezed in our two main additional differences (Require Bitlocker, require invalidating subjects using insecure authentication protocols), and tagged the base disagreements between the two groups. In the doc, my comments are identified with text inside of <<double angle brackets>>.

 

--- Eric