Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] RE: Do Kerberos keys use variable salt?

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

[AD-Assurance] RE: Do Kerberos keys use variable salt?


Chronological Thread 
  • From: "Capehart,Jeffrey D" <>
  • To: "" <>
  • Subject: [AD-Assurance] RE: Do Kerberos keys use variable salt?
  • Date: Thu, 23 May 2013 17:48:58 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport01.merit.edu; dkim=neutral (message not signed) header.i=none

Thanks Brian!

 

Yes, support for alternative means statements will be important for acceptance of additional risks if they can be mitigated in other ways.

 

If the information applies to Server 2008 R2, then there is a reasonable and practical case to be made for a window of time to allow servers to be upgraded to the latest version. Statements along the lines of…

-          Support is needed for the environment until legacy systems can be made compliant by 2015 per our plan

-          The majority of logins will be from Windows 7 machines which will use Kerberos V5 (secure authentication protocols?)

-          All logins performed via InCommon Federation/Shibboleth with Silver assertions will use Kerberos V5 / LDAP-S (SSL/TLS)

-          (More specific case statements that help make strong affirmations for the alternative means)

 

BTW- My usual search method starts with a key term.  Then when I find something interesting, I’ll narrow the search with a secondary term.  Of course, I also like to read several pages of search results rather than just picking the top few that show in the browser window.  Occasionally you’ll get some deeper insight into a topic based on something only peripherally related to it.

 

Jeff

 

From: [mailto:] On Behalf Of Brian Arkills
Sent: Thursday, May 23, 2013 1:22 PM
To:
Subject: [AD-Assurance] RE: Do Kerberos keys use variable salt?

 

You dig up  the most interesting documents, Jeff. :)

 

RODCs have only a subset of all accounts & passwords. And additionally, as you've noted RODCs issue tokens with a different version number than RWDCs (read-write DCs or what most folks just call DCs). That version number is only relevant because there is also another additional capability, namely account revocation checking at the session level. In other words, with vanilla Kerberos, once you have a TGT, you can get as many TGS tickets when you want, even if the underlying account is no longer valid. Microsoft has added additional checking such that prior to issuing a TGS, it checks to make sure that the TGT is still valid to be used to issue a TGS. If your RODC has been compromised, you can revoke its version number, which means that any token issued by that RODC can no longer be used to get a TGS. See 3.3.5.5.1 of that document for the revocation checking stuff. This is also covered in a cursory manner in section 5.1.3 (or at http://msdn.microsoft.com/en-us/library/dd973899.aspx which is the same content as your link, but not in PDF format).

 

One thing this does bring to attention is that the account revocation checking features here are something we might reference in an alternative means write-ups. Those features are relevant whether you are using a RODC or a RWDC. I believe KILE is WS2012 DCs only though ... but I could be wrong about that.

 

From: [] On Behalf Of Capehart,Jeffrey D
Sent: Thursday, May 23, 2013 7:55 AM
To:
Subject: [AD-Assurance] Do Kerberos keys use variable salt?

 

I was reading a Microsoft document about MS-KILE which is the Kerberos V5 protocol extensions that Microsoft has added.  These may only apply to newer (Server 2012) versions of Kerberos, but it was interesting to note the variable salting.

 

If I read this correctly, the only way to get a variably salted hash is to use an Approved Algorithm.  I guess that doesn’t help us much.

 

Would Read-Only Domain Controllers change anything with respect to the 4.2.3.4 criteria for stored authentication secrets, in case of compromise of the KDC?

 

3.1.1.2 Cryptographic Material

Kerberos V5 establishes a secret key that is shared by a principal and the KDC and a session key that forms the basis for privacy or integrity in the communication channel between client and server. When KILE creates an AES128 key, the password MUST be converted from a Unicode (UTF16) string to a UTF8 string ([UNICODE], chapter 3.9). KILE concatenates the following information to use as the key salt for principals:

§ User accounts: < DNS of the realm, converted to upper case> | <user name>

§ Computer accounts: < DNS name of the realm, converted to upper case > | "host" | < computer name, converted to lower case with trailing "$" stripped off > | "." | < DNS name of the realm, converted to lower case >

 

The [MS-KILE] Kerberos Protocol Extensions
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-KILE%5D.pdf

 

 

5.1.1 RODC Key Version Numbers

Because read-only domain controllers (RODCs) can be deployed in less secure locations, RODCs have different key version numbers (section 3.1.5.8) to ensure they are using a different key than the domain's DCs. This protects the domain if an RODC is compromised.

 

 

Jeff

 

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu

 




Archive powered by MHonArc 2.6.16.

Top of Page