ad-assurance - [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
[AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft
Chronological Thread
- From: Ann West <>
- To: "" <>
- Subject: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft
- Date: Fri, 4 Oct 2013 15:12:32 +0000
- Accept-language: en-US
Hi All,
Below are a few comments on the Cookbook from Joe St Sauver. I will link
this note to the comments wiki page.
Ann
On 10/2/13 11:46 AM, "Joe St Sauver"
<>
wrote:
>Hi Ann,
>
>Thanks for the opportunity to review and comment on
>https://spaces.internet2.edu/display/InCAssurance/InCommon+Silver+with+Act
>ive+Directory+Domain+Services+Cookbook+-+DRAFT+20131002#InCommonSilverwith
>ActiveDirectoryDomainServicesCookbook-DRAFT20131002-DocumentStatus
>Please pass these comments along to the appropriate parties for
>consideration.
>
>-- "4.1.2 Interpretation of IAP requirement, Section 4.2.3.4 - 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:
>
> http://msdn.microsoft.com/en-us/library/cc236715.aspx
>
> http://technet.microsoft.com/en-us/library/dd560653%28WS.10%29.aspx
>
> 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
> http://support.microsoft.com/kb/2793313
>
> [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 4.2.3.6.2
> 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:
>
>
>http://www.irongeek.com/i.php?page=videos/derbycon2/1-2-4-zack-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)
>
>-- 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
> http://tools.cisco.com/security/center/home.x
>
>Regards,
>
>Joe
>
- [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Ann West, 10/04/2013
- Re: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, David Walker, 10/04/2013
- [AD-Assurance] More responses to Joe S's comments, Eric Goodman, 10/04/2013
- [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Brian Arkills, 10/07/2013
- [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Rank, Mark, 10/07/2013
- [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Eric Goodman, 10/07/2013
- [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Capehart,Jeffrey D, 10/07/2013
Archive powered by MHonArc 2.6.16.