Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

I’m certainly with you up to the last two bullets. Once we get there I’m only hesitant to start defining “strong” too specifically in the absence of a definition in the IAP. So I don’t think I’m disagreeing with your actual point, but I’d be more inclined to use language that’s more objective than interpretive of the IAP:

• NTLMv2, MS Kerberos (and others?) fall between the strength of NTLMv1 and Protected Channels (identified as strong by the IAP). For purposes of this Cookbook, we presume these to be “strong enough” to meet the strength requirements of the IAP.
• Other factors affect protection overall.  For example, longer, more complex passwords can make some protocols more resistant attacks.

All I’ve done is change from talking about whether things are strong per the IAP to talking about relative strength of protocols. It’s my wishy-washy nature to not make assertions that I’m not the final authority for and that haven’t been approved by anyone who claims to be the final authority.

 

This is the one where I have the most hesitation:

• Use of these protocols (Kerberos, NTLMv2) for Silver compliance should be accompanied by a strategy for migration to stronger protocols in the future.

My hedging thoughts:

1)      Again referring to the conversation on the Assurance list around FICAM v NIST v InCommon, this will only be necessary to the extent that InCommon adopts the stricter language in FICAM TFPAP 2 or NIST 800-63-2

2)      Realistically, I don’t see that it’s possible to stop use of these protocols in a Windows environment unless Microsoft changes something drastically.

a.       That said, I agree that you could mitigate Kerberos’ main vulnerability by increasing required user password complexity/entropy (which you already addressed). Perhaps NTLMv2 attacks similarly would benefit from increased password complexity? (I’m thinking Ron or Jeff might know more about that than I do.)

 

--- Eric

 

 

 

From: [mailto:] On Behalf Of David Walker
Sent: Wednesday, April 02, 2014 8:44 AM
To:
Subject: Re: [AD-Assurance] RE: AD Silver Comment - AAC Response

 

This all sounds good to me.

Regarding the advice on protocols that are "strong" enough, I would suggest a message something like

• The IAP does not define "strong," in the context of protection of authentication secrets.  Strict interpretation is left to you and your auditors.  We do, however, offer this advice.
• Protected Channels, as defined in the IAAF, are strong, even Protected Channels without client authentication are strong.
• NTLMv1 (and others?) are not strong.  Their vulnerabilities are too well known and exploited.
• NTLMv2, MS Kerberos (and others?) are strong, but marginally so.  Their vulnerabilities are known but (currently) not widely exploited.  Use of these protocols for Silver compliance should be accompanied by a strategy for migration to stronger protocols in the future.
• Other factors affect protection overall.  For example, longer, more complex passwords may require less strength, depending on the protocol.  (Other examples?)

Sound reasonable? 

David

 

On 04/01/2014 01:54 PM, Eric Goodman wrote:

Ahh, further good point on your end. It starts making sense to me why 800-63-2 moved to password requirements around “absolute minimum entropy requirements plus fixed numbers of guesses per unit time”, as compared to the old “entropy divided by total guesses” rules. (I’m somewhat conflating the “online” (32ish bits of entropy) and “offline” (80 bits of entropy) guessing problems here, but it may be related…).

 

This is the kind of example I was thinking about (but couldn’t articulate) when I was grilling David and Ann on another list about how much newer NIST/FICAM guidelines might impact IAP planning.

 

--- Eric

 

 

 

From: [] On Behalf Of Capehart,Jeffrey D
Sent: Tuesday, April 01, 2014 1:38 PM
To:
Subject: RE: [AD-Assurance] RE: AD Silver Comment - AAC Response

 

Good point Eric, regarding strong protection.  I think we have an opportunity here to identify (in the cookbook) the protocols used by AD that we would consider “strong” for the “strong protection of authentication secrets”.

 

Now, grant you, strong encryption can be made weak by using a short, human generated password when cracking via off-line guessing.  So, that said, do we need to also consider some “’entropy” concerns as well to go along with “strong” that are at least the minimum entropy required for online guessing, but might there need to be higher entropy for the protection to be strong enough?  This is where maybe a 12 char password is better than an 8 char.   These extra cookbook requirements would not be there solely to meet the IAP entropy, but to meet sufficient strength for non-IdP authentication.  Also there could be a mix rather than a hard set limit of # chars, complexity, character set count, etc.

 

My point is that the secrets aren’t going to be foolproof, but they need to have strong protection and resistance, and I think that would be excellent guidance for the cookbook to make.

 

Think of it like a dartboard or target where a bull’s-eye is the best, 10 points.  Next ring is 9 points, then 7 points.  If you are below X points or maybe not even on the board, then that isn’t good enough.  If it is easy to figure out if you are compliant, then it will be easy to audit too.

Jeff

 

From: [] On Behalf Of Eric Goodman
Sent: Tuesday, April 01, 2014 4:21 PM
To:
Subject: RE: [AD-Assurance] RE: AD Silver Comment - AAC Response

 

After some digesting, I agree with Jeff that there may be details they missed that flow from our discussion, but I also think that without dragging them down our ratholes this is probably as good a read as we’d be able to get from a committee. I could believe we could engage individuals (Hi Tom!) more, but given that they are reviewing our interpretations, I’m not sure it does make sense to get their concurrence on our listed implications.

 

Parsing their response:

 

AAC: We do not believe that this statement implies that Protected Channels MUST be used. There may be other controls that could provide strong protection of Authentication secrets, depending on the specific use case. Ultimately, it will depend on whether an auditor is satisfied, should an implementer decide not to use Protected Channels. Since our interpretation does not explicitly require Protected Channels, no Alternate Means is required. The Cookbook can of course recommend best practices as you see fit.

 

I take it as significant that the response repeats the wording “strong protection of authentication secrets” from the title of the requirement and that they use language around “other controls that could provide strong protection”. That is, I would now interpret this as them saying that word “strong” from the section title is itself implicitly part of the requirement, and that the specific measures listed in *.2 are giving an example measure that “strong” protection can be compared against.

 

Taking that point of view, I’m tempted to argue that while NTLMv1-type protocols are not explicitly addressed in the IAP, this language clarification does provide for excluding NTLMv1 support on the basis that it fails to provide “strong protection” of passwords/authentication secrets. That is, NTLMv1 can be shown under most reasonable scenarios to not provide strong protection of the password. My only hesitation with that argument is that there’s also a possible argument against NTLMv2 and Kerberos here (i.e. that they are not strong for some definitions of “strong”) but I’m happy avoiding that can of worms, since it starts getting into less self-evident descriptions of what “strong” means.

 

As far as how well the AAC understood the “Bronze requirement being stronger than the Silver one” issue, I assume this was at least considered during the overall discussion even if it wasn’t explicitly raised (I’m making the assumption because the point was part of Ron and Tom’s discussion).

 

I guess going further than my comment in the first paragraph of this message, it seems that we’ve found a fairly firm limit to how much guidance we’re going to get from the AAC, and that the next validation-related steps are more likely to be driven by auditors actually going through reviews and applications being sent to InCommon than via our more theoretical discussions.

 

 

Proposed Action Items:

 

·         Clarification of Protected Channels in 4.2.6.2

o   Look at our categorization of protocols to ensure no language is in conflict with the updated interpretation.

o   Clarify IAP 4.2.6.2’s interpretation to match the interpretation.

o   Determine language around NTLMv1

·         IAP 4.2.6.3 clarification

o   Update the Cookbook to take IAP 4.2.6.3 out of scope of the AD Cookbook

o   Further clarify IAP 4.2.6.2’s interpretation in the Cookbook to also match the clarification (Tom’s interpretation of transmission vs. handling of passwords) here.

·         IAP silent on NTLMv1?

o   No change here, though the language may already be changed based on Protected Channels in 4.2.6.2, above.

 

--- Eric

 

From: [] On Behalf Of David Walker
Sent: Tuesday, April 01, 2014 8:16 AM
To:
Subject: Re: [AD-Assurance] RE: AD Silver Comment - AAC Response

 

Yeah, wow.  It would seem that this would allow a Silver-compliant system to send passwords for verification purposes in the clear.  I wonder if they realize that 4.2.3.5 is Bronze only.

David

On 04/01/2014 07:54 AM, Capehart,Jeffrey D wrote:

Wow, yes, very interesting responses.  My take:

1)      Protected channels aren’t required?  That’s pretty generous, probably a lot more loose than many of us have been thinking, but it will make it easier for AD.  That could open the door for Eduroam, Radius, and perhaps some other protocols.

2)      Well, we were thinking the protocol was the key, but with statement #1, is that a moot issue other than a best practice recommendation?

3)      Seems to agree with the thinking behind 1 & 2.

 

So, based on a lot of this interpretation, it really seems like it would be a good idea to call out some best practices in the cookbook.  Perhaps something like a minimal level to meet Silver would be X, but an improved/better/stronger level would be to do some other things (NTLMv2, etc.)

 

Without being a party to the actual AAC discussions, it is difficult to know for certain that they understand all the risks involved.  I only say that because a decision made just reading the emailed questions may miss some technical nuances like password v. hash v. encrypted challenge, etc. that we have been struggling with as to what will comply.

 

I think that having to keep a list of approved protocols would be a nightmare, something no one wants to have to do.  So perhaps that falls under the risk assessment or some other part of the IAP, but is really left up to each implementer to decide.

 

Also I keep coming back to wondering what the next iteration of the IAP will look like considering all the questions and problems we have had.  Keeping it vague gives a lot of flexibility but could make it where two silver institutions have quite different protection levels for their secrets.

 

Thank you for sharing Eric, and all your work putting the questions together!

Jeff

 

From: [] On Behalf Of Eric Goodman
Sent: Tuesday, April 01, 2014 10:24 AM
To:
Subject: [AD-Assurance] Fwd: AD Silver Comment - AAC Response

 

Hi all,

 

Interesting response on question number one. The others are pretty much as we expect. I haven't had a chance to process how the first response might change the Cookbook, but didn't want to wait to share with the list. 

 

--- Eric

Sent from my iPhone

Begin forwarded message:

From: Steve Devoti <>
Date: April 1, 2014 at 6:57:21 AM PDT
To: <>
Cc: <>
Subject: AD Silver Comment - AAC Response

Hi Eric,

 

First, I just wanted to thank you and all the AD Cookbook team for the excellent work. It is quite the accomplishment and will be very valuable to the community. Members of the AAC have discussed your questions and our responses are below. Please let me know if you have any questions.

 

-Steve

 

 

On 3/21/2014 11:23 AM, Eric Goodman wrote:

AAC Members,

 

Thank you yet again for your input and responses to our questions. It’s been extremely helpful! Appended here are three additional (and hopefully final!) questions based on the last round of communications with the AAC and some discussions with individual AAC members.

 

On behalf of the AD Cookbook team,

 

--- Eric

 

 

QUESTION #1 Modification to the IAP 4.2.3.6.2 Interpretation

 

Does AAC agree with or have any concerns about this language addition? 

 

Based on conversations with Tom Barton, we plan to add the following language to this interpretation:

 

“We treat the following language in this requirement:

 

Protected Channels should be used, but Protected Channels without client authentication may be used

 

To mean that one or the other (Protected Channels or Protected Channels minus client authentication) MUST be used, even though a literal parsing of the sentence may imply that there is no specific requirement (both verbs used – should and may – could imply an optional practice to some readers)”

 

AAC: We do not believe that this statement implies that Protected Channels MUST be used. There may be other controls that could provide strong protection of Authentication secrets, depending on the specific use case. Ultimately, it will depend on whether an auditor is satisfied, should an implementer decide not to use Protected Channels. Since our interpretation does not explicitly require Protected Channels, no Alternate Means is required. The Cookbook can of course recommend best practices as you see fit.

 

 

 

QUESTION #2: Request for clarification of distinction between IAP 4.2.3.6.2/3

 

Which definition of the distinction between these two sections does the AAC see as correct?

 

Based on conversations with the AAC, Tom Barton, and among the AD Cookbook editors, we lean towards Tom’s interpretation being the correct one.

 

Question	Tom Barton	Chris Spadanuda	AD Cookbook Draft
What differentiates when IAP 4.2.3.6.2 vs. IAP 4.2.3.6.3 governs a circumstance?	Network transmission of vs. in-app handling/disclosure of secrets.	IdP vs. non-IdP app use of a credential.	Authentication protocol in question is used by IdP vs. not.

 

                AAC: We agree that Tom’s statement more clearly describes what is meant in 4.2.3.6.

 

 

QUESTION #3: Clarification of use of non-IdP Protocols

 

Does the AAC concur with the (following) conclusion that the IAP is silent on non-IdP Protocols that do not contain passwords?

 

From discussions with the AAC to date, it appears that there are no specific restrictions in the InCommon IAP on non-IdP protocols that do not contain the user’s password. Specifically:

• NTLMv1 is very weak and its use represents a significant risk to user passwords, as well as to other enterprises that rely on its IdP.
• Despite it putting the password at immediate risk, there are no specific requirements in the InCommon IAPs that would restrict its use by non-IdP apps connecting to an AD Verifier.

• By comparison, NIST 800-63 (800-63-2) has specific language about protocols that operate similarly to NTLMv1 (i.e., protocols that use the user password to encrypt random challenges without actually transmitting the password) being used by non-IdP apps.

Assuming concurrence with this conclusion, we will warn against the use of NTLMv1 in the Cookbook, but will clarify that it is not a compliance requirement, and rather just a best practice.

 

                AAC: We agree with your interpretation of non-IdP Protocols that do not contain passwords.

 

Please let us know if further technical detail/discussion is desired on this or other questions.

 

 

Steve Devoti

Senior IT Architect

University of Wisconsin-Madison

608.265.3997