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

[ciscomoderator]

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.

[christoph.hable]

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:

802.1X:

• 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 (http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6638/config_guide_c17-605524.pdf). 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.

Thanks!

Regards

Christoph

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!

[Akhil Behl]

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

http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7925g/7_0/english/administration/guide/7925cfgu.html#wp1407513 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

https://www.cisco.com/cisco/psn/bssprt/bss?searchType=bstbugidsearch&page=bstBugDetail&BugID=CSCua55385 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
akbehl@cisco.com

Author of “Securing Cisco IP Telephony Networks”
http://www.ciscopress.com/title/1587142953

[Aman Soi]

Hi Akhil,

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

regds,

aman

[Akhil Behl]

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

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/security/8_5_1/secugd/secuphne.html#wp1054438

Akhil Behl
Solutions Architect
akbehl@cisco.com

Author of “Securing Cisco IP Telephony Networks”
http://www.ciscopress.com/title/1587142953

[Aman Soi]

thanks..