This discussion is locked

Ask the Expert:Security for Cisco Unified IP Phones (Wired, Wireless) and Soft Phones

Unanswered Question
Nov 13th, 2012

Read the bioWith 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 have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.9 (12 ratings)
rschuknecht Thu, 11/15/2012 - 06:26

Hi Akhil,

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 and on the Gateway i am running IOS Ver 15.2(3)T1.


akbehl Thu, 11/15/2012 - 07:28

Hi Robert,

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.

Akhil Behl
Solutions Architect

Author of “Securing Cisco IP Telephony Networks”

Aman Soi Fri, 11/16/2012 - 09:15

Hi Akhil,

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.



akbehl Fri, 11/16/2012 - 10:21

Hi Aman,

How're you?

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.

Akhil Behl
Solutions Architect

Author of “Securing Cisco IP Telephony Networks”

Aman Soi Sat, 11/17/2012 - 07:02

Hi Akhil,

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.



akbehl Sat, 11/17/2012 - 07:21

Hi Aman,

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 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.

Akhil Behl
Solutions Architect

Author of “Securing Cisco IP Telephony Networks”

john.ventura73 Thu, 11/22/2012 - 02:21

Hi Akhil,

What is the key strength of certificates used between endpoints and call-control (CUCM)?


akbehl Thu, 11/22/2012 - 22:22

Hi John,

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

Akhil Behl
Solutions Architect

Author of “Securing Cisco IP Telephony Networks”

soc-noc-ssp Thu, 11/22/2012 - 19:02

Hi Akhil,

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?





akbehl Thu, 11/22/2012 - 22:30


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 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.

Akhil Behl
Solutions Architect

Author of “Securing Cisco IP Telephony Networks”

soc-noc-ssp Fri, 11/23/2012 - 11:14

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?

akbehl Sat, 11/24/2012 - 01:06


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 for insight to PKI structure of Cisco UC, CUCM security, certificate information, and so on.

Akhil Behl
Solutions Architect

Author of “Securing Cisco IP Telephony Networks”

john.ventura73 Wed, 11/28/2012 - 06:52

Thanks Akhil for the detailed information and book helps.

Another question I had was; Are LSC’s a preferred method of enabling local device certificates (CAPF) or MIC?


akbehl Wed, 11/28/2012 - 20:27

Hi John,

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.

Akhil Behl
Solutions Architect

Author of “Securing Cisco IP Telephony Networks”

christoph.hable Wed, 11/28/2012 - 15:58

Hi Akhil,

just found this Ask the Expert round and fortunately it is not finished yet - one day left! 

I have many questions regarding IP Phone(& CUCM) security and hope you can answer me at least some of them:


  • Will there be any enhancements for authentication methods on wired phones? The wireless phones support rather more e.g. PEAP as authentication method. On wired phones just support EAP-FAST, EAP-TLS, and EAP-MD5
  •     PEAP was partly developed by Cisco so why not implementing it onto the wired phones? Wireless phones and video endpoints like EX60/90 support PEAP.
  • On wireless phones we can shorten the username (listed in Certificate as CN). On wired phones the username is always 24 characters long (e.g. CP-7965G-SEPAAAABBBBCCCC) - even with LSC. Nevertheless Ciscos White Papers still talks about shorter names for LSC ( Will this be implemented on the wired phones, too?
  • Can you verify with the BU the new and undocumented behaviour of the Common Name in LSC phone certificates?  In older firmwares and models (9.0.3) the name got shortened to SEP+MAC when  using LSC. But by any reason this has changed in all phone series.  I had a TAC case for this topic and received a new bug id with severity 6 / enhancement.. -> CSCua55385      This is a big issue for customers  using a Radius server which is not able to handle more than 20  characters (MS NPS..) and not every customer has an ACS or can buy it.

Certificates /PKI:

  • There are many customers which want to use their own PKI and they think "OK, CUCM has a certificate proxy function"... but honestly this is not the case and Cisco should rename the service or built-int this proxy functionality.  The CAPF is always the issuer for the LCS certs and the only certificate verification can be done with an OCSP URI.  Will there be a real certificate proxy function in the near future again?
  • Can you reinforce why CAPF should be a valid certificate issuer in a PKI environment? I have a customer with a policy that no CSR will be signed with an Issuer role since this is a possible security leak for them.
  • Any news regarding certificate provisioining for wireless phones? Till yet this need to be done manually for each wireless phone.
  • CUCM has the limit with CA signed certificates that it doesnt accept more than 2048 bit keys. Many customer have already Root CAs with RSA key size of 4096 bit. Can you confirm any Roadmap e.g. CUCM 9.5 that this support will be improved?

  • The newest CUCM Security Guide still recommends not using 2048bit LSC. Since the newer phone models (89xx, 99xx) are doing the certificate and key generation with their DSP/hardware I think we don't have this limitation anymore, do we?

      I would appreciate any kind of Roadmap for IP Phone (wired/wireless) and CUCM Security topics.




      PS: I've read your book "Securing Cisco IP Telephony Networks” - thanks for putting this out of the CIPT series since this topic needs to be explained and handled individually!

      akbehl Wed, 11/28/2012 - 21:25

      Hi Christoph,

      How are you?

      I'll try and answer your queries to the best of my knowhow. As some of these are pertinent to engineering, you'd have to pursue Cisco BU via your account team representatives in case you wish to have a bug being addressed faster or a new feature request as these are driven on case by case basis and need business justification to them.

      1. The wireless endpoints support PEAP as one of the authentication mechanisms however, with wired phones this doesn't seem to be in scope as of today.

      2. The most probable reason I can think of (and not speaking on behalf of Cisco BU) is that, EAP-TLS seems to be the way forward and as it is one of the most secure methods of 802.1x based authentication.

      3. As of today, scheme of username and password for the wired phones vs. the scheme of wireless phones differ as you pointed out and I do not see this changing going ahead. On page 21 of the whitepaper, it is mentioned that user name is hardcoded and cannot be changed. If you have any queries on this front, open a TAC case and have the TAC personnel/BU look into it.

      4. For the aforementioned bug I would defer on this to have a word with your account team and see if they can get it to a higher priority level within the BU so, it may be resolved earlier than expected. Also, as a workaround, you can have ACS 5.x in your environment. I understand that this may not be the desired solution however, there're perks for all Cisco infrastructure when it comes to compatibility, support, and ease of configuration/deployment.

      5. CAPF is a proxy for the endpoints and while it issues LSC for the endpoints, it is proxying the signed request from root CA to endpoint and vice-versa. In a nutshell CUCM validates phone’s certificate via chain validation. It needs the root CA to be in the trust store for two reasons:

      - External signed certificate for any components on CUCM is validated against the root CA before the certificate can be imported on to the system. This means in order for CAPF’s certificate to be signed by root CA, the root CA’s certificate must be first installed onto the system

      - During TLS handshake, the way CUCM uses OpenSSL for validation it needs the entire root chain to be present which in turn implies, root CA, subordinate CA, identity certificate

      6. While, the earlier point should answer this for you, the model that CUCM PKI follows is that, CAPF signs LSC on behalf of external certificates if using third party for signing the CSR. So, the flow is always like this:

      External CA Root / Subordinate CA > CAPF (LSC root) > LSC on endpoint

      It is important to realize that CAPF is root for all endpoint certificates i.e. LSC.

      I understand that different customers have different requirements however; at this point Cisco UC PKI is designed to work with CAPF as the root for LSC. I do not see this changing in near future.

      7. From what I know, the existing model of phone by phone basis for wireless phone is going to continue. However, for ease of management and to consolidate Cisco ACS/NAC infrastructure, now there's Cisco Identity Services Engine (ISE) which could cut short some of the work at backend.

      8. The support for certificates is currently limited at 2048 bits and this will continue as such at least in 9.x release. While, I cannot say for sure when in which release of CUCM with support for 4096 bit key size will be supported, there's work in progress to support the same. No set date has been confirmed by BU.

      9. While I do not have a concrete answer for you here, more often than not, the default key size is recommended here for maintaining interoperability and compatibility for all types of endpoints. Also, the key generation period can be significantly long for higher bit keys.

      Akhil Behl
      Solutions Architect

      Author of “Securing Cisco IP Telephony Networks”

      Aman Soi Thu, 11/29/2012 - 07:29

      Hi Akhil,

      On Cisco Call Manager under Device---Phones , we find Device Trusted as Green Correct Mark.What does that actual means ?



      akbehl Thu, 11/29/2012 - 08:26

      Hi Aman,

      A Trusted Device represents a Cisco device or a  third-party device that has passed Cisco security criteria for trusted  connections. This includes, but is not limited to, signaling/media  encryption, platform hardening, and assurance.

      See the following URL for more information

      Akhil Behl
      Solutions Architect

      Author of “Securing Cisco IP Telephony Networks”


      Login or Register to take actions

      This Discussion

      Posted November 13, 2012 at 2:59 PM
      Replies:19 Avg. Rating:4.85714
      Views:4204 Votes:0

      Related Content

      Discussions Leaderboard

      Rank Username Points
      1 21,026
      2 15,047
      3 10,314
      4 7,999
      5 4,856
      Rank Username Points