Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

> However, when AD does its own (non IdP) authentications and protocols like NTLM,

> etc. (as a Verifier to a non-IdP app), then AD transports the secret around perhaps in

> a manner that is not using approved algorithms and so it would be helpful to identify

>those as either out of scope or non-IdP protocols so they don’t matter.   I think we say

>those ‘secrets’ aren’t used by the IdP (directly).

 

Correct, and Tom agrees with that language.

 

> Of course, they do matter for offline password cracking (eavesdropper), but they

> wouldn’t matter for replay, hijack, etc., so that’s where those other cases get lumped

> in, even if they are covered under other parts of the IAP.  I think we already determined

> that IAP 4.2.5 applies only to IdP, whereas IAP 4.2.3 covers all credential technology. 

> But maybe we’re trying to say that we’re covering most (but not all) of the same

> requirements needed to ensure strong protection of authentication secrets.

 

My challenge is I hear the feedback from Tom saying that they do not matter even for eavesdropper resistance. It's largely a technical distinction, but we used this language in IAP 4.2.3.6.3:

 

Authentication Secrets[1] in the context of this requirement is interpreted to mean those secrets (passwords, Kerberos session keys, NTLM challenge responses, etc.) that can be used to directly authenticate to the IdP or to directly modify authentication credentials (e.g., can be submitted directly to a change my password page).

 

Tom agreed with this definition, but resisted our making any statements about those that are not used by the IdP (as we did in the next paragraph):

 

I don't think non-IdP authentication secrets, ie, those not used to authenticate to the IdP, regardless of what other apps they may be used to authenticate to, are specifically addressed anywhere in the IAP, with the possible exception of some authentication scenarios addressed in IAP 4.2.8.2.2 [requirements for admin passwords].

 

An LM hash is pretty much a hashed copy of the user's password, so would fall under IAP 4.2.3.6.2's "Protected Channels must be used" rule.

 

However, an NTLM hash (even v1) is an encrypted random challenge; it's not an encrypted copy of the password*. Based on this, if I follow Tom's argument, there's no compliance need to restrict NTLMv1 use, even though they are horribly vulnerable to allowing recovery of the raw password. Despite being defeatable, assuming your IdP doesn't  (a) eavesdropping isn't a concern because it's not an IdP authentication event (IAP 4.2.5.2) or an IdP Authentication Secret being used (IAP 4.2.3.6.2) and (b) brute force protection only refers to online guessing attacks and not attacks on eavesdropped packets.

 

I guess we can try to gain some further clarification, and again, Tom may be in a minority here, but if we treat Tom as the AAC interpreter, our suggestion to disable NTLMv1 is not a compliance need, it's just something we see as a best practice.

 

Hence my previous suggestion that we should remove any compliance requirement interpretations around non-IdP protocols (like NTLMv1), but that we can leave them in the recommendations. That oversteps our stated approach, in that we are recommending best practices beyond what compliance requires, but I can't imagine any of us wanting to say "go ahead and keep using NTLMv1".

 

--- Eric

 

 

* I've said this before, but I think there is a mathematical argument that any protocol that uses the password as a hashing or encryption key inherently contains the password, but the Cookbook is written assuming that it's the ciphertext (not the cipher key) that determines the nature of the "Authentication Secret". We could try to make the argument that using the password as the cipher key is the same as "encrypting the password", but that opens up all sorts of issues; most notably that NTLMv2 and Kerberos are not Protected Channels, so would be disallowed altogether under that interpretation as both would now be non-Protected Channels carrying IdP Authentication Secrets.