Meeting the InCommon Assurance profile criteria using Active Directory

["Michael W. Brogan" <>]

I don’t think we missed this issue (see attached email I sent on 8/9/13 that started a thread on this), I just think there wasn’t agreement on the interpretation. That’s why it was great idea to document the interpretations and send them to the AAC for feedback. I like the answer they gave us for 4.2.5 as it matches the interpretation we had adopted here at the UW!

 

--Michael

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Friday, September 13, 2013 7:33 AM
To:
Subject: RE: [AD-Assurance] AAC discussion of IAP requirement interpretations regarding Silver compliance for Active Directory

 

Re: The AAC disagreed with our interpretation of Section 4.2.5.2 Resist Eavesdropper Attack.

 

This seems like it is actually good news!  Wow, how did we miss that one?  The text from the 4.2.5 AUTHENTICATION PROCESS introduces the section by explicitly stating the scope: “The Subject interacts with the IdP to prove that he or she is the holder of a Credential, enabling the subsequent issuance of Assertions.”

 

Therefore, if you can meet 4.2.5.3 and use a Protected Channel for the Subject <-> IdP communications, and if the IdP does the communicating with the Verifier to get the proof/verification (ID/password valid), then you don’t have to worry about the Subject <-> Verifier direct link. (i.e. something like logging on to a workstation that was a member of the Active Directory domain.)

 

So that should agree that 4.2.5.2 means that all the [IdP interaction] authentication messages will pass over the establish Protected Channel with the IdP and therefore would be impractical to learn the secret.

 

The IdP itself should be communicating to the Verifier (AD DS) over its own protected-like channel which LDAPS could work nicely.  That would be covered under 4.2.3.6.3 as noted by the committee comments, and probably 4.2.8.2 also.

 

Side note: Where this might not help is a situation with a single-signon like environment using your Windows logon to tell the IdP that you’re already logged on to Windows and that you don’t need to send your ID and password.

 

On the final comment… for the 4.2.5.1 and 4.2.5.2 additional text for “impractical”, we could just recite the text from the IAAF, which never uses the word practical or impractical [see below].  But impractical is mentioned in the IAP.  We could also use wording from NIST SP 800-131A on Approved Algorithms as being reviewed as of January 2011 and determined to be acceptable (Acceptable is used to mean that the algorithm and key length is safe to use; no security risk is currently known.)

 

[IAAF] The security of communications between system components (IdP, IdMS, Verifier, etc.) is

important. A Protected Channel uses cryptographic methods that implement an Approved

Algorithm to provide integrity and confidentiality protection, resistance to replay and manin-

the-middle attacks, and mutual authentication. For example, typical SSL/TLS

implementations provide these protections.

 

To be explicit, we could say that NIST phases out cryptographic algorithms before attacks against them become practical, as can be seen with deprecation or disallowment of DES, Skipjack, and SHA-1.

 

--Jeff C.

 

From: [] On Behalf Of David Walker
Sent: Thursday, September 12, 2013 5:25 PM
To: InCommon AD Assurance Group
Cc: Mary Dunker; DHW; Ann West
Subject: [AD-Assurance] AAC discussion of IAP requirement interpretations regarding Silver compliance for Active Directory

 

As you know, the AAC discussed our IAP requirement interpretations earlier this week.  They agreed with all of our interpretations, except for 4.2.5.2 Resist Eavesdropper Attack.  Here are some notes from the discussion.

• In our interpretation of Section 4.2.3.6.1 Strong Protection of Authentication Secrets (subsection .1), we should clarify that we're only talking about passwords used by the IdP.
• The AAC accepted our interpretation of Section 4.2.3.6.2 Strong Protection of Authentication Secrets.  The interpretation, however, includes information that can be used to "...practically determine a user's password...," but the issue of practicality is not mentioned in that IAP section, so it should be removed from the interpretation.
• Also in Section 4.2.3.6.2, we should define what SPNEGO is.
• The AAC disagreed with our interpretation of Section 4.2.5.2 Resist Eavesdropper Attack. The first paragraph of this interpretation should be changed to say something like, "This section refers specifically to traffic between the Subject and the IdP, the IdP's Verifier, and/or a relying party. All other traffic to the AD DS is beyond the scope of 4.2.5.2."
• See the text of section 4.2.5 ("The Subject interacts with the IdP to prove that he or she is the holder of a Credential, enabling the subsequent issuance of Assertions.") for the intended scope. Section 4.2.3.6.3 covers other authentication traffic, requiring that "...the IdPO must have appropriate policies and procedures in place to minimize risk from this exposure."
• The AAC would like to have us add a little text describing what would comprise "impractical" in 4.2.5.1 and 4.2.5.2.  For example, we could mention use of Protected Channels and/or vendor attention to mitigating exploits as they appear in the wild.  This text will be helpful for others assessing compliance with these sections.

We can discuss this further in tomorrow's call.

David

--- Begin Message ---

• From: "Michael W. Brogan" <>
• To: "" <>
• Subject: RE: [AD-Assurance] VERY drafty alternative means statement
• Date: Fri, 9 Aug 2013 22:56:28 +0000
• Accept-language: en-US
• List-archive: <https://lists.incommon.org/sympa//arc/ad-assurance>
• List-id: <ad-assurance.incommon.org>

I have a really basic question about the IAP requirements and our gaps table.

 

I believe we’ve interpreted section 4.2.5 (Authentication Process) to apply to any authentication events that involve a credential that is also used by the IdP. That’s why we’ve had to spend time discussing NTLM and LDAP. But as I read through the IAP I wonder if that was the intent of the requirements:

 

·         Under 4.2.5 the IAP talks only about the subject and the IdP

·         Under 4.2.5.2 the IAP talks only about the subject, verifier, and relying party

·         Under 4.2.5.3 the IAP talks only about the subject and IdP

·         Under 4.2.5.5 the IAP talks only about the IdP

·         4.2.5 makes no mention of non-IdP apps

 

I understand that attacks against authentication events involving non-IdP apps can compromise credentials also used by the IdP, but I’m questioning if section 4.2.5 has a scope any broader than authentication events involving the subject, the IdP, and the IdP’s verifier.

 

We made this narrower interpretation at the UW during a preliminary gap analysis based on IAP 1.1. I don’t think the changes in IAP 1.2 would have affected that interpretation.

 

Are we making too much work for ourselves in regards to 4.2.5?

 

--Michael

 

From: [mailto:] On Behalf Of David Walker
Sent: Thursday, August 08, 2013 4:58 PM
To: InCommon AD Assurance Group
Cc: DHW
Subject: [AD-Assurance] VERY drafty alternative means statement

 

In our last call, I said I'd take a stab at an alternatives means statement for the use of unapproved algorithms in AD.  As I got further into writing, though, I realized I'm really not sure what we're looking for and where in the IAP we need it.  Looking over our "gaps" table, I think we need this only in 4.2.5.1 and 4.2.5.2 for MS Kerberos's use of MD4-HMAC without a tunnel, that NTLMv2 is OK, so I've written it up that way.  Is that all we're concerned about, or are we also wanting to include weaker authentication protocols like NTLMv1 and unsigned/unencrypted LDAP?  I apologize that my memory of last week's discussion is not up to the task.

Anyway, take a look at https://spaces.internet2.edu/x/soB2Ag , and we can talk about it tomorrow.  It has the arguments for allowing less than perfect security in AD; I just don't know what sections of the IAP we want to apply them to.

I also suggest that we make a pass over the gaps table to make sure it reflects our current thinking.  It'll make it easier for us keep track of what we still need to resolve.

David

--- End Message ---