Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

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