Skip to Content.
Sympa Menu

ad-assurance - Re: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

Re: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft

Chronological Thread 
  • From: Ann West <>
  • To: "" <>
  • Subject: Re: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft
  • Date: Mon, 7 Oct 2013 19:18:30 +0000
  • Accept-language: en-US

I will ask Joe if he minds us responding to his comments on a public list.
Once we agree on the response, I think you should post it, Brian.


On 10/7/13 3:11 PM, "Brian Arkills"

>Here's a revised take, with just two changes:
>-a stronger emphasis on the compliance vs. security tension at the start,
>-removing the problematic sentence I had that Eric/Jeff called out.
>I've chosen not to try to get into AD-DS as a verifier, because I think
>that overcomplicates the response, and if we really need to explain that
>detail to Joe, then it should be in the cookbook.
>Assuming folks are copacetic with this version, what's the next step?
>At a minimum, I'm thinking we should ask Joe if he's OK having his name
>associated with our response on the assurance mailing list. If not, then
>we might want to make his comments anonymous in the wiki & remove his
>name below.
>And beyond that, I'd be happy to either post the response "on behalf of
>the AD-assurance team" or let someone else do so.
>Hi Joe,
>Thanks a lot for taking the time to review what we've put together, and
>for the really detailed comments. We really appreciate your time and
>One thing to keep in mind is that while we share your desire to be
>secure, the obligation of this document is to outline the minimum
>required to meet the IAP. We could recommend quite a few things that
>would be a more secure way to run AD-DS, but that would go above and
>beyond what is required to meet the IAP. We do not mean to discourage
>folks from going beyond, but not everyone can go beyond, so we must speak
>to the lowest common denominator that meets the IAP.
>To keep things simple, we've put some responses below in-line with your
>> >-- "4.1.2 Interpretation of IAP requirement, Section - Stored
>> > Authentication Secrets"
>> >
>> > "We interpret this requirement to mean that encryption software that
>> > decrypts disk sectors (and not just individual Authentication
>> > as they are accessed would meet the requirement of "only
>> > the needed Secret when immediately required for authentication" as
>> > spelled out in this section, presuming such software uses Approved
>> > Algorithms for the encryption process."
>> >
>> > As written, this would be overbroad, e.g., decrypting a needed
>> > for one individual might result in the decryption of MULTIPLE
>> > secrets, e.g., the one for that individual AND ones used by others.
>> >
>> > As such, that would violate the requirement that passwords must
>> > "only [be] decrypted when immediately required for authentication"
>> > because you're also potentially decrypting OTHER passwords that are
>> > not needed at all. This would represent a failure to meet the
>> > requirement, at least from my POV.
>> >
>> > In the extreme case, imagine a person proposing to use boot time
>> > whole disk decryption: while off, the disk may be encrypted with an
>> > Approved Algorithm, but upon boot, the entire disk is decrypted,
>> > including the password store, which is then "immediately" (and
>> > intermittently) used until the system is eventually shut down. Would
>> > that be satisfactory/sufficient to meet the requirement? I don't
>> > think so.
>> >
>> > Remember that presumably the goal is to limit the exposure of
>> > passwords to unauthorized access or misuse. If the passwords are
>> > routinely held in non-encrypted form whenever the system is "live",
>> > except briefly during boot time when the system is coming up, it
>> > isn't clear to me that the encryption protects against any exposure
>> > except theft of the disk from a quiescent system. Any attack against
>> > the password store while the system is live would not require the
>> > attacker to decrypt the password store if the password store is
>> > routinely decrypted at boot time.
>> >
>> > Thus, I explicitly reject the argument advanced in 5.1.1 later in
>> > the document.
>[BA] First, let me say that the AAC interpretation we've received
>validates our approach here. But let's jump down into the details. :)
>The details of the whole-disk encryption product you use here definitely
>may affect whether this approach is valid or not. We focused on
>BitLocker, because there is no extra cost to use it, and it is
>well-documented and understood. But we didn't want to arbitrarily limit
>everyone else to BitLocker. So let's examine whether BitLocker fails to
>meet the IAP requirement here or not.
>BitLocker decrypts data on a sector by sector basis *when* that data is
>needed. It does *NOT* decrypt the entire disk at boot time. This is
>well-documented and we took the extra step of verifying this with
>Based on some rough calculations, user object records are typically
>larger than the most common disk sector size (4K), so it is very unlikely
>that when needing to validate one user's password that many other user's
>passwords are also decrypted.
>But we'd like to take one step back, and note that the threat being
>addressed by this section is theft of disks, and we believe disk
>encryption is effective whether the system is quiescent or active. We'll
>try to make our interpretation of the threat clearer in the cookbook.
>> >-- "5.1.2 Remove Insecure (LMHASH) Stored Secrets"
>> >
>> > Good to see you recommend removing LMHASH'd passwords. However,
>> > unfortunately, you ALSO insist that NTLM ALSO not be used,
>> > consistent with:
>[BA] We didn't insist that NTLM also not be used. We believe you meant to
>"However, unfortunately, you *SHOULD* ALSO insist that NTLM ALSO not be
>In other words, we think you left out the word "should" in your assertion.
>With that assumption, we respectfully disagree. This section of the
>document refers to IAP section IAP section is focused on
>the security of passwords at rest. The 2 URLs you've noted below are not
>relevant to how passwords are stored in AD-DS--they are relevant to the
>negotiation of how to validate that you know the password, and speak to
>the security of transmission on the wire.
>AD-DS has *ONLY* two ways of storing a password:
>1. LM hash
>2. NT hash
>#1 is used by the LanMan authentication provider. #2 is used by the
>NTLMv1, NTLMv2, and Kerberos authentication providers.
>In other words, turning off NTLMv1 or NLTMv2 doesn't change whether or
>not an NT hash is stored in AD or not. There is currently no supported
>way to turn off whether or not an NT hash is stored.
>> >
>> >
>> >
>> >
>> >
>> > Note that you will run into issues if you have an environment that
>> > uses antique versions of Windows (Vista, 2008, XP, etc.), but those
>> > systems should be getting upgraded or taken off the wire anyhow.
>> >
>> > If you can't break use of NTLM entirely, at least break NTLMv1, see
>> >
>> >
>> > [Oh! I see that you talk about this in 5.3.2, as well... but you
>> > imply that NTLMv2 is "reasonably secure" -- it isn't]
>[BA] Section 5.3.2 of the document refers to IAP section IAP
>section is focused on the security of passwords in transit.
>We'll comment more about NTLM in the context of passwords in transit
>> >-- "5.2.1 Transmission of Authentication Secrets Between Credential
>> > Stores"
>> >
>> > In the bulleted item, the text current reads "select one of the AES
>> > options"
>> >
>> > There are only two options: AES128_HMAC_SHA1 and
>> >
>> > Of the two, AES256_HMAC_SHA1 would be preferable, but it still uses
>> > SHA1 which is deprecated/will be deprecated as the document itself
>> > notes at 2.3 in bold text.
>[BA] The recent security guidance around SHA1 is not that all forms of
>SHA1 are bad. To repeat: SHA1 != deprecated. If you look more closely at
>the details, you'll see that the guidance notes use of SHA1 where the
>effective bit count is lower than 112 is what is being discouraged.
>Neither AES128_HMAC_SHA1 nor AES256_HMAC_SHA1 stray below that mark, so
>both are acceptable.
>• HMAC-SHA-1 is approved after 12/31/2013 even though SHA-1 for digital
>signature is not.
>• HMAC-SHA-1 is capable of security strengths of 80, 112, and 128 bits.
>(112 is required after 12/31/2013).
>• SHA-1 is 160 bits and provides at least 112 bits of preimage
>that is needed to achieve the 112-bit security strength for HMAC.
>> > This section also requires use of LDAPS (TLS/SSL), but more
>> > specificity is needed when it comes to explaining what constitutes
>> > an acceptable version of TLS (e.g., is TLS 1.0 good enough? It
>> > shouldn't be treated as such). Require TLS 1.2 with an appropriate
>> > cipher suite (that should be a whole section of its own)
>[BA] We believe this issue to be outside the scope of this document. In
>specific, this document seeks to address issues unique to AD-DS when
>attempting to meet the IAP. TLS vs. SSL and specific versions are topics
>much broader than the scope of this document. We agree that implementers
>will be interested in this topic, but it won't just be AD-DS implementers
>that are interested in that.
>> > The Microsoft references in document section 5.3.1 ("Section
>> > requirements") really don't clear this up, either.
>> >
>> >-- 5.3.4
>> >
>> > How would a "temporarily compromised" account be rehabilitated? If
>> > account is every "temporarily compromised," it would need to have a
>> > thorough security audit before being re-enabled, but my worry is
>> > in some cases folks may just require a password change, and that
>> > obviously wouldn't be enough to ensure that a "temporarily
>> > compromised" account has been restored to a trustworthy state.
>> >
>> > Trivial example: assume that while "temporarily compromised" a
>> > backdoor was installed, or access controls were weakened, allowing
>> > persistent access and abuse, even if the password's changed.
>> >
>> > Also, this doesn't treat the possibility of a privileged account
>> > being "temporarily compromised", in which case the entire system
>> > (or even multiple systems, in the case of transitive trust
>> > relationships) may need to be audited and remediated.
>[BA] We also believe this issue to be outside the scope of this document.
>The IAP sets guidelines around restoring a compromised account. Whether
>the IAP's guidance is effective or not isn't a topic specific to this
>We will remove the word "temporarily", as we don't think that adverb
>provides any value and may be distracting.
>> >-- 6. "Alternate Controls and Alternative Means Statements"
>> >
>> > When I try to access the link in this part, I get an access failure.
>[BA] Thanks, we've fixed this.
>> >-- 7.1
>> >
>> > Repeats the unsatisfactory use of a full disk encryption tool
>> > approach. Still not okay.
>[BA] Addressed elsewhere.
>> >-- 7.3
>> >
>> > is the bold text "need to validate algorithm to see if this is
>> > good enough" an author's note that was meant to be resolved prior
>> > to publication?
>[BA] Yes, that needs to be cleaned up. Thanks for noticing. :)
>> > I also have a concern about the 72 hour window mentioned in the
>> > last paragraph of that section. 72 hours is an eternity for an
>> > attacker, and might as well be six months if you're going to make
>> > it 72 hours.
>[BA] 72 hours follows the spirit of the IAP requirements. From
>"The IdPO shall revoke Credential s within 72 hours after being notified
>that a Credential is no longer valid or is compromised." Whether this is
>effective or not is outside the scope of this document. This document is
>focused on helping folks with AD-DS meet the IAP, not focused on having
>the best/most effective security practices. We share your desire to be
>secure, but our obligation here is to outline the minimum required to
>meet the IAP.
>> > As suspected, too, I note that the "temporarily compromised"
>> > account is just required to have credentials reset. That's not
>> > enough, as previously discussed.
>> >
>> >-- 7.4
>> >
>> > Practical attacks against NTLMv2 exist. Example:
>> >
>> >
>> >
>> fasel-pwned
>> >-in-60-seconds-from-network-guest-to-windows-domain-admin
>> >
>> > Repeats the unacceptable "temporarily compromised" language.
>> >
>> > (yes, Zack is in the running for one of the top 10 most annoying
>> > presenters of all time, but still)
>[BA] Yes, practical attacks against NTLMv2 exist (as they do for Kerberos
>too). There are various pass-the-hash and pass-the-ticket vulnerabilities
>documented/known. But that's not relevant here because we are focused on
>AD-DS as part of your IDMS meeting the IAP. I don't believe your comments
>here are really specific to any particular section, so I'll take the
>liberty of being a bit more general too.
>Our relevant assertions are basically that:
>1) NTLMv2 can't be used to authenticate to the IdP
>2) it is impractical to deduce a user's password by intercepting NTLMv2
>Therefore, NTLMv2 use is not in violation of the Silver IAP (assuming
>NTLM cannot be used to authenticate to the IdP).
>From the AD Cookbook: "Even though such intercepted credentials may be
>used to gain access to, e.g., file shares in the AD Domain, this does not
>allow the IdP authentication process to be compromised."
>> >-- 7.6
>> >
>> > If a persistent password is used, how does it preclude a replay
>> > attack? The persistent password is the same thing this time, and
>> > next time, and the time after that, etc.
>> >
>> > A replay-resistent credential would be something like a one-time
>> > crypto fob -- you can't replay that credential because it's
>> > every time you use it...
>[BA] We believe your comments here are specific to section 7.5. But we
>note that we probably led you astray because of a mistake in section 7.6
>where we say "the authentication event resists replay attack." We meant
>to say "resists eavesdropping attack". We'll fix that mistake.
>7.6 is in support of IAP section (which we discuss in our section
>5.3.3). IAP is focused on protected channels. Protected Channels
>resist eavesdropper attacks, which is the requirement, not to preclude
>eavesdropper attacks. The password is clearly replayable. The packet
>containing the password is not, because the protected channel keeps it
>from being so. Similarly, the packet is clearly eavesdroppable, but the
>unencrypted ciphertext is what is not eavesdroppable. And the measure of
>“how hard does it need to be” is “it needs to be a protected channel”.
>> >-- Appendix A
>> >
>> > Recommend removal/decommissioning of all Windows XP systems.
>[BA] While a valiant suggestion, not required to meet the IAP.
>> >-- Appendix B
>> >
>> > Has the Cisco issue been filed with Cisco Security Intelligence
>> > Operations? If not, a case should be opened. See
>> >
>[BA] No. I (Brian Arkills) noted this issue because while working with a
>customer at the UW, I discovered it. I don't have any direct relationship
>with Cisco and have encouraged the customer to report & follow up.

Archive powered by MHonArc 2.6.16.

Top of Page