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: David Walker <>
  • To:
  • Subject: Re: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft
  • Date: Fri, 04 Oct 2013 08:37:49 -0700

Interesting comments.  I think much of what Joe says boils down the the issue we've wrestled with for months: to what degree do we look for perfection, as opposed to reasonably-managed risk.

Talk to you all in 25 minutes.


On Fri, 2013-10-04 at 15:12 +0000, Ann West wrote:
Hi All,

Below are a few comments on the Cookbook from Joe St Sauver. I will link
this note to the comments wiki page.


On 10/2/13 11:46 AM, "Joe St Sauver" <> wrote:

>Hi Ann,
>Thanks for the opportunity to review and comment on
>Please pass these comments along to the appropriate parties for
>-- "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.
>-- "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:
>   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]
>-- "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 AES256_HMAC_SHA1
>   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.
>   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)
>   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.
>-- 6. "Alternate Controls and Alternative Means Statements"
>   When I try to access the link in this part, I get an access failure.
>-- 7.1
>   Repeats the unsatisfactory use of a full disk encryption tool
>   approach. Still not okay.
>-- 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?
>   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.
>   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:
>   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)
>-- 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...
>-- Appendix A
>   Recommend removal/decommissioning of all Windows XP systems.
>-- Appendix B
>   Has the Cisco issue been filed with Cisco Security Intelligence
>   Operations? If not, a case should be opened. See

Archive powered by MHonArc 2.6.16.

Top of Page