With Akhil Behl
Welcome to the Cisco Support Community Ask the Expert conversation. Learn and ask questions of Cisco expert Akhil Behl about the importance of security at end-point level, which can otherwise be easily exploited by an insider or an attacker to either leverage the UC services or attack the UC network. This is your opportunity to discuss security aspects of: Cisco Unified IP Phones (wired and wireless), Cisco IP Communicator, Cisco Unified Personal Communicator, and Cisco Jabber which includes endpoint and associated application / infrastructure level security.
This discussion is a continuation of the Facebook Forum.
Akhil Behl is a senior network consultant with Cisco Advanced Services, focusing on Cisco collaboration and security architectures. He leads collaboration and security projects worldwideas well as the Collaborative Professional Services portfolio for the commercial segment. Previously at Cisco, he spent 10 years in various roles at Linksys and the Cisco Technical Assistance Center. He holds CCIE (Voice and Security), PMP, ITIL, VMware VCP, and MCP certifications. He has published several research papers in international journals including IEEE Xplore. He has been a speaker at prominent industry forums such as Interop, Enterprise Connect, Cloud Connect, Cloud Summit, Cisco SecCon, IT Expo, and Cisco Networkers. He is the author of title ‘Securing Cisco IP Telephony Networks’ by Cisco Press.
Remember to use the rating system to let Akhil know if you have received an adequate response.
Akhil might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Collaboration, Voice and Video sub-community forum shortly after the event. This event lasts through Nov 30, 2012. Visit this forum often to view responses to your questions and the questions of other community members.
i am trying to setup an ipsec connection between my CUCM Cluster (1 x Pub; 1 x Sub) and my H323 Gateway in my Lab. But the ipsec tunnel is only working between the Subscriber and the Gateway. The Connection form the Publisher is not working. On the Gateway i can see 2 isakmp sa (1 for Pub and 1 for Sub) but an ipsec sa is only build for Sub. On the callmanagers the IPSec configuration of both servers are same, besides the ip adresses.
My SW Version on CUCM is 184.108.40.20600-9 and on the Gateway i am running IOS Ver 15.2(3)T1.
How are you?
When you mention that only ISA SA is being formed, what is the state of the same? Is it in QM_IDLE or MM_NO_STATE?
Also, please check the phase 2 policies for the Pub crypto map as it should be a mirror of what has been defined on Pub. I cannot say for sure however, it may be due to a mismatch in destination peer ip or incorrect ACL.
I had a query on Cisco IP phone.Does Cisco IP phone when shipped from Cisco carries any version firmware load in it.
In case,if the firmware version is same on IP phone and TFTP server [Call Manager] and phone is powered ON for first time, does any TFTP request goes to call manager for downloading the firmware.
Yes, the Cisco Unified IP Phone comes with a firmware installed on it. The firmware version may vary depending on when the phone was manufactured and what was the current firmware / last firmware release at that time.
About your other query, if the firmware version on the phone is same as that on CUCM, it will skip the firmware update process and will proceed with configuration file, phone button template, ring list etc. download. Essentially, whenever a phone is restarted, rebooted, or plugged for the first time in switch port, it will query TFTP server defined in option 150 however, will skip firmware if the version on CUCM and on the phone NVRAM is the same.
Thanks a lot of reply.
I am not able to understand the last line in second paragraph that is will skip firmware if the version on CUCM and on the phone NVRAM is the same.The phone comes with SCCP or SIP by default when shipped from Cisco.
Lastly do you have any documeneted procedure to upload the firmware in IP phone in case if Call Manager is not available for Call Manager 4.x. I do have procedure for call Manager 5 and above using TFTPd32 but not sure if it is same.
By that sentence I meant that, if the firmware version on the IP Phone and CUCM TFTP is the same, IP Phone skips the update process however, will try and download anything else that might have changed for example the configuration of the phone. A very widely seen instance is when the configuration say device pool, CSS or pattition is updated and the phone is reset or apply config option is selected in CUCM. During this time, the IP Phone only downloads the new configuration file however, skips firmware, ring list, and other downloadable items.
As for your other question, CUCM 4.x is EOL, EOS. Not sure why you would still wish to have that in a production/lab environment. In CUCM 4.x firmware can be updated by installing the right patch for CUCM which contains the phone firmware/locale etc.
An example for endpoint package/patch is
http://www.cisco.com/cisco/software/type.html?mdfid=280264388&flowid=5321 for CUCM 4.2(3) You can download the version for your CUCM from
Aman, as this post is about IP Phone and Soft Client security pertinent to Cisco UC solution, I'd appreciate if you can post more relevant queries geared towards UC Security. Also, if you have any queries on Cisco IP Telephony Security you can post them here or consult Cisco Press book Securing Cisco IP Telephony Networks.
How are you?
In Cisco IP Telephony, CUCM enables the encryption of voice calls (signaling and media) with the subsequent scheme:
- For signaling messages using TLS encryption with AES 128-bit encryption.
- For media transfer using SRTP AES 128-bit encryption.
For more information on Cisco UC PKI and other UC security specifics you can refer to Securing Cisco IP Telephony Networks http://www.amazon.com/gp/product/1587142953
I have a CUCM cluster in Mixed Mode with 6000 IP Phones, but the next certificates are going to expire tomorrow!!!, what I have to do?
Hi NOC SOC SSP,
Well, for all CUCM certificates they come with a default life time and for CAPF certificates this is 5 years.
If you have a mixed mode cluster and your certificates are about to expire, the next action depends on whether they are self-signed or signed by external CA.
In case of self-signed certificates, you can regenerate the certificates by loginin to OS Administration > Certificate Management and Regenerating the specific certificate.
In case of external CA, have a new CSR generated for each type of certificate you wish to renew and have it signed by the CA. Upload the root CA certificate as trust and signed request as the entity e.g. for tomcat, when you generate a CSR for OS Administration > Certificate Management get the CSR signed by external CA. Upload CA root as tomcat-trust followed by signed CSR as tomcat.
You can refer to Securing Cisco IP Telephony Networks http://www.amazon.com/gp/product/1587142953 for detailed instructions on how to get certificates signed and uploaded to CUCM, CUC, CUPS, and so on.
If you are using CAPF for end-points and have enabled auth or encryption, you should then run the CTL client again and reset the phones by device pool or indiviually to ensure the phones download the new CTL file with renewed certificates. For tomcat, please restart the tomcat service from CLI - utils service restart Cisco Tomcat
Note: CTL Client operation followed by endpoint reset should be done during non-peak hours / maintenance schedule as it is service impacting.
Ok, then if:
-I have a 4 appliance cluster
-I have 6000 encrypted phones (Mixed Mode)
-I have 600 encryped conference bridges
-I´m affected by CSCth84019
-I do not have the tokens in order to edit CTL file
-Certificates self-signed going to expire soon
what I have to do?
what will happen if I do nothing?
Hi NOC SOC SSP,
For the bug you mentioned, the only workaround is to have TAC look into the cluster
Also, if you are using all self-signed certificates, as I mentioned in my earlier post you can regenerate the certificates.
On the CTL client front, you will need the tokens to run the client. At least 1 token which was originally used to run CTL client to re-run the client and at this time you will opportunity to add new USB tokens in the CTL. Please contact the person in-charge to get access to original USB token(s)
In a nutshell, re-running CTL Client builds CTL file. CTL File is a list of records. These records are all the CallManager certificates for all the nodes in the Cluster , CAPF certificate from the Publisher and eTokens certificates. Phones download the CTL file to get the latest list of records (Certificates and the roles for each Certificates). Without the new certificates, the phones will fail to trust CUCM and vice-versa.
For conference bridges you need to repeat the process of CUCM certificate upload to IOS routers and vice-versa so, the new certificates are accepted by the CFB resources.
Lastly, if you do nothing, eventually, the certificates will expire and the devices will not be able to trust CUCM and same applies in other way as well i.e. CUCM will not trust devices.
You can refer to Securing Cisco IP Telephony Networks http://www.ciscopress.com/title/1587142953 for insight to PKI structure of Cisco UC, CUCM security, certificate information, and so on.
Thanks Akhil for the detailed information and book reference...it helps.
Another question I had was; Are LSC’s a preferred method of enabling local device certificates (CAPF) or MIC?
When it comes to Phone certificates for signaling and media encryption, Locally Significant Certificates (LSC) are definitely have an edge over Manufacturing Installed Certificates (MIC). This is for a few reasons:
1. LSC are generated inline with CAPF server and have a default lifetime which can be set to be more than 5 years (default lifetime) by CUCM parameters
2. LSC are more secure than MIC for aforestated reason as well as the fact that they can be revoked manually
3. While a Cisco CA assigned MIC is more or less static, LSC is generated in real time and can be applied in various forms to an endpoint viz. by null authentication, with password, authenticated by MIC etc.