Meeting the InCommon Assurance profile criteria using Active Directory

[Ann West <>]

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.

Ann


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

>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
>thoughtfulness.
>
>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
>comments.
>
>> >-- "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.
>
>[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 4.2.3.4. IAP section 4.2.3.4 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.
>
>> >
>> >   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]
>
>[BA] Section 5.3.2 of the document refers to IAP section 4.2.3.6.3. IAP
>section 4.2.3.6.3 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
>> 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.
>
>[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 
>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
>>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.
>
>[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 4.2.4.2.1:
>"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:
>> >
>> >
>> >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)
>
>[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
>and
>2) it is impractical to deduce a user's password by intercepting NTLMv2
>packets
>
>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
>>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 4.2.5.2 (which we discuss in our section
>5.3.3). IAP 4.2.5.2 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
>> >   http://tools.cisco.com/security/center/home.x
>
>[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.