Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

Ah, yes.  I suppose I should stick with the group consensus...  ;-)

Regarding my language, I was thinking of it as an outline of what should be sent to the AAC, rather than the full text.  You probably want to incorporate some of your material as background to the (perhaps overly) simple text that I wrote.

David

On 03/19/2014 09:37 AM, Eric Goodman wrote:

I understand what you are saying. My notes from the meeting just don’t agree with you. :) They clearly state I’m supposed to be asking a question.

 

I can just incorporate your simplification of my language, but still leave it as a question or indicate that it a statement that we want confirmed. I agree your presentation is much more straightforward than mine in any case. (If we agree this is the case, we should probably call it out in the Cookbook somewhere for clarity).

 

That said, I see risk in suggesting alignment with the language in NIST 800-63. Alignment would rule out use of NTLMv2 (implicitly) and Windows Kerberos with user-selected passwords (explicitly), not just NTLMv1. So I wouldn’t go so far as to recommend that the AAC seek to match the 800-63 requirements if we want silver credentials to be able to exist in ADs.

 

Shall I make the change to use David’s language minus the recommendation for alignment?

 

I’ll still have to look a bit to see where we’d add language in the Cookbook to add this assertion/distinction (NTLMv1 being a good idea, not a compliance issue). I’m thinking it would go somewhere in the discussion of the “general issues”, but haven’t looked that closely yet.

 

--- Eric

 

From: [] On Behalf Of David Walker
Sent: Tuesday, March 18, 2014 4:14 PM
To:
Subject: Re: [AD-Assurance] RE: [aac] Assurance Cookbook: February 2014 Interpretation Sections

 

Eric,

1 and 2 seem pretty clear to me and ready for the AAC.

For 3, I think we know the answer; the IAP is silent on protocols like NTLMv1 that meet the criteria you list.  I wonder if 3 should be reworded as advice for a future version of the IAP, as well as a warning in the Cookbook about NTLMv1.  Right now, 3 is pretty broad, and I'm afraid the AAC will have trouble wrapping their minds around it.  (I'm having trouble right now...)

I think the points we want to make are:

1. We believe NTLMv1 is currently allowed under the IAP, but it is very weak and represents significant risk to an enterprise, as well as other enterprises that rely on its IdP.
2. The latest version of NIST 800-63 (800-63-2) disallows the use of authentication protocols that are as weak as NTLMv1 for LoA-2.
3. We will warn against the use of NTLMv1 in the Cookbook, but we also recommend alignment with 800-63-2 for the next version of the IAP  If the AAC concurs, we will document that potential future requirement in the Cookbook.  (I suppose we could also the recommendation to the AAC, even without their concurrence.)

Make sense?

David

 

On 03/18/2014 03:45 PM, Eric Goodman wrote:

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: [] 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.