Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] RE: BitLocker operational issues

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

[AD-Assurance] RE: BitLocker operational issues


Chronological Thread 
  • From: Eric Goodman <>
  • To: "" <>
  • Subject: [AD-Assurance] RE: BitLocker operational issues
  • Date: Fri, 7 Jun 2013 22:09:06 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport04.merit.edu; dkim=neutral (message not signed) header.i=none

>Why again did we rule out an alternate means for Microsoft's own proprietary encryption for the credential store?

 

My take:

                                                                                                                                                                                      

1)      As Ron said, since BitLocker is delivered at no cost, it seemed like it made more sense to recommend meeting the requirement than to recommend not meeting it and arguing an alternative means.

2)      As David called out on the call, and as I argued when we removed the “entropy defense” for storage of password secrets, the mode of attack may argue for when an RC4 alternate means makes sense. Specifically:

a.       When the secret being protected is a transient one (e.g., the contents of an NTLMv2 authentication) then a successful attack requires targeting an individual account, and seeing multiple interactive operations. To use David’s language from this AM’s call, the attack proceeds at “network speed”, and in many cases it is possible to mitigate attacks by limiting the maximum network speed. (E.g., account lockouts, delays in responding to authentication requests etc).

b.      When the secret being protected is a static collection (e.g., the contents of the AD password store) – and when the collection is not salted – then any attack is actually a simultaneous attack on all accounts, and is not limited by actions that can be mitigated by the domain admin. Again using David’s language, the attack proceeds at “machine speed”.

c.       Based on the difference here, there’s a reasonable argument that even if we argue RC4 as an appropriate alternative means for the interactive processes (NTLMv2, Kerb authentication) that it might still not be sufficient for protection of the stored secrets. Note that even Microsoft argues that AD DS meets FIPS-like standards on the basis of the use of BitLocker, and not based on an alternative means statement for RC4, so it’s not unreasonable to separate the two use cases.

 

I think I fall on the side of preferring to meet for stored passwords (rather than using an Alternative Means) even if we do an Alternative Means for the interactive stuff. But again, I don’t think that’s a clear decision of the group, as much as it’s an open question that might be driven by the discussion with Microsoft.

 

In any case, no one has drafted any Alternate Means statements for the use of RC4 for either use case, so if we want to present one, that’s an AI someone has to take. I think our current plan is to talk to MS to see if we get a better feel of whether AM is needed and what we should say, which is (I presume) why no one walked away with the task of drafting that (those?) specific AM statements.

 

--- Eric

 

 

 

From: [mailto:] On Behalf Of Rank, Mark
Sent: Friday, June 07, 2013 1:16 PM
To:
Subject: [AD-Assurance] RE: BitLocker operational issues

 

 

Why again did we rule out an alternate means for Microsoft's own proprietary encryption for the credential store?

 

Just curious.

Mark

 

 

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

Mark Rank
Project Manager - Identity & Access Mgt

UCSF Information Technology Services (ITS)
email:

phn:414-331-1476

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


From: [] on behalf of Ron Thielen []
Sent: Friday, June 07, 2013 11:59 AM
To:
Subject: [AD-Assurance] BitLocker operational issues

I raised the question about BitLocker operational issues, because something was  nagging at the back of my mind.  I asked the Windows admins and they pointed me in the right direction.

 

It turns out that there is a significant issue that may affect some institutions.  BitLocker is not supported in virtual environments by either Microsoft or VMware.  We run some of our domain controllers on VMware VMs, so this is certainly an issue for us.

http://technet.microsoft.com/en-us/library/hh831507.aspx#BKMK_VHD

and

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2036142

 

I guess we have to decide whether to move our VMs to physical hardware and lose the advantages that virtualization provides or submit an alternative means statement for RC4.

 

Ron

 

 




Archive powered by MHonArc 2.6.16.

Top of Page