Meeting the InCommon Assurance profile criteria using Active Directory

[Ann West <>]

I would hope that FICAM would be a very remote option. Negotiations could take months and given our discussion yesterday, affect 800-63 as much as the FICAM program. This option is extreme in my book and only happens if we have no place to turn.

Agree with David that the next step is finishing off our matrix, developing our questions for MS and engaging Dean to confirm our identified gaps and mitigation strategies, requesting that he take the remaining issues back to MS for discussion. Once we hear back, we can proceed on deciding  whether we can assemble a "good enough" set of solutions, maybe with short and long term time frames. 

Ann

From: Eric Goodman <>
Reply-To: "" <>
Date: Wednesday, April 17, 2013 8:56 PM
To: "" <>
Subject: RE: [AD-Assurance] Friday's call

I think this is a good re-orienting suggestion.

 

I lean towards proposing #4 directly with FICAM, perhaps in combination with the “monitor and mitigate” approach. I have a hard time believing that FICAM would blanket refuse AD-based solutions for 800-63/Silver LoA2 certification, as that would be a major blow to adoption.

 

I’m not at all a fan of lowering security for ease of implementation, but I really have to wonder whether campuses that use AD would ever apply for Silver certification if AD was ruled out based on what we’ve found. I would think that this would be a fairly drastic step, and/or would need to be done based on positive evidence of AD being a problem.

 

Even if your first strategy (ask Microsoft for a solution) works, it sounds like there’s a very good chance the solution will include “upgrade all of your workstations to Windows 8”, which would likely go over just as well at the campus level as forbidding AD outright.

 

If we do get the okay on #2 + #4, can InCommon develop (or host) utilities that would assist in doing the required monitoring?

 

I believe the suggestion of “higher entropy passwords” was two-fold: (a) it creates potentially greater challenges to brute force decrypting and (b) older NTLM style hashes can only be created for 14 character or shorter passwords. Essentially, I think they were partially saying that selecting a 15 character password implicitly disables many of the lower security mechanisms, even if your AD domain policy does not enforce stronger methods on a global level.

 

--- Eric

 

 

From: [] On Behalf Of David Walker
Sent: Wednesday, April 17, 2013 2:47 PM
To:
Cc: DHW
Subject: [AD-Assurance] Friday's call

 

Everyone,

Given what we just learned this afternoon (that NASA has not certified their AD to 800-63, LoA-2), I propose we talk on Friday about high-level strategies for getting AD ready for Silver.

We've got at least the following strategies we can apply to IAP sections that give us trouble (i.e., ones for which we can't just describe an AD configuration that complies):

• Ask Microsoft for a solution.  I suspect we won't discover anything we don't already know, but we should ask.  Microsoft might be able to tell us of future plans to resolve the issue.
• Apply Ron's "monitor and mitigate" alternatives means.
• Require passwords with higher entropy?  This only works if AD's technical weaknesses are riskier for shorter/less complex passwords.  (I'm not nearly enough of a cryptographer to know.)
• Weaken Silver by allowing something that 800-63 does not.  This is suboptimal and may not pass FICAM (may not even pass the AAC, I suppose).
• Temporarily weaken Silver by allowing something that 800-63 does not, for a limited period of time.  This might work if Microsoft has a solution waiting in the wings and FICAM is being moderately generous.

Other ideas for approaches?  Here are the IAP sections in our table.  I've included what I think our strategy is when I know it.

• 4.2.3.4 - Stored Authentication Secrets (S).  Use AD on top of Bitlocker or some other compliant full-disk encryption.
• 4.2.3.5 - Basic Protection of Authentication Secrets (B).
• 4.2.3.6 - Strong Protection of Authentication Secrets (S).
• 4.2.5.1 - Resist Replay Attack (B, S).  Monitor and mitigate alternative means (assuming approval).
• 4.2.5.2 - Resist Eavesdropper Attack (B, S).  Monitor and mitigate alternative means (assuming approval).
• 4.2.8.2.1 - Network Security (S). Monitor and mitigate alternative means (assuming approval).

Could we use "monitor and mitigate" for 4.2.3.5 and 4.2.3.6?  Higher entropy passwords?  Does Microsoft have something coming up that would help us?  Other ideas?

Looking forward to Friday's discussion.

David