Upload
letuong
View
263
Download
6
Embed Size (px)
Citation preview
Cisco UC Manager Security
Ryan Ratliff, Technical Leader - Services
BRKUCC-2501
Abstract
• The offering of security features in Cisco Unified Communications Manager has greatly increased allowing for an effective defense throughout the system. This session will bring attendees up to date on the latest UC security updates and provide an understanding of how to protect against toll fraud and other threats. Discussion topics will include UCM 10, 10.5, and 11 security updates including the enhancements to CTL, CAPF, UC Manager PKI, and also cover the fundamentals of intrusion protection and encrypted signaling and media.
• UC Security updates
• Understand the Cisco UC strength of security in layers
• Hardened appliance model & Toll Fraud Protection
• Certificates & PKI
• Certificate Trust List (CTL) & Initial Trust List (ITL)
• Cisco Product Security
• Q & A
Agenda
What’s new with UC Security
Release 9.X Security Updates
• Securing Extension Mobility Cross Cluster: allows for secure phone (encrypted config, signaling, media) in EMCC deployments
• SIP URI Dialing: Intercluster Lookup Service (ILS) traffic secured with TLS (9.0)
• Enhanced Locations CAC: intercluster Location Bandwidth Manager (LBM) communications secured with TLS (9.1)
• SIP Profile: Expanded RTP/sRTP port ranges, 2048 to 65535 (9.1)
Focus on securing video and intercluster features
Release 10.0 Security Updates
• CTL deployment options
• Return of CAPF external CA support
• New server X.509v3 certificate options
• New SAML Single Sign On (SSO) Admin GUI support
• Lock icon display flexibility
• ITL recovery
Focus on flexibility in securing CUCM
Releases 10.5.1 & 10.5.2 Security Updates
• Multi-server SAN certificates
• FIPS 140-2 Compliance
• End User SAML SSO Support
• Information Assurance enhancements
• Kernel, JDK, Tomcat, openssl updates
• SIP Crypto Updates
Continued focus on security improvements
Release 11.0 Security Updates
• Information Assurance Updates
• Common Criteria requirements for Unified CM
• Elliptical Curve Cryptography support for certificates
• HTTPS for TFTP downloads – new Extended ITL
• RSA v3 Update
• Clusterwide deletion of certificates
• Tokenless CTL Recovery
• NTLMv2 Support in IM&P
Why Single Sign-On?
• Security & Compliance: align with the broader enterprise authentication strategy
• Simplify user provisioning and deprovisioning
• Integral to a common identity architecture - providing users with a single identity across cloud and on-prem services
• Mobile devices drive need for externally reachable identity and access management systems
• Potential for stronger client authentication
Highly recommended session for a deeper dive:
BRKUCC-2444 Directories Services and Single Sign-On for Collaboration
Single Sign On (SSO) 10.0 update
• 10.0 introduces SAML SSO for Administrative GUIs in 10.0
• Product support: Unified CM, IM&P, Unity Connection, Prime Collaboration, Cisco WebEx Meeting Server
• Tested and verified IdP’s
• Microsoft ADFS 2
• OpenAM 9 & 10
• Ping Federate
• Customers that have deployed with (pre 10.0) OpenAM SSO with Agent Flow must migrate existing SSO integration to SAML SSO
• OpenAM SSO with Agent Flow removed in 11.0
SAML 2.0 + OAuth
OpenAM
Edge SSO Solution UCM 10.5(2) + Jabber 10.6SAML Solution Network Elements
Collaboration Services
Unified CM
Unified CM IM&P
Unity Connection
Jabber 10.6
Identity
Infrastructure
EXPWY-C
UCM
Internet
EXPWY-E
Internal Network External NetworkDMZ
LDAP
IdP
IdP
Proxy
Proxy
Service
Provider
Directory
SAML
Request
SAML
Assertion
Assertion
Consumer
Service
Browser
Domain
Name
System
DNS
Identity
Provider
Unified CM Information Assurance Updates
10.5(2)
• All Web Applications but OS Admin and DRS
• Local Users Only
11.0
• LDAP and SSO Authenticated Users
• OS Admin and DRS Now Supported (Local Users)
1 of 3
• Successful Logins Only for SSO
Unified CM Information Assurance Updates
• OS Admin CLI updated to include show login commands
• Includes OS admin and DRS HTTPS login attempts, plus ssh and console
show logins successful
• To display the details of previous successful logins
show logins unsuccessful
• To display the details of previous unsuccessful logins
2 of 3
Unified CM Information Assurance Updates
• New feature that can automatically disable inactive end user accounts
• This feature only applies to non-ldap sync’d end users, displayed in UCM as local users
• Feature is activated via Cisco Database Layer Monitor Advanced Service Parameter: “Disable User Accounts unused for (days)”
3 of 3
• The default value of zero days, disables the feature
• Successful end user authentication (pin or password) resets the inactivity timer
• Admin has the ability to enable/disable accounts from the end user pages only when this feature is enabled
Unified CM SIP Crypto Updates
• Prior to version 10.5.2, SIP trunks and SIP Lines only supported TLS 1.0
TLS_RSA_WITH_AES_128_CBC_SHA (AES_128_CBC_SHA)
• Version 10.5.2 introduces TLS 1.2 support with the following cipher suites
ECDHE_RSA_WITH_AES_256_GCM_SHA384
ECDHE_RSA_WITH_AES_128_GCM_SHA256
• Highest strength cipher will be offered or negotiated by default
• New ciphers are available by default on upgrade to UCM 10.5.2
New TLS1.2 GCM Ciphers
1 of 4
Unified CM SIP Crypto Updates
New TLS Elliptical Curve Cryptography (EC) Ciphers
• Meets Common Criteria Recognition Arrangement (CCRA) Requirements
• Version 11.0 introduces support for the following EC ciphers
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• New CallManager-ECDSA certificate used for TLS connections using EC ciphers
• Existing CallManager certificate used for TLS connections using RSA ciphers
2 of 4
Unified CM SIP Crypto Updates
• Prior to version 10.5.2, SIP trunks and SIP Lines only supported SHA1 based media encryption ciphers
• Version 10.5.2 introduces support for new GCM (Galois/Counter Mode)ciphers
AEAD_AES_256_GCM (32 byte key)
AEAD_AES_128_GCM (16 byte key)
• New ciphers are available by default on upgrade to UCM 10.5.2
• Highest strength cipher will be offered or negotiated by default
• SHA1 based SRTP cipher compatibility remains for non-SIP devices
New AES256 SRTP Ciphers
3 of 4
Unified CM SIP Crypto Updates4 of 4
Enterprise Parameter Updates for updated TLS, SRTP Ciphers
RSA Key Updates
• RSA keys sign COP files
• New RSA v3 key in use
• Supported Natively in 10.x, 11.0
• Older RSA keys removed in 11.0
• Older versions must install ciscocm.version3-keys.cop.sgn to add support.
• RSA v3 COP files have k3 in the filename e.g.
ciscocm.free_common_space_v1.2.k3.cop.sgn
• Version specific COP files may not have k3 in the filename e.g.
cmterm-devicepack10.5.2.12014-1.cop.sgn
HTTPS TFTP Downloads
• TFTP now listens on 3 TCP ports for incoming requests
• 6970 (HTTP)
• 6971 (HTTPS – serves CallManager certificate chain and keys)
• 6972 (HTTPS – serves Tomcat certificate chain and keys)
• Mutual Authentication via ECDSA LSC on the endpoint
• All files available over both HTTP and HTTPS
AES algorithm with 128 or 256 bit key size
EDCHE algorithm used with the 256 bit EC to derive and exchange the
server’s and client’s ephemeral public key and curve IDs are
exchanged (Diffle-Hellman parameters) to derive the same secret
keys on party A and B involved in the transaction
Symmetric Key exchange
symmetric key of 128 or 256 bits generated at server and client
side
Plain text (Data to be encrypted)
AES algorithm encrypts/decrypts the data (a fixed 128) bit block using the symmetric key
Cipher text (Encrypted data )
Data Encryption
RSA signs the data using 1024 or 2048 bit
public key for integrity check
TLS operation (AES 128 or 256GCM based ciphers)
TLS & SRTP Crypto UpdatesMinimum Software Requirements
Minimum SW Release Availability
Unified CM 10.5.2 Now
78XX 10.3(1) Now
88XX 10.3(1) Now
Jabber Desktop 10.6 Now
Jabber Mobile 10.6 Now
DX650, DX70, DX80 10.2(4) Q2 CY15
EX, SX, MX, C-series CE 8.0 ? Q2 CY15
Secure Network, Secure Endpoints, Secure Call
Control
Infrastructure Security MeasuresSegregation
• Virtual LANs (VLANs) separates voice and data traffic
• VLAN Access Control Lists (VACLs) limits traffic between devices on the voice VLAN
• QoS Packet Marking ensures UC traffic receives appropriate priority over other traffic
Layer 2
• DHCP Snooping creates binding table
• Dynamic ARP Inspection examines ARP & GARP for violations
• Port Security limits the number of MAC addresses allowed per port
• 802.1x limits network access to authentic devices on assigned VLANs
•Multi-Domain Authentication (MDA) binds two devices to assigned VLANs
•MAC Authentication Bypass (MAB) provides a measure of control over devices which don’t support802.1x
Layer 3
• IP Source Guard examines physical port, VLAN, IP, & MAC for inconsistencies
IP Phone Security Features• Cryptographically assured device identity
• Manufacture Installed Certificate(MIC)
• Locally Significant Certificates (LSC)
• Signed firmware images
• Signed & encrypted configuration files
• Mutually authenticated & encrypted signaling & media
• Embedded 802.1x Supplicant
• Positive disconnect for handset & speakerphone
• Positive off-hook indicator for speakerphone
• Disable or block access to voice VLAN for downstream port
• Disable web interface
• Disable “settings” button
• Disable SSH access
• FIPS mode (select models)
• Gratuitous ARP rejection
Unified Communications Manager SecurityEncrypted Signaling & Media
• SIP & SCCP Phones
• SIP Video Endpoints
• MGCP, H.323, & SIP Trunks
• TAPI & JTAPI Applications
• Meet-me, ad-hoc, & barge Conferences
• Extension Mobility Cross-Cluster
• Intercluster Lookup Service (ILS)
• Location Bandwidth Manager (LBM)
Secure Interfaces & Protocols
• Web, CLI, CTI, & LDAP
• HTTPS, TLS, SRTP, SSH, SFTP, SLDAP, & IPSec
Unified Communications Manager Security
• Disallow trivial passwords
• Require minimum length
• Prevent reuse with configurable depth
• Lockout on failed attempts with configurable depth, time span, & duration
• Lockout on inactivity with configurable time span
• Expire after configurable time span
• Expiry warning with configurable time span
User Credential Policies
Control frequency of credential modifications with configurable time span
Force credential modification on next attempt
Prevent credential modification by user
Lockout by administrator
Configurable session timeouts
SAML Single-Sign-On (SSO)
Balancing Risk
Low
Easy or Default
Medium
Moderate and Reasonable
High
Advanced or Not Integrated
Hardened Platform IP VPN Phone UC-Aware Firewall (Inspection)
SELinux – Host Based Intrusion
ProtectionSecure Directory Integration (SLDAP) Phone Proxy
iptables - Integrated Host Firewall Encrypted Configuration Ipsec
Signed Firmware & Configuration TLS & SRTP for Phones & Gateways Rate Limiting
HTTPS Trusted Relay Points (TRP) Managed VPN (Remote Worker)
Separate Voice & Data VLANs QoS Packet Marking Network Anomaly Detection
STP, BPDU Guard, SmartPorts DHCP Snooping Scavenger Class QoS
Basic Layer 3 ACL’s (Stateless) Dynamic ARP Inspection 802.1x & NAC
Phone Security Settings IP Source Guard, Port Security
Cost - Complexity - Resources - Performance - Manpower - Overhead
Cluster Security Mode: Feature Tradeoffs
Feature Non Secure Cluster Mixed Mode Cluster
Auto-registration
Signed & Encrypted Phone
Configs
Signed Phone Firmware
Secure Phone Services (HTTPS)
CAPF + LSC
IP VPN Phone
Secure Endpoints (TLS & SRTP)
Hardened Appliance Model
• SELinux enforcing mode provides host based intrusion protection
• iptables provides host based firewall
• Third party software installations NOT allowed
• Root account disabled, no other uid=0 accounts
• OS and applications are installed with a single package
• All software updates must be signed packages from Cisco
• Secure Management (HTTPS, SSH, SFTP)
• Audit logging
• Active & Inactive partition architecture – easy to fallback if needed
Why is UCM considered a hardened platform?
Eliminate Toll Fraud
• Deny network access to unauthorized users
• Partitions and Calling search spaces provide dial plan segmentation and access control
• Device Pool “Calling Search Space for Auto-registration” to limit access to dial plan
• Employ Time of day routing to deactivate segments of the dial plan after hours
• Require Forced Authentication Codes on route patterns to restrict access on long distance or internal calls.
• “Drop Ad hoc Conferences” (CallManager Service Parameter)
• “Block OffNet to OffNet transfer” (CallManager Service Parameter)
• Monitor Call Detail Records
• Employ Multilevel Administration
• Voice Gateways: Call Source Authentication (IOS 15.1(2) feature)
How do our customers prevent toll fraud?
Security in Layers Trivia QuestionWhich of the following step(s) allow customers to protect their voice and video environment?
A. Change the default root account password on UCM
B. Use mixed mode to enable secure device profiles allowing for encryption and mutual authentication
C. Implement VACLs to limit traffic between devices on the voice VLAN
D. Install anti-virus application on UCM
E. Turn on QoS
Certificates and PKI
Endpoint Certificates
• Manufacturing Installed Certificate (MIC)
• Cisco IP Phones ship from the factory with a unique MIC pre-installed
• MIC is valid for 10 years
• No certificate revocation support
• Locally Significant Certificates (LSC)
• preferred certificate for endpoint identity
• Endpoint support includes IP Phones, TelePresence, Jabber clients, CIPC
• LSC signed by CAPF Service running on CUCM Publisher
• LSC supports the same RSA and EC key sizes as Unified CM
• LSC can be installed, re-issued, deleted in bulk with CUCM Bulk Admin Tool
• LSC signed by CAPF is valid for 5 years
• Paper process required to track certificate expiration
Cryptographically assured device identity
Endpoint Certificates
• Default Key Order is RSA Only with 2048 bit Key Size
• Key Size updated for RSA and EC separately
• No current client support for EC only
• Auto-generated Device Security Profile will have a suffix indicating Key Order and Key Size
CAPF Support for EC Key Sizes
Best Practice: IP Phone MIC
• Endpoints can use MICs to authenticate with CAPF for LSC installation
• Use MIC for initial endpoint provisioning of IP Phones before LSC installation is done
• Not recommended to use MIC for TLS, VPN, or 802.1x
• MIC is installed at time of manufacturing and cannot be revoked
• When both LSC and MIC are installed on a device, LSC takes preference
• MIC CA certificates included in both the CallManager and CAPF trust stores:
• CAP-RTP-001
• CAP-RTP-002
• Cisco_Manufacturing_CA
• Cisco_Root_CA_2048
Cisco Manufacturing CA SHA2
• Cisco’s newest IP Phones include MIC certificates signed by this new Manufacturing SHA2 CA
• CUCM 10.5(1)+ includes and trusts the new SHA2 certificates
• Customers on older versions of CUCM may need to download the new Manufacturing CA certificate and
• upload to the CAPF-trust to allow phones to authenticate with CAPF to obtain an LSC
• upload to the CallManager-trust if customer want to allow phones to authenticate with MIC for SIP 5061
http://www.cisco.com/security/pki/certs/cmca2.cer
8811, 8841, 8851, 8861
Unified CM Certificates
• Unified CM includes seven certificate types:
• Tomcat (web services)
• CallManager RSA and EC (SIP/SCCP TLS, TFTP config signing, etc.)
• CAPF (CA cert used to sign LSC, only employed on the publisher)
• IPSEC (ipsec tunnels to gateways or other CUCM)
• TVS (Trust Verification Service, security by default)
• ITLRecovery (used as a trust anchor for bulk ITL recovery)
• Default to self-signed certificates, valid for 5 years*
• ITLRecovery is valid for 20 years beginning in 11.0
• Option to have signed by 3rd party CA
• Self-signed, 3rd party CA signed certificates, and trusted certificates managed via OS Admin page
Improved Certificate Management GUIIncluding the ability to filter, sort and view certificate expiration from the list view
Key Type new in 11.0
Expiration new in 10.5
• New option to share a single CA signed certificate across all nodes in a cluster
• Each cluster node’s FQDN included as Subject Alternative Name (SAN) in a single certificate, custom SANs can also be included
• Available for Unified CM (UCM + IM&P) and Unity Connection clusters
• Specifically for Tomcat, CallManager, CUP-XMPP & CUP-XMPP-S2S certificate types, CallManager-ECDSA in 11.0
Multi-Server Certificate Support
Simplify certificate management in clustered environments
Unified CM Cluster
UCM nodes IM&P nodes
One CA signed Multi-Server Tomcat certificate for the entire Unified CM cluster
Multi-Server CSR
Distribution drop-down provides Multi-server option
Common Name can be edited, defaults to “–ms” suffix
Auto-populated domains, parent domain, and other admin supplied domain names all included in CSR as individual DNS SANs
Multi-Server CSR Workflow
1. All nodes in the cluster need to be installed and powered on
2. Navigate to Publisher’s OS Admin > Cert Mgmt page and generate CSR with distribution set to “Multi-Server”, supply other SANs if required
3. Admin will be prompted for other cluster nodes OS admin credentials to securely replicate CSR throughout the cluster (no prompt when using common credentials)
4. Download CSR and take to CA to procure a signed certificate
a. Depending on the CA, you may need to re-enter each SAN in the CA’s web form
b. Verify the CA signed certificate includes all SANs you requested
5. Upload CA certificate chain to tomcat-trust via Publisher’s Cert Mgmt page (tomcat-trust certs are always replicated throughout the cluster)
6. Upload signed Tomcat multi-server certificate via Publisher’s Cert Mgmt GUI
7. Restart services on all nodes (utils service restart Cisco Tomcat)
Using the Tomcat certificate as an example
XMPP Multi-Server CSR Workflow
• cup-xmpp & cup-xmpp-s2s multi-server CSRs need to be generated from IM&P nodes
• Auto-populated domains will include
• IM&P node FQDNs
• Presence domains
• Group Chat Server Alias (cup-xmpp-s2s only)
• Email domains, if configured (cup-xmpp-s2s only)
• Restart Cisco XCP Router service after uploading signed cup-xmpp certificate
• Restart Cisco XCP XMPP Federation Connection Manager service after uploading signed cup-xmpp-s2s certificate
XMPP CSR differences from the previous Tomcat workflow
Known Caveats - CA signed CallManager certs
• Not recommended to use Multi-Server CSR for CallManager certificate on older 10.X releases.
• known caveats exist pre 10.5(2)SU2
• CSCur79530, CSCuq02712, CSCur97909
• CallManager certificates should not be signed by a CA with 4096 bit key -CSCur67631 (this is unrelated to Multi-Server certificate usage)
• All of these defects addressed in 10.5(2)SU2
• No known defects related to Tomcat, CUP-XMPP or CUP-XMPP-S2S Multi-Server certificate usage
Specific to CallManager.pem certificate
Certificate Key Length & Hash Algorithm OptionsAvailable across all server certificate types
Certificate Key Length & Hash Algorithm Options
• New ECDSA certificate with EC encryption
• Host portion of certificate CN will end in –EC
• Multi-Server certs will end in –EC-ms
• CallManager-ECDSA cert is included in ITL with role of TFTP
• Key size will limit hash algorithm selection
Key Pair Length Hash algorithm supported
256 bits SHA256, SHA384, SHA512
384 bits SHA384, SHA512
512 bits SHA512
‘set web-security’ CLI command
• CLI command used for updating certificate details including Organizational Unit (OU), Organizational Name (O), Location (L), State (S), and Country (C)
• One DNS SAN can also be added via the cli command (optional)
• SANs for Multi-server CSRs can also be set from OS Admin CSR GUI
Best Practice: Tomcat Certificate signed by CA
• CUCM Tomcat: HTTPS certificate used for serving CUCM admin, end user self-care page, and UDS
• By default Tomcat is self signed
• Self signed certificates generate ugly security warnings and reinforce bad habits
• Use a CA signed certificate to avoid certificate errors in browser for both end users and admins
• Save time and money with multi-server Tomcat certificate
Avoid untrusted certificate warnings in browsers and Jabber
UCM PKI Trivia Question
True or False: A single CA signed Multi-Server Tomcat certificate can be used as the Tomcat Certificate for CUCM, IM&P and Unity Connection?
False
CUCM and IM&P nodes in the same cluster can share a single Tomcat Multi-Server certificate, but there is no way to extend this outside the cluster boundary to the Unity Connection servers.
A single Multi-Server Tomcat certificate can be shared across nodes in a Unity Connection cluster.
Certificate Trust List (CTL) &
Initial Trust List (ITL)
Certificate Trust List (CTL)
• Enabling Mixed Mode to support encrypted signaling and media requires CTL
• Minimum of 2 USB secure tokens required, KEY-CCM-ADMIN-K9= or new KEY-CCM-ADMIN2-K9=
• CTL client produces Certificate Trust List (CTL) file and uploads to CUCM TFTP
• Download the CTL Client from CUCM Admin, install on Windows workstation
• CTL file is downloaded by endpoints and is the basis for endpoint certificate trust
CTL provides a trust mechanism for Cisco endpoints
Certificate Trust List (CTL)
• Unified CM 10.0 supports two different methods of building the CTL
• Classic CTL client, minimum 2 USB tokens required
• New token-less CTL
• Token-less CTL is activated with admin cli command (publisher only),
• utils ctl set-cluster mixed-mode
• CallManager certificate private key is used to sign the CTL, rather than the USB token
• DRS backup !!!
• Other CTL cli commands include
• utils ctl update CTLFile
• utils ctl set-cluster non-secure-mode
New token-less CTL option
Initial Trust List (ITL)
• Unlike the CTL file, the ITL file is built automatically when the cluster is installed or upgraded to 8.0+
• Downloaded by phones at boot or reset, after CTL file
• Has the same format as the CTL File
• Does not require eTokens; uses a soft eToken (the CallManager cert private key)
• Static and Dynamic ITL Files are built
• ITLFile.tlv ITLSEPMAC.tlv
Security by Default component
Initial Trust List (ITL) Contents
Certificate Roles: TFTP, CCM+TFTP, SAST, TVS
• TFTP, CCM+TFTP (mixed mode cluster)
• CallManager RSA certificate from the local node
• CallManager ECDSA certificate from the local node (11.0)
• SAST (allowed to sign the ITL file):
• CallManager RSA certificate from local node (8.x, 9.x, 10.x)
• CallManager RSA certificate from every node (11.0)
• ITLRecovery certificate (10.5+)
• TVS:
• All nodes in the cluster
• ITL Contents viewable with CLI show itl
• Includes CallManager-ECDSA and CallManager certificates for the entire cluster
• Only served to endpoints when the request for ITL comes in over HTTPS
• No endpoint support today
• Listed after regular ITL in CLI show itl
Extended ITL
Trust Verification Service
• Trust Verification Service (TVS) runs on each CUCM server and authenticates certificates on behalf of the phone
• Provides endpoint trusted certificates scale
• Instead of downloading all the trusted certificates, phones need only to trust TVS
• Up to 3 TVS per phone (primary, secondary and tertiary from CallManagerGroup)
• No support when failover to SRST by phone
• TVS function relies on SBD enabled and correct TVS certificate in the endpoint’s ITL file
Security by Default Component
• ITL file is built by the TFTP service in UCM 8.6+
• TVS service built the ITL file in UCM 8.0 & 8.5
• Each node running TFTP creates a unique ITL
• ITL file is rebuilt when:
• TFTP Service Restarts
• Any certificate inside the ITL changes
• CallManager Group Changes
• IP Phones automatically reset on certificate change (8.6+)
• ITL Signature should always match on endpoint and TFTP server
Managing Security by Default (SBD)ITL File Awareness
Managing Security by Default (SBD)
• “Prepare Cluster for Rollback to pre 8.0” Enterprise parameter empties the ITL file, disabling Security by Default feature
• Disable SBD if customer upgraded but needs to roll cluster back to 6.X, 7.X
• Endpoints cannot use HTTPS Services with SBD Disabled
• Default internal services will fail with SBD disabled prior to 10.5(2)
Disabling Security By Default
How Do Phones Trust the ITL File?
Case 1: Non-Existing CTL File
First ITL File is trusted in a leap of faith (similar to initial CTL)
Subsequent ITL Files must be either
• signed by the same TFTP private key
• or TVS is able to provide the certificate corresponding to the signer
• or ITL is signed with the ITL Recovery Key
Case 2: Existing CTL File
Phone uses the certificates in the CTL File to authenticate the ITL File signature
DRS Backup/Restore Certificates & Keys
• The trust anchor for the ITL File is the TFTP private key (CallManager certificate)
• Certificates and private keys are both included in DRS backups
• The backup package is encrypted to protect the private key
• DRS can be used to restore certificates and keys
• Take a fresh backup after regenerating server certificates to insure the ITL trust anchor can be restored in a disaster scenario
ITL Recovery Key
• The ITL Recovery key is a new addition to the ITL file in 10.0
• It provides a fallback mechanism to restore trust between endpoints in rare conditions were phones no longer trust the ITL file or new signed configuration files server by TFTP
> show itl
New key added to the ITL in 10.0
Reset ITL Trust
• >utils itl reset localkey
• Restart phones after running this command on the publisher
• Similar procedure available for tokenless CTL (11.0, 10.5(2)SU2)
Recover phones not accepting config changes or new ITL files
Backing up the ITL Recovery Key
> file get tftp ITLRecovery.p12
ITLRecovery backup alternative
Cisco Product Security Awareness
Cisco Secure Development Lifecyclewww.cisco.com/go/csdl
Cisco PSIRT has your back
• Dedicated, global team managing security vulnerability information related to Cisco products and networks
• Responsible for Cisco Security Advisories, Responses and Notices
• Interface with security researchers and hackers
• Assist Cisco product teams in securing products
• Subscribe (RSS or email) to Cisco notification service
Product Security Incident Response Team (PSIRT) - www.cisco.com/go/psirt
Product Security Awareness
• Subscribe/Monitor PSIRT security advisories, responses and notices
• Consult advisory details to understand impact, workarounds, and other details
• Reference linked Cisco Applied Mitigation Bulletins (AMB) when available
• Make preparations to patch systems via upgrade or COP files
• Verify DRS backups available before patching critical systems
Q&A
Continue the Conversation using Cisco Spark
• Sign up free for Cisco Spark at http://www.ciscospark.com/
• Download the application from iOS App Store, Google Play Store, or from http://download.ciscospark.com/
• Visit the World of Solutions Cisco Spark area for demos
• Use Cisco Spark to continue the conversation or ask any additional questions with the speaker for this session. The room name is BRKUCC-2501
• How to get added to the Cisco Spark room for this session
• To opt in, send an email to [email protected] with the message “Please add me to the BRKUCC-2501 room
Complete Your Online Session Evaluation
Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online
• Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card.
• Complete your session surveys through the Cisco Live mobile app or your computer on Cisco Live Connect.
Cisco Customer Connection ProgramConnect with Cisco & Peers
17,000+
Members
• Influence Collaboration product direction
• Access to early adopter & beta trials
• Contribute to advisory groups
• Monthly technical & roadmap briefings
• Exclusive perks at Cisco Live
– Collaboration Cloud Fusion: Vision & Architecture (speaker: Jonathan Rosenberg, VP/CTO CTG)
– 5 NDA Roadmap Sessions + Microsoft Interop
– Q&A Open Forum with Product Management
– Reserved seats at Work Human Innovation Talk (Wed. 3:30 – 4:30)
Visit the Customer Connection Program -
Collaboration zone in the Cisco Campus
Join the Customer Connection program
Explore the Collaboration community
New CCP members get a thank-you gift
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Table Topics
• Meet the Engineer 1:1 meetings
• Related sessions
Thank you
Backup slides
Lock Icon – non secure video considerations
• Allows administrator to determine what encryption criteria must be met to display the lock icon
• Old Service Parameter: “Override BFCP Application Encryption Status When Designating Call Security Status”
• Renamed 10.0 service parameter: Secure Call Icon Display Policy
TLS Ciphers SIP Line/Trunk Establishing a ConnectionTLS Ciphers Option Cipher Order Client Certificate
AES-256 SAH384 ciphers only RSA preferred TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
CallManager
AES-128 SHA256 ciphers only RSA preferred TLS_ECDHE_RSA_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
CallManager
AES-256, AES-128 ciphers ECDSA preferred TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_RSA_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA1
CallManager
AES-256, AES-128 ciphers ECDSA only TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
CallManager-ECDSA
AES-256, AES-128 ciphers RSA preferred TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_RSA_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA1
CallManager
AES-128 SHA1 cipher only TLS_RSA_WITH_AES_128_CBC_SHA1 CallManager
TLS Ciphers SIP Line/Trunk Receiving a ConnectionTLS Ciphers Option Cipher Order
AES-256 SAH384 ciphers only RSA preferred TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
AES-128 SHA256 ciphers only RSA preferred TLS_ECDHE_RSA_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
AES-256, AES-128 ciphers ECDSA preferred TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_RSA_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA1
AES-256, AES-128 ciphers ECDSA only TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
AES-256, AES-128 ciphers RSA preferred TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_RSA_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA1
AES-128 SHA1 cipher only TLS_RSA_WITH_AES_128_CBC_SHA1
TLS Ciphers Secure CTI Manager Receiving a ConnectionTLS Ciphers Option Cipher Order
AES-256 SAH384 ciphers only RSA preferred TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
AES-128 SHA256 ciphers only RSA preferred TLS_ECDHE_RSA_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
AES-256, AES-128 ciphers ECDSA preferred TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_RSA_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA1
AES-256, AES-128 ciphers ECDSA only TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
AES-256, AES-128 ciphers RSA preferred TLS_ECDHE_RSA_AES_256_GCM_SHA384
TLS_ECDHE_RSA_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA1
AES-128 SHA1 cipher only TLS_RSA_WITH_AES_128_CBC_SHA1