for the delay in updating this. Attached is the proposed
message to the AAC.
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.
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
On behalf of
the AD Cookbook team,
#1 Modification to the IAP 18.104.22.168.2 Interpretation
AAC agree with or have any concerns about this language
conversations with Tom Barton, we plan to
add the following
language to this interpretation:
“We treat the following language in
Protected Channels should be
used, but Protected Channels without client authentication
may be used
To mean that one or the other (Protected
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
should and may – imply an optional practice)”
#2: Request for clarification of distinction between IAP
definition of the distinction between these two sections
does the AAC see as correct?
conversations with the AAC, Tom Barton, and among the AD
Cookbook editors, we lean towards Tom’s interpretation being
the correct one.
differentiates when IAP 22.214.171.124.2 vs. IAP 126.96.36.199.3
governs a circumstance?
transmission vs. in-app disclosure of secrets.
vs. non-IdP app use of a credential.
protocol in question is used by IdP vs. not.
Clarification of use of non-IdP
Does the AAC concur with the
(following) conclusion that the IAP is silent on non-IdP
Protocols that do not contain passwords?
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.
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.