Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192


Secure signaling in CUCM provides authentication and authorization of communicating
devices of Cisco IP Phones and CUCM and authentication of the signaling messages
exchanged between them. It can also provide encryption of the signaling messages.
Secure Signaling 437
Secure signaling is supported for SCCP and SIP phones. Only type B phones support
encrypted signaling; type A phones are limited to authenticated signaling messages.
Figure 16-17 illustrates how secure signaling is implemented in CUCM when two Cisco IP
Phones on the same cluster call each other.
Figure 16-17 Secure Signaling Overview
TLS is used to protect signaling messages by two-way certificate-based device authentication
and Secure Hash Algorithm 1 (SHA-1) Hashed Message Authentication Code (HMAC)
for packet authentication, and Advanced Encryption Standard (AES) for packet encryption.
To ensure the authenticity of encrypted packets in CUCM, packet encryption is supported
only if it is combined with packet authentication.
NOTE It is a general rule in cryptography to always complement packet encryption
with packet authentication. If encryption is used without authentication, the receiver of
an encrypted packet has no guarantee that the packet comes from the expected source. If
an attacker does not know the key that is to be used for the encryption, the attacker might
not be able to send valid data but could send arbitrary data to keep the receiver busy
decrypting the packets. Because decryption performed at the receiver can cause considerable
processing overhead, an attacker could launch a DoS attack just by flooding a system
with packets that the receiver will decrypt. In some situations, the attacker could
even inject incorrect data into the application. This is possible when the sent data does
not have any special format but when any bit patterns are considered to be valid data and
are accepted by the receiver, such as encrypted digitized voice samples. The receiver can
detect invalid data, such as in the transfer of an encrypted Microsoft Word file. In this
case, after decrypting the received arbitrary data (or a valid file that has been encrypted
with an incorrect key), the receiver would not recognize the file as a valid Word
document.
438 Chapter 16: Implementing Security in CUCM
Certificate Exchange in TLS
Figure 16-18 illustrates the certificate exchange that occurs at the beginning of a TLS
session.
Figure 16-18 Certificate Exchange in TLS
Phone Hello
The CUCM server and the IP Phone first exchange certificates by using the following
messages:
1. The IP Phone and the CUCM server negotiate the cryptographic algorithms in the IP
Phone Hello and CUCM Hello messages.
2. The server sends its self-signed certificate to the IP Phone.
3. The server requests a certificate from the IP Phone.
4. The IP Phone sends its certificate to the server.
At this point, both the IP Phone and the server validate the certificates they just received
over the network:
• The IP Phone simply looks up the certificate of the server in its local certificate store.
The received certificate must be found locally because it must have been sent in the
CTL. If it is not included in the CTL, the session is dropped. If it is found, the server's
public key is extracted from the certificate.
• The server looks up the IP Phone in the local device database to see whether this IP
Phone is known and authorized to connect via TLS. Then the certificate of the IP Phone
is validated by using the locally available CAPF public key from the CAPF certificate.
If the certificate is valid, the public key of the IP Phone is extracted from the IP Phone
certificate.
Server-to-Phone Authentication
The next stage of the TLS "handshake," as shown in Figure 16-19, is when the IP Phone
authenticates the server.
Secure Signaling 439
Figure 16-19 Server-to-Phone Authentication
Phone Hello
Here's a simplified version of the authentication steps shown in the figure:
1. The IP Phone generates a random challenge string and sends it to the server. This is a
request for the server to sign the message with the server's private RSA key.
2. The server signs the message with its private RSA key and returns the result (response)
to the IP Phone.
3. The IP Phone verifies the signature by using the server's public key.
Phone-to-Server Authentication
After the server has authenticated to the IP Phone, the IP Phone needs to authenticate to the
server, as shown in Figure 16-20.
Figure 16-20 Phone-to-Server Authentication
Phone Hello
440 Chapter 16: Implementing Security in CUCM
Here's a simplified version of the authentication steps shown in the figure:
1. The server generates a random challenge string and sends it to the IP Phone. This is a
request for the IP Phone to sign the message with the private RSA key of the IP Phone.
2. The IP Phone signs the message with its private RSA key and returns the result
(response) to the server.
3. The server verifies the signature with the public key of the IP Phone.
NOTE In the certificate of the IP Phone, the public key of the IP Phone is tied to the IP
Phone's identity. Because CUCM identifies an IP Phone by MAC address and not by IP
address or name, the phone's MAC address is used as the identifier in the certificate of
the IP Phone.
TLS Session Key Exchange
Figure 16-21 shows the session key exchange that occurs after the bidirectional
authentication.
Figure 16-21 TLS Session Key Exchange
Phone Hello
Cisco Unified Communications Manager Hello
Cisco Unified Communications Manager Certificate
Certificate Request
Phone Certificate
Challengel
Responsel
Challenge2
Response2
Key Exchange
Session key exchange involves these steps:
1. The IP Phone generates session keys for SHA-1 HMAC packet authentication and AES
packet encryption.
2. The IP Phone encrypts the message by using the server's public RSA key and sends the
keys to the server.
3. The server decrypts the message and thus also knows which keys to use to protect the
TLS packets.
Secure Media Transmission Between Cisco IP Phones 441
Secure Signaling Using TLS
The IP Phone and the server can now exchange SCCP or SIP signaling messages in a secure
way by using TLS packet authentication and encryption, as shown in Figure 16-22.
Figure 16-22 Authenticated Signaling Using TLS
SHA-1
The authenticated and encrypted TLS session ensures the integrity and authenticity of each
signaling message that is exchanged between the two devices.
NOTE TLS encrypts SCCP or SIP signaling on Layers 5 through 7. The headers on
Layers 2, 3, and 4 are not encrypted. This allows routers between the phone and CUCM
to route the signaling packets without being involved in the encryption process.