I'm wondering whether anybody has run into the situation to implement something like a customized revocation mechanism for LSCs when using 802.1x?
The following is somewhat theoretical and a little bit strange, but anyway.
The scenario would be that a phone is stolen or so heavily broken that, as a result, the phone is not reachable by CUCM anymore. Means, the phone is gone but still has a valid LSC on it.
Our client now has concerns that in some clever way somebody might be able to get into that stolen or broken phone, gets out the LCS and uses it to introduce a rogue device to its 802.1x network. Because, having no revocation information available for LSCs, the 802.1x based NAC would consider that “stolen” LSC as a still valid/trusted certificate. If not manual blocked on the AAA server by means of an exemption policy and a blacklist entry. But, this is not an option for our client. He insists on having a sort of automated way to provide revocation information for LSCs to its NAC environment.
I.e., he’d ask us to find a workaround such that a given LSC can be in some sort of way be included into a CRL to be published via a CDP, maybe by means of a CA like openCA or another, non-Cisco based CA. Although we already mentioned that the recommendation would be to use a blacklist and an exemption policy on the client’s AAA server.
I know that LSCs/CAPF do not support revocation, but I'm just wondering. The client's theoretic idea would be to export all LCSs to an external database in a first step. Then, if an LSC needs to be revoked, take the LCS's information from that database and try to include it into a CRL to be built by a non-Cisco CA. Maybe utilized by using a CA product supporting indirect CRLs. Last, distribute the generated (indirect) CRL via a CDP.
I have my doubts that this can be put to work as suggested by the client but would be very interested on any though on this approach.