Meeting the InCommon Assurance profile criteria using Active Directory

[Ron Thielen <>]

I understand and considered your concern about making changes at this point.  I’m fine either way.   I don’t think that the change itself is substantive enough to cause a problem for those who have already read the document.  I’m happy to let someone else decide.

 

Ron

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Tuesday, October 29, 2013 6:16 PM
To:
Subject: RE: [AD-Assurance] proposed scope addition

 

Sorry all, I kinda dropped off the earth prepping for a presentation that is now complete, I’ll get our response to the AAC together (may not be until tomorrow AM).

 

Ron, I still need to look over your change, which I will also do by tomorrow AM.

 

I question whether the scope update should be added directly into the document at this time, or if we should hold onto it until Ann announces some official “revised draft” announcement. Again, just a process thing, since it’s out for open comment I’m hesitant to make changes that will be “invisible” to the reviewers. And really, I’ll defer to Ann for the “final answer”.

 

--- Eric

 

From: [] On Behalf Of Ron Thielen
Sent: Tuesday, October 29, 2013 12:55 PM
To:
Subject: RE: [AD-Assurance] proposed scope addition

 

Thanks David.  If I don’t hear any objections before then, I will put the changes into the wiki by the close of business tomorrow.

 

From: [] On Behalf Of David Walker
Sent: Tuesday, October 29, 2013 12:12 PM
To:
Subject: Re: [AD-Assurance] proposed scope addition

 

Ron, this looks good to me.  I noted one typo below.

David

On Mon, 2013-10-28 at 22:31 +0000, Ron Thielen wrote:

I propose the following change to section 2,3. I broke the first paragraph into two and added 4 sentences explaining the need to understand how AD fits into the IDMS infrastructure in the context of InCommon identity assurance. Also deleted a redundant “IAQ” in the MFA paragraph.

2.3. Scope

This document focuses specifically on those aspects of Silver IAP compliance specific to an AD environment when using user-selected passwords as the authentication credential. Other authentication components in your environments must also be assessed for compliance with InCommon Silver, but are outside of the scope of this document. For instance, HTTP traffic is not used to communicate with an AD DS store, so requirements for securing HTTP traffic are not discussed in this document, even though institutions will likely need to address security of HTTP traffic in an overall compliance review.

Any institution undertaking a Silver implementation project should carefully read the InCommon Identity Assurance Assessment Framework (IAAF) and Identity Assurance Profiles (IAP), both available from the Assurance section of the InCommon web site. You should thoroughly understand these documents, and determine the remediation needed in your specific environment. Specifically, your will need to understand the role that AD does and does not

"Specifically, you will need..."

play within the context of the defined terms of the IAAF. For example, while AD may provide identities it is likely not the IdP (Identity Provider) for the purposes InCommon Silver or Bronze identity assertions, since AD is unlikely to be issuing the assertions. Similarly, AD may be a Verifier but it may or may not be the Verifier used by the IdP in your environment. Since many of the IAP’s requirements are scoped to some component or process within the identity management infrastructure, a careful understanding of where AD fits within that infrastructure is necessary to understanding which IAP requirements apply to AD in your environment and how they may apply.

Note that this document does not specifically address Bronze IAP compliance.

We believe that many of the approaches documented in this cookbook are applicable to all versions of AD DS from Windows Server 2003 forward (with possible exception of the IPSec approach), although the exact steps to implement them may vary. The documentation below references Windows Server 2008 R2 settings.The recommendations of this document are challenging to implement in a production environment, but the authors believe it is possible to implement them in a reasonable amount of time given some dedicated project resources and a good plan. The size of your AD DS deployment, the types of clients connected to it, the number of customers served (and in what capacity they are served) represent some of the variables you will need to consider when allocating staff and other resources to your AD DS risk mitigation project.

We also note that using Multi-Factor Authentication (MFA) to authenticate Silver IAQ holding users may be a more effective strategy to achieve certification than the recommendations provided in this document, with its focus on securing of password storage and communication of replayable passwords. An MFA-based InCommon Silver compliance review would focus much more on the technology and function of the MFA solution implemented.

A note on SSL/TLS and SHA1: At the time of this writing, there is ongoing discussion of whether or not SSL/TLS based on SHA1 encryption will be considered a FIPS-approved Protected Channel after Jan 1, 2014. All recommendations in this document that refer to SSL/TLS channels assume that such channels are based on FIPS-approved algorithms. Whether SHA1 specifically will suffice for this purpose is beyond the scope of this document. More information regarding this specific issue is available in Draft Special Publication (SP) 800-52 (Revision 1).

 

 

Ron