Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

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