Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

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)”

 

 

 

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.

 

 

 

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.

o   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.

 

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