Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

From Eric...

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.

Remember that, while FICAM really seems to like InCommon, its focus is largely on the big identity providers like Google, not enterprise-level identity management.  I'm not sure it would bother them all that much if some universities have trouble with AD; it's just not that large a segment to them.

Also, Ann can correct me on this, but we don't propose our alternative means to FICAM; that process is internal to InCommon.  FICAM trusts us to make good decisions about alternative means.  Where it could get us in trouble, though, is when we need to recertify as a trust provider,  so we need to make sure that our reasoning is defensible.

I think all of this brings us back to understanding what Microsoft is doing, and for them to understand where we're going.  As someone observed, their answer might be that everyone needs to upgrade to Windows 8.  That would be a sad answer for us, but we're also a small segment for Microsoft, putting us between a rock and a hard place.

Anyway, I don't think we're out of options yet; we've got some good paths to explore.  We also haven't considered relaxing our requirement to use AD-stored passwords for Silver compliance.  For institutions that do not need to vet very many people for Silver, something like PhoneFactor (now owned by Microsoft), Duo, or Yubico might be a good alternative, if it can be integrated into AD cheaply and easily.

David

On Thu, 2013-04-18 at 13:27 +0000, Curry, Warren wrote:

I concur.   Going to FICAM etc would be a nearly worst case …

 

WHC

 

Warren H. Curry

UFIT – Identity Access Management

PO Box 113359,  2008 NE Waldo Rd

352-273-1383

 

Have a great day!!!

 

From: [mailto:] On Behalf Of Ann West
Sent: Thursday, April 18, 2013 8:54 AM
To:
Subject: Re: [AD-Assurance] Friday's call

 

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