Meeting the InCommon Assurance profile criteria using Active Directory

[Ann West <>]

Maybe take out my initial note and your comments and  just include Joe's
questions and your answers?


Ann

On 10/8/13 3:49 PM, "Brian Arkills" 
<>
 wrote:

>Since things have died down, I'm going to assume that the latest revised
>response meets with everyone's approval such that I should move ahead
>with sending it.
>
>I'll plan on sending this out around 2pm Pacific time (about an hour from
>now), unless someone throws a flag on the play. :)
>
>And so folks know, I'll add this pre-amble to that response, to set the
>stage.
>-----
>Hi folks,
>
>I'm writing today on behalf of the InCommon Assurance Active Directory
>working group, the folks that recently published the "InCommon Silver
>with Active Directory Domain Services Cookbook" draft which is open for
>public comment and review through November 8, 2013. See
>https://spaces.internet2.edu/x/dJSVAQ for that draft.
>
>Last week, we received a set of extensive comments from Joe St. Sauver.
>Joe took a lot of time carefully reviewing the draft and clearly put some
>extra effort into those comments. We are grateful for his time.
>
>We are taking the somewhat unusual step of responding to his comments
>publicly on this list to encourage discussion and review of our draft
>while also possibly raising other related discussion. Joe has graciously
>agreed to allow us to respond here so that we can promote broader
>discussion than a private response (or a response on an obscure web page)
>would foster. :) 
>---
>
>
>> -----Original Message-----
>> From: 
>> 
>>  [
>> ]
>>  On Behalf Of Ann West
>> Sent: Monday, October 07, 2013 12:19 PM
>> To: 
>> 
>> Subject: Re: [AD-Assurance] FW: [InC] New Silver with Active Directory
>> Cookbook: Call for Comments on 20131002 Draft
>> 
>> 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.
>