Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

[Resending in case the “blank subject” caused issues for other people too.]

 

AD Cookbookers,

 

Apologies for the delay in updating this. Attached is the proposed message to the AAC.

 

Any concerns or additions? Should we meet this AM to discuss? I don’t know that meeting is necessary, as hopefully everything below is a rehash of last week’s discussion, but I’m happy to dial in if discussion is desired or warranted.

 

--- Eric

 

-----

 

AAC Members,

 

Thank you yet again for your input and responses to our questions. It’s definitely extremely helpful! Appended here are three additional (and hopefully final!) questions based on the last round of communications with the AAC and individual 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 (the both verbs used – should and may – imply an optional practice)”

 

 

 

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 vs. in-app disclosure of secrets.	IdP vs. non-IdP app use of a credential.	Authentication protocol in question is used by IdP vs. not.

 

 

 

1.       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 restrictions on non-IdP protocols that do not contain the user’s password. Specifically:

·         NTLMv1 is very weak and represents a significant risk to user passwords, as well as 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.