brkcrt-2202

© 2008, Cisco Systems, Inc. All rights reserved.14370_04_2008_c1.scr

1

© 2008 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKCRT-220214370_04_2008_c1 2

CCVP Prep:Cryptography in Cisco Unified Communications

BRKCRT-2202


2

© 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 3BRKCRT-220214370_04_2008_c1

What Is Covered by This Session?

Impossible to cover all topics about voice security in a two hour session

Session helps to prepare for current CCVP exam questions that relate to Cisco Unified Communications Manager security

Intended for CCVP candidates lacking security experience

Cisco Unified Communications Manager knowledge is expected


Agenda

Threats to Cisco Unified Communications

Introduction to Cryptography

Cisco Unified Communications Manager Security

Summary

Q & A


3


Threats to Cisco Unified Communications


Examples of Threats Targeting the IP Telephony System

Loss of Privacy Loss of Integrity

Impersonation Denial of Service

Customer Bank

Deposit$1000

Deposit$100

I am Bob,send me

phone calls.I am the PSTN,send me calls.

Loss of Dial Tone

Confidential Information


4



Symmetric vs. Asymmetric Encryption


Symmetric Encryption

Same (“shared”) key encrypts and decrypts

Key must be kept secret (sender and receiver)

Fast

Algorithms: DES, 3DES, AES, RC4, SEAL, Blowfish, etc.

Decrypt

Encryption andDecryption Key

Encryption andDecryption Key

Encrypt$1000 $!@#IQ $1000


5


Symmetric Encryption (Cont.)

Key ManagementDifferent key for each pair of devices

Keys should be changed frequently (hours to weeks)

Same key must be known by both parties

UsageBulk Data Encryption (e-mail, IPsec packets, sRTP, HTTPS, TLS)

Algorithm Example—AESPublicly announced by NIST in 2000

Much faster and more efficient than DES/3DES

Used to encrypt signaling (TLS) and media (sRTP)


Asymmetric Encryption

Based on key pairs: data encrypted by one key can only be decrypted by other key

Each entity owns its pair of keys

Only one key (decryption key) must be kept secret

Slow

Algorithm: RSA

DecryptEncrypt$1000 %3f7&4 $1000

EncryptionKey

DecryptionKey


6


Asymmetric Encryption (Cont.)

Key ManagementDifferent key pair for each entity

Keys can be used for longer periods (months to years)

One key must remain secret (“private key”), the other key must be known by other entities (“public key”)

UsageLow Volume Data (symmetric keys)

Algorithm Example—RSADeveloped in 1977, public domain since patent expired in 2000


Two Ways to Use Asymmetric Encryption

ConfidentialitySender encrypts data with public key of the receiverAny sender can generate encrypted messageSenders need to know public key of receiverOnly receiver can decrypt encrypted dataOnly receiver knows its corresponding private key

Authenticity and IntegritySender encrypts data with its own private keyOnly sender can generate encrypted (signed) messageOnly sender knows its private keyAll receivers can decrypt encrypted (signed) messageAll receivers need to know corresponding public key of sender


7



Hash-Based Message Authentication Codes (HMAC)


Hash Functions

One-way functions

Generate fixed-length output (“hash”, “digest” or “fingerprint”) from arbitrary input data

Impossible to recover hashed data from digest

Collisions (multiple inputs result in same hash output) possible

Fast

Algorithms: MD5, SHA-1

HashFunction

e883aa0b24c09...

Message~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Data of Arbitrary Length

Fixed-Length Hash


8


No Integrity Provided by Pure Hashing

Only the algorithm has to be known to create a valid hash—algorithms are well known.

Attacker changing the data can easily create a new hash.

Receiver cannot detect the manipulation.

For security, a secret element has to be added to the computation.

HashingAlgorithm

Data

e8F0s31a...

ConfirmOrder

ConfirmOrder

HashingAlgorithm

e8F0s31a...Hash Digest

e8F0s31a...Same Hash

Digest?


Hash-Based Message Authentication Code or “Keyed Hash”

Secret key added to provide authenticity and integrity:

Sender creates hash value from input data plus locally known key

Sender transmits data plus hash

Receiver creates hash from received data plus locally known key

Locally created hash must match received one

Symmetric Key NatureDifferent key for each pair of devices

Keys should be changed frequently (hours to weeks)

Same key must be known by both parties

Used for bulk data (IPsec packets, HTTPS, TLS, sRTP)

HashingAlgorithm

Data

bff6f12a0…

ConfirmOrder

ConfirmOrder

HashingAlgorithm

bff6f12a0…HMAC

(AuthenticatedFingerprint)

bff6f12a0…HMAC

Verified

Secret Key

Secret Key


9



Digital Signatures


Digital Signatures

Provide authenticity, integrity and non-repudiation

Based on asymmetric cryptographic methodsSender’s private key used as signature-generating key

Sender’s public key used as signature-verification key

Slower than HMACNot used for bulk or real-time traffic

Used for device authentication and exchange of symmetric keys


10


Digital Signatures (Cont.)

RSAEncrypt

Purchase Order$100,000

Private Key of Signer

Untrusted NetworkSHA-1 Hash

RSADecrypt SHA-1 Hash

49eD0e3A7c44...Same Hash Digest?

Public Key of Signer

e10d6200aCe...

49eD0e3A7c44...



Signature



Public Key Infrastructure (PKI)


11


Key Distribution Issues

Symmetric Keys used by Symmetric Encryption and HMAC

Frequent key exchange between peers is needed

Confidentiality and authenticity are required for key exchange

Out-of-band exchange does not scale

Public Keys used by Asymmetric Encryption and Digital Signatures

Public keys need to be distributed to all devices

Authenticity and integrity are required for key exchange

Out-of-band verification or exchange do not scale


Symmetric Key Distribution Protected byAsymmetric Encryption

Symmetric key is generated by one peerKey is encrypted with the public key of the receiver and sent over the networkOnly the receiver can decrypt the message by using its private keyAllows secure automated key distribution of symmetric keysRelies on knowledge of public keys of all possible peers

A RSARSA

Public Key of User B

Private Key of User B

B

AES Key AES Key


12


Public Key Distribution in Asymmetric Cryptography

All entities have to know public keys of all other entities.

If automated key exchange is used, authenticity and integrity must be provided to avoid man-in-the-middle attacks

Out-of-band verification does not scale

PKI can be used to solve scalability issues A

Public Key of User A

Public Key of User B

B


PKI as a Trusted Third-Party Protocol

Does not eliminate the need for authenticity and integrity of public keys (out-of-band verification)

Solves scalability issuesUses a hierarchical model by adding a trusted introducer

Authenticity and integrity (out-of-band verification) only required between trusted introducer and each entity

Authenticity and integrity between entities are then guaranteed by trusted introducer (no out-of-band verification required)

Trusted introducer will then guarantee authenticity and integrity of public keys of other entities by use of certificates, signed by the introducer


13


PKI—Generating Key Pairs

Every entity, including the trusted introducer, needs to generate its own public and private key pair

Private Key of Trusted Introducer

Public Key of Trusted Introducer

A C


Private Key of User A

Public Key of User C

Private Key of User C

Trusted Introducer


PKI—Distribution of the Public Keyof the Trusted Introducer

Each entity obtains the public key of the trusted introducer andverifies its authenticity and integrity (out-of-band)



A C







Trusted Introducer


14


PKI—Requesting Signed Certificates

Each entity submits its public key to the trusted introducer andrequests a certificate





A C





Trusted Introducer

Trusted Introducer




Trusted Introducer

PKI—Signing Certificates

The trusted introducer verifies the received public key (out-of-band) and creates a certificate signed with the trusted introducer’s private key

Trusted Introducer


APublic Key of User A

RSA

Content

Signing Key

Sign



Public Key of User A Signed by the

Trusted Introducer


15


PKI—Providing Entities with Their Certificates

The trusted introducer sends signed certificates to the entities



A C





Trusted Introducer

Trusted Introducer



Trusted Introducer


Trusted Introducer



Trusted Introducer


Trusted Introducer


PKI—Exchange of Public Keys Between Entities Using Their Signed Certificates

Entities can now exchange their public keys by means of their signed certificates

Signature of a received certificate is verified using the public key of the trusted introducer. This ensures the authenticity and integrity of the peer’s public key

A CPublic Key of Trusted Introducer






Untrusted Network


16


PKI Entities

Sometimes entities issue self-signed certificates:CA, as the root of a PKI

Entities that are not part of a PKI (not associated with a CA) but use PKI-enabled applications

Require out-of-band verification

Self-signed Certificates

Digital form (X.509v3) including the identity of a PKI user, its public key, and a signature (created by the CA)

Certificates

Devices, users, or applications that want to safely distribute their public keys

PKI Users

The trusted introducer signing certificates of PKI entities (PKI users)

CA (Certificate Authority)

FunctionTerm


X.509v3 Certificates

2C086C7FE0B6E90DA396AB…CA SignatureExtension(s) (v3)

756ECE0C9ADC7140...Subject Public Key Information

C = US O = Cisco CN = CCMCluster001Subject X.500 Name

Start = 04/01/04

Expire = 04/01/09Validity Period

C = US O = Cisco CN = CAIssuer X.500 Name

RSA with SHA-1Signature Algorithm Identifier for CA

12457801Certificate Serial Number

Version 3Certificate Format Version


17



PKI Example: SSL in the Internet


Internet-CA

Public Key of Web Server

Internet Web Server Certificate

Used for sensitive web applications

The web server has a private and public key

The web server has a certificate, usually issued by a public Internet-CA

Internet-CA

Web Server


Private Key of Internet-CA

Private Key of Web Server


18


Internet Web Browser: Embedded Internet-CA Certificates

Web browser applications have Internet-CA certificates already embedded (100+)Eliminates the need to download and verify the Internet-CA’s certificate


Web Browser Web Server

Internet-CA


Internet-CA


Internet-CA

Public Key of Internet-CA

Obtaining Authentic Public Key of Web Server

The server passes its certificate to the client at connection startup

The client verifies the certificate using the embedded certificate of the Internet-CA that has issued the certificate of the web server

The client extracts the public key of the web server from the certificate


Private Key of Web ServerPublic Key of

Web Server

Internet

Verify Signature


19


Web ServerWeb Browser

Web Server Authentication

The client sends challenge with random data to the web server

The web server uses its private key to sign the data and sends it back to the client

The client verifies the returned data using the public key of the web server previously retrieved from the certificate

If returned data matches the sent data, the web server has the correct private key, and therefore it is authentic



InternetRSA

RSARj@as94iDg...

Rj@as94iDg...

p2CksD1f3r...

Challenge

Response

SignRandom String



Exchange of Symmetric Session Keys

The client generates symmetric session keys for encryption and HMAC algorithms to provide session protection

The client encrypts the keys using the public key of the web server and sends them to the web server

The web server (only) can decrypt the session keys using its private key


InternetRSA

RSAke4P6d23Le...


Session Keys

Session Keys

Generate Session Keys


20



Internet

Session Encryption

Packets between web server and client can now be authenticated (using HMAC, such as keyed SHA-1) and encrypted (using symmetric encryption algorithms such as AES)

AES

AESSs199le4...

Session Keys

Data from Browser

Session Keys

AESData from Server

AESData from Server

dV46ax7...

Data from Browser



PKI Topologies Used in Cisco Unified Communications


21


PKI Topologies in Cisco Unified Communications Manager Deployments

Cisco Unified Communication Manager services certificates are self-signed: CCM, TFTP and Certificate Authority Proxy Function (CAPF)

Manufacturing Installed Certificates (MICs) on current Cisco Unified models are signed by Cisco manufacturing CA

Locally Significant Certificates (LSCs) on 7940, 7960 and current Cisco IP phone models are signed by CAPF or by an external CA

Secure SRST Certificate signed by external CA


CAPF

Public Key of CAPF

TFTP

Public Key of TFTP

CCM2

Public Key of CCM2

CCM1

Public Key of CCM1

Self-Signed Certificates

Each CallManager service has a self-signed certificate

The TFTP service also has self-signed certificates

If the CAPF is used (needed for LSC), it also has a self-signed certificate

All of them act as their own PKI root

Private Key of CCM1

Public Key of CCM1

CCM1

Private Key of CCM2

Public Key of CCM2

Private Key of TFTP

Public Key of TFTP

Private Key of CAPF

Public Key of CAPF

TFTP

CCM2CAPF


22


Cisco CA

Public Key of Cisco CA

Private Keyof Cisco CA

Public Keyof Cisco CA

Manufacturing Installed Certificates (MIC)

Cisco IP phone models with MICs have a public and a private key pair and MIC for the phone installedThe certificate of the IP phone is signed by the Cisco manufacturing CACisco manufacturing CA is the PKI root for all MICs

Private Key of Phone

Public Key of Phone

Public Keyof Cisco CA

Cisco CA

Issue Certificate During Production

Cisco CA

Public Key of Phone


Locally Significant Certificates (LSC)

LSCs can be used on phones with MICs or on Cisco Unified IP Phone 7940 and 7960 models (SCCP only)They use LSCs issued either by the CAPF or by an external CAThe CAPF or external CA is the root for all LSCsCisco Unified Communications Manager 5.0 and 6.0 do not support an external CA

CAPF

CCM1

Enroll

CAPF Actingas a CA

Enroll

Enterprise CA

CAPF

CCM1

Enroll

CAPF Actingas a Proxy


23


CAPF

Public Key of 7940

Cisco CA

Public Key of 7941

TFTP

Public Key of TFTP

CCM1

Public Key of CCM1

Multiple PKI Roots in Cisco Unified Communications Manager Deployments

No single root but multiple independent PKI topologies

All need to be known and trusted (out-of-band verification)

Cisco Certificate Trust List (CTL) allows verification of roots

Private Key of CCM1

Public Key of CCM1

CCM1Private Key

of TFTP

Public Key of TFTP

TFTP

7941Cisco CA CAPF CAMIC 7940LSC



Cisco Certificate Trust List (CTL)


24


Cisco CTL Client

Cisco CA

Public Key of Cisco

CTL Client

CAPF

Public Key of CAPF

TFTP

Public Key of TFTP

Cisco CA

Public Key of Cisco

CTL Client

CTL Client Signs CTL

Obtains certificates of all certificate-issuing instances (PKI roots)Creates a list (CTL) containing all obtained certificates and signs the listCisco CTL client keys physically stored on a security token

Private Key of Cisco

CTL Client

Public Key of Cisco

CTL Client

CCM1 Signed List of Certificate IssuersCisco CTL

Client

TFTP

CAPF

CCM1

Public Key of CCM1

TFTP

Public Key of TFTP

CCM1

Public Key of CCM1

CAPF

Public Key of CAPF


Cisco CTL Client

Cisco CA

Public Key of Cisco

CTL Client

Cisco CA

Public Key of Phone

TFTP

Public Key of TFTP

CCM1

Public Key of CCM1

TFTP

CTL Download

The CTL is sent to the IP phones over TFTP at bootThe CTL contains all entities that issue certificatesThe IP phone now knows which issuers are trustedSimilar to Internet browser embedded Internet-CA certificates

Private Key of Phone

Public Key of Phone


25


Cisco CTL Client Application

Cisco CTL client software is used to create or update the CTL

The CTL is signed by Cisco CTL client using the private key from one of the administrator security tokens, which are all signed by the Cisco CA

The CTL file must be updated only if Cisco Unified Communications Manager services or security tokens change

The CTL also acts as an authorization list specifying which certificates belong to which function (such as Cisco Unified Communications Manager and TFTP) Security Token


Cisco CTL Client

Cisco CA

Public Key of Cisco

CTL Client

TFTP

Public Key of TFTP

CCM1

Public Key of CCM1

Cisco CTL Client

Cisco CA

Public Key of Cisco

CTL Client

CCM2

Public Key of CCM2

TFTP

Public Key of TFTP

CCM1

Public Key of CCM1

CTL Verification on the IP Phone

Every time the IP phone receives a new CTL, it is verifiedNew CTL must be signed by one of the authorized security tokens (listed in the IP phone’s current CTL file)If no CTL file is present in phone, new CTL is not verified (initial deployment or after erasing the CTL from the IP phone)

Existing CTL on the Phone

New CTLover TFTP


26


IP Phone Usage of the CTL

Encrypted Signaling (CallManager Service Certificate)SCCP or SIP over TLSCertificate-based two-way authentication between IP phone and Cisco Unified Communications ManagerIP phone verifies self-signed Cisco Unified Communications Manager certificate against CTL

LSC Enrollment (CAPF Certificate)Protected by TLSCertificate-based authentication of CAPF to IP phoneIP phone verifies self-signed CAPF certificate against CTL

Signed IP Phone Configuration Files (TFTP Server Certificate)TFTP file is signed by private key of TFTP serverIP phone needs to know authentic public key of TFTP server

Signed CTL File (CTL Client Certificate)CTL file is signed with private key of a security tokenCorresponding public key must be known in current CTL



Signed Phone Loads


27


Signed Phone Loads

Authenticated phone images (signed phone loads) introduced with Cisco CallManager Release 3.3(3)

Image signed by Cisco manufacturing (using a private key)Current image verifies signature and phone model information of new image before accepting it (using the corresponding public key embedded in the verification code of the current image)Prevents falsification of phone image

Public Key of Cisco

CTL

TFTP Server

Binary Executable

File

Cisco IP Phone Image Signature

Image.bin.sgn

TFTP

Image.bin.sgnConfig1.xml.sgnConfig2.xml.sgnConfig3.xml.sgn



Signed and Encrypted Configuration Files


28


TFTP

Public Key of TFTP

CTL XML Configuration

File

Signature of TFTP Server

Config2.xml.sgn

TFTP


Signed IP Phone Configuration Files

Configuration files signed by the TFTP server (using its private key)

Phone verifies signature before applying configuration (using corresponding public key from CTL)

Automatically done for supported IP phones when security mode isenabled for cluster

Prevents falsification of phone configuration files

TFTP Server


Symmetric Key Used

for Encryption

and Decryption

TFTP Server

XML Configuration

File with Encrypted

Content

Config2.xml.sgn

TFTP


Encrypted IP Phone Configuration Files

Configuration file encrypted by TFTP serverPhone decrypts configuration file before applying configurationTwo ways to manage key used for encryption (symmetric)

TFTP server encrypts the symmetric key using the IP phone’s public key (for supported phones) and appends it to the configuration fileManually entered keys used for IP phones that do not support public and private keys (7905/7912 writeable web; 7940/7960 (SIP only): UI)

Prevents exposure of sensitive phone configuration settings


29



Secure Real-time Transport Protocol (sRTP)


sRTP Packet Format

V P X CC M PT Sequence NumberTime Stamp

Synchronization Source (SSRC) Identifier

Contributing Sources (CSRC) Identifier. . .

RTP Extension (Optional)

RTP Payload

sRTP MKI—0 Bytes for VoiceSHA-1 Authentication Tag (Truncated Fingerprint)

Encrypted Data Authenticated Data


30


sRTP Encryption

The sender encrypts the RTP payload using the AES algorithm and a symmetric key

The receiver uses the same key to decrypt the RTP payload

Prevents eavesdropping of conversation

Voice

74lizE122U Encrypted Voice

A B

AES

74lizE122U

Voice

74lizE122U

AESAES AES


Voice or Encrypted

Voice

sRTP Authentication

The sender hashes the RTP payload together using the SHA-1 algorithm and a symmetric keyThe hash digest is truncated to 32 bits and added to the RTP packetThe receiver uses the same key for a local computation of the truncated hash and compares it against the received onePrevents falsification of RTP packets

+SHA-1

SHA-1

s197i

32-bit Truncated Hashes Equal?

s197iVoice or

Encrypted Voice

Voice or Encrypted

Voice+

SHA-1

SHA-1

s197i

A B


31


sRTP in Cisco Unified Communications

Intra-cluster sRTP is supported byCisco IP phones using SCCP (since Cisco Unified CallManager 4.0)Cisco IP phones using SIP (since Cisco Unified Communications Manager 5.0)MGCP gateways (since Cisco Unified CallManager 4.0)H.323 gateways (since Cisco Unified Communications Manager 5.0)

Inter-cluster sRTP is supported since Cisco Unified Communications Manager 5.0sRTP session keys (symmetric keys used for truncated HMAC and AES) are generated by

Cisco IP phones (SIP) Cisco Unified Communications Manager

Symmetric keys are exchanged in signaling messagesSecure signaling is required for key protectionAuthenticated and encrypted signaling is mandatory for Cisco IP phones (SCCP and SIP) when using sRTPMGCP, H.323, Cisco Unified Communications Manager intra- and inter-cluster signaling are NOT secured by defaultIPsec should be used in these cases to protect keys in signaling messages



Secure Signaling


32


Certificate Exchange in TLS

TLS hellos are used to negotiate attributes of the TLS session (one or two-way certificate exchange, encryption and HMAC algorithms, key lengths, etc.)Certificates are exchangedCertificates are then validated

Phone Hello

CallManager Hello

CallManager Certificate

Certificate Request

Phone Certificate


Server-to-Phone Authentication

The IP phone sends a challenge to the server containing random data to be signed by the server

The server signs the random data with its private key and returns the signed data to the IP phone

The IP phone verifies the signature using the public key of the server

Prevents impersonation of server

Phone Hello

CallManager Hello


Certificate Request

Phone Certificate

Challenge1

Response1


33


Phone-to-Server Authentication

The server sends a challenge to the IP phone containing random data to be signed by the IP phone

The IP phone signs the random data with its private key and returns the signed data to the server

The server verifies the signature using the public key of the IP phone

Prevents impersonation of IP phone

Phone Hello

CallManager Hello


Certificate Request

Phone Certificate

Challenge1

Response1

Challenge2

Response2


TLS SHA-1 and AES Session Key Exchange

The IP phone generates session keys for SHA-1 and AES, encrypts them using the public key of the server and sends the encrypted keys to the serverThe server decrypts the keysIP phone and server now share secret keys

Phone Hello

CallManager Hello


Certificate Request

Phone Certificate

Challenge1

Response1

Challenge2

Response2

Key Exchange


34


SHA-1AES

Secure Signaling Using TLS

Symmetric keys shared by IP phone and server are used to protectsignaling message (SCCP or SIP) using authenticated and encrypted TLS packetsPrevents falsification and eavesdropping of signaling messages

TLS

SCCP or SIP

SHA-1AES



Secure Conferencing


35


Secure Conferencing Overview

Cisco Unified Communications Manager 6.0 introduces secure conferencing support

Secure conference bridge configured in Cisco IOS software

Registers with Cisco Unified Communications Manager using SCCP over TLS

TLS authentication includes two-way certificate exchange:Cisco Unified Communications Manager certificate(s) have to be known by secure conference bridge (to be able to compare received certificate)

Certificate of CA that issued certificate to secure conference bridge has to be known in Cisco Unified Communications Manager systems (to be able to verify signature of received certificate)

Manually added during configuration time

Supported Cisco Unified IP phones:7940 and 7960: SCCP only, authenticated conference only

7906, 7911, 7931: SCCP only

794[125], 796[125], 797[015]


Secure Conferencing Configuration Procedure

1. Obtain a certificate for the secure conference media resource atthe Cisco IOS router

2. Configure a secure conference media resource in Cisco IOS software and associate it with the previously obtained certificate

3. Export Cisco Unified Communications Manager certificate(s)4. Add downloaded Cisco Unified Communications Manager

certificate(s) to Cisco IOS router5. Export certificate of the CA that issued the certificate to the secure

conference media resource6. Add downloaded CA certificate(s) to Cisco Unified

Communications Manager server(s)7. Add and configure the secure conference bridge in Cisco Unified

Communications Manager8. Optional: Configure a minimum security level for Meet-Me

conferences if desired (default is nonsecure)


36



SIP Digest Authentication


SIP Digest Authentication

No TLS support for third-party SIP phones

No TLS support for Cisco IP phones 7905, 7940 and 7960 when using SIP

SIP digest authentication can be used with these devices (and on SIP trunks) for signaling protection

Provides authentication only using HMAC

Based on a client-server model (server challenges client)

Cisco Unified Communications Manager supports both functions on SIP trunks (send challenges and respond to challenges)

Cisco Unified Communications Manager only supports server function to IP phones (sends challenges only)

If used with Cisco IP phones, HMAC key is downloaded in TFTP configuration file

Use encrypted configuration files for key protection in TFTP files

Prevents falsification of SIP signaling messages


37



IPSec


IPsec

Network layer based securityApplicable for any sensitive traffic that is not protected by applications themselvesEspecially important when cryptographic keys are sent in clear text—like sRTP keys in signaling messages

Server-to-server intra-cluster signalingInter-cluster trunk signalingSignaling to H.323 gatewaysSignaling MGCP gateways

Supported by Cisco Unified Communications Manager 5ESP only, no AHPre-shared keys or X.509 certificates

Recommended to be used on network infrastructure devicesPrevents impersonation of IPsec peersPrevents falsification and eavesdropping of protected IP packets


38


IPSec Scenarios in Cisco Unified Communications

H.323 GatewaysRTP

sRTP

TLS

TLS

TLS

H.323

Cisco Unified Communications Manager

IP Phone

IP Phone

IP Phone IP Phone

MGCP GatewaysRTP

MGCP




TLS

Recommendation: Use closest-possible network infrastructure device instead of Cisco Unified Communications Manager

Inter- or intra-cluster



Secure Survivable Remote Site Telephony (SRST)


39


Secure SRST

Allows Cisco IP phones to use TLS for signaling and sRTP for media when in SRST mode

Prevents impersonation of SRST gateway and IP phones

Prevents falsification and eavesdropping of signaling and RTP packets

Secure SRST

IP Phone

IP Phone

TLS

TLS

sRTP


PKI Topology with Secure SRST

Phones have certificates (MIC and/or LSC) and CTL

The SRST gateway obtains a certificate from any (external) CA

SRSTIP Phone

CA

LSCSRST Certificate

MIC

CAPF CCMTFTPCisco CA

Certificate Trust List (CTL)


40


Trust Requirements with Secure SRST

IP phones must be able to verify Secure SRST gateway certificate(issued by any external CA)

Secure SRST gateway certificate is not verified by its signature (using public key of issueing CA)

Secure SRST gateway certificate is obtained by Cisco Unified Communications Manager at configuration time (using the credential service at the gateway)

Manual verification is requested at configuration time

Cisco Unified Communications Manager adds received (and manually verified) certificate to phone configuration files

Secure SRST gateway must be able to verify IP phone certificatesIP phone certificates are signed by either CAPF (LSC) or Cisco Manufacturing CA (MIC)

CAPF and Cisco Manufacturing CA certificates are added manually to Secure SRST gateway


Secure SRST—Certificate Import: Cisco Unified Communications Manager

Imports certificate from the Secure SRST gateway over the networkManual certificate fingerprint verification required


41


Secure SRST—Certificate Import: Secure SRST Gateway

srst(config)#crypto pki trustpoint CAPFsrst(ca-trustpoint)# enrollment terminalsrst(ca-trustpoint)# revocation-check nonesrst(ca-trustpoint)#exitsrst(config)#crypto pki authenticate CAPF

Enter the base 64 encoded CA certificate.End with a blank line or the word "quit" on a line by itself(paste the certificate)

:quitCertificate has the following attributes:Fingerprint MD5: F7E150EA 5E6E3AC5 615FC696 66415C9FFingerprint SHA1: 1BE2B503 DC72EE28 0C0F6B18 798236D8 D3B18BE6% Do you accept this certificate? [yes/no]: yTrustpoint CA certificate accepted.% Certificate successfully imported

Certificates of entities that signed phone certificates (CAPF, Cisco Manufacturing CAs) are added manually


Certificate Usage in Secure SRST

SRST

MICsigned byCisco CA

LSC signed by

CAPF

IP Phone

TFTP

SRST Certificate

Configuration File

SRST Certificate

SRST Certificate

LSC signed by CAPFCisco CACertificates

Manually Entered

CAPF Certificate

SRST Certificate

Obtained from GatewayCredentials Service during Configuration

TLS Two-wayCertificate Exchange

MIC signed by Cisco CA

or

IP phone verifies received SRST gateway certificate against the one in its configuration file

SRST gateway checks received IP phone certificate’s signature using public key of issuer (Cisco CA or CAPF)

Compare Certificates

Check Certificate’sSignature

and added to IP Phone Configuration Files


42


Summary


Summary

Threats to Cisco Unified CommunicationsLoss of privacyLoss of integrityImpersonationDenial of service

CryptographySymmetric and asymmetric encryptionHMACsDigital signaturesPKI

Cisco Unified Communications Manager security featuresPKI-enabled, certificate-based solution; CTL in IP phonesSigned phone loads, signed and encrypted configuration filessRTP and secure signalingSIP digest authenticationIPsecSecure SRST


43


Q and A


Recommended Reading

Continue your Cisco Live learning experience with further reading from Cisco Press

Check the Recommended Reading flyer for suggested books

Available Onsite at the Cisco Company Store


44


Complete Your Online Session Evaluation

Give us your feedback and you could win fabulous prizes. Winners announced daily.

Receive 20 Passport points for each session evaluation you complete.

Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center.

Don’t forget to activate your Cisco Live virtual account for access to all session material on-demand and return for our live virtual event in October 2008.

Go to the Collaboration Zone in World of Solutions or visit www.cisco-live.com.


brkcrt-2202

Documents