Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] RE: [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

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

Chronological Thread 
  • From: Brian Arkills <>
  • To: "" <>
  • Subject: [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft
  • Date: Mon, 7 Oct 2013 16:38:38 +0000
  • Accept-language: en-US

Here's a draft response. I've borrowed (ok, copied) some of the discussion.
:) Feel free to point out portions you think are lacking or need a rewrite.

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

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 Secrets)
> > as they are accessed would meet the requirement of "only decrypt(ing)
> > 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 secret
> > 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 Microsoft.

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 say:
"However, unfortunately, you *SHOULD* ALSO insist that NTLM ALSO not be used"

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 below.

> >-- "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

• 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
resistance 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 an
> > account is every "temporarily compromised," it would need to have a
> > thorough security audit before being re-enabled, but my worry is that
> > 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 document.

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).

If AD-DS is the verifier for your IdP, then your concerns are warranted.

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 different
> > 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