OCSP support is not included in the current roadmap of SecureW2 for some key reasons. Here’s a brief overview of your options for certificate revocation:
OCSP stands for Online Certificate Standard Protocol. It’s a protocol described in RFC 6960 that can be used to request the revocation status of a digital certificate.
In OCSP, every authentication request requires the RADIUS server to do a lookup against the PKI using HTTP. The OCSP response requires several operations on the PKI side, including a private key operation on the OCSP response (create signature). This response is then sent back to the RADIUS server and requires another cryptographic operation (which is expensive in terms of server load) to verify the response (verify signature).
One solution to minimize the lookup costs is a technique called “OCSP Stapling”, in which two of the necessary requests are combined to further enhance speed. However, stapling is not supported for Wi-Fi client certificates. Furthermore, some implementations of OCSP are vulnerable to replay or man-in-the-middle attacks.
In contrast, CRL stands for Certificate Revocation List. It’s exactly what it sounds like – a list of revoked certificates populated by the issuing CA.
SecureW2 CRLs are pre-parsed for faster checks. The file is copied from our PKI at fixed intervals and requires a very simple public key decryption (verify signature) and a binary lookup of a serial id in a file. Essentially, we skip the slow parts of a CRL check by doing the heavy lifting in advance of the authentication event. Even if the file grew to a few hundred MB (which is quite a lot of serials!) it would still be quicker to use the CRL because we use another improved CRL technique called “Delta + Base CRL”.
In this setup, a copy of the CRL is stored locally on the RADIUS server for quick reference (the Base CRL) and updated regularly, often during off-peak times. The update request returns the Delta CRL, a much smaller list that only contains changes to the Base CRL since the last update, significantly reducing the load.
Although it’s often considered an upgrade, the reality is that a lot of popular browsers don’t even use OCSP: Google Chrome uses a CRL; Firefox uses a CRL (admittedly, with a soft check for OCSP if the CRL fails). Some OCSP configs are actually just using a CRL under the hood for most operations because it tends to be faster. Ultimately, the limiting factor in checking revoked certificates is typically network latency, not CPU cycles, so CRLs are shown to perform better across distributed networks.
OCSP had the potential to replace CRL, but in its current state, it is our belief that OCSP is an inferior solution for Wi-Fi security applications.
For more info about certificate management, feel free to reach out to our expert support engineers. Want your network protected by a PKI vendor that pushes the envelope on features like this? Check out our Managed PKI solution here to see how we can deploy passwordless Wi-Fi on your network with no forklift upgrades.
