How Does CLO Work?

I’ll admit that I was a bit intimidated when I was first introduced to PKI/CLO (Public Key Infrastructure/Cryptographic Logon).  I knew I could put my SmartCard (commonly referred to as CAC, Common Access Card) into a computer and then I wouldn’t need to remember a complex password, but everything happening in the background seemed so complicated, I resisted learning how it worked. To add to the complexity, asymmetric encryption was pretty difficult to wrap my head around. After I went through Security+ with an excellent instructor, asymmetric encryption finally made sense and after a recent deployment where I no longer had the luxury of just letting CLO happen in the background, it was finally time to bite the bullet and tackle this beast. The main reason I was able to learn this was because of the excellent PKI support section at MCNOSC, make sure you get ahold of them and take advantage of their services.

The first question to answer is: why do we want to use CLO?  The main reason is passwords.  Passwords are a continual point of contention.  The complexity requirements and frequent changes are frustrating to users, yet passwords are frequently the “weak link in the chain”.  Of course there is also the bit of it being a requirement.  I actually really like CLO.  I’ve had some conversations with my Marines that went something along the lines of “I want to live in a world where I don’t have to deal with these stupid passwords”.  By replacing passwords as the authentication method, the security of your network is increased.  This is specifically increased because by using CLO, we are using two of the three forms of authentication (something you know, something you have, something you are) with a physical card and a PIN for the card.

The important players in the CLO scene are the end workstations, Domain Controllers (DCs), Repeaters, and Responders. The end workstations need to have smart card readers. The smart card readers allow the user to present credentials to authenticate to the domain. When logging into the domain, there is actually a 2-way authentication. The end user proves they are who they say they are to the domain (using the private key stored on their smart card), and the domain controller proves it is an authentic domain controller to the end workstation (using the private key stored on the domain controller).  It looks like this:

This 2-way authentication needs a mediator, someone who is trusted by the end workstations and the domain controllers. Enter the Repeater and Responder. When credentials are presented, which take the form of digital certificates, they need to be validated and their issuing source needs to be validated as well.  It looks something like this:

After your request is passed to your Repeater/Responder, what happens? Depending on your implementation, you may have a Repeater, or a Repeater and a Responder. I’ll do my best to talk you through what the roles of each of these devices are, and you can decide for yourself what is right for your environment. If you are wondering what I do, I’ve always employed a Repeater and Responder. The Responder is a server that will download the Certificate Revocation List (CRL). This is a list of certificates that have been revoked, ie. certificates that are considered bad. To save on bandwidth, you can download a compact CRL (a version of the CRL with superfluous information removed). After the CRL is downloaded, your Responder will create a database that essentially contains a list of pre-computed answers to validation questions. The database contains an invalid status for certificates that are on the CRL and assumes those certificates not on the CRL are valid certificates. This process is very resource intensive when it is in progress (you will see your virtual CPU pegged for a good amount of time while the database is being computed), so I would recommend assigning this device additional resources (RAM and CPU).  After the database is computed, it is sent to the Repeater.  The Repeater (assuming you setup your middleware client this way) will be the first to receive your request.  The answer to your request will likely be part of the database that was sent to the Repeater from the Responder.  The Repeater will then reply to the requesting device with a status for the certificate.  It would look like this:

Now that we’ve got an idea of what the whole process looks like, let’s dig a bit deeper into the specifics of how this works and some of the design and planning considerations that will help you with your CLO employment.  Previously, we talked about the 2-way authentication and how you need digital certificates on your smart cards and your DCs. Your smart cards already have your personal certificates on there, so thankfully this does not require anything additional. The DCs on your network, however, will not have digital certificates installed. You will need to fill out the proper paperwork and then download and install your new certificate. There are walk-thru documents available to take you through all of this. The pre-cursor to doing this is to create your domain and to name your DCs. Please keep in mind any DC can process login requests, so EVERY DC for your domain will need a valid certificate. This information will need to be used as part of your certificate request documentation.  Additionally, for the motivated self-starters among us, you CANNOT create your own self-signed certificate (even though technically Windows will allow you to do this) because a self-signed certificate cannot be validated.

Now that we’ve got certificates for the end user and the DCs, we need software that will be able to validate certificates that are presented. This software is called middleware. An example of this would be tumbleweed.  Middleware will need to be installed on all devices that need to validate certificates, and because we are doing 2-way authentication, we will need middleware on the end user workstations, the authentication servers (DCs), and the other member servers that are part of your domain.  The middleware is configured with the information for your Repeater/Responder and when your computer receives the digital certificate for the DC two requests for certificate validation will be passed to your Repeater/Responder.  The settings you choose in your middleware configuration file, will determine the order in which your device attempts to use validation sources (Repeaters/Responders).  The first request will be to validate the certificate for your DC, and the second request will be to validate the certificate of whoever signed your DC’s certificate. If you flip your vantage point and pretend you are the DC, when a user’s certificate is passed, the DC will need to validate the user certificate and whoever signed the user certificate.