Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Thanks Ron,

 

I think that the term service, though not defined, is used in the IAP and IAAF in more of a ITSM type context than a technical one.  So, my desktop talking to a domain controller might not be covered by 4.2.3.6.2 at all, because my desktop is not a service.  However, it could be exposing Authentication Secrets in a transient fashion and covered by 4.2.3.6.3.

…

So, I would argue that generally non-password tokens are not in scope.  Tokens that incidentally contain passwords used by the IdP or hashes of those not using approved algorithms would be in scope.

 

Just to clarify, you are in agreement with the text here, right? (Wasn’t sure if this was responding to the cookbook text or David’s comments).

 

I agree with the notion that if non-password, non-IdP tokens could be used to leverage a Silver certified credential then they might be in scope; however, that would only be if that leverage allowed you to compromise the actual “Authentication Secrets used by the IdP (or the IdP’s Verifier)”.  I believe that’s what you mean by “within the context of an IdP authentication event” although I find that a little cumbersome.

 

Yes. The phrase “(within the context|as part|outside) of an IdP authentication event” came from the AAC’s request that we clarify that 4.2.5 only applies if the tokens are actually being handled by the IdP or as part of generating (validating) an IdP assertion, whereas 4.2.3.6 applies for any authentication events. Again, if there’s better language I’m happy to take suggestions. I think that removing the qualifier altogether would be ambiguous, and barring better language I’d vote for cumbersome over ambiguous.

 

I also agree that “should” vs. “must” is an important distinction, as I pointed out back in August. 

 

Yes, my comment “as discussed before” was meant to say “as someone else pointed out before”, and was intended to refer to that comment. :)

 

However, I don’t have a feeling for how auditors would look at the difference.  I hope to persuade them on the point.

 

You neglected to indicate what view you hope to persuade them to here!

 

--- Eric

 

From: [mailto:] On Behalf Of Ron Thielen
Sent: Wednesday, September 25, 2013 4:13 PM
To:
Subject: RE: [AD-Assurance] RE: Edits to AD Cookbook

 

I don’t know if this helps or not, but these are my thoughts on the 4.2.3.6 thread.

 

The difference between 4.2.3.6.2 and 4.2.3.6.3 is that the former is scoped to exchanges between services and the latter expands to include any transient exposure of the secret, for example through conversations between the subject and a service.  Neither one “wins” over the other necessarily.  I think that the term service, though not defined, is used in the IAP and IAAF in more of a ITSM type context than a technical one.  So, my desktop talking to a domain controller might not be covered by 4.2.3.6.2 at all, because my desktop is not a service.  However, it could be exposing Authentication Secrets in a transient fashion and covered by 4.2.3.6.3.

 

One key to all of this is that the “Identity Provider” as defined in the IAAF is “The IdMS system component that issues Assertions.”  While 4.2.3.6.2  and .3 talk both about non-IdP applications, they are both still scoped to “Authentication Secrets used by the IdP (or the IdP’s Verifier).”  I believe that commonly AD will not be IdP because it is not “The IdMS system component that issues Assertions.”  Is anyone issuing SAML assertions from AD?  So, “Authentication Secrets used by the IdP (or the IdP’s Verifier)” will never be NTLMv2 tokens.  They could be NTLMv1 tokens because we know that those actually contain a hash of the password, but again it is because it is a hash of the password used by the IdP not because it is just any old Authentication Secret.  So, I would argue that generally non-password tokens are not in scope.  Tokens that incidentally contain passwords used by the IdP or hashes of those not using approved algorithms would be in scope. 

 

I agree with the notion that if non-password, non-IdP tokens could be used to leverage a Silver certified credential then they might be in scope; however, that would only be if that leverage allowed you to compromise the actual “Authentication Secrets used by the IdP (or the IdP’s Verifier)”.  I believe that’s what you mean by “within the context of an IdP authentication event” although I find that a little cumbersome.

 

So given all that, I disagree with the notion that a general statement about “Authentication Secrets, including non-IdP replayable tokens” suffices.  The only Authentication Secrets in scope are those that are used by the IdP or its Verifier or could be used to compromise those same secrets.  Not all Authentication Secrets are equal, and not all contexts are equal.

 

I also agree that “should” vs. “must” is an important distinction, as I pointed out back in August.  However, I don’t have a feeling for how auditors would look at the difference.  I hope to persuade them on the point.

 

Ron

 

From: [] On Behalf Of Eric Goodman
Sent: Wednesday, September 25, 2013 4:29 PM
To:
Subject: RE: [AD-Assurance] RE: Edits to AD Cookbook

 

Most of these look fine. If I have any quibbles when editing I’ll let you know.

 

I wanted to respond to the most substantive question you raised:

• In 3.2.3, I don't understand why you feel that only non-password authentication secrets apply to IAP section 4.2.3.6.3.  I would remove the first bullet and change the second to say "This section addresses non-IdP applications that have even transient access to Authentication Secrets, including non-IdP replayable tokens (e.g., LM, NTLMv1, NTLMv2 or MIT Kerberos protocols) as well as passwords,  that could be leveraged to authenticate an InCommon Silver certified account within the context of an IdP authentication event."

To be more precise, by our interpretations BOTH 4.2.3.6.2 and 4.2.3.6.3 apply when password authentication is used. But as 4.2.3.6.2 is the more restrictive requirement, it would “win”. So while password-handling applications are technically covered in 4.2.3.6.3, they would still require Protected Channels (per the preceding section).

 

So I like your language, but would want to add that caveat about passwords. If you’re questioning the interpretation of the applicability of 4.2.3.6.2 in these cases (and I invited such scrutiny in my original message), I’m still stuck.

 

The language in 4.2.3.6.2 refers to “Authentication Secrets used by the IdP (or the IdP’s Verifier)” being sent from “some non-IdP application to a Verifier”, which really sounds like “passing the plaintext password” to me. Our interpretation of 4.2.3.6.2 is in line with this assumption. I will note that – as discussed before – 4.2.3.6.2 does use the language “should” and not “must” with respect to Protected Channels, so perhaps there is no actual requirement here. I.e., campuses could choose not to use Protected Channels for these operations and claim compliance because it’s not required though that means there’s no standard for positively meeting the requirement if Protected Channels are not used.

 

If there’s an intent (on the part of the AAC) to exclude these non-IdP web apps collecting passwords from the requirements outlined 4.2.3.6.2, I’m still not clear what the “non-IdP application” language is addressing in this section.

 

--- Eric

 

 

 

From: [] On Behalf Of David Walker
Sent: Tuesday, September 24, 2013 5:23 PM
To:
Subject: Re: [AD-Assurance] RE: Edits to AD Cookbook

 

Eric,

Here are comments, many of which you may want to ignore as overly nit-picky.  Overall, it's an impressive body of work.  Even though the following list is kinda long, it's mostly polish; it doesn't detract over the much longer list of what's right in the document.

• I'd change section 1.1 Purpose to say:

"The goal of this document is to offer practical compliance recommendations for InCommon Silver when a Microsoft Active Directory Domain Services (AD DS, commonly referred to as "Active Directory") forest, using user-selected passwords as the authentication credential, has been integrated into or with a campus Identity Management System.

This document is intended to aid in configuring AD DS to meet requirements of the InCommon Identity Assurance Profiles (IAP) version 1.2 for the Silver assurance profile that specifically affect AD DS. Only sections of the IAP where there is a challenge unique to AD DS are specifically addressed. For example, issues of brute-force guessing and password entropy pose no unique challenge to AD DS; like most authentication services AD DS has controls to enable password rotation, and mitigating features like account lockout, and configuring these controls to meet those IAP sections is an exercise that requires no knowledge unique to AD DS."

• I'd change the third paragraph of 1.3 Scope to say:

"We also note that using Multi-Factor Authentication (MFA) to authenticate Silver IAQ holding users may be a more effective strategy to achieve Silver certification than the recommendations provided in this document, with its focus on securing of password storage and communication of passwords.  An MFA-based InCommon Silver compliance review would focus much more on the technology and function of the MFA solution implemented."

• Remove the third method for protecting passwords in 3.1.1.  (It isn't a method for protecting passwords; it's an alternative to using passwords.)
• In 3.2.1, change "(?ALSO HOW IS THE DATA ENCRYPTED?IF RC4 OR MD5 it's still not a protected channel?)" to "Also, we have not been able to determine if LDAP data signing uses an Approved Algorithm."
• In 3.2.3, I don't understand why you feel that only non-password authentication secrets apply to IAP section 4.2.3.6.3.  I would remove the first bullet and change the second to say "This section addresses non-IdP applications that have even transient access to Authentication Secrets, including non-IdP replayable tokens (e.g., LM, NTLMv1, NTLMv2 or MIT Kerberos protocols) as well as passwords,  that could be leveraged to authenticate an InCommon Silver certified account within the context of an IdP authentication event."
• In 3.2.5, I agree with your note about "impractical."
• In 4.3.1, change the first sentence of the second paragraph to be more specific: "To simplify the process of asserting compliance we recommend an IdP configuration that requires direct entry of user credentials for user authentication, rather than relying on existing authentication tokens from user desktops through the use of SPNEGO or similar software."
• Change the very end of 4.3.1 to "...as they are specific to web-application security and not AD DS."
• Add the following sentence to the end of the last paragraph of 4.3.2:  "Also, if those applications store credentials that could be used in the context of an IdP authentication, then appropriate measures should be taken to protect those passwords at rest."
• In Appendix D - Definitions and Background, add "SPNEGO - Microsoft software that allows AD DS authenticated workstation login sessions to be extended to web-based applications without prompting the user to re-authenticate."
• Remove the Glossary section heading; it conflicts with Appendix D.

There are also a number of notes about things that we don't have yet.  I guess that's OK, but we'll need to clear about status when we announce this thing.

Again, thanks for all the great work getting us to the point where all we have to do is polish.

David

On Tue, 2013-09-24 at 00:01 +0000, Eric Goodman wrote:

Two other comments:

 

·        I went back and forth, and ended up using “Authentication Credentials” in many cases where I could have said “Passwords”. My thinking in doing this is that to prevent man-in-the-middle attacks, it’s just as important to block access to one-time passwords as to block user-selected static passwords. As you read the doc, consider whether you like my choices here.

·        If you read the “comparison” version, be mindful of the wiki-markup. In some cases I “added” sections that start with a dash “-“, those are areas where I actually changed the text to strikeout (probably combined with some previous minor edit).

 

Of course, any other corrections, comments, etc. are welcomed, the ones I list are just the ones I focused on during my editing.

 

--- Eric

 

From: [] On Behalf Of Eric Goodman
Sent: Monday, September 23, 2013 4:56 PM
To:
Subject: [AD-Assurance] Edits to AD Cookbook

 

Well, as per my usual, the edits ended up being a bit beefier than I expected.

 

·        Scope

o  Added a note about SSL/TLS and SHA1 in the scope section to say that we assume whatever SSL/TLS you are using is still an approved method.

·        Interpretations

o  4.2.3.6.2

§ Explicitly state that this section covers use of authentication credentials (passwords) by any app (not just the IDP) against the IDP Verifier.

·        Was implied in earlier drafts (“secrets that can be used to directly authenticate to the IDP…”), but was not as explicitly called out.

§ Updated the footnotes as per AAC request.

o  4.2.3.6.3

§ Added this section.

§ Please carefully review interpretations for this section and preceding (4.2.3.6.2). They are very explicit re: categorizing authentication traffic each addresses. I think the categorization is correct, but in getting explicit, I entered territory we hadn’t fully discussed in the past. As written, these interpretations are key for distinguishing when a Protected Channel is required, vs authentication methods that generally “minimize risk”.

o  4.2.5.1/2

§ Modified (clarified) the AAC’s suggested wording (my additions in bold):

·        "This section refers specifically to traffic between the Subject and the IdP, the IdP's Verifier, and/or a relying party as part of an IDP authentication/assertion event. All other traffic between the subject and to the AD DS is beyond the scope of 4.2.5.2."

·        AAC’s language still said it pertained to “traffic between the Subject and the IdP’s Verifier”, which other comments indicated was too broad of a scope.

§ Made a similar change to both 4.2.5.1 and .2. (This constituted an addition in .1).

§ Removed (strikeout for now) the “impractical” in this section, as with the rescoping from the AAC, the definition was irrelevant. Moved much of the language in this section to 4.2.3.6.2/3

·        Configuration recommendations

o  4.2.3.6.2

§ I think I added language to make it clearer that we recommend prompting user directly for authentication credentials, and not SPNEGO-like methods (as well as the “why”)

§ Added the requirement that all non-IDP applications that handle authentication credentials directly must use protected channels as well (pre the clarification noted in “interpretation”, above); i.e., LDAPS or equivalent for talking to AD DS.

§ Clarified that while IDP and web apps that prompt for user passwords must use HTTPS or equivalent on “front end”, that’s not an AD DS requirement (it’s web app security) so isn’t covered here.

o  4.2.3.6.3

§ Moved language re LM and NTLMv1 disabling here.

§ Called out that NTLMv2 and Kerberos are fine given our other recommendations.

o  4.2.5.1/2

§ Moved most language from 4.2.5.1/2 to 4.2.3.6.2/3.

§ Stated that if IDP uses direct entry of user authn credentials, no extra requirements here beyond those for 4.2.3.6.2

o  Renamed “Monitor and Mitigate” to be a “Compensating Controls Statement” (not an Alternative Means)

o  Removed “Alternative Means for use of Kerberos” section [shows as strikeout]

o  Removed “Time Skew” for Kerberos discussion [shows as strikeout]

o  Removed discussion of 4.2.3.5 (Bronze) [shows as strikeout]

·        Management Assertions

o  Much of the same…

o  Moved assertions from 4.2.5.1/2 to 4.2.3.6.2/3

o  Removed much of the language in sections 4.2.5.1/2 (using strikeout), and referenced 4.2.3.6.2 instead.

o  Added a note in 4.2.8.1 re the one configuration we specifically recommend (to enforce AES for DC replication)

 

I’m sure I made other edits that I’m not catching here. Version 68 is the version that was up previous to my edits, so if you want to see everything I did, look at this URL:

 

https://spaces.internet2.edu/pages/diffpagesbyversion.action?pageId=38668089&originalVersion=68&revisedVersion=76

 

--- Eric