Meeting the InCommon Assurance profile criteria using Active Directory

["Capehart,Jeffrey D" <>]

Great find Ron!

 

Interesting that Microsoft basically says that it doesn’t matter that RC4 isn’t an approved algorithm because ultimately an approved algorithm is used by Bitlocker.  Translation:  You need to BitLocker your domain servers to get FIPS 140-2/Approved Algorithm for the password store.

 

The implementation of the RC4 encryption and decryption is not provided by a Windows OS cryptographic module, but residing within the Active Directory (ntdsa.dll and ntdsai.dll).  However, because of the availability of the Windows OS BitLocker™ components for supporting the Full volume encryption, the above attributes are ultimately encrypted.  As shown on http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2008.htm, Windows Vista BitLocker™ components have received FIPS-140-2 (Cert # 947) and Windows Server 2008 BitLocker™ components have received FIPS-140-2 (Cert # 1054).  Consequently, the password based authentication data stored as Active Directory object attributes are encrypted through the use of operating system provided cryptographic services, which are compliant with the FIPS-140-2 requirements.

 

The doc also addresses the RPC functions for resetting password on page 208-209.  (Ron, Eric: RPC action item?)

 

On NTLM there were several mentions that also covered DPAPI and PKCS#5v2.  From initial reading, I could not tell absolutely if PKCS would meet approved algorithm, since it is based on a pseudo-random function (PRF) for password-based key-derivation which is then supposed to be used to feed an AES256 or 3DES (TDEA) encryption. (Pages 203, 206, and 207).  HMAC is used with SHA1 which is reported to be an approved algorithm, which is used to create a derived key via PKCS, which is then used in the cryptographic algorithm (AES256 or TDEA). 

 

However, with all the above considered, it looks likely that functions using DPAPI, even with an NTLM OWF/password hash, could potentially be considered compliant due to the way in which the NTLM gets used in the process.

 

(Additional review based on other standards left to the reader as an exercise…)

The Microsoft doc was dated 2009, and at that time, indicated no products had been evaluated per the Common Criteria (CC).

 

The link in the document has many operating systems now (as of 2013) evaluated per the CC.  There are several for Windows.

 

Scroll through the list for various OS such as Red Hat Linux, IBM zOS, IBM AIX, CITRIX, and Microsoft Windows 7 / Server 2008 R2.  Be sure to find the specific version you have, as some reports are only EAL1 whereas others are EAL4+.  Latest Microsoft Windows OS reports are from 2012-02-06, but country may factor into the evaluation too.

http://www.commoncriteriaportal.org/products_OS.html#OS

 

Each OS evaluation will have:

   Certification Report (PDF)

   Security Target (PDF)

   Protection Profile (PDF, optional)

 

Perhaps these certification reports may have some bearing on acceptance for any alternative means.

 

Jeff C.

 

From: [mailto:] On Behalf Of Ron Thielen
Sent: Friday, May 31, 2013 6:37 PM
To:
Subject: RE: [AD-Assurance] RE: Action Items from May 10

 

I was sure I pasted in the URL for the doc, but apparently not.  It can be found here.  This link takes you to version of the document which is about 140 pages longer than the one I originally found.

http://www.microsoft.com/en-us/download/confirmation.aspx?id=5506

 

 

From: [] On Behalf Of Ron Thielen
Sent: Friday, May 31, 2013 5:11 PM
To:
Subject: RE: [AD-Assurance] RE: Action Items from May 10

 

Okay, I finally found something from Microsoft that verifies that 128 bit RC4 is what syskey uses for encryption.  There are lots of, what I considered to be, non-authoritative sources that said this, but most of the Microsoft documentation doesn’t get so specific.  Then I found a gem of a document “Addressing a Commercial Grade Operating System Security Functional Requirement Set with Windows Vista and Server 2008.”

 

This 518 page document sets out to demonstrate how Vista and Server 2008 can meet a set of security requirements for “commercial grade operating systems” that are drawn up from a variety of influences, including ISO 15408 CAPP, USGPP, SP 800-53, et al.  I haven’t dug through its entirety, but noted that it includes things like a section on FIPS 140-2 conformance.  I think we will want to spend some quality time with this paper.

 

For syskey, if we write alternative means for RC4, then someone could make a case that it suffices for the protection of stored secrets.

 

Ron

 

From: [] On Behalf Of Ron Thielen
Sent: Friday, May 17, 2013 2:11 PM
To:
Subject: RE: [AD-Assurance] RE: Action Items from May 10

 

Yes, and the “default stored locally” is what I was referring to when I talked about the key material being stored in the registry.

 

Ron

 

From: [] On Behalf Of Brian Arkills
Sent: Friday, May 17, 2013 2:01 PM
To:
Subject: RE: [AD-Assurance] RE: Action Items from May 10

 

http://technet.microsoft.com/en-us/library/hh994564(v=ws.10).aspx has some explanation of syskey. There are 3 modes:

-syskey stored locally. This is the default.

-syskey generated by the administrator and not stored anywhere. This option requires that at boot, someone interactively supply that syskey.

-syskey stored on floppy (or apparently any removable media at a:\). This option also requires that at boot, someone provide the syskey via removable media.

 

So syskey is used in all scenarios, it's just a matter of where it is stored that changes.

 

From: [] On Behalf Of Ron Thielen
Sent: Friday, May 17, 2013 11:44 AM
To:
Subject: RE: [AD-Assurance] RE: Action Items from May 10

 

I believe that without syskey the SAM password data is encrypted, but just with DES_ECB.  Also, from what I have read, the encryption key is known to be the user’s RID (Relative ID, part of their SID), so it doesn’t actually protect anything just obfuscates with a weak algorithm.

 

I agree that RC4 is in play with syskey.  Everything I’ve read indicates that RC4 128 bit is the algorithm that syskey uses.

 

One problem with syskey is that the default is to store the PEK in the registry.  Given enough, readily available, knowledge about how the PEK is secured  and used you can derive its value and then potentially decrypt the syskey protected data.  If we want to pursue this, I think we may need to recommend using a boot time passphrase or storage on a removable device that is indeed removed during normal operations.

 

It might be worth noting that stealing the SAM database generally means that the attacker has already compromised administrative credentials on the system.  Since administrators of the IDMS have to have credentials that meet or exceed the requirements of the IAP profile being applied, there is a certain level of mitigation in place already.  Additionally technologies like IDS or file monitoring can be used to detect potential compromises and policies like ones requiring destruction of media for IDMS systems, e.g. we don’t let vendors take our hard drives replaced under maintenance.

 

Ron

 

From: [] On Behalf Of Jeff Whitworth
Sent: Friday, May 17, 2013 11:22 AM
To:
Subject: Re: [AD-Assurance] RE: Action Items from May 10

 

My understanding is that the database is encrypted even without syskey being used, but that it is fairly trivial to determine that key from the registry.  Using syskey does bring in RC4 into the mix but the encryption key is based on the syskey value instead data stored within LSA secrets.  I may be a little off, but that is what I remember.  I also believe that using syskey means the valueused for encryption is never written to disk, but is stored in memory.

 

Jeff

Jeff Whitworth

Manager, Enterprise Systems Architecture

University of North Carolina at Greensboro

336.334.9854

 

MCITP: Enterprise Administrator

GIAC Certified Windows Security Administrator

 

On Fri, May 17, 2013 at 12:01 PM, Capehart,Jeffrey D <> wrote:

Eric,

 

Nice work.  You are a Goodman**2.  (That’s my geek-speek for ‘Goodman, you’re a good man’)

 

I went back and read all the minutes from the previous cookbook discussion just so they would be fresh.  I had not realized that we had gone from 1.0 (NIST encryption) to 1.1 (industry standard) and now (1.2) back to NIST Approved Algorithm.  Interesting.

 

The entropy requirements seem to be leaned on heavily for the 2012 cookbook.  To me, it makes more sense to place the entropy in context, such that if someone can go out on the limb and say that an 8 character password with 10**14 entropy would be sufficient to mitigate the risks with Kerberos, then it becomes relevant to AD meeting “resist [replay, eavesdropper, hijack]” rather than resistance-is-futile.

 

I also thought that RC4 can come into play if SYSKEY is being used.  What I am still not clear on is whether the “password database” is encrypted if SYSKEY isn’t used.  Is the Password Encryption Key used (supposedly RC4) if SYSKEY isn’t turned on?

 

Just an overall comment about the document for the purposes of a “per-institution” version… the “fill-in-the-blank” areas need to be made more explicitly clear that they need to be filled out so that they actually get filled out, rather than being left “blank.”

 

Don’t forget to add a note on the version history when revisions are ready for broader review! J

Jeff

 

From: [mailto:] On Behalf Of David Walker
Sent: Friday, May 17, 2013 11:32 AM

To:
Subject: Re: [AD-Assurance] RE: Action Items from May 10

 

Eric,

This is good stuff.  As a general comment, I think it's fine for us to disagree with the earlier cookbook group.  I say we go ahead with the changes we feel are appropriate and ask them to review our version when we get to a point where it's reviewable.

Some further comments below...

David

On Fri, 2013-05-17 at 02:02 +0000, Eric Goodman wrote:

• Eric to take a first cut at reviewing the Cookbook and develop recommendations for what to keep, cut, and edit.

 

So this one turned out to be quite a bit more challenging than I expected. (It didn’t help that I didn’t really get started on it until today).

 

My edits were – probably unwisely – made on a second copy of the original cookbook (Called “Working copy of …” rather than just the AD cookbook title).

 

https://spaces.internet2.edu/display/InCAssurance/Working+copy+of+InCommon+Silver+with+Active+Directory+Domain+Services+Cookbook+-+May+2013

 

This resulted in page to be harder to find, without adding any value since Confluence would have saved the original pre-edit version anyway. If I can figure out how to move my copy back into the original one, I’ll do that and delete this alternate copy.

 

 

In any case, some major disagreement between the AD cookbook analysis and the Alternative Means strategies we identified around stored passwords. Specifically, the AD cookbook states that the specification of the use of salt is over-prescriptive and basically states that the entire requirement (of using a salt, or on access encryption) is unnecessary. Therefore there is no clear “stub” for us to note the need of Bitlocker (though the use of Bitlocker is encouraged). This conclusion is largely due to the Cookbook misapplying (in my estimation) the entropy requirements against brute force password guessing to the protection of passwords at rest (see my comments in the doc).

I agree that password entropy and encryption at rest are not interchangeable.  I think we can state that as a disagreement with the earlier group and make our Bitlocker statement.

Because the risk assessments are so out of phase with one another in the area of stored passwords, I didn’t see how to put in our commentary without completely rewriting (and revising) the original AD cookbook suggestions, which I think bears more discussion – or at least we should alert the original group that we disagree – before actually making any edits of that magnitude.

I think we agreed to keep a copy of the 2012 Cookbook.  We should feel free to make any changes we see as needed.  As I said, we can ask for the earlier group's input.

On the other areas, we mostly agreed; I added a couple of comments, but there’s still lots of room for editing what I added. E.g., I say “add some of Jeff’s references here” rather than actually having selected his best references. I’m willing to do that addition as well, I just didn’t get to it at this point.

 

I’d like to see the document better formatted to clarify what sections are background info, what are specific operating configuration recommendations, and what is language to use to assert (non-AM) compliance, but I haven’t quite sussed out how to do that yet. For now, I squeezed in our two main additional differences (Require Bitlocker, require invalidating subjects using insecure authentication protocols), and tagged the base disagreements between the two groups. In the doc, my comments are identified with text inside of <<double angle brackets>>.

 

--- Eric