Meeting the InCommon Assurance profile criteria using Active Directory

[Ann West <>]

You are correct Eric and my bad for not commenting on the politeness and
thoroughness of Brian's responses.

Ann



On 10/8/13 4:35 PM, "Eric Goodman" 
<>
 wrote:

>Agreed, but I will say that I like the preamble (as well as your
>answers). Assuming the preamble goes right before his comments and your
>answers (one level of quotes of his comments, none for your answers) it
>looks great.
>
>--- Eric
>
>-----Original Message-----
>From: 
>
>[mailto:]
> On Behalf Of Ann West
>Sent: Tuesday, October 08, 2013 1:05 PM
>To: 
>
>Subject: Re: [AD-Assurance] FW: [InC] New Silver with Active Directory
>Cookbook: Call for Comments on 20131002 Draft
>
>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.
>>
>