MIC LSC CTL confusion

[Yan Tian]

Hi team,

I have reviewed lots of posts on this community regarding ITL, CTL, LSC, MIC, PKI. However I still have lots of confusions not cleared.

Q1: we already have MIC by default, why we still need LSC
- Reason #1, more secure ? I do not think so. MIC is signed by private key of Cisco Manufacturing CA, LSC is signed by private key of CAPF cerfiticate. I do not see big difference.
- Reason #2, LSC support encryption of signaling & media. From technology perspective, MIC can also do that. I do not see the difference as well.

Q2: How is LSC generated and downloaded to IP Phone

- Phone submits its MIC to CUCM and CUCM signs it using CAPF private key and pass back to Phones?

Q3: Why we need LSC and MIC coexist on the same Phone?

Q4: How is CTL file/CTL client/USB token related to LSC ? Can we use LSC without them ?

Thanks in advance for your help.

[Aaron Harrison · Accepted solution]

Hi

A1: Try this scenario - you are permitting access to your corporate VPN based on certificates. You can either trust the issuer of the MICs (Cisco's CA) or the LSCs (Your CAPF service on CUCM). Which is best?

Your CAPF. That way you are trusting certs that you issued, rather than trusting every certificate on every IP phone in the universe that has a Cisco badge on it. You can command phones to delete the certificates from your CAPF, and control it in other ways.  Every Cisco phone has a Cisco MIC, but that defeats the point of having a certificate. That's why many of the guides advocate password based enrollment rather than simple MIC-trusting even if that's what most of us do...

A2: You can either trust the MIC, and issue an LSC based on that (as noted above). You can also set a password on the dev in CUCM, and then you need to enter that password on the phone (more secure). Or you can use a 'null' password, ie. just dish them out freely.

A3: The MIC is built into the phone and is permanent. The LSC is your corporate cert, issued by your system to your devices. It would be the LSC you 'use' generally.

A4: 

CTL File : a list of certificates for your servers and services taht is distributed to the phones. The phones will trust only these services. This prevents your phones from being diverted to servers that are not yours (i.e. hacked).

CTL Client : this is just a software app that signs the CTL, puts the cluster in secure mode, distributes certificates around the cluster etc.

USB Token; this (as I understand it) simply contains some private keys that were generated by Cisco. These are used to sign the CTL. They basically ensure that you have a method of recovery - you use two, and as long as you don't lose both you are OK. 

Basically you need the token to use the CTL client to generate the CTL file, which is what the phones use to securely identify the cluster.

http://www.cisco.com/web/about/security/intelligence/IP_Phone_Security_WP.html

Aaron

[Yan Tian]

Hi Aaron,

Many thanks for your reply, and sorry for my delayed reply as I did spend quite some time to understand your reply and digest them.

A1: You reply cleared my confusion. In a nutshell, LSC further narrows down CUCM Cluster's trust scope from all Cisco-manufactured phones in this word to phones which are managed by a specific Cluster.

A2:  I believe the exact content of MIC will be: Phone Certificate (including Phone Public Key) + signature by Cisco Manufacture CA's private key. After MIC is signed by CAPF's private key, it is now a LSC, and the content will be: Phone Certificate (including Phone Public Key) + signature by Cisco Manufacture CA's private key + signature by CAPF's private key.

When CUCM verify the LSC, it will verify LSC 2 times against CA's public key and CAPF's public key respectively ?

A3: clear now.

A4: Phone submit MIC for signature / Phone download LSC / Phone submit LSC for authentication / Phone contact TFTP server to downloading CTL / CTL client and USB token to generate CTL file, what are the correct sequence for above events ?

Thanks in advance