In this blog post, I will be talking about how smart cards work, side by side with Kerberos, and explain in detail what strict Kerberos authentication means.
I was reading a lot about this mechanism of authentication that is called Strict Kerberos 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 get the whole idea. Be careful, this blog requires good understanding of Kerberos.
While smart cards have definite advantages over passwords, they should be deployed with a realistic understanding of the actual protections they provide. 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 authenticating to low-integrity workstations, even with a smart card. Knowing how smart cards work is so important if you really want to protect your key assets.
Kerberos in simple words
Kerberos is network authentication protocol that uses Key Server approach in cryptography. The problem with symmetric cryptography is that each party should maintain its key, and all other keys for the parties it needs to communicate with. 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 to only him and to the key server. Bob setup a key Kb that is only known to him and the key server. Other parties setup keys in exactly 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. He can simply send all the traffic to the key server, and let the key server act as a delivery guy. But this is a bit hard on the key server. 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, and the beauty of this complex protocol is that the key server doesn’t need to maintain any states about the key it issues, and all parties can communicate using mutual authentication and without further communication with the key server. The key server is called (KDC) or Key Distribution Center in Microsoft Networks. Of course the initial trust between any party and the KDC is created when the machine is joined to the domain, and got a secret, and that secret will be used for the secure channel.
How smart cards work as a first-class credential type
How smart cards work? Smart cards offer many important advantages over passwords. They provide two-factor authentication as a user must 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 attack-able, 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! We will dig deeper now and talk about how smart cards work.
Smart Card Only-Logins can use NTLM
The myth that use of smart cards prevents use of NTLM probably arises from the fact that the NTLM protocol is password-based, and smart card users do not enter (or may not have) a standard password.
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 and to learn how smart cards work, let us suppose that when a user logged on to a domain joined machine (regardless using a normal 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.) .Now let us move on.
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 being based on a password it is simply a randomly generated 128 bit value. When a user logged on using his smart card and talked to the KDC using Kerberos, to support NTLM authentication, the user’s OWF is sent to the client in the privilege attribute certificate (PAC).
After initial logon, both a Kerberos TGT and the OWF are available, 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. The KDC has a unique, long term, shared key for every principal in the realm, and the 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 actually 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?”.
How KDC trusts a smart card certificate?
Well, the KDC will somehow do something like querying its trusted root certificate store. Actually it will query this location in AD: “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 (NTAtuhCertificates). After that, KDC will do certificate mapping to map a certificate to a user account, and will perform couple of certificate health checking (like CRL checks).
How Smart Card users will trust a KDC?
Since there is no secret shared between both parties, how can the smart card user trust it is connecting to a valid trusted KDC? Knowing the answer will reveal more about how smart card works. 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 our 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 EKU. So ,how can clients verify a Windows Server KDC without the PKINIT KDC EKU?
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: “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 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 do-main 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 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 YES!!!
Strict KDC validation as a Solution
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 NTAuth store.
- For non-domain-joined systems, the root CA of the KDC’s certificate is in the Third-Party Root CA or Smart Card Trusted Roots store.
KDC’s certificate has the KDC EKU.
- KDC certificate’s DNSName field of the subjectAltName (SAN) extension matches the DNS name of the domain.
I hope this article will help you understand more how smart cards work side by side with Keberos and NTLM. If you find this article useful, please share it.