Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Based on our discussion last Friday, I am documenting the following three items:

 

1.       Modification to the IAP 4.2.3.6.2 Interpretation:

 

Add the following language (I’m assuming I don’t need to actually add this language prior to sending this summary to the AAC):

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

 

 

2.       Request for clarification of distinction between IAP 4.2.3.6.2/3.

 

Which definition of the distinction between these sections is correct? (We lean towards the answer being “Tom’s”)

 

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.

 

 

 

3.       Clarification of IAP overall:

 

Is there any IAP restriction on using a protocol that meets the following criteria?

(a)    Is not used by the IdP directly

(b)   Does not send the password or a hashed/encrypted version of the password in the authentication interaction

(c)    Uses a user’s verifier password in the authentication mechanism in a way that makes the password viable to infer by an eavesdropper?

 

NTLMv1 in particular is a protocol that meets all of these criteria; there are websites that allow submission of an eavesdropped NTLMv1 authentication packet, and the site will return the plaintext password within ~24 hours.

 

Given that

·         IAP 4.2.5.x addresses authentication to the IdP (not the IdP Verifier)

·         IAP 4.2.3.6.2 only applies to Authentication Secrets used by the IdP Verifier

·         IAP 4.2.3.6.3 does not apply any specific requirements, and may (based on answer to #2, above) not apply to non-IdP Protocols/Authentication Secrets,

 

it appears as if the IAP is silent on protocols meeting this criteria. Using NTLMv1 as an example again, while we (the Cookbook team) want to recommend against using NTLMv1, it’s unclear if it is a compliance requirement as compared to just a recommended best practice.

 

By comparison, NIST 800-63-2 section explicitly restricts uses of these kinds of protocols. (We understand that the IAP is distinct from 800-63, we call this out to clarify the kind of protocol behavior we want clarity on.)

 

From NIST 800-63-2, section 8.2.2 “Eavesdropping-resistant protocols make it impractical[27] for an Attacker to carry out an off-line attack where he or she records an authentication protocol run and then analyzes it on his or her own system for an extended period to determine the token secret or possible token authenticators.”

 

Footnote 27 of NIST 800-63-2 defines an entropy level to achieve the “impractical” standard (80 bits of entropy in the token secret), and requires that LoA 2 implementations meet this “impractical” level of resistance.

 

 

Is that sufficient to explain and share the information with the AAC?

 

--- Eric

 

 

 

From: [mailto:] On Behalf Of Ann West
Sent: Wednesday, March 12, 2014 8:26 AM
To:
Subject: Re: [AD-Assurance] RE: [aac] Assurance Cookbook: February 2014 Interpretation Sections

 

We can also send your comparison chart to the AAC, Eric, and ask them to reconcile the differences.

 

Ann

 

 

On 3/11/14 6:42 PM, "Eric Goodman" <> wrote:

 

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