ad-assurance - [AD-Assurance] RE: Cookbook items - Entropy and Kerberos
Subject: Meeting the InCommon Assurance profile criteria using Active Directory
List archive
- From: Eric Goodman <>
- To: "" <>
- Subject: [AD-Assurance] RE: Cookbook items - Entropy and Kerberos
- Date: Tue, 18 Jun 2013 23:10:02 +0000
- Accept-language: en-US
- Authentication-results: sfpop-ironport05.merit.edu; dkim=neutral (message not signed) header.i=none
OK, what would help is to determine if “entropy” (as used in the password guessing table A.1) is equivalent to “cryptographic operations” (as used with impractical, on the order
of 280 operations, for off-line cracking resistance as the result of eavesdropping.) Both of these definitions come out of SP 800-63-1, so they are not in the Silver spec, but table A is included by reference. The Silver spec mentions entropy, eavesdropping resistance,
and impractical. Perhaps those are terms and assumptions that could be “defined” as part of the AD Alternative Means purposes. My assumption is that a cryptographic operation is a single hashing or encrypting process. Hence my reference to rounds/passes of encryption in the original comment. AES applies its encryption between 10 and
14 times, depending on the actual algorithm. So my assumption is that a password with 2^30 entropy would take ~2^34 cryptographic operations to brute force (2^30 * 14 rounds/password). This may have been a short-cut, but the complete space for 95 characters with 12 length would be 9512 which works out to roughly 279 which is reasonably on
the order of 280 combinations. I don’t think the full entropy calculation was factored in for the “impractical” calculation. Not really following. I understand the character space is 2^79. That assumes random password creation. In reality, humans use many fewer letters. That’s what table A.1 is estimating: the loss in possible entropy
based on their presumptions about the actual “randomness” inherent in user chosen passwords. Going back to Kerberos, SP 800-63-1 is even more unforgiving in that it says “All
assertion protocols used at Level 2 and above require the use of Approved cryptographic techniques. As such, the use of Kerberos keys derived from user generated passwords is not permitted at Level 2 or above.”
How does sentence 2 relate to sentence 1? Kerberos can certainly be set to use only approved algorithms. Is this exclusion related just to the assertion? If that is the case, then for Shibboleth, the assertion is sent via SAML and not Kerberos. I don’t know where that assertion came from (other than our NASA people saying FICAM doesn’t like Kerberos) and wasn’t trying to imply an answer on the Kerberos side. I was strictly focused on the entropy lookup,
and the “entropy vs. cryptographic operations” language. My thinking here is that if Kerberos could be interpreted/configured to be OK for Level 2 (Silver), with keys derived from user generated passwords, then Kerberos-only could be
a method for configuring Active Directory to meet Silver. Microsoft even says that Kerberos is their strategy and that NTLM is not going to be “fixed”. Well, I agree with your hypothetical, but my agreement is not worth much since I’m not helping prove the antecedent.
J --- Eric |
- [AD-Assurance] RE: Cookbook items - Entropy and Kerberos, Capehart,Jeffrey D, 06/18/2013
- [AD-Assurance] RE: Cookbook items - Entropy and Kerberos, Eric Goodman, 06/18/2013
- Re: [AD-Assurance] RE: Cookbook items - Entropy and Kerberos, David Walker, 06/20/2013
- RE: [AD-Assurance] RE: Cookbook items - Entropy and Kerberos, Capehart,Jeffrey D, 06/21/2013
- RE: [AD-Assurance] RE: Cookbook items - Entropy and Kerberos, Rank, Mark, 06/21/2013
- RE: [AD-Assurance] RE: Cookbook items - Entropy and Kerberos, Capehart,Jeffrey D, 06/21/2013
- Re: [AD-Assurance] RE: Cookbook items - Entropy and Kerberos, David Walker, 06/20/2013
- [AD-Assurance] RE: Cookbook items - Entropy and Kerberos, Eric Goodman, 06/18/2013
Archive powered by MHonArc 2.6.16.