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: ,Eric Goodman <>
- Subject: RE: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft
- Date: Tue, 08 Oct 2013 14:13:38 -0700
+1
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: [mailto:ad-assurance-
] 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:start,
-a stronger emphasis on the compliance vs. security tension at the-removing the problematic sentence I had that Eric/Jeff called out.that
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
explaindetail to Joe, then it should be in the cookbook.then
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,we might want to make his comments anonymous in the wiki & removespeak
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 mustto the lowest common denominator that meets the IAP.Stored
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 -thatAuthentication Secrets"
"We interpret this requirement to mean that encryption
softwareasdecrypts disk sectors (and not just individual AuthenticationSecrets)as they are accessed would meet the requirement of "onlydecrypt(ing)the needed Secret when immediately required for authentication"Approvedspelled out in this section, presuming such software usesothers.Algorithms for the encryption process."secret
As written, this would be overbroad, e.g., decrypting a neededfor one individual might result in the decryption of MULTIPLE
secrets, e.g., the one for that individual AND ones used byauthentication"As such, that would violate the requirement that passwords must
"only [be] decrypted when immediately required forarebecause you're also potentially decrypting OTHER passwords
thatannot 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
withWouldApproved 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."live",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 isexposureexcept briefly during boot time when the system is coming up, it
isn't clear to me that the encryption protects against anyagainstexcept theft of the disk from a quiescent system. Any attackdefinitely[BA] First, let me say that the AAC interpretation we've receivedthe 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.
validates our approach here. But let's jump down into the details.
:)
The details of the whole-disk encryption product you use heremay affect whether this approach is valid or not. We focused onunlikely
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 verythat when needing to validate one user's password that many otheruser'spasswords are also decrypted.We'll
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.try to make our interpretation of the threat clearer in the cookbook.However,-- "5.1.2 Remove Insecure (LMHASH) Stored Secrets"
Good to see you recommend removing LMHASH'd passwords.to[BA] We didn't insist that NTLM also not be used. We believe youunfortunately, you ALSO insist that NTLM ALSO not be used,
consistent with:
meantsay:be
"However, unfortunately, you *SHOULD* ALSO insist that NTLM ALSO notused"assertion.
In other words, we think you left out the word "should" in yourWith that assumption, we respectfully disagree. This section of theon
document refers to IAP section 4.2.3.4. IAP section 4.2.3.4 is
focusedthe security of passwords at rest. The 2 URLs you've noted below arenotrelevant to how passwords are stored in AD-DS--they are relevant tous/library/dd560653%28WS.10%29.aspx
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-thatNote that you will run into issues if you have an environmentthoseuses antique versions of Windows (Vista, 2008, XP, etc.), butseesystems should be getting upgraded or taken off the wire anyhow.
If you can't break use of NTLM entirely, at least break
NTLMv1,AES[BA] Section 5.3.2 of the document refers to IAP section 4.2.3.6.3.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]
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
theusesoptions"AES256_HMAC_SHA1
There are only two options: AES128_HMAC_SHA1 andOf the two, AES256_HMAC_SHA1 would be preferable, but it stillitselfSHA1 which is deprecated/will be deprecated as the documentat[BA] The recent security guidance around SHA1 is not that all formsnotes at 2.3 in bold text.
of
SHA1 are bad. To repeat: SHA1 != deprecated. If you look more
closelythe details, you'll see that the guidance notes use of SHA1 wheremark, so
the effective bit count is lower than 112 is what is being discouraged.
Neither AES128_HMAC_SHA1 nor AES256_HMAC_SHA1 stray below thatboth are acceptable.digital
• HMAC-SHA-1 is approved after 12/31/2013 even though SHA-1 forsignature is not.resistance
• 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 preimagethat is needed to achieve the 112-bit security strength for HMAC.constitutesThis section also requires use of LDAPS (TLS/SSL), but more
specificity is needed when it comes to explaining whatappropriatean acceptable version of TLS (e.g., is TLS 1.0 good enough? It
shouldn't be treated as such). Require TLS 1.2 with antopics[BA] We believe this issue to be outside the scope of this document.cipher suite (that should be a whole section of its own)
In specific, this document seeks to address issues unique to AD-DS
when attempting to meet the IAP. TLS vs. SSL and specific versions
aremuch broader than the scope of this document. We agree thatimplementerswill be interested in this topic, but it won't just be AD-DSimplementersthat are interested in that.IfThe Microsoft references in document section 5.3.1 ("Section4.2.3.6.2requirements") really don't clear this up, either.
-- 5.3.4
How would a "temporarily compromised" account be rehabilitated?have aanaccount is every "temporarily compromised," it would need toallowingthorough security audit before being re-enabled, but my worrythat
isin 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,document.[BA] We also believe this issue to be outside the scope of thispersistent 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.The IAP sets guidelines around restoring a compromised account.failure.
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[BA] Thanks, we've fixed this.4.2.4.2.1:[BA] Addressed elsewhere.-- 7.1
Repeats the unsatisfactory use of a full disk encryption tool
approach. Still not okay.[BA] Yes, that needs to be cleaned up. Thanks for noticing. :)-- 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] 72 hours follows the spirit of the IAP requirements. FromI 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."The IdPO shall revoke Credential s within 72 hours after beingnotifiedthat a Credential is no longer valid or is compromised." Whetheris
thiseffective or not is outside the scope of this document. Thisis
documentfocused on helping folks with AD-DS meet the IAP, not focused onKerberos
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.[BA] Yes, practical attacks against NTLMv2 exist (as they do forAs suspected, too, I note that the "temporarily compromised"fasel-pwned
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--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)too). There are various pass-the-hash and pass-the-ticketvulnerabilitiesdocumented/known. But that's not relevant here because we areon
focusedAD-DS as part of your IDMS meeting the IAP. I don't believe yourcommentshere are really specific to any particular section, so I'll take thenot
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
doesallow the IdP authentication process to be compromised."7.6[BA] We believe your comments here are specific to section 7.5. But-- 7.6different
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'severy time you use it...
we note that we probably led you astray because of a mistake in
sectionwhere we say "the authentication event resists replay attack." Wesection
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 our5.3.3). IAP 4.2.5.2 is focused on protected channels. ProtectedChannelsresist eavesdropper attacks, which is the requirement, not toof
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“how hard does it need to be” is “it needs to be a protected channel”.a[BA] While a valiant suggestion, not required to meet the IAP.-- Appendix A
Recommend removal/decommissioning of all Windows XP systems.[BA] No. I (Brian Arkills) noted this issue because while working-- 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
withcustomer at the UW, I discovered it. I don't have any directrelationshipwith Cisco and have encouraged the customer to report & follow up.
- Re: [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, (continued)
- Re: [AD-Assurance] RE: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, David Walker, 10/07/2013
- [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Brian Arkills, 10/07/2013
- Re: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Ann West, 10/07/2013
- RE: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Brian Arkills, 10/08/2013
- RE: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Capehart,Jeffrey D, 10/08/2013
- Re: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Ann West, 10/08/2013
- RE: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Eric Goodman, 10/08/2013
- RE: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, David Walker, 10/08/2013
- Re: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Ann West, 10/08/2013
- RE: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Eric Goodman, 10/08/2013
- RE: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Brian Arkills, 10/08/2013
- Re: [AD-Assurance] FW: [InC] New Silver with Active Directory Cookbook: Call for Comments on 20131002 Draft, Ann West, 10/07/2013
Archive powered by MHonArc 2.6.16.