Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

We've been getting into a lot of details recently, and I'm afraid we may lose our way.  Stepping back a level or two, here's where I think we are:

• The document we need to comply with is the InCommon IAP.  Other documents from Kantara, FIPS/NIST, etc. are useful for comparison, but we don't need to comply with them.
• When thinking about potential alternative means proposals, we should be thinking about the intent of the IAP, not necessarily its specific wording.  As one of the IAP's authors, I can tell you that we might have said things that we didn't really mean.

Applying this thinking to the "requirements and gaps" matrix on the wiki ( https://spaces.internet2.edu/x/BA8wAg ), I think we need to address the following issues:

• Credentials (passwords) used for Silver-level authentication must be protected wherever they are used.  We don't care about other credentials.  This is addressed in 4.2.3.4 (mitigated by full disk encryption), 4.2.3.5 and 4.2.3.6 (mitigated by elimination of insecure protocols and/or monitoring for their use), and 4.2.8.2.1 (I don't think we've identified a problem here).
• Sessions between an IdMS and its Subjects in support of identification / registration / credentialing / authentication processes must resist replay and eavesdropping.  We don't care about other sessions.  This is addressed in 4.2.5.1 and 4.2.5.2.  While we know that RC4-HMAC is weaker than we'd like it to be, I still believe that it renders replay and eavesdropping "impractical."  I agree with Eric that this might become "practical" within a few years, but so might many of our technical mitigation strategies.  We can certainly provide information about where we think AD is marginal.

Sound reasonable?  It's fascinating to dive into all these standards documents in such detail, but I fear it may be distracting from our purpose.

(I do think, though, that we need to do some detail-level due diligence with Microsoft.  I'll send a separate note about that.)

David


On Tue, 2013-04-30 at 16:57 +0000, Eric Goodman wrote:

I was calling out that the Kantara Specs, while looser, are just as vague as InCommon’s or 800-63 as it applies to the definition of “equivalent” algorithms.

 

That said, I recognize that I’m not really adding anything to the conversation by calling this out; we’re all clear that this is still the sticking point. David called out several threads ago that we need to either recommend AD/RC4-HMAC be considered a FIPS 140-2 equivalent, or we need to ask Microsoft for an alternative, and Jeff has already provided proposed language that AD/RC4-HMAC be considered “good enough” through 2015, pending any breaches in the meantime.

 

I think I’ve been convinced for a while that RC4 is “good enough” for today. My hesitation in whole-heartedly supporting Jeff’s recommendation is that it sounds like RC4 strength against attacks is falling off fairly quickly, and it seems that there could well be an attack between now and 2015(ish) that could further compromise RC4 to the point where it’s not sufficient for Silver purposes.

 

Should such an event occur, anyone who has implemented an AD-DS-based IdP solution using the RC4-based elements would be dependent on Microsoft to provide a new solution (patches, etc), or could face a very challenging requirement of overhauling their Microsoft environment (e.g., pervasive Windows 8/2013 upgrades). Is there a reasonable warning/risk notice we could add to any Alternate Means language that would appropriately call out the (my?) perceived risk? Is that even appropriate for AM language? Or are we even in agreement that this is a real risk, as compared to a hypothetical that could apply as well to AES mechanisms?

 

The conversation with Microsoft may help with this part of my concern.

 

--- Eric

 

From: [mailto:] On Behalf Of Ann West
Sent: Tuesday, April 30, 2013 9:11 AM
To:
Subject: Re: [AD-Assurance] Applying FISMA to 800-63

 

All,

 

Kantara spec is technically comparable to ours and 800-63 and has been reviewed by FICAM as well. If they interpret things a bit looser in the requirements, it's a big clue that we can follow suit. 

 

-------

I do note that this is a little looser than what we’ve been discussing, as it only applies to intra-IdP-service communication over public and unsecured networks.

 

--- Eric