Chapter 8
Securing Cisco Unified Communications Manager (Cisco)
Securing a Cisco Unified Communications Manager involves more than just enabling Secure Real-time Transport Protocol (SRTP) and Transport Layer Security (TLS) to secure the signaling and media between endpoints or configuring and enforcing user access controls. This chapter explains some specific aspects to securing endpoints, conferencing, and Smart Licensing with a specific focus on Cisco Unified CM.
Endpoint Hardening
Hardening endpoints is the same as hardening an OS or other network device. Endpoint hardening is nothing more than removing and disabling unused features and services. When dealing with endpoints, you need to make some considerations to properly lock down devices and still allow them to function. An example is disabling the PC port on an IP phone. Using the example of disabling a PC port also lets us address some additional caveats to hardening endpoints. When looking at disabling a PC port, you need to consider the location and function of the phone that is having its PC port disabled. Disabling the PC port on a lobby phone makes sense, because in most instances a lobby phone does not have a PC connected to it. However, disabling the PC port on a user’s desk phone would mean there would need to be two separate network connections: one for the PC and one for the phone. Some security policies might require separate voice and data network connections. These are infrequent in most environments because one of the benefits of using VoIP is the reduced network infrastructure when voice and data networks are consolidated. This section covers the basics of hardening endpoints to illustrate where the settings are configured and what common settings are used to secure the endpoints.
Where to Configure the Settings
The settings to harden an endpoint can be configured in several different places. Cisco uses a layered approach to applying configuration settings within Cisco Unified CM. This way UC administrators can provide default endpoint profiles systemwide that can then be updated to be either site or device specific.
For example, within Cisco Unified CM, you can define a clusterwide endpoint security policy by configuring the settings under System > Enterprise Phone Configuration. By default, these settings are not applied, but as the UC administrator, you do have the ability to configure default settings for all endpoints. At this top level in configuration options, you can configure many options, such as enabling FIPS on the endpoint, disabling the PC port, and configuring 802.1x authentication. Although not every configurable option is available at this level, it does enable you to define a baseline security posture for endpoints.
Diving a little deeper, you can refine the configuration options for groups of phones using Common Phone Profiles. These profiles, located at Device > Device Settings > Common Phone Profile, enable you to configure groups of phones with configuration settings that override the Enterprise Phone Configuration settings. The same options configurable with Enterprise Phone Configuration can be configured here.
The previous two methods for configuring endpoints provide a way to ensure endpoints are hardened by default. This can be at the enterprise level where all devices that register to Cisco Unified CM have a specific set of features enabled. Or with the use of Common Phone Profiles, groups of phones at a site or function level can be configured with specific features that override the Enterprise settings.
The last method is at the device level. Configuration settings at the device level take priority over both the Enterprise Phone Configuration settings and the Common Phone Configuration settings. These settings should be configured for one of two reasons: either it is a one-off situation, or the setting does not exist at the Enterprise Phone Configuration or Common Phone Profile levels. For example, one such feature that is available only at the device is the ability to disable the speakerphone.
Features and Services to Consider
There is no hard-and-fast rule when it comes to which features and services need to be configured so that an endpoint can be considered hardened. It is important to consider what the endpoint is used for when defining the hardening criteria. A sample scenario to consider is whether to enable or disable the built-in video camera on an IP phone. In most cases, this feature could be left enabled, with no change to the Enterprise Phone Configuration. However, if the phone is used in a secure environment or where personally identifiable information (PII) could be viewed by unauthorized parties during a video call, disabling it might be prudent. There are a couple of issues to consider here. The first is whether deploying a video-enabled phone is the right choice for that location. If it is and there is a pressing reason to deploy this type of endpoint, it could still be an indicator that these devices should have their video disabled, for example, at the Common Phone Profile. A second example is the PC port. Should it be enabled or disabled? For most endpoints, this port should be enabled because most users connect their workstations to this port for network access. If, however, the endpoint is a public area, like a lobby or elevator, likely the PC port should be disabled.
The following are some of the common settings used to harden endpoints:
Gratuitous ARP: You should disable Gratuitous ARP to reduce the likelihood of ARP spoofing.
Web Access: If the web services are disabled, the phone does not open HTTP port 80 or HTTPS port 443 for monitoring purposes and blocks access to the phone’s internal web pages. This is the easiest approach, but it reduces the ability to monitor and maintain the endpoint, which means it is not a feasible solution for some environments. Another option is to restrict access to use HTTPS rather than HTTP. Using this secure protocol and ensuring CA-signed certificates are deployed on the endpoints ensure the traffic is trusted within the enterprise. Last, rather than disabling web access to the phones, a more common approach is to apply access control lists (ACLs) to the phone IP subnets to restrict access to approved networks.
PC Voice VLAN: Cisco phones, by default, forward all traffic received on the phone’s network switch port to the PC port. This setting can be disabled if desired. Disabling it can cause problems with applications connected via the PC port that use the voice VLAN.
Setting Access: Setting access can be either Enabled, Disabled, or Restricted. The default, Enabled, allows the end user to access the phone network configuration, ring type, and volume on the phone. When this setting is set to Restricted, only access to the user preferences and volume settings is available. When it is set to Disabled, setting access is completely disabled; no options appear when Settings is selected. Additionally, the ringer volume cannot be adjusted and volume settings cannot be saved. An option to restrict the network configuration settings of the endpoint while setting access is enabled is to configure the Common Phone Profile with a Local Phone Unlock Password. With this password configured (see Figure 8-1), end users can access the user preferences, but a password is required to access the Administrator settings on the device.
Figure 8-1 Local Phone Unlock Password
PC Port: Disabling the PC port should be common practice on endpoints where it is not needed; typically, this would be a lobby or courtesy phone. An extra step to take with devices like this and in general is to use 802.1x for network authentication or even a restricted data VLAN that does not allow network connectivity. This way, if someone unplugs the phone and attempts to connect, that user still does not have network access.
Other settings can be considered when identifying what to configure to lock down an endpoint, such as video calling, speakerphone, and SSH access. Consider where the endpoint will be located and what features are required. If video calling is enabled, is there any sensitive information that might be inadvertently shared? If so, disable video calling or educate the end users to obscure or remove sensitive information when using video. The same process goes for speakerphone.
Secure Conferencing
In Chapter 7, “Encrypting Media and Signaling,” we described how to secure the signaling and media between endpoints, but what happens when you begin to use system features and services? Conferencing within Cisco Unified CM is handled by different components, depending on the conference type being invoked. Endpoints can use built-in conferencing resources when features like barge are used. Cisco Unified CM itself has built-in software-based conferencing resources; however, this resource type cannot use SRTP, and it supports a combination of wideband or G.711 a-law and mu-law. External conferencing resources can be configured within Cisco Unified CM as either hardware or software based. This section covers the behavior and configuration of secure conferencing when hardware-based DSPs and software-based Cisco Meeting Server are used as external conferencing resources.
For a complete listing of the conferencing resources supported by Cisco Unified CM, review the relevant chapter in the System Configuration Guide for Cisco Unified Communications Manager by going to System Configuration > Configure Conference Bridges (see www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/12_5_1SU2/systemConfig/cucm_b_system-configuration-guide-1251su2/cucm_b_system-configuration-guide-for-cisco-1251su2_chapter_01100.html).
In a secure conference, all participating endpoints have encrypted signaling and media. Just like between endpoints, a secure conference uses SRTP encryption over a TLS or IPsec connection. Common conference types are ad hoc, Meet-Me, and barge. Depending on the conference type invoked, the behavior of the conference can change based on the security status of the participants.
An encrypted conference can revert to authenticated or nonsecure if an authenticated or nonsecure participant connects to the call. To illustrate this behavior, a secure conference that includes three encrypted connections and one authenticated connection has a conference security status of authenticated. If the authenticated connection drops, the conference transitions to being encrypted. A nonsecure participant who connects to a conference call renders the conference nonsecure. A conference status can also change in several scenarios like when participants chain conferences together, when a held conference call is resumed on another device, when a conference call gets barged, or when a transferred conference call completes to another device.
When an encrypted phone connects to a secure conference bridge, the media streaming between the device and the conference bridge gets encrypted; however, the icon for the conference can be encrypted, authenticated, or nonsecure depending on the security levels of the other participants. A nonsecure status indicates that one of the parties is not secure or cannot be verified.
Cisco endpoints indicate the security status of a conference by displaying a security icon for the security level of the entire conference. The icon is the same status icons used for a secure two-party call.
A lock icon is displayed when the conference bridge is secure and all participants in the conference are encrypted.
Older phone models like the 79XX display a shield icon when the conference bridge is secure and at least one of the participants is authenticated. The newer model phones like the 78XX and 88XX do not display this icon, and the call appears nonsecure.
Cisco enables you to verify and maintain the security level of a secure conference through two methods when traditional conferencing methods (DSPs, Unified CM Software Conference Bridges) are used. The first is with ad hoc conference lists. Using conference lists, the conference participants can see the list of participants and their associated security status. Figure 8-2 shows the display that a conference participant would see when a conference list is used. Participants in the conference with an undesired security status can be removed from the conference. The second method is with Meet-Me conferences with a minimum-security level.
Figure 8-2 Conference List Security Level
Ad Hoc Conferencing
An ad hoc conference is initiated when a user invokes the conference feature key or a call using a built-in bridge exceeds more than three participants and is escalated to use either Cisco Meeting Server or hardware DSPs. For this process, the digital certificates that are used should all be signed by the same enterprise CA to simplify the configuration steps.
Secure Conferencing Using Hardware-Based DSPs
Enabling secure conferencing with DSPs involves several steps:
Generate a certificate signing request (CSR) on the Cisco IOS gateway.
Sign the CSR by the enterprise certificate authority.
Import the certificate chain and signed device certificates.
Create the secure conferencing resource.
Associate the resource with the SCCP CCM group.
Configure the secure conference bridge in Cisco Unified CM.
For specific restrictions and prerequisites on enabling media and signaling encryption on DSP farm conferencing, refer to www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/itsdsp.html.
The first step in the process is to create the crypto key that will be used as part of generating the certificate. You accomplish this with the crypto key generate rsa modulus 2048 label <key> command. You can add the exportable keyword to the end of the command string to allow the certificates (public and private keys) to be exported from the system. It is recommended to export the keys that will have their public key certificates imported into other devices because in the event of a device failure, the exported keys can be imported back into the original device. By doing this, you do not have to request new certificates that then need to be uploaded to other devices. One thing to keep in mind is that if the keys are exported, it is imperative that they are stored in a secure location to prevent them from being compromised.
(config)# crypto key generate rsa modulus 2048 label Secure-DSP The name for the keys will be: Secure-DSP % The key modulus size is 2048 bits % Generating 2048 bit RSA keys, keys will be non-exportable... [OK] (elapsed time was 8 seconds)
With the key generated, the next task is to configure a trust point (see Example 8-1) and create the CSR. This trustpoint is used to store the digital certificates used on the DSP farm. The sequence of commands used is as follows:
crypto pki trustpoint: This command defines the trustpoint that the certificates will use and enters the CA-trustpoint configuration.
enrollment terminal: Enrollment of the certificates takes place at the command line.
serial-number none: This command specifies that a serial number is not included in the certificate request.
fqdn none: This command specifies a fully qualified domain name (FQDN) that is included as unstructuredName in the certificate. This is the FQDN of the router. The none keyword specifies that the FQDN is not included in the request.
ip-address none: This command specifies that an IP address is not to be included in the certificate request.
subject-name <x.500-name>: This command specifies the subject name in the certificate request.
revocation-check none: Certificate checking is not required.
rsakeypair <key>: This is the label used when the crypto key was generated.
hash {md5 | sha1 | sha256 | sha384 | sha512}: This command specifies the hash function for the signature that the Cisco IOS client uses. The use of md5 and sha1 is no longer recommended.
Example 8-1 Create Secure CFB Trustpoint
(ca-trustpoint)# crypto pki trustpoint Secure-CFB (ca-trustpoint)# enrollment terminal (ca-trustpoint)# serial-number none (ca-trustpoint)# fqdn none (ca-trustpoint)# ip-address none (ca-trustpoint)# subject-name CN=secure-cfb,OU=Cisco Press,O=Practical UC Security,L=RTP,ST=NC,C=US (ca-trustpoint)# revocation-check none (ca-trustpoint)# rsakeypair Secure-DSP (ca-trustpoint)# hash sha256
Next, you generate the CSR using the crypto pki enroll to generate command and display the CSR to the terminal session (see Example 8-2).
Example 8-2 Generate Secure CFB Certificate Signing Request
(ca-trustpoint)# crypto pki enroll Secure-DSP % Start certificate enrollment .. % The subject name in the certificate will include: CN=secure-cfb,OU=Cisco Press,O=Practical UC Security,L=RTP,ST=NC,C=US % The fully-qualified domain name will not be included in the certificate Display Certificate Request to terminal? [yes/no]: yes Certificate Request follows: MIIC2jCCAcICAQAwdDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk5DMQwwCgYDVQQH EwNSVFAxHjAcBgNVBAoTFVByYWN0aWNhbCBVQyBTZWN1cml0eTEUMBIGA1UECxML Q2lzY28gUHJlc3MxFDASBgNVBAMMC3NlY3VyZS1jZmJ+MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAu4y6PF4SOQ5Zs7Vs+fTQC8AoSo1w2cB/pOokHA4F oiCc3cbUkjmovgThKw0qFHfamv3QVHgG2ln0PBqugsWe9NycbyjkJBjDwvhf/kWp jW34bdZJBEOx9NMgGMifORH1tllrm6au2eY9kWSZxsa7ek2vP6oR3sKsBVMgGcHC 5QJu2YeKvwy1IIfdShhhNXBu14gKNq52RH3gXkt/s8eqhtAH8uRltjgVIbLovHIG 6mYfOVVtveVno+zOU4gFtmaTl7ZWKnTvJqa8D8WIp8+WOv5VlaW1yHrOHRjp3y6w yeN+ls1dSLwlTMjTAKpXtdl8ST/01W5uoe/xAIw2aTZxkQIDAQABoCEwHwYJKoZI hvcNAQkOMRIwEDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAHme KAdNqSASJ/4+NoaQXBm01thPEFtfBJkVhu0aPdIzQJ3dcgflNheU09yO8jrzogZY sCxxSkWtWS+XNRaGPhJXJHrrk/y54U5w1GiiSWQY98zrd+MSpoaRzX4TTpHXUk4t hwuTbEYnaj5z9M3Qgut+qnct43HHwDpcCEknKiIEIrhDb9zfQB+4J9wgz++ZZDgi Uh+EmPkXUuDX+VxSBIslsSbrFRjMfHEbLPnq5TkCcPnHH+1ob77oFF9i6TTJAAzO ubrpQPBOK2A1GG7bmNxx9+pGa5XSwq0/LlsSlMAHmBGGY5/iOerODtEEX+Qe5NF3 /s6QyFqzzPdhaCWxc0A= ---End - This line not part of the certificate request--- Redisplay enrollment request? [yes/no]: no
You can copy the text that comes after Certificate Request follows:.
Cisco IOS does not include the standard begin and end certificate request lines. It is recommended that you add those headers when saving the file. Example 8-3 shows the final output of the CSR with the header and footer additions.
Example 8-3 Certificate Signing Request Example
-----BEGIN CERTIFICATE REQUEST----- MIIC2jCCAcICAQAwdDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk5DMQwwCgYDVQQH EwNSVFAxHjAcBgNVBAoTFVByYWN0aWNhbCBVQyBTZWN1cml0eTEUMBIGA1UECxML Q2lzY28gUHJlc3MxFDASBgNVBAMMC3NlY3VyZS1jZmJ+MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAu4y6PF4SOQ5Zs7Vs+fTQC8AoSo1w2cB/pOokHA4F oiCc3cbUkjmovgThKw0qFHfamv3QVHgG2ln0PBqugsWe9NycbyjkJBjDwvhf/kWp jW34bdZJBEOx9NMgGMifORH1tllrm6au2eY9kWSZxsa7ek2vP6oR3sKsBVMgGcHC 5QJu2YeKvwy1IIfdShhhNXBu14gKNq52RH3gXkt/s8eqhtAH8uRltjgVIbLovHIG 6mYfOVVtveVno+zOU4gFtmaTl7ZWKnTvJqa8D8WIp8+WOv5VlaW1yHrOHRjp3y6w yeN+ls1dSLwlTMjTAKpXtdl8ST/01W5uoe/xAIw2aTZxkQIDAQABoCEwHwYJKoZI hvcNAQkOMRIwEDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAHme KAdNqSASJ/4+NoaQXBm01thPEFtfBJkVhu0aPdIzQJ3dcgflNheU09yO8jrzogZY sCxxSkWtWS+XNRaGPhJXJHrrk/y54U5w1GiiSWQY98zrd+MSpoaRzX4TTpHXUk4t hwuTbEYnaj5z9M3Qgut+qnct43HHwDpcCEknKiIEIrhDb9zfQB+4J9wgz++ZZDgi Uh+EmPkXUuDX+VxSBIslsSbrFRjMfHEbLPnq5TkCcPnHH+1ob77oFF9i6TTJAAzO ubrpQPBOK2A1GG7bmNxx9+pGa5XSwq0/LlsSlMAHmBGGY5/iOerODtEEX+Qe5NF3 /s6QyFqzzPdhaCWxc0A= -----END CERTIFICATE REQUEST-----
Now you need to save this output to a text file and submit it to the enterprise CA to request the digital certificate for the DSP farm. When the digital certificate is signed by the CA, ensure that it is collected in Base 64 format. This allows the digital certificates to be easily imported into the Cisco router housing the DSP farm. Additionally, ensure that the root and all the intermediate digital certificates are downloaded because they need to be uploaded to build the chain of trust for the DSP farm’s digital certificate.
One way to verify the signing and root certificates for your certificate is by opening the certificate. In Windows, you can save the certificate with a .cer extension, and after it is opened, navigate to the tab titled Certification Path. The certificates used to sign the device’s digital certificate are shown on this tab (see Figure 8-3).
Figure 8-3 Digital Certificate > Certification Path
Next, you need to create the trustpoint to be used by the enterprise CA signing certificates.
(config)# crypto pki trustpoint CiscoPUCS-CA-Root (ca-trustpoint)# enrollment terminal (ca-trustpoint)# revocation-check none
Once the trustpoint is created, the Intermediate certificate (issuer of the device certificate) must be authenticated to the trustpoint that was initially created (Secure-DSP). This step should happen before authenticating the root certificate to the enterprise CA trustpoint that was just configured (CiscoPUCS-CA-Root).
Now you can start by authenticating the enterprise CA intermediate certificate that signed the actual certificate for the secure DSPs by using the crypto pki authenticate <trustpoint name> command, as shown in Example 8-4. A successful import reflects “% Certificate successfully imported” at the end of the command output.
Example 8-4 Authenticate Intermediate CA into the IOS Trustpoint
(ca-trustpoint)# crypto pki authenticate Secure-DSP
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
-----BEGIN CERTIFICATE-----
MIIFezCCBGOgAwIBAgITHAAAAANnNT673RXs3wAAAAAAAzANBgkqhkiG9w0BAQsF
ADBWMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJY2lzY29w
dWNzMSQwIgYDVQQDExtjaXNjb3B1Y3MtQUQtRE5TLUNBLUVYQ0gtQ0EwHhcNMTkx
MTI4MDI1MzQ3WhcNMjExMTI4MDMwMzQ3WjBNMRMwEQYKCZImiZPyLGQBGRYDY29t
MRkwFwYKCZImiZPyLGQBGRYJY2lzY29wdWNzMRswGQYDVQQDExJjaXNjb3B1Y3Mt
U1VCQ0EtQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCffj2/PZar
0jPzhgvhs3BFe8SrD1ip0nFqhXyVqG74rc9WWv7/Uirx7AWiafIOqDiGrm1TFif4
00Tio/FeRmyyB0ESJqt10oJ8oQoi1T904ixrscV3z1Z2YMVcCFZMdFHuHF6Cfqkx
wlOy35ZE0yaVUyb/VXmWs7zQvqlC4zvkmbkfO0YYhnYKMlRcmj93TG6mmxZvP7Na
CIX2UyzBXJTvoByMNCa28W7AiL6YapeWvi+zhZjEnJxUyWw8+KYy6ciYPgyDgYBl
SVxdBpxYx0+KZvXhvlhZ8621aDF2Lo5/4BytPqq8c4KwzR0pmlG3a3B5uUXGlDgC
5pSyBRa3u0CNAgMBAAGjggJJMIICRTAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4E
FgQUBTp/bxDf6thaIRyE8TWjxthdkN4wGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBD
AEEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAU
4FH/CNl0I4JIkCo8SrvQVRDFsqQwgeIGA1UdHwSB2jCB1zCB1KCB0aCBzoaBy2xk
YXA6Ly8vQ049Y2lzY29wdWNzLUFELUROUy1DQS1FWENILUNBLENOPUFELUROUy1D
QS1FeGNoLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2
aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNpc2NvcHVjcyxEQz1jb20/Y2VydGlm
aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1
dGlvblBvaW50MIHPBggrBgEFBQcBAQSBwjCBvzCBvAYIKwYBBQUHMAKGga9sZGFw
Oi8vL0NOPWNpc2NvcHVjcy1BRC1ETlMtQ0EtRVhDSC1DQSxDTj1BSUEsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv
bixEQz1jaXNjb3B1Y3MsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RD
bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBCwUAA4IBAQBQ
cDozmao6c+W4CxWZ9eSmZeAQJ5tL85UI3PLeb6MCMuFpdXguXksGnE2/P2p1P+qI
5VSEb3PbTsndu69u/kv30QsvqICI1h8EXtp93Q/wbsPoSuwxHVDTN6LVGKjwnZbi
NbNN5pLwjArZvQBL4DFHOybiK2vGK86RgcVcMbSpXL2fx2lkZKGUqvb0w/80hW7u
2L2iXUn4u4YSljPd/bak/fcwv+PBFonRKJ9CpRvrrOIN1Z055l1Zxiu7BJfuIthr
5guHuCYWzxB7ZejiMF/V37j0EalvPkHeFvDBHI8mfKph4BGjgoUd2pbCumd7aRJK
ldeGtC4Hu3g2H4oVv8aG
-----END CERTIFICATE-----
Certificate has the following attributes:
Fingerprint MD5: BAC09690 17AB5389 723B540D 77CE2FF5
Fingerprint SHA1: 037EE4BB 4547C089 CD36F95C B9A805DC F139CC6C
Certificate validated - Signed by existing trustpoint CA certificate.
Trustpoint CA certificate accepted.
% Certificate successfully imported
Now you authenticate the enterprise CA root certificate by using the crypto pki authenticate <trustpoint name> command, as shown in Example 8-5.
Example 8-5 Authenticate Root CA in to IOS Trustpoint
(ca-trustpoint)# crypto pki authenticate Secure-DSP
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
-----BEGIN CERTIFICATE-----
MIIFezCCBGOgAwIBAgITHAAAAANnNT673RXs3wAAAAAAAzANBgkqhkiG9w0BAQsF
ADBWMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJY2lzY29w
dWNzMSQwIgYDVQQDExtjaXNjb3B1Y3MtQUQtRE5TLUNBLUVYQ0gtQ0EwHhcNMTkx
MTI4MDI1MzQ3WhcNMjExMTI4MDMwMzQ3WjBNMRMwEQYKCZImiZPyLGQBGRYDY29t
MRkwFwYKCZImiZPyLGQBGRYJY2lzY29wdWNzMRswGQYDVQQDExJjaXNjb3B1Y3Mt
U1VCQ0EtQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCffj2/Pzar
0jPzhgvhs3Bfe8SrD1ip0nFqhXyVqG74rc9WWv7/Uirx7AwiafIOqDiGrm1Tfif4
00Tio/FeRmyyB0ESJqt10oJ8oQoi1T904ixrscV3z1Z2YMVcCFZMdFHuHF6Cfqkx
wlOy35ZE0yaVUyb/VXmWs7zQvqlC4zvkmbkfO0YYhnYKMlRcmj93TG6mmxZvP7Na
CIX2UyzBXJTvoByMNCa28W7AiL6YapeWvi+zhZjEnJxUyWw8+Kyy6ciYPgyDgYBl
SvxdBpxYx0+KZvXhvlhZ8621aDF2Lo5/4BytPqq8c4KwzR0pmlG3a3B5uUXGlDgC
5pSyBRa3u0CNAgMBAAGjggJJMIICRTAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4E
FgQUBTp/bxDf6thaIRyE8TWjxthdkN4wGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBD
AEEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAU
4FH/CNl0I4JikCo8SrvQVRDFsqQwgeIGA1UdHwSB2jCB1zCB1KCB0aCBzoaBy2xk
YXA6Ly8vQ049Y2lzY29wdWNzLUFELUROUy1DQS1FWENILUNBLENOPUFELUROUy1D
QS1FeGNoLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2
aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNpc2NvcHVjcyxEQz1jb20/Y2VydGlm
aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1
dGlvblBvaW50MIHPBggrBgEFBQcBAQSBwjCBvzCBvAYIKwYBBQUHMAKGga9sZGFw
Oi8vL0NOPWNpc2NvcHVjcy1BRC1EtlMtQ0EtRVhDSC1DQSxDTj1BSUEsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv
bixEQz1jaXNjb3B1Y3MsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RD
bGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqGSIb3DQEBCwUAA4IBAQBQ
cDozmao6c+W4CxWZ9eSmZeAQJ5tL85UI3Pleb6MCMuFpdXguXksGnE2/P2p1P+qI
5VSEb3PbTsndu69u/kv30QsvqICI1h8Extp93Q/wbsPoSuwxHVDTN6LVGKjwnZbi
NbNN5pLwjArZvQBL4DFHOybiK2vGK86RgcVcMbSpXL2fx2lkZKGUqvb0w/80hW7u
2L2iXUn4u4YsljPd/bak/fcwv+PBFonRKJ9CpRvrrOIN1Z055l1Zxiu7BjfuIthr
5guHuCYWzxB7ZejiMF/V37j0EalvPkHeFvDBHI8mfKph4BgjgoUd2pbCumd7aRJK
ldeGtC4Hu3g2H4oVv8aG
-----END CERTIFICATE-----
Certificate has the following attributes:
Fingerprint MD5: BAC09690 17AB5389 723B540D 77CE2FF5
Fingerprint SHA1: 037EE4BB 4547C089 CD36F95C B9A805DC F139CC6C
Certificate validated – Signed by existing trustpoint CA certificate.
Trustpoint CA certificate accepted.
% Certificate successfully imported
The last step is to import the device’s certificate by using the crypto pki import <trustpoint name> certificate command. The command output is shown in Example 8-6.
Example 8-6 Import Identity Certificate for the Secure DSPs
(config)# crypto pki import Secure-DSP certificate % The fully-qualified domain name will not be included in the certificate Enter the base 64 encoded certificate. End with a blank line or the word "quit" on a line by itself -----BEGIN CERTIFICATE----- MIIFeDCCBGCgAwIBAgITWAAAABrCsLGV0iRyUQAAAAAAGjANBgkqhkiG9w0BAQsF ADBNMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJY2lzY29w dWNzMRswGQYDVQQDExJjaXNjb3B1Y3MtU1VCQ0EtQ0EwHhcNMjAwNjA1MDMzODQ2 WhcNMjExMTI4MDMwMzQ3WjB0MQswCQYDVQQGEwJVUzELMAkGA1UECBMCTkMxDDAK BgNVBAcTA1JUUDEeMBwGA1UEChMVUHJhY3RpY2FsIFVDIFNlY3VyaXR5MRQwEgYD VQQLEwtDaXNjbyBQcmVzczEUMBIGA1UEAwwLc2VjdXJlLWNmYn4wggEiMA0GCSqG Sib3DQEBAQUAA4IBDwAwggEKAoIBAQC7jLo8XhI5DlmztWz59NALwChKjXDZwH+k 6iQcDgWiIJzdxtSSOai+BOErDSoUd9qa/dBUeAbaWfQ8Gq6CxZ703JxvKOQkGMPC +F/+RamNbfht1kkEQ7H00yAYyJ85EfW2Wwubpq7Z5j2RZJnGxrt6Ta8/qhHewqwF ***Output Omitted*** gcUwgcKggb+ggbyGgblsZGFwOi8vL0NOPWNpc2NvcHVjcy1TVUJDQS1DQSxDTj1z dWJjYSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj ZXMsQ049Q29uZmlndXJhdGlvbixEQz1jaXNjb3B1Y3MsREM9Y29tP2NlcnRpZmlj YXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludDCBxgYIKwYBBQUHAQEEgbkwgbYwgbMGCCsGAQUFBzAChoGmbGRhcDov Ly9DTj1jaXNjb3B1Y3MtU1VCQ0EtQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y2lzY29w dWNzLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTAhBgkrBgEEAYI3FAIEFB4SAFcAZQBiAFMAZQByAHYA ZQByMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA0GCSqGSIb3DQEBCwUAA4IBAQBHsNpF BpiIuUPJfuFQrJegU2zMUKTvSk2OksTmvskhuYaQ1c1gPYX4KpXmqclkJ9EyjtLc tuj+lelBAsfT16gInmXm2dUjh8kJTgj8eB6Dj5810SxupLQvRcrUMcjRwT3owBRd LvPh1LobG3GrPvw8Q78QD9ErsUHuDbFk9dvVmYR83KgVLDWyPPyyRTxNXg86sr2V 8m31zss6uziXkhGNjP89idnVHkJa7Qcjt2A0RaMHMBYJPNaec27/1CixcM4T7WQ0 qxmhs74m1Ib888ll2wYKtbw/aAm3G5p1xJ4j0gf87CfzokviisBWcQL02NxzIZqn 2L5HSJmcJSWUFmro -----END CERTIFICATE----- % Router Certificate successfully imported
The certificates can be verified with the show crypto pki certificates <trustpoint name> command shown in Example 8-7. For troubleshooting purposes, this command would provide useful information to verify that the proper certificates are being used (serial number) and that the name used to register the conference bridge is correct (Subject Name).
Example 8-7 Show Certificate Chain of Trust
# show crypto pki certificate Secure-DSP
Certificate
Status: Available
Certificate Serial Number (hex): 580000001AC2B0B195D224725100000000001A
Certificate Usage: General Purpose
Issuer:
cn=ciscopucs-SUBCA-CA
dc=ciscopucs
dc=com
Subject:
Name: secure-cfb
cn=secure-cfb
ou=Cisco Press
o=Practical UC Security
l=RTP
st=NC
c=US
CRL Distribution Points:
ldap:///CN=ciscopucs-SUBCA-CA,CN=subca,CN=CDP,CN=Public%20Key%20Services,
CN=Services,CN=Configuration,DC=ciscopucs,DC=com?certificateRevocationList?base?
objectClass=cRLDistributionPoint
Validity Date:
start date: 23:38:46 est Jun 4 2020
end date: 22:03:47 est Nov 27 2021
Associated Trustpoints: Secure-DSP
CA Certificate
Status: Available
Certificate Serial Number (hex): 1C0000000367353EBBDD15ECDF000000000003
Certificate Usage: Signature
Issuer:
cn=ciscopucs-AD-DNS-CA-EXCH-CA
dc=ciscopucs
dc=com
Subject:
cn=ciscopucs-SUBCA-CA
dc=ciscopucs
dc=com
CRL Distribution Points:
ldap:///CN=ciscopucs-AD-DNS-CA-EXCH-CA,CN=AD-DNS-CA-Exch,CN=CDP,CN=Public%
20Key%20Services,CN=Services,CN=Configuration,DC=ciscopucs,DC=com?certificate
RevocationList?base?objectClass=cRLDistributionPoint
Validity Date:
start date: 21:53:47 est Nov 27 2019
end date: 22:03:47 est Nov 27 2021
Associated Trustpoints: Secure-DSP
Next, you need to configure the secure DSP resources. Currently, although IOS-based DSPs support secure transcoders and media termination points, they are not supported by Cisco Unified CM.
The first step in configuring the secure DSPs is to enable them. Using Example 8-8 as a reference, you use the voice-card <slot> and then dspfarm commands to enable the DSPs. The show dspfarm dsp command can be used to show the DSP status after they have been enabled.
Voice-card: Configure a specific voice card.
dspfarm: Enable the DSP farm feature for this voice card.
Example 8-8 Enable DSPFarm
(config)# voice-card 0 (config-voicecard)# dspfarm
A best practice when working with DSP resources is to include only the codecs that are used in the environment. This helps provide more sessions because the number of sessions available depends on the number of DSPs and the complexity of the enabled codecs. When secure resources are enabled, the maximum number of sessions is reduced to account for this feature being enabled.
You create the secure conference DSP resource by using the dspfarm profile <profile number> conference security command. The DSP farm profile specifies the codecs that the conference bridge supports, the maximum number of sessions, and the trustpoint used to secure the signaling and media. Most importantly, DSP farm profiles are shut down by default, so you need to enable them; otherwise, they never register.
(config)# dspfarm profile 1 conference security (config-dspfarm-profile)# trustpoint Secure-DSP (config-dspfarm-profile)# maximum sessions 10 (config-dspfarm-profile)# associate application SCCP (config-dspfarm-profile)# no shutdown
The last portion of the IOS configuration when enabling secure conferencing is to enable and configure SCCP. A reference for this is provided with Example 8-9. The configuration here is the same as a normal conference bridge where SCCP is bound to a local interface, the Unified CMs that SCCP communicates with are defined, and the DSP farm profile is associated with an SCCP CCM group.
The sequence of commands used is as follows:
sccp local interface-type interface-number: Selects the local interface that SCCP applications (transcoding and conferencing) use to register with Unified CM.
sccp ccm {ip-address | dns} identifier identifier-number: Specifies the Unified CM node that is configured within the Unified CM Group applied to the conference bridge. There should be an entry for each Unified CM node in the Unified CM group that is applied.
sccp: Enables the SCCP protocol and its related applications.
sccp ccm group group-number: Creates a Unified CM group and enters SCCP Unified CM configuration mode.
bind interface-type interface-number: Binds an interface to a Cisco Unified Communications Manager group.
associate ccm identifier-number priority priority-number: Associates a Unified CM with a Unified CM group and establishes the Unified CM’s priority within the group.
associate profile profile-identifier register device-name: Associates a DSP farm profile with a Unified CM group. The profile-identifier should be the same as the subject name (CN) field in the trustpoint.
Example 8-9 Secure Conference Bridge SCCP Configuration
(config)# sccp local GigabitEthernet0/0 (config)# sccp ccm 10.1.10.81 identifier 1 version 7.0 (config)# sccp ccm 10.1.10.82 identifier 2 version 7.0 (config)# sccp (config)# sccp ccm group 3 (config-sccp-ccm)# associate ccm 1 priority 1 (config-sccp-ccm)# associate ccm 2 priority 2 (config-sccp-ccm)# associate profile 1 register secure-cfb
The next portion of the configuration does not differ from the standard configuration to enable DSP-based resources. The only caveat is that the name used to register the conference bridge should be the common name (CN) of the device certificate. This is the same name used in Cisco Unified CM to register the conference bridge.
Now that the IOS voice gateway has been configured, the next phase is to configure the conference bridge in Cisco Unified CM. In Cisco Unified CM, you navigate to the Cisco Unified CM Administration GUI and select Media Resources > Conference Bridge. The new secure conference bridge is created as an IOS Enhanced Conference Bridge.
When the conference bridge is configured, the device security mode should be set to Encrypted Conference Bridge. This setting allows a conference to be encrypted, authenticated, or nonsecure based on the lowest security level of the participants.
When it is saved, the conference bridge should reflect a valid registration status (see Figure 8-4).
Figure 8-4 Cisco Unified CM Secure Conference Bridge Creation
The show sccp command can also be run from the IOS voice gateway to verify the current registration status of the conference bridge and whether it is encrypted (see Example 8-10).
Example 8-10 Verify SCCP State and CFB Status
# show sccp
SCCP Admin State: UP
Gateway Local Interface: GigabitEthernet0/0
IPv4 Address: 10.1.10.6
Port Number: 2000
IP Precedence: 5
User Masked Codec list: None
Call Manager: 10.1.10.82, Port Number: 2000
Priority: N/A, Version: 7.0, Identifier: 3
Trustpoint: N/A
Call Manager: 10.1.10.81, Port Number: 2000
Priority: N/A, Version: 7.0, Identifier: 2
Trustpoint: N/A
Call Manager: 10.1.10.80, Port Number: 2000
Priority: N/A, Version: 7.0, Identifier: 1
Trustpoint: N/A
Conferencing Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: 10.1.10.80, Port Number: 2443
TCP Link Status: CONNECTED, Profile Identifier: 1
Security
Signaling Security: ENCRYPTED TLS
Media Security: SRTP
Supported crypto suites: AES_CM_128_HMAC_SHA1_32
Reported Max Streams: 80, Reported Max OOS Streams: 0
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: g729br8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30
Supported Codec: rfc2833 pass-thru, Maximum Packetization Period: 30
Supported Codec: inband-dtmf to rfc2833 conversion, Maximum Packetization Period: 30
TLS : ENABLED
Secure Conferencing Using Cisco Meeting Server
Starting with Cisco Unified CM version 10.5, the ability to leverage Cisco’s Meeting Server platform for ad hoc resources has reduced the cost of implementing ad hoc resources and greatly expanded the capacity of available conferencing resources.
This section covers enabling Meeting Server as a secure ad hoc conferencing resource. Although the design and clustering of Meeting Server are beyond the scope of this book, Chapter 10, “Securing Cisco Meeting Server,” does provide the foundational information needed to secure Cisco Meeting Server that is deployed in a clustered environment. For this example, Meeting Server is configured as a single-server deployment.
There are two phases to configuring Meeting Server to act as an ad hoc conferencing resource in Cisco Unified CM. The first step is to configure Meeting Server with a valid API user and certificates signed by the enterprise CA for call bridge and web admin. The second phase is to configure the Meeting Server in Cisco Unified CM as a conference bridge with a SIP trunk from Cisco Unified CM to Meeting Server.
To start the configuration of Meeting Server, you need to generate CA-signed certificates that have both server and client authentication for enhanced key usage. Depending on the specific IT security policy, separate certificates for each service (call bridge/web admin) may be required. In most instances, though, a single combined certificate suffices and reduces the complexity of the deployment. These steps are provided for reference because the use of certificates to secure the signaling, media, and traffic is considered a prerequisite for this configuration. Chapter 10 provides a more robust explanation of the certificate generation process use cases and deployment for Meeting Server.
The first step here is to connect to the Mainboard Management Processor (MMP) in Meeting Server and issue the pki csr <file name> CN:<common name> subjectAltName:<subject alternative names> command. The common name should be the FQDN of the server that is resolvable via the DNS and IP addresses of the Meeting Server, and the subject alternate names should be the domain name and can contain other addresses or urls such as join.domain.com (assuming both web admin and call bridge use the same interface).
hq-adhoc-cms> pki csr secureconf CN:hq-adhoc-cms.ciscopucs.com subjectAltName:ciscopucs.com,10.1.10.94 .............. ..... Created key file secureconf.key and CSR secureconf.csr CSR file secureconf.csr ready for download via SFTP
This command creates .key and .csr files that are used to create the certificates for the services.
Next, you copy the .csr file from the Meeting Server using SFTP and submit it to the enterprise CA so that it can be signed.
Once the CSR has been signed, you collect the new digital certificate as a Base 64 along with the root and intermediate certificates in the certificate path. The services certificate should have .cer as its file extension for consistency.
The root and intermediate certificates must be combined (certbundle.cer) so that they can be uploaded to the Meeting Server with the services certificate. You accomplish this by opening the root and intermediate certificates with a text editor and copying and pasting the contents into a new file. The root certificate should be first, followed sequentially by the remaining intermediate certificates. The contents of the new bundled certificate should look like Example 8-11.
Example 8-11 CMS Combined Cert Bundle
-----BEGIN CERTIFICATE----- MIIDhzCCAm+gAwIBAgIQMAe3B21axIZGiqHmifSuNjANBgkqhkiG9w0BAQsFADBW MRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJY2lzY29wdWNz MSQwIgYDVQQDExtjaXNjb3B1Y3MtQUQtRE5TLUNBLUVYQ0gtQ0EwHhcNMTkxMTI3 MDMwMzEyWhcNMjQxMTI3MDMxMzEyWjBWMRMwEQYKCZImiZPyLGQBGRYDY29tMRkw FwYKCZImiZPyLGQBGRYJY2lzY29wdWNzMSQwIgYDVQQDExtjaXNjb3B1Y3MtQUQt RE5TLUNBLUVYQ0gtQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1 z73qVQqKAoZ2MjBHWw2gUDG5rO6xMIqHi4/IFTX2QGWC7cRtXMK3P02pTQa9pleO 5XdBO1jLUPytzo48kwJVO7Oq2gdd9uz8PxWgiblLxXGldKjD9X+Yl/6Hu70w+811 912RQ10Ae3IncTA+LbF8j8VNGPlQlzvSGNkRco4R/JAJNiKFw0LfccssTR+BIR8u QylU5dwQbAIoeQo6H+thSjN+VU3kjG8ve35z2hO8woucSz99vfkCHDw0FB3Xsg0T o0byehjZYKO+ZIrNTYZflfiMB3c0iCSi5udvniZm+lnVkmZD448/Vma6gA== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIFezCCBGOgAwIBAgITHAAAAANnNT673RXs3wAAAAAAAzANBgkqhkiG9w0BAQsF ADBWMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJY2lzY29w dWNzMSQwIgYDVQQDExtjaXNjb3B1Y3MtQUQtRE5TLUNBLUVYQ0gtQ0EwHhcNMTkx MTI4MDI1MzQ3WhcNMjExMTI4MDMwMzQ3WjBNMRMwEQYKCZImiZPyLGQBGRYDY29t MRkwFwYKCZImiZPyLGQBGRYJY2lzY29wdWNzMRswGQYDVQQDExJjaXNjb3B1Y3Mt U1VCQ0EtQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCffj2/PZar 0jPzhgvhs3BFe8SrD1ip0nFqhXyVqG74rc9WWv7/Uirx7AWiafIOqDiGrm1TFif4 00Tio/FeRmyyB0ESJqt10oJ8oQoi1T904ixrscV3z1Z2YMVcCFZMdFHuHF6Cfqkx wlOy35ZE0yaVUyb/VXmWs7zQvqlC4zvkmbkfO0YYhnYKMlRcmj93TG6mmxZvP7Na NbNN5pLwjArZvQBL4DFHOybiK2vGK86RgcVcMbSpXL2fx2lkZKGUqvb0w/80hW7u 2L2iXUn4u4YSljPd/bak/fcwv+PBFonRKJ9CpRvrrOIN1Z055l1Zxiu7BJfuIthr 5guHuCYWzxB7ZejiMF/V37j0EalvPkHeFvDBHI8mfKph4BGjgoUd2pbCumd7aRJK ldeGtC4Hu3g2H4oVv8aG -----END CERTIFICATE-----
You can save this file with any name, but the extension should be .crt, .cer, or .pem.
Now you upload the certificates to Meeting Server using SFTP and then apply the certificates to the two services, as shown in Example 8-12. First, you use the webadmin certs <key-file> <crt-file> <cert-bundle> command to apply the certificates to the web admin service. Then you use the callbridge certs <key-file> <crt-file> <cert-bundle> command to apply the certificates to the call bridge service.
Example 8-12 CMS Configure Webadmin PKI
hq-adhoc-cms> webadmin disable hq-adhoc-cms> webadmin certs combined.key combined.cer certbundle.cer hq-adhoc-cms> webadmin enable SUCCESS: TLS interface and port configured SUCCESS: Key and certificate pair match SUCCESS: certificate verified against CA bundle hq-adhoc-cms> callbridge certs combined.key combined.cer certbundle.cer hq-adhoc-cms> callbridge restart SUCCESS: listen interface configured SUCCESS: Key and certificate pair match SUCCESS: certificate verified against CA bundle
Cisco Unified CM dynamically creates ad hoc conferences in Meeting Server using APIs. Consequently, you need to create a new account that has the API role assigned to it:
hq-adhoc-cms> user add apiadmin api Please enter new password: Please enter new password again: Success
To ensure that the signaling and media of the ad hoc conference is secured, you need to enable SIP media encryption in Cisco Meeting Server (see Figure 8-5). You do so under Configuration > Call Settings and by selecting either Allowed or Required. If all endpoints will use SRTP, select the option for Required. If, however, you expect to have a mix of endpoints using SRTP and RTP, set the option to Allowed. The default setting of Disabled does not allow the media to be encrypted.
Figure 8-5 CMS SIP Media Encryption
The next phase of the configuration takes place in Cisco Unified CM and begins with uploading the services certificate that was just created in Cisco Meeting Server so that a chain of trust can be established. This step is optional, however, if the root and intermediate certificates are already present in the CallManager-trust certificate store. When the root and possibly intermediate certificates are present in Unified CM, you need to create an SIP trunk between Unified CM and Meeting Server. Lastly, you need to define the Meeting Server as a conference bridge in Cisco Unified CM.
Now you can log in to the Cisco Unified OS Administration and navigate to Security > Certificate Management. From here, you select Upload Certificate/Certificate Chain and upload the root and intermediate enterprise CA certificates that are not present in the CallManager-Trust store. You may need to repeat this process on each node in the Cisco Unified CM cluster if the certificates are not replicated from the Publisher to remaining nodes in the cluster.
After the services restart, log in to the Cisco Unified CM Administration GUI and create a new SIP Trunk Security Profile (System > Security > SIP Trunk Security Profile). This profile is applied to the SIP trunk used to communicate with the Meeting Server for ad hoc conferencing. Table 8-1 provides the recommended settings to configure on the SIP Trunk Security Profile.
Table 8-1 SIP Trunk Security Profile Configuration
SIP Trunk Security Profile Information |
|
Name* |
Meaningful profile name (e.g., Ad-Hoc-CMS) |
Description |
Useful profile description (e.g., Ad Hoc Conferencing Resources) |
Device Security Mode |
Encrypted |
Incoming Transport Type* |
TLS |
Outgoing Transport Type |
TLS |
Secure Certificate Subject or Subject Alternate Name |
FQDN of CMS callbridge |
Incoming Port* |
5061 (default value) |
Accept replaces header |
checked |
Figure 8-6 reflects the standard SIP Trunk Security Profile that is configured to support using Meeting Server as an ad hoc conference resource.
Figure 8-6 SIP Trunk Security Profile
Next, you navigate to Device > Trunk and select Add New to create a new SIP Trunk that points to Meeting Server. Select SIP Trunk from the Trunk Type drop-down. The default options SIP for Device Protocol and None for Trunk Service Type* do not need to be changed. In an enterprise UC environment, the standard SIP trunk configuration settings can be and should be very specific. Configuration settings like Device Pool, Location, and Incoming CSS are important, so you must ensure that these settings are consistent with the existing UC environment.
Figure 8-7 illustrates the areas of interest on the SIP Trunk to Meeting Server. For our purposes, the important settings are
Figure 8-7 Cisco Unified CM SIP Trunk Configuration
SRTP Allowed: When this box is checked, Encrypted TLS needs to be configured in the network to provide end-to-end security. Failure to do so exposes keys and other information.
Consider Traffic on This Trunk Secure*: Set to When using both sRTP and TLS.
Destination Address and Destination Port: This setting specifies the Meeting Server FQDN that will be used for ad hoc conferencing connecting on port 5061.
SIP Trunk Security Profile: This setting specifies the profile previously created that specifies encryption will be used on a TLS connection.
SIP Profile: This setting specifies SIP-specific settings and options to use.
Normalization Script: This setting provides a method of normalizing the SIP packets sent to Meeting Server. Current versions of Unified CM use the normalization script called cisco-meeting-server-interop. Depending on the version of Unified CM that you are working with, you may not have this normalization script. If this is the case, you can use the normalization script called cisco-telepresence-conductor-interop.
The Meeting Server ad hoc conference bridge is created by navigating to Media Resources > Conference Bridge and selecting Add New. The conference bridge type being created should be Cisco Meeting Server. The conference bridge is then configured with the recently created SIP Trunk and uses the web admin interface with the API user account that was created previously. The configuration here brings up an interesting point. When Cisco Meeting Server is used as an ad hoc conference resource, there are two secure connections between Unified CM and Cisco Meeting Server. The first is the SIP trunk itself, because the SIP Trunk Security Profile that was applied is configured for encryption. This means that the signaling is authenticated (TLS) and the data is encrypted (SRTP). The second is the API traffic that is used by the Cisco Meeting Server Conference Bridge is configured to communicate using HTTPS. Figure 8-8 shows the configuration of the Cisco Meeting Server Conference Bridge.
Figure 8-8 Configured Cisco Meeting Server Ad Hoc Conference Bridge
This next step is to identify the port that should be used for the conference bridge API. Depending on whether webrtc (web bridge) is enabled on the Meeting Server, you may need to use a different port for HTTPS. This is common practice to simplify the login process for the Cisco Meeting Web App or Cisco Meeting App. You can verify the port that is used by running the webadmin status command from the Meeting Server MMP.
hq-adhoc-cms> webadmin status Enabled : true TLS listening interface : a TLS listening port : 8443 Key file : combined.key Certificate file : combined1.cer CA Bundle file : certbundle.cer HTTP redirect : Disabled STATUS : webadmin running
Now that the Meeting Server conference bridge is configured, it can be added to the existing media resource groups and media resource group lists within the enterprise UC environment.
Meet-Me Secure Conferencing
Meet-Me conferences are static on-demand conferences that can be configured so that they require a minimum level of security. The device that initiates the Meet-Me conference must meet the required security level; otherwise, the conference will fail. If an endpoint tries to join the conference and does not meet the security level that is configured, the call will fail. A Meet-Me conference that is configured as nonsecure accepts all calls and has a status of nonsecure. Figure 8-9 shows the configuration of a Meet-Me conference with the minimum security level configured.
Figure 8-9 Authenticated Meet-Me Conference
Ad hoc conference: If a nonsecure or an authenticated ad hoc conference attempts to join an encrypted Meet-Me conference, the call will fail.
Barge: When a barge is attempted on a participant in a secured Meet-Me conference, the barge caller must meet the minimum-security requirements of the Meet-Me conference. When a nonsecure phone attempts to barge a call that is in authenticated Meet-Me conference, the barged device is downgraded, and both the device and the barged caller are dropped from the Meet-Me conference.
Shared line: A caller on a shared line that has connected to a Meet-Me conference with a configured minimum-security level restricts the other devices with the shared line. When a Meet-Me call is placed on hold, it cannot be resumed from a shared line unless the phone resuming the call meets the minimum-security level configured.
Conference Now
Conference Now can utilize secured conference bridges and can dynamically upgrade and downgrade the security level of the conference based on the participants. Unlike ad hoc conferencing, Conference Now does not provide a method to list the conference participants, but the overall conference status is displayed like a normal endpoint-to-endpoint call (see Figure 8-10).
Figure 8-10 Conference Now Security Level
Smart Licensing
Cisco has begun implementing Smart Licensing across its product portfolio to ease the burden that licensing customers have voiced over the years. This section covers some of the security considerations surrounding the information that Smart Licensing shares with Cisco and the methods available to implement Smart Licensing. Consult the following references to build a foundational understanding of Smart Software Licensing before continuing:
Cisco Smart Software Licensing: Overview and Deployment Options White Paper: www.cisco.com/c/en/us/products/collateral/software/smart-accounts/white-paper-c11-741659.html
Care and Feeding of Smart Licensing BRKARC-2034: www.ciscolive.com/global/on-demand:library.html?ssoToken=y9z15986237578780019dr8nn2&showMyInterest=true#/session/1542224299905001rWD6
Transitioning to Smart Licensing: Cisco Unified Communications Manager and Cisco Unity Connection 12.x BRKUCC-2725: www.ciscolive.com/global/on-demand-library.html?ssoToken=y9z15986237578780019dr8nn2&showMyInterest=true#/session/1542224335413001rk8J
From a simplified point of view, you can think of Smart Accounts as containers where Smart Licenses or traditional licenses can be deposited. This means that instead of licenses being issued to an individual Cisco Connection Online ID (CCO Id), they are issued at an organizational level. Because all Cisco products are moving to Smart Licensing, Smart Accounts will be required for all licensing eventually. Smart Accounts also allow customers to manage, move, store, and view software assets that they are entitled to.
How do Smart Accounts address security?
Utilization visibility: Smart Accounts enable you to see where licenses are being used and provide a way to audit usage to ensure licenses are used in the proper manner.
Improved self-management: Reduced overhead is needed to interact with the Cisco Global Licensing Organization when working with common tasks related to licenses.
Increased control: With Virtual Accounts, the customer can group licenses by technology, department, region, or other business requirement.
Improved compliance controls: Virtual Accounts enable you to verify license usage and break down the enabled features along virtual domains of control.
By default, a Smart Account has one Virtual Account named default. Virtual Accounts are used to organize licenses and can be defined to fit a company’s specific requirements. Virtual Accounts can be defined by region, line of business, or technology so that licenses can be grouped together to allow for easier management and utilization tracking.
User Access Control to a Smart Account and Virtual Account is controlled with four different user account types:
Smart Account Administrator: Able to edit the Smart Account, manage users, and perform overall license management
Smart Account User: Able to view licenses in the Virtual Account(s) but cannot create Virtual Accounts
Virtual Account Administrator: Able to edit Virtual Accounts and perform license management
Virtual Account User: Able to view and perform licensing activities for a specific Virtual Account
An example of these accounts in practical application is an individual or a group that is a Smart Account Administrator. This group can create Virtual Accounts, move licenses between Virtual Accounts, accept the EULA, and finally grant others rights within a Smart Account. Depending on the security policies and company size, it is possible that all users may be Smart Account Administrators. A more common scenario is that Virtual Account Administrators and users are also utilized. With these account types in use, a more granular UAC is available to the Smart Account Administrators. This allows them to provide users with only the access they require to perform their job functions.
What makes up a Smart Account, and how do devices communicate with Cisco? The key piece of software that devices communicate with for Smart Licensing is the Cisco Smart Software Manager (CSSM). The CSSM can be located either in the cloud (direct deployment) or an SSM located within the enterprise network using SSM On-Prem (mediated deployment). A final method, License Reservation (SLR), is also available; however, this method still requires interaction with CSSM upon initial deployment.
Direct deployment: This is the simplest of the deployment models for Smart Licensing. This method requires the end device to have access to the Internet directly or through a proxy. This method provides full functionality for Smart Licensed devices because they connect back to Cisco.com for license management. The infrastructure supporting the CSSM is located within the US, and user access is controlled through the management of the Smart Account and Virtual Account administrators.
Mediated deployment: For environments where the IT security policy doesn’t allow the UC infrastructure to communicate directly with the cloud SSM, Cisco has developed an on-premises version that provides the same functionality as the cloud version (see Figure 8-11). With SSM On-Prem, the communication with the cloud is centralized to the SSM On-Prem, and the internal UC infrastructure can in kind be configured to communicate with the SSM On-Prem. This scenario provides several advantages to user provisioning and the mapping of the local Virtual Accounts to the Virtual Accounts in the cloud. By using the SSM On-Prem, the accounts (users and Virtual Accounts) are local to the SSM On-Prem; they do not have to reside in the Cloud SSM. These users can create additional Virtual Accounts within the SSM On-Prem that are not visible to the Cisco Cloud SSM. By using this method, you can effectively hide the network information from Cisco and send limited information relating to license usage requirements.
Figure 8-11 SSM On-Prem Account to Cisco Virtual Account Relationship
License Reservations: License Reservation comes in two flavors: Specific License Reservation (SLR) and Permanent License Reservation (PLR). Cisco discourages you from using this type of licensing because it removes the software and license management capabilities that Smart Licensing makes available and node-locks the license to the device. License Reservation is expected to be used by governmental agencies and the military. Specifically, PLR is made available only to the military because it enables all functions available to the device permanently. While the other methods of licensing provide a self-service methodology, the License Reservation method removes that capability, so Cisco’s Global Licensing Organization must be engaged.
Regardless of the method used to communicate with CSSM, the connection is secured using TLS to ensure end-to-end encryption of the communication channel. The choice on which SSM to use is completely up to customers and their security requirements.
How does the use of SSM On-Prem help secure the UC environment? One easy answer is that it helps address common concerns about what data Cisco has access to when Smart Licensing is used. Cisco can collect seven different data sets but requires only three pieces of information to license a device:
Trusted Unique Identifier: This is the identifier used by both SSM and SSM On-Prem during the licensing process. It is a combination of the serial number and UUID.
Licenses Consumed: These are the license types and counts for each license type required for operation.
Organization Identifier (Token): This ID is used to associate the product to the specific account and Virtual Account.
The following data sets are included by default but can be disabled. Cisco does not track this information, and it is provided for customer reporting. The recommendation here is that when SSM On-Prem is used, this information is reported internally so that the data can be used in reports but disabled when connecting to CSSM.
Host name (Optional)
IP address (Optional)
MAC address (Optional): used in reporting for the customer
Other Smart Call home information (Optional)
Another benefit that SSM On-Prem provides is the ability to add local users to manage licenses that are separate from the users in CSSM. With SSM On-Prem, deployed users can be configured locally or imported from LDAP. Authentication for imported users can be handled through LDAP, OAUTH2 ADFS, and single sign-on (SSO).
While the CSSM never initiates communication with SSM On-Prem or a device directly registered to it, the communication must happen for the licenses to be synchronized and remain in compliance. With SSM On-Prem used as the registration point for the enterprise, it can either communicate automatically with CSSM or use a disconnected manual method. This manual method uses a sneaker net file transfer to synchronize with CSSM. This process works by generating a sync request from SSM On-Prem and then uploading the file to CSSM. CSSM then generates an account authorization file that is uploaded to the SSM On-Prem.
Ultimately, for those concerned with the information sent to Cisco to allow licensing to work, SSM On-Prem can perform basic network hiding from Cisco. This is accomplished with multiple local Virtual Accounts created on the SSM On-Prem; the local Default Virtual Account can be used to synchronize license usage between CSSM and the SSM On-Prem. When these aspects are taken into account, SSM On-Prem should be the primary tool used for monitoring and tracking license usage.
Summary
To recap, this chapter covered endpoint hardening, securing of conferencing resources, and Smart Licensing. Endpoint hardening is a layered approach where only the features and services necessary for an endpoint to function are enabled. The remaining unused features are either disabled or restricted. When you are hardening endpoints, start with Enterprise Phone Configuration settings to make configurations at a global level and then move to the Common Phone Profile and then the device to apply more specific settings at a site or device level. To secure conferences, you need to understand the different conference types. For example, you need to know when the built-in bridge within an IP phone is used to conference versus when a software or hardware conference resource is used. Simply enabling SRTP and TLS between endpoints does not provide a secure conference if the conference resource is not secure. The connections between the endpoint and the conference might be secure, but without the proper configuration, the conference itself might not be secured. In this chapter, you learned how the use of Smart Licensing affects the security of Cisco Unified CM and by extension the other Smart Licensed UC products. For Smart Licensing, you learned what components make it up and, in addition, you learned who needs a Smart Account and what Virtual Accounts are and when they should be used. The chapter also discussed which method of synchronization with CSSM makes sense for the UC environment: whether a direct connection to CSSM, a mediated deployment using SSM On-Prem, or something more traditional like License Reservation. Regardless of the method used to synchronize license usage, the connections always use TLS to encrypt the connections. Finally, you learned what information Cisco requires for a successful synchronization and how you can limit this information only to the required information.
Additional Resources
Security Guide for Cisco Unified Communications Manager, Release 12.5(1)SU2
Phone Hardening - https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/12_5_1SU2/cucm_b_security-guide-1251SU2/cucm_b_security-guide-1251SU2_chapter_01111.html
Secure Conference Resources Setup - https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/security/12_5_1SU2/cucm_b_security-guide-1251SU2/cucm_b_security-guide-1251SU2_chapter_010000.html?bookSearch=true
Cisco Collaboration System 12.x Solution Reference Network Designs (SRND) – Cisco Rich Media Conferencing - https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/confernc.html?bookSearch=true