Cisco Connect Ottawa 2018 secure on prem

Cisco Connect Ottawa
Canada • 2 October 2018
Hikmat El Ajaltouni – Systems Engineer
Secure Collaboration for On-Premise
Voice & Video Deployments

© 2 0 1 8 C is c o a n d / o r it s a f f ilia t e s . A ll r ig h t s r e s e r v e d . C is c o C o n f id e n t ia l
Why Collaboration Security?

Securing Collab Deployments Strategy
Internet
CUCM
IdP
Collaboration Apps
Enterprise
CA
Secure
out-of-the-box
Easy
to manage
Cloud-ready
Certification
Compliant

The Federal Space
Federal Certifications Testing Agencies
Common Criteria NIAP (NSA)
DoD Unified Capability
Approved Products List
JITC
Commercial Solutions
for Classified
NSA / CSS
FedRAMP 3PAO

© 2 0 1 8 C is c o a n d / o r it s a f f ilia t e s . A ll r ig h t s r e s e r v e d . C is c o C o n f id e n t ia l© 2 0 1 8 C is c o a n d / o r it s a f f ilia t e s . A ll r ig h t s r e s e r v e d . C is c o C o n f id e n t ia l
Agenda
• Security Fundamentals: PKI, Certificates, TLS
• Platform, Protocols and Feature Security
• CUCM Security
• Edge Security (CUBE, Expressway, & MRA)
• Conclusion

PKI &
Certificates

abcde
fghijk
lmnop
qrstuv
01011
11001
10100
00010
abcde
fghijk
lmnop
qrstuv
Shared Key
Must be kept secret
Same key to encrypt and decrypt
Symmetric Key Cryptography

Asymmetric Key Cryptography
• Public Key
Can be distributed
Used to encrypt data:
Used to verify signatures:
• Private Key
Must be kept secret
Used to decrypt data:
Used to sign data:
abcde
fghijk
lmnop
qrstuv
abcde
fghijk
lmnop
qrstuv
abcde
fghijk
lmnop
qrstuv
abcde
fghijk
lmnop
qrstuv
01011
11001
10100
00010
abcde
fghijk
lmnop
qrstuv

Digital Signatures
Message Integrity + Authentication/non-repudiation
Lorem
ipsum
dolor
Jr%434
Hash
Function
Hash
Function
Lorem
ipsum
dolor
Lorem
ipsum
dolor
Jr%434
=?
2c87a
7ac7e
2c87a
7ac7e
2c87a
7ac7e
2c87a
7ac7e

How a TFTP Configuration File is Signed

Validating a Signed TFTP Configuration File

Signed TFTP Configuration Files
http://<TFTP_IP_Address>:6970/<SEP>.cnf.xml.sgn

© 2 0 1 8 C is c o a n d / o r its a ffilia te s . A ll r ig h ts r e s e r v e d . C is c o P u b lic
#CLUS
Digital Certificates
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 6 (0x6)
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=root, OU=ca, O=cisco
Validity
Not Before: Mar 25 10:46:17 2013 GMT
Not After : Mar 25 10:46:17 2014 GMT
Subject: CN=router, OU=TAC, O=Cisco, C=BE
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:c2:e5:4d:45:50:8b:18:86:45:ca:b6:b2:f0:f1:
[...]
36:c2:16:ca:a2:df:ac:8e:3d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: sha1WithRSAEncryption
03:65:af:30:c5:8d:e4:45:b1:00:1b:4f:e0:22:8b:ef:3b:d3:
[...]
c3:5d:37:ac
Certificate properties
Issuer identity
& signature
Subject identity, key
& attributes
B R K U C C -2 5 0 1 1 3

© 2 0 1 8 C is c o a n d /o r its a ffilia te s . A ll rig h ts re s e rv e d . C is c o P u b lic 1 4B R K U C C -2 5 0 1
Types of Certificates
Certificates issued to a specific
entity (a device) and signed or
issued by a root CA or sometimes
by an intermediate CA.
Optional
Certificates signed by a Root CA
and in turn can sign other identity
certificates.
Cisco Employee CA
Issuer CN = Cisco Root CA 2048
Self-Signed certificates used by
Certificate Authorities to sign other
certificates.
Cisco Root CA 2048
https://www.cisco.com/security/pki/

Certificate Trust Chain
Root
Certificate
Intermediate
Certificates
Identity
Certificate
Trust Chain Identity
Signed Signed
Root CA Public Certificates
Must be stored in Clients’
Trust Store(s)

#CLUS
CUCM Certificate Types
CallManager
CAPF
TVS
ITLRECOVERY
IPSec
Tomcat
B R K C O L - 2 0 1 4
Identity Certificates for
different Services and
Functions

#CLUS
CUCM Certificate Trust Stores
Identity Certificate Trusted Certificates
Type Type-trust
B R K C O L - 2 0 1 4

Certificate Trust Stores

#CLUS
CUCM Certificate Truststores
B R K C O L - 2 0 1 4
Truststores for
Services and Functions
CallManager-Trust
CAPF-Trust
TVS-Trust
Phone-VPN-Trust
IPSec-Trust
Tomcat-Trust

CallManager Service Trust Store Example
CallManager-trust
CallManager
CUCM/CUBE
Client
CallManager
Server
SYN ACK
SYN
ACK
Client Hello
Server Hello
Certificate
CallManager
Client
CUCM/CUBE
Server
SYN ACK
SYN
ACK
Client Hello
Server Hello
Certificate
Trusted ?

#CLUS
Best Practice: Tomcat Certificate Signed by CA
Avoid Untrusted Certificate Warnings In Browsers And Jabber

Transport
Layer Security
& Ciphers

TLS Session Establishment
Client Server
ServerHello
Certificate
ServerKeyExchange
ServerHelloDone
[ChangeCipherSpec]
Finished
ClientHello
ClientKeyExchange
[ChangeCipherSpec]
Finished
TLS Established

TLS Session Establishment - Mutual TLS
Client Server
ServerHello
Certificate
ServerKeyExchange
CertificateRequest (MTLS)
ServerHelloDone
[ChangeCipherSpec]
Finished
ClientHello
Certificate (MTLS)
ClientKeyExchange
CertificateVerify
(MTLS)
[ChangeCipherSpec]
Finished
TLS Established

Deconstructing the Cipher Suite
Message Authentication Code
• SHA2 with key size
Bulk Encryption
• AES GCM: Advanced Encryption
Standard Galois Counter Mode
Key Exchange
• ECDHE: Elliptic Curve Diffie-
Hellman Ephemeral
Signature Algorithm
• RSA: Rivest-Shamir-Adleman
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• Elliptic Curve Cryptography (ECC) provides comparable
cryptographic strength to RSA but with a smaller key size.
Elliptic Curve Cryptography
Symmetric Key Size
(bits)
RSA and DH Key Size
(bits)
Elliptic Curve Key Size
(bits)
80 1024 160
112 2048 224
128 3072 256
192 7680 384
256 15360 521

Encryption Strengths
NSA Top Secret
NSA Secret
For your reference

Ciphers in TLS

Certificates in TLS

Cipher Suites Support
• CUCM 10.5(2): Added SIP support of
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
And SRTP support of AEAD_AES_256_GCM and AEAD_AES_128_GCM
• CUCM 11.0: Added SIP support on CUCM for
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• CUCM 11.5: Added HTTPS support for ECDSA based cipher suites

#CLUS
Certificate Distribution
Available for Tomcat, CallManager, CallManager-ECDSA, CUP-XMPP &
CUP-XMPP-S2S certificate types
Multi-Server Certificates
Unified CM Cluster
UCMnodes 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
For your reference

• PCI DSS: Deadline of June 30, 2018.
• Other Security Requirements.
Requirements
Disable TLS 1.1/1.0, SSL 3.0 and
lower protocols
TLS 1.2 support

Product Support
Product Support
Supports
TLS 1.2
Disable
TLS 1.0
Disable
TLS 1.1
Notes
CUCM/IM&P, UCxn, CER, PLM*, PCD, TMS, secure
CUBE (G2/G3)
þ ý ý CSR 12 and earlier (e.g. backport to
11.5)
Other infrastructure (CMS, Conductor, TP Server,
Expressway, Contact Center, PCP, secure SIP PSTN
GW/CUBE/MTP/CFB G2/G3, secure SRST G3, secure
analog VG)
þ ý ý CSR 12
CE Endpoints (DX70/80, MX 200/300 G2, MX 700/800,
SX, IX 5000
þ ý ý 9.1.3
78xx/88xx þ ý ý 12.1
Newer TC endpoints (can run CE)
(MX 200/300 G2, MX 700/800, SX)
þ þ ý Can SWupgrade to CE
Legacy TC endpoints
(C-series, EX, MX 200/300 G1, Profile)
þ þ ý End of Sale
Legacy Immersive
(TX 9000 series, CTS)
þ ý ý End of Sale
Older IP phones (e.g., 79xx series, 69xx, 99xx, 89xx,
DX on Android, IP Communicator)
ý ý ý No support or partial support
P
For your
reference

TLS 1.2 Compatibility Matrix
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/uc_system/unified/communications/system/Compatibility/TLS/TLS1-2-Compatibility-Matrix.html
TLS 1.2 Support
(Interop)
Disabling TLS 1.0/1/1
(PCI Compliance)
For your reference

• 3DES is disabled on all TLS interfaces
(and SSH interfaces).
• CUCM 11.5(1)SU4+
• CUCM 12.0(1)SU2+
CUCM 11.5(1) and 12.0(1): 3DES Being Removed

• Will let the administrator select a list of allowed cipher
suites.
• New GUI page in the CUCM OS page.
• OpenSSL cipher suite string format.
CUCM 12.5: Cipher Suite Control
Future
(subject to change)

• ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
Cipher Suite String: List of Cipher Suites
Future
(subject to change)

• ALL:!MD5:!SHA
Cipher Suite String: Keywords
Future
(subject to change)

• If configured, this will
overwrite the default
behavior
Which TLS Interface?
ALL TLS
HTTPS TLS
SIP TLS
Future
(subject to change)

• Also have the ability to add some ciphers… to a certain extent…
• For example, can re-add 3DES, but cannot enable very weak ciphers
such as DES.
• Limitation: This list represents the cipher suites that are allowed…
But interfaces may not support those cipher suites…
⚠ Be careful when manipulating this cipher suite list!
Possible interoperability issues.
Ability to DELETE and ADD cipher suites
Future
(subject to change)

• Roadmap item for CSR 12.5
• Would provide support of an ECDSA certificate on 7800/8800
phones.
• Notes:
• SIP TLS and HTTPS web access would negotiate an ECDSA-based
cipher suite.
• Not all cryptography will be based on EC Cryptography (e.g. CAPF, TVS,
TFTP configuration file signature).
Feature Overview
Future
(subject to change)

Media Encryption

Secure protocols for endpoints
4 4B R K C O L -3 5 0 1
TLS TLS
SRTP
SIP/ SCCP SIP/ SCCP
Signaling
Media
CUCM Mixed Mode cluster

#CLUS
What’s Secure RTP?
m=audio 8256 RTP/AVP 0
c=IN IP4 14.50.248.31
a=rtpmap:0 PCMU/8000
m=audio 8264 RTP/SAVP 0
c=IN IP4 14.50.248.31
a=rtpmap:0 PCMU/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:
L5+zq2AXJxLk+058lu/XRQWJZiK0c0D0
SDP for SRTPSDP for RTP
• As per RFC 3711: SRTP is a profile of the Real-time Transport Protocol (RTP), which can
provide confidentiality, message authentication, and replay protection to the RTP traffic“
• It uses AES (Advanced Encryption Standard) as the default cipher for stream encryption
• HMAC (Hash-based Message Authentication Code) is used to authenticate the message and
protect its integrity
a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]
Detailed information

#CLUS
Question: Does the MRA Endpoint have the Certi!cate
of the locally registered endpoint ?
MRA Media and Signaling Encryption
DMZ
Firewall
Expressway-C Expressway-E External
Firewall
SIP TLSSIP TLS
SRTP
SIP TLS*
SRTP*
Media and Signaling always encrypted
SIPTLS*

#CLUS
MRA Media and Signaling Encryption
• SIP TLS always enforced between MRA clients & Exp-E, Exp-C &
Exp-E
• Voice/Video streams always SRTP encrypted between Exp-C and
MRA client
• * UCM mixed mode required to achieve SRTP on internal network
and SIP TLS between Exp-C and UCM
DMZ
Firewall
Firewall
SIP TLSSIP TLS
SRTP
SIP TLS*
SIP TCP
SRTP*
RTP
Media and Signaling always encrypted

#CLUS
MRA Authentication
• MRA endpoints verify the Expressway-E Server Certificate
• Jabber Clients rely on the underlying platform trusted CA list
• Hardware endpoints rely on a trusted CA list included in firmware
=> One reason why a public CA must be used with Expressway-E
• Expressway-E does not verify the MRA endpoint certificate
DMZ
Firewall
Firewall
SIP TLSSIP TLS
SRTP
SIP TLS*
SIP TCP
SRTP*
RTP

#CLUS
sRTP Fallback– vcs-interop Lua Script
Direction Conditions Behavior Applies to
Inbound to
UCM
m=RTP/AVP media description
a=crypto lines in the SDP
Convert media descriptions to
RTP/SAVP
Add x-cisco-srtp-fallback
header
All requests containing
SDP
Outbound to
Expressway
m=RTP/SAVP media description
a=crypto lines in the SDP, or
both of the a=setup and
a=fingerprint attributes
Convert media descriptions to
RTP/AVP INVITEs only
Outbound to
Expressway All Requests and Responses
Modify the RHS of the SIP URI to
the Top Level Domain on the any of
the following headers (if present):
From, Remote-Party-Id, P-
Asserted-Identity
All requests, including
INVITEs with modified
media descriptions
B R K C O L - 3 2 2 4 4 9
For your reference

Platform,
Protocols &
Feature Security

Balancing Risk
Cost - Complexity - Resources - Performance - Manpower - Overhead
High
Advanced or Not Integrated
UC-Aware Firewall (Inspection)
Phone Proxy
Ipsec
Rate Limiting
Managed VPN (Remote Worker)
Network Anomaly Detection
Scavenger Class QoS
802.1x & NAC
Medium
Moderate and Reasonable
IP VPN Phone
Secure Directory Integration (SLDAP)
Encrypted Configuration
TLS & SRTP for Phones & Gateways
Trusted Relay Points (TRP)
QoS Packet Marking
DHCP Snooping
Dynamic ARP Inspection
IP Source Guard, Port Security
Low
Easy or Default
Hardened Platform
SELinux – Host Based Intrusion
Protection
iptables - Integrated Host Firewall
Signed Firmware & Configuration
HTTPS
Separate Voice & Data VLANs
STP, BPDU Guard, SmartPorts
Basic Layer 3 ACL’s (Stateless)
Phone Security Settings
For your reference

© 2 0 1 8 C is c o a n d /o r its a ffilia te s . A ll rig h ts re s e rv e d . C is c o P u b lic
Unified Communications Manager Security
Platform Protocols Features
5 2B R K U C C -2 5 0 1

Hardened
Platform
SELinux
FIPS
Mode
IPTables
No 3rd
Party
Software
Signed
Upgrade
Active &
Inactive
Partition
Secure
Mgmt
Protocols
Secure Platform

SIP
Trunks
MGCP
H.323
TAPI &
JTAPI
ILSLBM
Media
Resources
SLDAP
SIP &
SCCP
R e g is tr a tio n
Secure Protocols

User
Credential
Policies
Certificate
ExpiryNotification
Toll Fraud
Protection
Call
Security
Icons
Multilevel
Admin
Auto
Registration
Audit
Logging
Encrypted
Config
Files
Encrypted
Backups
Security Features

Toll Fraud Prevention - CUCM
• Partitions and Calling search spaces provide dial plan segmentation and access control
• “Block offnet to offnet transfer” (CallManager service parameter)
• “Drop Ad hoc Conferences” (CallManager service parameter)
• 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 international calls.
• Monitor Call Detail Records
5 6B R K C O L - 2 0 1 4

UCM Cluster Security Mode
Non-Secure or Mixed
• NOT On/Off
Mixed Mode Requirements:
• Export Restricted version of UCM
• CTL File
Configured via:
• Windows CTL Client
• ‘utils ctl set-cluster’ CLI
Status in Enterprise Parameters:
5 7B R K U C C -2 5 0 1
Mixed
Non-Secure

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)
For your reference

CUBE / IOS Security
Security Features
• IP Trust List: Don’t respond to any SIP INVITEs if not originated from an IP address
specified in this trust list
• Call Threshold: Protect against CPU, Memory & Total Call spike
• Call Spike Protection: Protect against spike of INVITE messages within a sliding
window
• Bandwidth Based CAC: Protect against excessive media
• Media Policing: Protect against negotiated Bandwidth overruns and RTP Floods
• NBAR policies: Protect against overall SIP, RTP flood attacks from otherwise “trusted”
sources
• Voice Policies: Identify patterns of valid phone calls that might suggest potential abuse
5 9B R K C O L - 2 0 1 4
voice service voip
ip address trusted list
ipv4 10.1.1.10
ipv4 66.66.66.66

Expressway Security
Security Features
6 0B R K C O L - 2 0 1 4
• Call Policy (CPL) Rules
• Granular TLS version control and cipher control
• Media encryption policy
• TLS certificate verification policy (TLS verify)
Traversal Zone
Internet
Authenticated
non-authenticated
Expressway-C
Expressway-E

CUCM Security

#CLUS
Phone Certificate Types
• Signed by Cisco Manufacturing CA
• Automatically installed in supported phone models
• Used to authenticate with CAPF for LSC installation or
downloading an encrypted configuration file
• Cannot be overwritten or deleted or revoked
Manufacture-Installed Certificate (MIC)
• Used for authentication and encryption
• Signed by CAPF
• Takes precedence over MIC
Locally Significant Certificate (LSC)
Recommended

#CLUS
Phone Certificate Trust Chains

UCM non-secure
Endpoint not supporting ITL (e.g. older phone or Jabber)
2
1
Validate with
existing
firmware
Unsigned
config
(.xml)
TFTP Server
Signed
Firmware
(.sbn)

#CLUS 6 5B R K C O L - 3 5 0 1
Initial Trust List (ITL)
Anchor for Security By Default feature from 8.0
ITLFile.tlv
Publisher CallManager.pem
CAPF.pem
ITLRecovery.pem
TVS.pem
ITLFile.tlv
Subscriber CallManager.pem
CAPF.pem
ITLRecovery.pem
TVS.pem

#CLUS
4
3
2
1
Validate
with ITL
Trust ITL if
none on file.
Otherwise
validate ITL
signature
CTL not
found and
not on file
Validate
with
existing
firmware
TFTP ServerITLFile.tlv
Signed
config
(.xml.sgn)
Signed
Firmware
(.sbn)
CTLFile.tlv
UCM non-secure
Endpoint supporting ITL
ITLFile.tlv
Signed
config
Signed
Firmware

#CLUS
CTLFile.tlv
6 7B R K C O L - 3 5 0 1
Certificate Trust List (CTL)
CTL Client using KEY-CCM-ADMIN2-K9 Publisher
E-Token 1
E-Token 2
CallManager.pem
CAPF.pem
ITLRecovery.pem
Publisher
Subscriber Subscriber
CTL Provider
CTL Client

#CLUS
CTLFile.tlv
6 8B R K C O L - 3 5 0 1
Certificate Trust List (CTL)
Token-less CTL in UCM 10.0 and later Publisher
SSH
CallManager.pem
CAPF.pem
ITLRecovery.pem
Publisher
Subscriber Subscriber
utils ctl set-cluster mixed-mode

Signed
Firmware
UCM in mixed mode
Initial bootstrap
4
3
2
1
Validate
with
CTL
Validate
with CTL
Trust CTL if
not present.
Otherwise
check CTL
signature
Validate with
existing
firmware
TFTP ServerITLFile.tlv
Signed
config
Signed
Firmware
CTLFile.tlv
Signed
config
ITLFile.tlv
CTLFile.tlv

#CLUS
Do I trust this
device?
High Level View of a Secure Phone Registration
Phone with security profile set to Authenticated or Encrypted mode
?
Yes
Trust
it?Yes
Truststore
Client Hello
TLS
ITLFile.tlv
CTLFile.tlv

#CLUS
ITLFile
CTLFile
ITLFile
CTLFile
End-to-End Phone Signaling Encryption
Phones with security profile set to Encrypted mode
TLSTLS
SRTP

#CLUS
ITLFile
CTLFile
Signaling Secure to Non-Secure Interworking
TCP
ITLFile
CTLFile
TLS
RTP

#CLUS
Trust Verification Service Example
7 3B R K C O L - 3 5 0 1
TFTP
GET CTLSEPmac.tlv
GET ITLSEPmac.tlv
GET SEPmac.cnf.xml.sgn
404
TVS
TVSTVS
TVS
GET CTLSEPmac.tlv
GET ITLSEPmac.tlv
TFTP
CallManager.pem
404
CallManager.pem
Authorize CallManager.pem
Authorized
Role: SAST

LSC Expiration Visibility in UCM 11.5
Search & Reporting

ITLRecovery
Trust Anchor

• What happens if the CallManager and TVS certificates are renewed
while the endpoint is off-line?
Loss of Trust
TVS
TVSTVS
TVS
GET ITLSEPmac.tlv
TFTP
CallManager.pem
TVS

• Issue:
Phones could loose trust to CUCM.
• Consequences:
Cannot accept any configuration changes anymore.
Phones may not be able to register anymore.
Procedure to re-establish the trust issue could be tedious.
• Conditions:
This could happen when the CallManager and TVS certificates are
regenerated.
Change hostname.
Current Challenge

• ITL/CTL: Establishes trust for the phones.
• In CUCM 11.5.1 and prior releases, ITL and
tokenless CTL are signed by the CallManager key.
ITL/CTL: CallManager Current Signer
ITLFile.tlv
TFTP
CAPF.pem
ITLRecovery.pem
TVS.pem
CallManager.pemCallManager.pem

• New long-lived Trust Anchor: ITLRecovery.
• In 10.0: Introduced, only used for recovery procedure.
• In 12.0: Part of the normal operations.
Solution: ITLRecovery

• In 12.0, ITL and tokenless CTL are signed by the
ITLRecovery key.
• Benefit: Renewing CallManager and TVS certificates or
changing hostname will not cause possible trust issues
anymore.
ITL/CTL: ITLRecovery New Signer in CUCM 12.0+
ITLFile.tlv
TFTP
CAPF.pem
TVS.pem
CallManager.pem
ITLRecovery.pemITLRecovery.pem

Prior to CUCM 12.0: Exchange of (many) CallManager certificates.
CUCM 12.0 onwards: Exchange of one ITLRecovery certificate per remote cluster.
CUCM Cluster Migration

ITLRecovery certificate added to ITL/CTL when importing it to the phone-SAST-trust.
CUCM Cluster Migration – 12.0+
ITLFile1.tlv ITLFile2.tlv

Does not rely on TVS.
CUCM Cluster Migration – 12.0+
ITLFile1.tlv ITLFile2.tlv

Automatic
Phone
Certificate
Enrollment

• Endpoints continue to use CAPF protocol to request a client certificate (LSC)
• CUCM proxies enrollment requests to Enterprise CA using relevant API
• CA supported in 12.5: Microsoft CA (using NTLM authentication)
Automatic Phone Certificate Enrollment
CUCM
Enterprise CA
(Microsoft)
CAPF
CES
CAPF
Future
(subject to change)
API
LSC LSC
New “Certificate Enrollment
Service” (CES)

Automatic Phone Certificate Enrollment
CUCM/CAPF Configuration
Future
(subject to change)
New “Online CA”
CAPF Mode
Online CA
Configuration
Parameters

Non-LSC Endpoints

#CLUS
1. Generate keypair and certificate
openssl req -newkey rsa:2048 -nodes -keyout key.pem -x509 -days 365 -out certificate.pem
2. Upload to Endpoint
Don’t forget the private key!
TC & CE Endpoints
8 8B R K C O L - 3 5 0 1
Non-LSC Endpoint Identity Certificates

#CLUS
Bulk Non-LSC Endpoint Identity Certificates
Using xAPI (from CE9.2)
xCommand Security Certificates Services Add
-----BEGIN CERTIFICATE-----
<cert>
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
<private key>
-----END PRIVATE KEY-----
.
OK
*r ServicesAddResult (status=OK):
** end
8 9B R K C O L - 3 5 0 1
Initiate Command, hit <enter>
Paste PEM-encoded
certificate followed by private
key
“.” on a line by itself signals
end of input
Result of command

Edge Security

#CLUS
Certificate
Authority
Trustpoint and Generating CSR
Importing Trustchain and Identity Certificate
crypto pki authenticate <trustpoint_name>
crypto pki import <trustpoint_name> certificate
<trustpoint_names>
CUBE
crypto pki trustpoint <trustpoint_name>
crypto pki enroll <trustpoint_name>

#CLUS
Trustpoint (s)
Do I trust this
device?
High Level View of a Secure Connection
?
Yes
Trust
it?Yes
Truststore
Client HelloCUCM CUBE
TLS

Automatic
Certificates
for
Expressway-E

• On-premises Jabber needs to validate cert’s of all server it connects to (CUCM/IM&P, Unity Cxn)
• Both Jabber and endpoints need to validate Expressway-E certificates over MRA
• Expressway-E certificates signed by a public CA also needed for B2B video and XMPP federation
• All these certificates need to be obtained/uploaded/renewed manually from external CA’s
UC Server Certificates Today
Internet
CUCM
Expwy
E
Expwy
C
IM &P
Firewall
Jabber clients
Jabber
clients
Endpoints
over M RA
Unity Cxn
Tom cat cert
XM PP cert
Expressway cert
Private CA
Public CA
Cert validation
M anual CSR

Let’s Encrypt – https://letsencrypt.org
Automated
domain validation
and certificate
issuance using
ACME protocol
(IETF Internet-Draft)
Validation challenge
involves accessing
a special file on the
server over HTTP

Internet CUCM
Expwy
E
Expwy
C
IM &P
Firewall
Jabber clients
Jabber
clients
Endpoints
over M RA
Unity Cxn
ACME
Automatic enrollment and renewal of Expressway-E certificates with
LetsEncrypt CA (ACME client)
Automatic Certificates for Expressway-E
Future
(subject to change)

• CSR must be initiated once from each
Expwy-E node in the cluster
• Also available via API
• Certificate is automatically obtained
and periodically renewed before its
expiration
(current validity of LE certs: 90 days)
• Not available for Expwy-C nodes
• Certificate revocation
support may come later
Automatic Cert’s for Expwy-E
Configuration and Caveats
Future
(subject to change)

SIP OAuth

• Authorization framework for SIP
• Based on RFC 5749 – OAuth2.0
• OAuth (Open Authorization) is an open standard for token-
based authentication and authorization.
• Similar to OAuth 1.0, OAuth 2.0 provides users with the ability to grant
third-party access to web resources without sharing a password.
• Adds a simple identity layer based on the OpenID Connect Core 1.0
• Enable Clients to verify the identity of the End-User based on the
authentication performed by an Authorization Server
SIP OAuth

Architecture Evolution
API Authorization for Jabber Clients – 12.X
C UC M /IM &P
Unity C xn
IdP
Expressw ay E/C
LDAP
Directory
OAuth
OAuth
AuthZ Service :
• Always-on OAuth flow (with
SAML, LDAP or local authN)
• Authorization code grant flow
with refresh tokens
• Self-contained tokens (JWT)
• Runs on all CUCM nodes
Jabber clients use OAuth
on all interfaces in all
deployments
(see next slide)
(optional)
Expressway, Unity Connection:
• Retrieve signature validation
and decryption keys from
AuthZ Service
• Validate and decrypt tokens
New!
(11.5SU3 - 12.0)
SAM L
IdP

sRTP
sRTP
Jabber over MRA:
• SIP signaling is authenticated (TLS +
OAuth token) and encrypted
• Expwy-C enforces encryption (B2BUA)
• Media is encrypted (Jabber ↔ Expwy-C)
• No ICE media path optimization possible
Jabber SIP and Media Security – CSR 12.0
Internet DM Z Enterprise
Expressw ay E Expressw ay C
Jabber
clients
RTP
Jabber
clients
SIP/TC P
SIP/TLS
SIP/TLS
SIP/TLS
SIP/TLS
SIP/TC P
Jabber on-premises:
• SIP signaling and media are not
authenticated nor encrypted by default
• Encryption requires CUCM mixed mode
• Signaling authentication is certificate-based
(mTLS), requires CAPF enrollment
C UC M
sRTP
sRTP
SIP/TC P
SIP/TC P

Jabber over MRA:
• Expwy-C proxies OAuth token to CUCM
• Media is encrypted end-to-end
• ICE media path optimization is possible
Jabber SIP and Media Security – CSR 12.5
Internet DM Z Enterprise
Jabber
clients
Jabber
clients
Future
(subject to change)
Jabber on-premises:
• Media is encrypted (no need for CUCM
mixed mode or CAPF enrollment)
C UC M
Expressw ay E Expressw ay C
SIP/TLS
SIP/TLS
SIP/TLS
SIP/TLS
SIP/TLS
SIP/TLS
sRTP
sRTP
sRTP
SIP/TLS
SIP/TLS
sRTP
TURN

HTTP (CUCM) SIP XMPP HTTP (Unity Cxn)
Jabber on-premises
(Local/LDAP AuthN) OAuth token
Certificate-based*
(Future: OAuth token)
OAuth token
OAuth token
Jabber via MRA
(Local/LDAP AuthN) OAuth token OAuth token OAuth token OAuth token
Jabber on-premises
(SAML SSO) OAuth token
Certificate-based*
(Future: OAuth token)
OAuth token OAuth token
Jabber via MRA
(SAML SSO) OAuth token OAuth token OAuth token OAuth token
*: Requires CUCM mixed mode
New!
(11.5SU3 – 12.0)
API Authorization Based on Authentication Option – 12.X

New option in Phone Security
Profile enables encryption without
LSC/CAPF, using “single” TLS +
OAuth tokens
• Must be first enabled via CLI
(requires unrestricted license)
• New SIP ports on CUCM
(configurable)
• Automatic mTLS with Expwy-C
for MRA-registered clients
SIP OAuth Support in CUCM
Future
(subject to change)
LSC
Tom cat C M
TCPmTLSTLS
(+ OAuth in SIP)
mTLS
5061 50605090
5091
SN’s/SAN’s
of Expw y
nodes
Non-secureEncrypted
Encrypted
(OAuth)
Expwy-C
(MRA)
CUCM
Device Security Modes

Conclusion

Rome was not built in a day
Future:
• Server cert reduction
• Cert revocation
• Always-secure phones
• 802.1x certs (IoT-ready)
CSR 12.5:
• TLS cipher suite control
• EC certificates
• SIP OAuth
• Expwy-E automatic certificates
• Automatic phone cert enrollment
CSR 12.0-12.1:
• Jabber MRA improvements
• ITLRecovery trust anchor
• TLS 1.2
CSR 11.x:
• LSC management
• Next-gen encryption
• Single SAML agreement
• Mixed mode auto-reg
CSR 10.x:
• SAML SSO
• Cluster-wide certs
• MRA
(Items in blue are subject to change)
Covered
today

Security is a Journey, Not a Destination
• Stay up-to-date on the latest security news and upgrade / install security updates when
applicable
• Product Security Incident Response Team (PSIRT)
• www.cisco.com/go/psirt
• Latest Threats
• Security advisories and
responses
• Get Notifications

#CLUS
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

Cisco Connect Ottawa 2018 secure on prem

Cisco Connect Ottawa 2018 secure on prem

Recommended

Recommended

More Related Content

Similar to Cisco Connect Ottawa 2018 secure on prem

Similar to Cisco Connect Ottawa 2018 secure on prem (20)

More from Cisco Canada

More from Cisco Canada (20)

Recently uploaded

Recently uploaded (20)

Cisco Connect Ottawa 2018 secure on prem