Strict KDC Validation
This blog post talks about Strict KDC Validation, and how it works in great details. Please be advised that this blog requires good understanding of Kerberos and how it works.
I was reading a lot about this new mechanism of authentication called Strict KDC Authentication, and I was wondering, why it is important, and what is the vulnerability that it mitigates.
I didn’t find a clear answer at the beginning, then I start digging deeper, until I got the whole idea. To understand what Strict KDC Validation is really about, we shall talk briefly about PKI, Kerberos, and smart cards all together.
While smart card authentication has definite advantage over passwords, it should be deployed with a realistic understanding of the actual protections it provides. Installations should take advantage of the latest configuration and hardening options available.
Administrators should continue to audit and work to eliminate outdated protocols like NTLM from their networks, and privileged users should always exercise caution when authentication to low-integrity workstations, even with a smart card. Let us go deep and learn more about Strict KDC Validation, and how it help us solve a key trust issue.
Brief introduction about Kerberos
To start talking about Strict KDC Validation, we shall spare sometime talking about the basics of Kerberos, and how it work
Kerberos is network authentication protocol that uses Key Server approach in cryptography. The problem with symmetric cryptography is that each party should maintain his key, and all other keys for the parties it needs to communicate with. And there is also the challenge for exchanging those symmetric keys through a secure channel, which is a problem by itself.
Kerberos still uses symmetric cryptography, but in the same time it solves all the problems rising from using it. The basic idea is simple. Suppose that everybody setup a shared secure key with the key server. For example, John setup a key Kj that is known only to him and to the key server. Bob setup a key Kb, that is only known to him and to the key server. Other entities setup keys in the same fashion.
Now suppose that John wants to communicate with Bob. He has no keys he can use to communicate with Bob, but he can communicate securely with the key server. The key server in return can communicate securely with Bob. John can simply send all the traffic to the key server and let the key server acts as a delivery guy. But this is a bit hard on the key server because it will act as man in the middle, proxying all traffic. A better solution is to let the key server setup a key K(J,B) that is shared by Bob and John.
This is the simple idea behind Kerberos. The beauty of this complex protocol is that the key server doesn’t need to maintain any states about the key it issues, and the all parties can communicate using mutual authentication without further communication with the key server. The key server is called (KDC) or Key Distribution Center. Of course, the initial trust between any party and the KDC is created when the machine is joined to the domain, get a secret, and that secret will be used for the secure channel.
Smart cards are a first-class credential type
Smart card authentication offers many important advantages over passwords. it provides two-factor authentication as a user must both have possession of the physical card and know the PIN code to use it. A lost card can be deactivated and, until such time, is useless without the PIN. With proper policy, smart cards can prevent concurrent account usage. Unlike a password, a smart card can guarantee that authentication secrets are cryptographically strong and cannot be written down, lost, shared, “phished” or re-used in an insecure system. More generally, asymmetric cryptography can help eliminate the need for attackable, locally stored authenticators and server-side password databases.
The most miss-understandable points when deploying smart cards
- Deploying smart card only-logins will guarantee Kerberos is used for Integrated Windows Authentication, eliminating the risks associated with the older NTLM protocol.
- Private keys cannot be exported, so it is safe (or at least, safer) to authenticate to a potentially compromised workstation with a smart card, because no long-lived credential material exists that can be used by an attacker after the card is removed.
Both previous statements are NOT TRUE.
Smart card only-logins can use NTLM
The myth that the use of smart cards prevents the use of NTLM, probably arises from the fact that NTLM protocol is password-based, and smart card users do not enter (or may not have) a standard password. You can review my previous blog post about how smart card logon works.
Although it is true that the initial Active Directory domain logon with a smart card is guaranteed to use Kerberos, and that asymmetric credentials cannot be used for NTLM, it is not true that users who authenticate with a smart card will never use NTLM to access network resources.
To explain my point, let us state that when a user logged on to a domain joined machine (regardless using a password or smart card), the user will get a Ticket Granting Ticket (TGT) and a PAC (Privilege Attribute Certificate) that includes all information needed to generate the user access token (like group SIDs that the user is member of, etc.) .
Most password-based authentication protocols in Windows are not based directly on the password, but on a hash of the password. There are two versions of this hash, the LM and the NTLM OWF (one-way function). Active Directory stores a copy of these hashes and uses it to verify standard Kerberos and NTLM authentication traffic.
Smart card only users do not have a password, but they still have an OWF. Instead of the hash being based on a password, it is simply a randomly generated 128-bit value. When users try to logon using smart cards and talk to KDC using Kerberos, and to support NTLM authentication, KDC will send the OWF to clients in the privilege attribute certificate (PAC).
After the initial logon, both a Kerberos TGT and the OWF are available to the client, and the behavior of Windows Integrated Authentication is no different for smart card-originated logons than for password-originated logons.
Password and smart card-based logons are subject to identical risks from the use of the NTLM protocol with regard to credential forwarding and lack of server authentication. The only advantage offered by smart cards is that the random OWF generated for a smart card only login will be significantly more resistant to dictionary or rainbow table attacks against NTLM protocol messages, especially NTLMv1, than will a user-selected password.
If NTLM is allowed on the network, the OWF sent as part of the Kerberos PAC is a long-term password equivalent. It can be used to perform network authentication with NTLM, as the user, without requiring the presence of the smart card. If the user is not configured for smart card only logon, the OWF is also a password equivalent for Kerberos initial authentication.
Even if NTLM is completely disabled on the network and a user is configured for smart card only logon, a user’s TGT is valid for 10 hours and renewable up to 7 days by default. It is not safe for a highly privileged user to logon to a low integrity workstation, even with a smart card, unless the account used has no rights for Network Logon elsewhere in the forest.
Certificate trust in public key Kerberos implementations
Mutual authentication is a critical security service provided by the Kerberos protocol. A client and the KDC can each verify the identity of the other, as can a client and a service. In standard Kerberos, this is accomplished by using shared symmetric keys. KDC has a unique, long term, shared key for every principal in the realm, and KDC can allow clients and services to be mutually authenticated by creating a new, ephemeral key, and encrypting a copy of it with each of their keys.
Public key Kerberos leaves most of the basic mechanisms unchanged but modifies the initial authentication step between the client and KDC to use public key cryptography, typically an X.509 certificate-based PKI.
While this change may seem trivial on the surface, it introduces considerable complexity which is “Since KDC and smart card user don’t share a secret (user password), then how can the KDC trust the smart card user and vice versa?”
Step 1: How KDC trusts the client’s smart card certificate?
Well, the KDC will somehow do something like querying its trusted root certificate store. In the case of Microsoft Active Directory, the KDC will query this location in Active Directory “CN=NTAuthCertificates, CN=Public Key Services, CN=Services, CN=Configuration, DC=name, DC=com”
The certificate from the smart card client should be issued from one of the issuing CA servers listed in that location. After that, the KDC will do Certificate mapping to map a certificate to a user account and will perform couple of certificate health checking like (CRL checks).
Step 2: How smart card users will trust a KDC?
Since there is no secret shared between both entities (smart card client and the KDC), how can the smart card user trust it is connecting to a valid trusted KDC? In SSL/TLS implementation, the acceptance policy is that the certificate presented to the client should contain (Server Authentication) in the EKU and the name in the certificate subject (or in the SAN) should match the DNS name of the host the client was attempting to reach.
This approach will not work in this case, because the client may not know the name of a valid KDC. A Windows server or workstation joined to a domain has to perform a discovery process to identify the nearest and most available KDC. This process uses insecure protocols, such as local NetBIOS broadcasts or DNS SRV record lookups. Because the name is not discovered securely, matching the name to a presented certificate cannot provide meaningful assurance in the general case.
If name verification is not generally used, what verification mechanism does the protocol specify, and what have clients implemented? RFC 4556 specifies that the [Digital Signature Key] Usage and [id-pkinit-PKPKdc] Enhanced Key Usage should be present in certificates issued to a KDC. Microsoft doesn’t implement the [id-pkinit-PKPKdc] Enhanced Key Usage, so how can clients verify a Windows Server KDC without the [id-pkinit-PKPKdc]?
Windows client behavior was not documented for some time. Beginning in 2008 (with Windows Vista SP1 and Windows Server 2008) a new group policy option appeared “Require Strict KDC Validation”.
In the description for this policy setting, it states that “If you disable or do not configure this policy setting, the Kerberos client requires only that the KDC certificate contain the Server Authentication purpose object identifier in the EKU extensions.”
Is this enough to distinguish a KDC from other systems in the domain? Microsoft cautions that it is not. When a domain-joined client computer performs a PKINIT with a server, the client needs to be able to verify that the other computer has a valid certificate and that it is also a Domain Controller. The [Domain Controller] and the [Domain Controller Authentication] certificate template add the domain controller’s fully qualified domain name (FQDN) to the certificate.
However, with this information, a client is not able to truly verify whether the machine is a valid domain controller, because a client does not have an authoritative list of all valid domain controllers for a domain. Therefore, the [Kerberos Authentication] certificate template adds the domain name instead of the domain controller’s FQDN to the certificate.
If clients only verify the [Server Authentication] EKU, what other systems have certificates that meet the verification criteria for a Windows KDC certificate? The [Web Server] template supplied by Microsoft Active Directory certificate services contains this EKU. There may be many dozens of such certificates in a large enterprise, and a lot of internal web applications can contain security weakness. More troubling than web servers, the [Computer] certificate template also contains the [Server Authentication] EKU.
Is this true? Can any certificate with a [Server Authentication] EKU be presented as a KDC certificate and be accepted by a client? The answer is surprisingly YES!!!.
Strict KDC Validation comes to solve this
Strict KDC Validation is a more restrictive set of criteria that must be met by a KDC for successful authentication. This functionality is controlled by a Group Policy setting called “Require strict KDC validation”, which was added in Windows Vista. A system with this policy enabled will validate certificate-based AS-REP messages from domain controllers by ensuring that all the following are met:
- The domain controller has the private key for the certificate provided.
- For domain-joined systems, the certification authority (CA) that issued the KDC’s certificate is in the AD NTAuth store.
- For non-domain-joined systems, the root CA of the KDC certificate is either in the Third-Party Root Certification Authorities or in the Smart Card Trusted Roots containers of the Windows client’s certificate store (accessible from the Certificates MMC snap-in).
- The KDC certificate has the KDC Authentication entry in the Extended Key Usage (EKU) X.509 extension.
- The KDC certificate’s SubjectAltName (SAN) X.509 extension contains the domain’s DNS (FQDN) and NetBIOS names.
- The KDC certificate’s DNSName field of the SubjectAltName (SAN) X.509 extension matches the domain’s DNS name (FQDN).
Plan a head
I hope I could explain why there is something called Strict KDC Validation, and why you might want to use it in your environment. It is important that you enroll all your domain controllers with the correct KDC certificate that adheres to the above conditions. This can be done by creating a valid domain controller certificate using the new certificate template called (Kerberos Authentication), that was included in Windows Server 2008. Certificates created from this template will have KDC EKU and SAN certificate extensions. This new certificate template is a good replacement from the old Domain Controller and Domain Controller Authentication certificate templates.
You can deploy the Kerberos Authentication certificate template to your domain controllers, by using auto-enrollment, and by specifying the (Domain Controller Authentication) and (Domain Controller) certificate templates, as superseded templates in the (Kerberos Authentication) certificate template. As this blog post is not addressing the deployment aspect, here is a blog post that goes through the deployment part.
- Enabling Strict KDC Validation in Windows Kerberos reference article.
- Discover how smart cards work.