Meeting the InCommon Assurance profile criteria using Active Directory

["Dunker, Mary" <>]

AD Assurance Cookbook Working Group members,

On behalf of the InCommon Assurance Advisory Committee (AAC), I am forwarding 
(below) comments by Scott Koranda and Tom Barton regarding specific sections 
of the AD Assurance Cookbook. We look forward to further discussion with you 
during your conference call at noon on Friday, November 1, 2013. 

Best regards,
Mary Dunker 
Chair, InCommon Assurance Advisory Committee

-----------------------------------------------------------------
Mary Dunker
Director, Secure Enterprise Technology Initiatives
Virginia Tech Information Technology
1700 Pratt Drive
Blacksburg, VA 24060
540-231-9327

 
--------------------------------------------------------------------


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Tom Barton
Sent: Monday, October 14, 2013 12:30 PM
To: 

Subject: Re: [aac] AD Assurance Cookbook: Interpretation Sections

Some responses to the issues Scott raised are below. -Tom

On 10/13/2013 11:04 AM, Scott Koranda wrote:
> Hi,
>
>> Hi All,
>>
>> As I mentioned on yesterday's AAC call, the AD Assurance Cookbook has 
>> been released for open review, and the working group is looking for 
>> our guidance on their interpretations of the specific sections. I've 
>> included the link to the entire cookbook below as well as the specific 
>> wording they would like reviewed.
>>
>> LINK: https://spaces.internet2.edu/display/InCAssurance/
>> InCommon+Silver+with+Active+Directory+Domain+Services+Cookbook+-+DRAFT+20131002
>> #
>> InCommonSilverwithActiveDirectoryDomainServicesCookbook-DRAFT20131002
>> -SecuringAuthenticationTraffic
>>
>> Thoughts?
>>
>> Ann
>>
>>
>> 4.2.2. Interpretation of IAP requirement, Section 4.2.3.6.1 - Strong 
>> Protection of Authentication Secrets (Second Sentence)
>>
>> Note, this IAP requirement addresses both storage and transmission of 
>> passwords, so is addressed under both the "Encrypting Passwords" 
>> topic and the "Securing Authentication Traffic" sections.
>>
>> This requirement applies when IdP Verifier passwords are provisioned 
>> into an AD DS store, whether or not the AD DS store being provisioned 
>> to is the actual IdP Verifier. Note that this requirement only 
>> applies to passwords for accounts that are actually authenticated by 
>> the IdP (non-IdP accounts that are "co located" in the AD DS have no such 
>> requirements).
> I think the statement "this requirement only applies to passwords for 
> accounts that are actually authenticated by the IdP (non-IdP accounts 
> that are "co-located" in the AD DS have no such requirements)" is too 
> strong.
>
> I would agree that non-administrative non-IdP co-located accounts have 
> no such requirements, but any administrative account in the AD must be 
> covered and subject to operational constraints in 4.2.3.4 and 4.2.8, 
> since any compromise of an AD privileged account immediately escalates 
> to compromising AD accounts that are authenticated by the IdP.

Right, although this section of the cookbook addresses 4.2.3.6.1 perhaps it 
should also account for 4.2.8.2, which it currently does not mention.

>> For example, if an MIT Kerberos system is used as the IdP Verifier, 
>> but the passwords used by that Kerberos system are also provisioned 
>> into an AD DS, the AD DS provisioning process is in scope and 
>> therefore must use Protected Channels, even though it is not being 
>> used as the IdP's Verifier. (Again, this only applies to passwords 
>> for accounts that are actually authenticated by the
>> IdP)
> See above. It should apply to passwords for accounts that are actually 
> authenticated by the IdP AND all administrative or privileged accounts 
> that can be used to make any administrative changes to accounts that 
> are authenticated by the IdP.
>
>> 4.2.3. Interpretation of IAP Requirement, Section 4.2.3.6.2
>> - Strong Protection of Authentication Secrets
>>
>> Authentication Secrets[1] in the context of this requirement is 
>> interpreted to mean those secrets (passwords, Kerberos session keys, 
>> NTLM challenge responses, etc.) that can be used to directly 
>> authenticate to the IdP or to directly modify authentication 
>> credentials (i.e., can be submitted directly to a change my password 
>> page).
>>
>> Another way of stating this is that the intent of 4.2.3.6.2 is only 
>> to protect against risks that can attack the IdP’s direct 
>> authentication to its Verifier; protection of non-IdP Authentication 
>> Secrets that incidentally use the same Verifier as the IdP, such as 
>> Windows/Kerberos Tickets used to authenticate a user to a domain (a 
>> la ctrl-alt-del)[2], are not in scope of 4.2.3.6.2. These non-IdP 
>> Authentication Secrets are addressed elsewhere in the spec, such as 
>> in 4.2.3.6.3.
> I disagree.
>
> 4.2.3.6.2 is clear:
>
> "...for example, an IdP to a Verifier, or some non-IdP application to 
> a Verifier".
>
> The phrase "non-IdP application to a Verifier" clearly puts "non-IdP  
> Authentication Secrets that incidentally use the same Verifier as the 
> IdP" in scope for 4.2.3.6.2.
>
> I understand that by making this statement and arguing that
> 4.2.3.6.2 keeps in scope the AD traffic between MS Windows deployments 
> and the AD server there are serious issues, but I see no other way to 
> interpret 4.2.3.6.2 in version 1.2 of the spec.
>
> I would appreciate hearing other input on this before I proceed 
> further with the items below, since I believe the construction the AD 
> Cookbook team is using to "thread the needle" here falls apart here if 
> my interpretation stands.

When I read this section I understand "non-IdP authentication secrets" to 
mean those of credentials that are not in scope for the IAP (for which a 
definition is offered in the first paragraph of this cookbook section). I 
don't see any statement in cookbook section 4.2.3 that implies that a non-IdP 
app using AD as a verifier is exempt from 4.2.3.6.2 when handling an in-scope 
secret. Also the cookbook's recommendations in section 5.3.1 explicitly apply 
to non-IdP apps equally.

I read cookbook section 4.2.3's use of a "change my password" app to be a 
literal broadening of what it means to be in scope for the IAP, though a 
logical one. But I suppose it might also mislead a reader to think that no 
other non-IdP app is covered by 4.2.3.6.2. Perhaps a specific statement 
should be included explaining that non-IdP apps which handle in-scope secrets 
are also subject to 4.2.3.6.2 and those that use AD as a verifier are 
addressed in cookbook section 5.3.2.

Further, use of a "change my password" app in connection with in-scope 
secrets is covered under IAP 4.2.4.3. When IAP 4.2.4.3.1 is used for password 
changing, the password changing app is subject to 4.2.3.6.2. So I'm not sure 
that singling it out here is really helpful.

Back to defining what's in scope, the definition in this cookbook section 
appears to be: if it's used to authenticate to the IdP, or if it's used to 
authenticate to a change my password app. I think the definition of in-scope 
authentication secrets is not related solely to specific technologies. They 
are in scope if they meet a whole variety of criteria that underpin the 
design of the overall Silver implementation.

We might suggest editorial changes be made in cookbook section 4.2 to help 
ensure that readers understand what I think the authors intended.

> Thanks,
>
> Scott
>
>> [1] The term “Authentication Secret” is assumed here to include the 
>> information in an authentication packet; e.g., in addition to actual 
>> authentication credentials (username/password), the information 
>> negotiating the initial exchange of a session key or the response to 
>> an authentication challenge is an “Authentication Secret”.
>>
>> [2] This assumes that the local Windows/Kerberos tickets cannot be 
>> leveraged to authenticate the user to the IdP, such as a standard 
>> webpage that prompts for entry of user credentials. If the IdP 
>> supports mechanisms that allow the user to generate authentication 
>> assertions based directly on the possession of local Windows/Kerberos 
>> tickets (e.g., SPNEGO, GSSAPI), then the Windows/Kerberos tickets used in 
>> that interaction WOULD be in scope of this requirement.
>>
>> 4.2.4. Interpretation of IAP Requirement, Section 4.2.3.6.3
>> - Strong Protection of Authentication Secrets
>>
>> This section addresses all handling of IdP Verifier authentication 
>> secrets, even if those authentication secrets are not used to 
>> authenticate anyone to the IdP. Note that authentication secrets that 
>> could be replayed to authenticate directly to the IdP are also 
>> covered by section 4.2.3.6.2, which has stricter requirements around 
>> transport encryption.
>>
>> That is, assuming an IdP that requires manual entry of a
>> username/password:
>>
>>    • applications (including non-IdP applications) that
>>    handle the username/ password would be covered by both
>>    sections 4.2.3.6.2 and 4.2.3.6.3.  • applications
>>    (including non-IdP applications) that handle non-IdP
>>    authentication secrets based on IdP passwords (e.g., LM,
>>    NTLMv1, NTLMv2 or MIT Kerberos authentication packets for
>>    Silver IAQ users) would be covered only by section
>>    4.2.3.6.3
>>
>> This section requires that policies and procedures are in place to 
>> minimize the risk of this traffic being attacked in a way that would 
>> subvert the security of IdP authentication events. While traffic 
>> covered in this section may use Protected Channels to secure 
>> authentication communications, an institution could also use other 
>> mechanisms that are generally considered secure, even if they are not 
>> Protected Channels.
>>
>> For completeness, we note that protection of the password while it is 
>> being locally processed within any application is also required, not 
>> just protection while in transit to or from said application. 
>> However, security of the information while being handled in a 
>> transient fashion within a web application is beyond the scope of AD 
>> DS configuration, so is not covered here.
>>
>> 4.2.5. Interpretation of IAP Requirement, Section 4.2.5.1 - Resist 
>> Replay Attack
>>
>> 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 the AD DS is beyond the scope of 4.2.5.2. Replay of 
>> non-IdP authentication/assertion traffic is covered by sections
>> 4.2.3.6.2 and 4.2.3.6.3.
>>
>> 4.2.6. Interpretation of IAP Requirement, Section 4.2.5.2 - Resist 
>> Eavesdropper Attack
>>
>> 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 the AD DS is beyond the scope of 4.2.5.2. Eavesdropping 
>> on non-IdP authentication/assertion traffic is covered by sections
>> 4.2.3.6.2 and 4.2.3.6.3.
>>
>> 4.2.7. Interpretation of IAP Requirement, Section 4.2.8.2.1
>> - Network Security
>>
>> "Network communications supporting IdMS operations" is interpreted to 
>> mean communications between the actual software elements of the IDMS 
>> operation or administrative traffic to the IDMS.
>>
>> So the only AD DS-specific communications that would be in scope of 
>> this requirement is intra-domain controller password replication. 
>> (Note that provisioning of passwords into AD-DS is covered by 
>> 4.2.3.6.1)
>>
>>
>> Ann West Assistant Director, InCommon Assurance and Community 
>> Internet2 based at Michigan Tech 
>> 
>>  office: 
>> +1.906.487.1726