Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

David,

 

I’ve just skimmed through the 478 page FICAM Roadmap and Implementation Guidance Version 2.0 http://www.idmanagement.gov/documents/FICAM_Roadmap_and_Implementation_Guidance_v2%200_20111202.pdf

 

Big Picture: Maybe we have been looking at this wrong?  Ultimate question:  Is AD-DS really in scope?

 

My take on the FICAM roadmap document is that they want to help federal agencies get out of the business of maintaining separate ID’s and passwords for every application that a government worker has to login to.  So right now, doing that is a bigger problem than say, following the letter of SP800-63 as defined for the credential store (i.e. Active Directory).

 

Here are some examples where the more difficult parts of SP800-63 seem to be overlooked, bypassed, worked-around, or future-to-worry-about.

 

(See page 93.) 4.6. Create, Issue, and Maintain Password Token

 

(Read through the use case and then note the assumptions below.)

Assumptions in this use case include:

· The as-is process will not describe password management via domain controllers or other central management tools.

· Management of roles, identity data or privileges associated with the password is out of scope of this use case; those activities are described in other use cases.

 

As you may read through the roadmap, there are references to SP800-63, and even some proofing wording pulled right out of LOA1 and LOA2.  But nowhere do they discuss the password storage.

 

So, if FICAM isn’t worried about it in their roadmap, it begs the question as to why even bother.  As we have seen, AD-FS pushes off the authentication to AD-DS, and as you said we had determined that AD-DS was out-of-scope for AD-FS. 

 

By that extension, if we’re using Shibboleth SAML 2.0, and say the VT middleware app that does LDAPS authentication to Active Directory, why should that be considered differently than how AD-FS works that puts AD-DS out-of-scope for Silver?

 

And here is even more explicit wording pulled straight from a 3-letter agency Protection Profile (PP) updated as of 8/31/2012:

 

FPT_APW_EXT.1.1 The TSF shall store credentials in non-plaintext form.

FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext credentials.

Application Note: The intent of the requirement is that raw authentication data are not stored in the clear, and that no user or administrator is able to read the raw authentication data through ―normal‖ interfaces. An all-powerful administrator of course could directly read memory to capture a password but is trusted not to do so. In this version of the PP there are no requirements on the method used to store the credentials in non-plaintext form, but cryptographic methods based on the requirements in FCS_COP are preferred. In future versions of this PP, FCS_COP-based cryptographic methods that conform to the Level 2 Credential Storage requirements from NIST SP 800-63 will be required.

 

FCS_COP says:  “should use sufficiently strong and sufficiently trusted encryption algorithms to protect data in transit to and from the TOE.”

4.5 Protected Credentials

Protecting transmitted credential information is only part of the credential protection picture. It is also critical to protect the credentials as stored by the TOE so that they cannot be accessed in a raw plaintext form, and the subsequently replayed and used to impersonate a user.

 

The upshot is that maybe we will find out from Microsoft that some future Windows version will be fully compliant and use only approved algorithms for storing authentication secrets, and that time is needed to transition to the fully compliant version.  If so, then we need to figure out if Active Directory is good enough as-is, good enough with at least a minimum set of compensating controls, good enough with configuration X-Y-Z, or perhaps scope it out like everyone else seems to be doing.

 

We know AD-DS is the credential store.  As such it is hard to just ignore it.  But is that a battle for today or tomorrow, and is following the crowd the right way to go?  Ideally, we do want to have full compliance with the specs.

 

Jeff

 

From: [mailto:] On Behalf Of David Walker
Sent: Tuesday, May 07, 2013 11:41 AM
To:
Subject: Re: [AD-Assurance] Microsoft Strategy / FICAM / Kantara

 

Jeff,

Thanks for the link.

You're right that all components of the IdMS must protect credentials, but my memory is that we determined that ADFS does not have access to passwords (as Shibboleth does not).  Nevertheless, it's worth confirming that with Microsoft.  I've added "Are AD-DS password credentials stored by other Microsoft identity management components, such as ADFS?  If so, what are those components?" to our list of questions.

David

On Tue, 2013-05-07 at 03:18 +0000, Capehart,Jeffrey D wrote:

David,

 

From Kantara, see http://kantarainitiative.org/programs/iop-saml/ where the product or service for ADFS 2.0 is listed as “IDP Light”.  There is also a note showing other protocols for ADFS are “WS-Federation”.

 

Yes, I agree on SAML 2.0, but Kantara Initiative is supposed to meet similar SP800-63 requirements for LOA-2 just as InCommon Silver.  If ADFS is being offered as a SAML 2.0 interoperability product under IdP Lite, (similar to Shibboleth for SAML 2.0 under InCommon?) then would not the IdP be responsible as well to meet the requirements of protecting stored secrets, protected channels, and approved algorithms, regardless of choice of interoperability (SAML 2.0)?  Therefore shouldn’t Microsoft explain how to configure both ADFS and ADDS to meet the requirements?

 

The table linked above has an entry for ADFS that links to a Microsoft page with many further links.  I’ve summarized a handful of links that I traversed through.

AD FS 2.0 Content Map

http://social.technet.microsoft.com/wiki/contents/articles/2735.ad-fs-2-0-content-map.aspx

 

Interesting Q&A on ADFS. http://blogs.technet.com/b/askds/

Question

In Windows 7 and Server 2008 Kerberos DES encryption is disabled by default.

At what point will support for DES Kerberos encryption be removed? Does this happen in Windows 8 or Windows Server 2012, or will it happen in a future version of Windows?

Answer

DES is still available as an option on Windows 8 and Windows Server 2012, though it is disabled by default. It is too early to discuss the availability of DES in future versions of Windows right now.

There was an Advisory Memorandum published in 2005 by the Committee on National Security Systems (CNSS) where DES and all DES-based systems (3DES, DES-X) would be retired for all US Government uses by 2015. That memorandum, however, is not necessarily a binding document. It is expected that 3DES/DES-X will continue to be used in the private sector for the foreseeable future.

I'm afraid that we can't completely eliminate DES right now. All we can do is push it to the back burner in favor of newer and better algorithms like AES.

 

Even more good stuff… Microsoft Security Intelligence Report (SIR) on Managing Risk and “Defending Against Pass the Hash” also has some information that may be helpful for Alternative Means. 

 

http://www.microsoft.com/security/sir/strategy/default.aspx#!password_hashes

 

For example:

“Microsoft has never provided an intentional way for any user to access stored credentials, although several tools have been discovered that are designed to give attackers access to stored hashes, often using Local Security Authority (LSA) process injection. Even then, the tools require Local System, local Administrator, or domain Administrator account level access to be successful—in other words, the attacker needs to have already compromised the computer or network before these tools can be used to harvest and use hashes.”

 

And finally, from Microsoft Technet Ask Premier Field Engineering (PFE) Platforms:  “What can be used to keep Active Directory data secure?”

http://blogs.technet.com/b/askpfeplat/archive/2012/09/26/what-can-be-used-to-keep-active-directory-data-secure.aspx

 

With the increase in concern over data privacy and security, one of my customers recently asked about securing Active Directory data while stored on disk and what could be done in relation to network traffic. My first thoughts were BitLocker and IPSEC. However, there are a number of different considerations that factor in. […]

 

 

Jeff

 

From: [] On Behalf Of David Walker
Sent: Monday, May 06, 2013 6:43 PM
To:
Subject: Re: [AD-Assurance] Microsoft Strategy / FICAM / Kantara

 

Jeff,

From my reading, "IdP Lite" is a level of SAML 2.0 interoperability, not assurance.  The list I saw, though, didn't mention Microsoft; do you have the URL of what you saw?

Nevertheless, the Kantara link is a good one.  I'll change that question to say "Does Microsoft have a strategy for supporting compliance with the Federal Identity, Credential, and Access Management (FICAM) requirements at LoA-2, perhaps through Microsoft's partnership with the Kantara Initiative? If so, what is the time frame?"

David

On Mon, 2013-05-06 at 21:35 +0000, Capehart,Jeffrey D wrote:

On the question “Does Microsoft have a strategy for supporting compliance with the Federal Identity, Credential, and Access Management (FICAM) requirements at LoA-2? If so, what is the time frame?”

 

Note that Microsoft is a partner with Kantara, and that AD-FS was listed as the Microsoft technology adopted that passed “IdP Lite” level

 

Presumably they passed based on the Common Criteria EAL4 done for Windows Vista and Server 2008?

 

Perhaps the question to ask is how does AD-FS and AD-DS meet the SP 800-63 approved algorithm requirement for stored authentication secrets, and other aspects per our gaps table?

 

When I looked at the documents, it seemed as if there was a reliance on AD-DS by AD-FS.  And the Common Criteria specs excluded the one piece that would have tested 4.2.3.6 as “not applicable”.

 

Not to mention the many references to assumptions that were made for the EAL4 evaluation…

 

However, the main point is that Microsoft should already be familiar with the Kantara Initiative, so perhaps that is the way to go since many of the same requirements are present due to FICAM profile approval.

 

Jeff