Meeting the InCommon Assurance profile criteria using Active Directory

[Warren Anderson <>]

Hi Eric,

Thanks to the workgroup for the thoughtful reply. I need to spend some 
careful time with these, but my initial impression is that this clarifies my 
concerns.

Cheers,
Warren

On Feb 21, 2014, at 23:48 , Eric Goodman 
<>
 wrote:

> 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 ofrequirement 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.
>  

+================[ WARREN G. ANDERSON ]====================+
| PO Box 413, Dept. of Physics, Milwaukee, WI 53201, USA   |
|   CANADA: (403) 617 6720          USA: (414) 212 5446    |
+==========================================================+