Authentication and Integrity

Cisco CallManager allows authentication of calls. When you are configuring devices for authenticated calls, two services are provided:

• Device authentication for the IP phone and the server Achieved by using device certificates and digital signatures
• Authentication and integrity of signaling messages Achieved by using TLS Secure Hash Algorithm 1 (SHA-1) Hash-based Message Authentication Code (HMAC) (with symmetric keys)

Certificate Exchange in TLS

At the beginning of a TLS session, the Cisco CallManager server and the IP phone exchange certificates using the messages shown in Figure 26-11.

Figure 26-11. Certificate Exchange Process

The certificate exchange process occurs as follows:

1. The IP phone and the Cisco CallManager server negotiate the cryptographic algorithms in the IP phone Hello and Cisco CallManager 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 public key of the server is extracted from the certificate.
• The server looks up the IP phone in the local device database to see if this IP phone is known and authorized to connect via TLS. Then, the certificate of the IP phone is validated using the locally available CAPF public key (from the CAPF certificate), and if 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 is authentication of the server by the IP phone. A simplified version of the authentication steps is shown in Figure 26-12.

Figure 26-12. Server-to-Phone Authentication

The CallManager-to-Phone authentication occurs as follows:

1. The IP phone generates a random challenge string and sends it to the server, requesting that the server sign it with the private RSA key of the server.
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 using the public key of the server.

Phone-to-Server Authentication

After the server has authenticated to the IP phone, the IP phone needs to authenticate to the server. A simplified version of the authentication steps is shown in Figure 26-13.

Figure 26-13. Phone-to-Server Authentication

The Phone-to-CallManager authentication occurs as follows:

1. The server generates a random challenge string and sends it to the IP phone, requesting that the IP phone sign it 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 identity of the IP phone. Because Cisco CallManager identifies an IP phone by MAC address and not by IP address or name, the MAC address of the phone is used as the identifier in the certificate of the IP phone.

 

TLS SHA-1 Session Key Exchange

After the bidirectional authentication, a SHA-1 session key is exchanged using these steps:

1.	The IP phone generates a session key for SHA-1 hashing.
2.	The IP phone encrypts it using the public RSA key of the server and sends it to the server.
3.	The server decrypts the message and thus also knows which key to use for SHA-1 hashing of the TLS packets.

The IP phone and the server can now exchange signaling messages over authenticated TLS packets, ensuring the integrity and authenticity of each signaling message exchanged between the two.

Encryption