Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

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