Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Warren Anderson had made several comments (or asked several questions) regarding the penultimate draft of the Workbook, which is public. The Workgroup has responses prepared for these comments, but those comments were going to be released publicly at the same time the final draft is completed.

 

We recognize that these responses are probably key context for your review of these interpretations, so attached here are Warren’s comments/questions, and the Workgroup’s not-yet-public response. Hopefully it provides helpful clarifications!

 

--- Eric

 

 

Original Comment (as reformatted on the “public comments” page)

 

I have a question regarding 4.2.5 and 4.2.6. In those sections there are highlighted phrases that restrict the consideration of secure communications as part of the IdP authentication/assertion event. There are accompanying statements that all other traffic between the Subject and the AD DS is beyond scope.

• Can I interpret that statement to imply that it is known that there is no practical way to leverage replay or eavesdropper attacks on non-IdP authentication events between the Subject and an AD DS to create an authentication event via the IdP?
  • For instance, what if I highjacked a password change session with the AD DS?
  • Or if I highjacked an authentication session that allowed access to a webmail system where password reset links are sent. Or similar sorts of escalation strategies?
• Is it implied in the cookbook that none of these sorts of things can happen within the context of AD?
  • Or is there an implicit statement that these sorts of vulnerabilities should be beyond the scope of the IAP for Silver?
    If the latter, as an SP operator I would really downgrade my current view of what I would accept Silver for.

 

Workgroup Response

 

In the more general case we do not mean to imply that there is no feasible way to leverage or replay eavesdropper attacks on non-IdP authentication events to create an authentication event via the IdP. Our intent is to classify protocols into categories of risk: 

• Not resistant to recovery of users's authentication credential. I.e., could be attacked to allow recovery of the user's actual password.
  • These protocols are disallowed or must be monitored
  • Examples: Cleartext (plain LDAP), LM, NTLMv1
• Resistant to recovery of the user's authentication credential (password), but perhaps less resistant to replay attacks.
  • These protocols are acceptable with non-IdP authentication events, but are recommended to be disabled for communications to the IdP (to avoid replay actually allowing an authentication event being "forged" via the IdP)
  • Examples: NTLMv2, Kerberos

·         Resistant to eavesdropping and replay.

• These protocols are allowed in non-IdP and IdP authentication events alike.
• Examples: LDAPS, LDAP with data signing

The cookbook does single out "change password pages" in section 4.2.3, discussing the interpretation of requirement 4.2.3.6.2 of the IAP), because as you note, attacks on these pages would lead directly to the ability to attack the IdP.

We also see AD Admin accounts able to modify Verifier passwords or configuration of the IdP itself as being covered by the requirement 4.2.8.2.2 network communications ("(All personnel with login access to IdMS Operations infrastructure elements must use access Credentials at least as strong..."). However, because this is not an AD-DS specific requirement (it would be true of any admin account on any IdP verifier, regardless of protocols or configurations) we didn't identify this requirement within the context of the AD Cookbook.


In response to your last two questions:

• We definitely do not mean to imply that session highjacking, etc. cannot happen in AD. The categorization of protocols referred to above was specifically to identify which protocols are vulnerable in the context of the IAP
  • Two elements from the Scope to clarify here:
    • The AD Cookbook focuses on compliance with the Silver IAP, and NOT security that is sufficient for your technical environment. That is, the focus is compliance, and we encourage institutions to go beyond the identified compliance activities wherever appropriate.
    • The AD Cookbook focuses on AD-DS specific functionality. So for example, the password change initiated by hitting ctrl-alt-delete would be in scope of the AD Cookbook (and there is an open question to Microsoft about this). By contrast, security of a password change page hosted by an external application (e.g., an IDM system) is not an AD-DS technology question; so while still in scope of the Silver IAP, is out of scope for the AD Silver Cookbook.