How CallManager Protects Against Threats

Cisco designed Cisco CallManager 4.0 with security largely in mind. A Cisco IP telephony network can now be protected by using cryptographic services. These services are used to provide the following:

  • Secure signaling For authentication of devices and authentication and encryption of signaling messages. This precaution stops all kinds of signaling attacks.
  • Secure media transfer For authentication and encryption of media streams, preventing eavesdropping on conversations.
  • Authentication of phone images To stop attacks against phone images by ensuring the integrity of the image file.
  • Authentication of phone configuration files To stop attacks against phone configuration files, again by ensuring the integrity of the file.

Secure Signaling and Media Transfer

Secure signaling in Cisco IP telephony provides authentication and authorization of communicating devices (Cisco IP Phones and Cisco CallManager) and authentication of the signaling messages exchanged between them. It can also provide encryption of the signaling messages. Securing the call signaling is mandatory if you plan to secure the media transfer as well. The reason for this precaution is that the keys used for securing the media channels are exchanged inside signaling messages.

Secure signaling is achieved by using Transport Layer Security (TLS) and is based on the Cisco IP telephony Public Key Infrastructure (PKI) solution. The secure signaling encapsulates the Skinny Client Control Protocol (SCCP, or Skinny) messages in TLS. TLS provides transport-layer protection and is similar to Secure Sockets Layer (SSL), used for secure web browsing.

Secure media transfer in Cisco IP telephony provides confidentiality by encrypting the media stream. If a hacker captures the media streams, the hacker cannot interpret them or play them back. Secure media transfer also provides integrity and authenticity so that the packets cannot be altered while in transit. If an attacker modifies, removes, or adds Real-Time Transport Protocol (RTP) packets, the receiver detects this manipulation because of the missing or incorrect authentication data. Secure media transfer requires encrypted call signaling because the media encryption keys are exchanged over signaling channels. After you encrypt the media stream, the call is considered a Secure RTP (SRTP) session.

Figure 26-1 illustrates that for secure media transfer, SRTP is used instead of the insecure RTP to exchange voice packets between IP phones. Encapsulating the Skinny protocol inside of TLS encryption ensures secure communication between the IP phone and the CallManager. SRTP is a standard-based (RFC 3711, The Secure Real-Time Transport Protocol) and an application-layer encryption that performs inside-payload encryption where the protocol headers do not change. Because the headers in RTP and SRTP are the same, an attacker who sniffs the conversation does not know whether the RTP stream has been encrypted when examining the packet header only. Only when further analyzing the sniffed packets and trying to play them back can the attacker recognize that the audio has been encrypted.

Figure 26-1. Secure Signaling and Media Transfer

 

Authentication of Phone Images

To ensure the integrity of Cisco IP Phone images that are loaded from a TFTP server, authenticated images are used. Cisco IP Phones support image authentication on all Cisco IP Phone models. With image authentication, Cisco manufacturing signs the images (using a private key) and appends the signature to the actual firmware. This signature ensures the firmware is from Cisco Systems. Most modern Cisco IP Phones already include the Cisco Systems public key to verify that the signature is accurate, as shown in Figure 26-2. In addition, this feature also allows phones to check the image device type so that incorrect images (those for other phone models) are not loaded.

Figure 26-2. Phone Image Verification

IP phone image authentication was introduced with Cisco CallManager Release 3.3(3). In this and later versions, phone images include the public key that corresponds to the private key used by Cisco manufacturing to sign phone images. In addition, the firmware accepts new images only if their signature is authentic.

IP phone image authentication does not need any additional configuration and is totally independent of the Cisco IP telephony PKI that is used for other features.

Tip

If you need to downgrade to an IP phone image that does not yet support IP phone image authentication (earlier than Cisco CallManager Release 3.3(3)), a special "breakout" image can be obtained from the Cisco Technical Assistance Center (TAC). Simply trying to load an older image does not work because the current image will accept only signed images.

 

Authentication of Phone Configuration Files

In addition to IP phone images, IP phone configuration files can be signed as well. This eliminates man-in-the-middle attacks on the Cisco IP Phone configuration files, which would attempt to direct the IP phone to an alternate (rogue) CallManager server.

Signed IP phone configuration files are implemented differently from signed images. The configuration files are signed by the Cisco TFTP server (with its private key). An IP phone loading a new configuration verifies the configuration file before applying it. The IP phone needs the public key of the TFTP server to do so. Except for the Cisco development public key, the public key of the TFTP server is different for every installation and, therefore, cannot be embedded in the firmware of the IP phone. Therefore, verification must use the Cisco IP telephony PKI. Authenticated IP phone configuration files prevent tampering with the files on the TFTP server or in transit.

Note

Because authenticated IP phone configuration files depend on the existence of a Cisco IP telephony PKI, the deployment of this feature is far more complex than signed IP phone images. On the other hand, when you enable your cluster for security, authentication of phone configuration files is automatic for all IP phones that are configured for secure operation.


PKI Topologies in Cisco IP Telephony

Part I: Cisco CallManager Fundamentals

Introduction to Cisco Unified Communications and Cisco Unified CallManager

Cisco Unified CallManager Clustering and Deployment Options

Cisco Unified CallManager Installation and Upgrades

Part II: IPT Devices and Users

Cisco IP Phones and Other User Devices

Configuring Cisco Unified CallManager to Support IP Phones

Cisco IP Telephony Users

Cisco Bulk Administration Tool

Part III: IPT Network Integration and Route Plan

Cisco Catalyst Switches

Configuring Cisco Gateways and Trunks

Cisco Unified CallManager Route Plan Basics

Cisco Unified CallManager Advanced Route Plans

Configuring Hunt Groups and Call Coverage

Implementing Telephony Call Restrictions and Control

Implementing Multiple-Site Deployments

Part IV: VoIP Features

Media Resources

Configuring User Features, Part 1

Configuring User Features, Part 2

Configuring Cisco Unified CallManager Attendant Console

Configuring Cisco IP Manager Assistant

Part V: IPT Security

Securing the Windows Operating System

Securing Cisco Unified CallManager Administration

Preventing Toll Fraud

Hardening the IP Phone

Understanding Cryptographic Fundamentals

Understanding the Public Key Infrastructure

Understanding Cisco IP Telephony Authentication and Encryption Fundamentals

Configuring Cisco IP Telephony Authentication and Encryption

Part VI: IP Video

Introducing IP Video Telephony

Configuring Cisco VT Advantage

Part VII: IPT Management

Introducing Database Tools and Cisco Unified CallManager Serviceability

Monitoring Performance

Configuring Alarms and Traces

Configuring CAR

Using Additional Management and Monitoring Tools

Part VIII: Appendix

Appendix A. Answers to Review Questions

Index



Authorized Self-Study Guide Cisco IP Telephony (CIPT)
Cisco IP Telephony (CIPT) (Authorized Self-Study) (2nd Edition)
ISBN: 158705261X
EAN: 2147483647
Year: 2004
Pages: 329

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net