Abstract. Avaya Solution & Interoperability Test Lab

Avaya Solution & Interoperability Test Lab Application Notes for Avaya Meeting Exchange Enterprise Edition 5.2 and Avaya Aura Messaging 6.2 using Transport Layer Security and Secure Real-time Transport Protocol with Third-party TLS Certificates - Issue 1.0 Abstract These Application Notes describe the steps to configure Avaya Meeting Exchange Enterprise Edition 5.2 and Avaya Aura Messaging 6.2 to use Transport Layer Security (TLS) to secure SIP signaling and Secure Real-time Transport Protocol (SRTP) to encrypt media with the default Avaya TLS identity certificates replaced by new certificates generated by a third-party Certificate Authority. Using TLS secures SIP signaling against interception and unwanted modification of SIP headers. SRTP protects the media portion of SIP calls from interception and recording by unauthorized parties. Replacing the default Avaya TLS certificates allows customers to uniquely define new identities for Avaya Meeting Exchange Enterprise Edition 5.2 and Avaya Aura Messaging 6.2, further enhancing security against unwanted connections. Avaya Aura Messaging is Avaya s next generation messaging product that allows users to flexibly manage their voicemail from easy to use interfaces. It offers new sophisticated capabilities and an enhanced user interface for increased flexibility and interactive collaboration between employees, partners and customers. Avaya Meeting Exchange Enterprise Edition 5.2 is a market-leading audio conferencing software solution optimized for IP networks. Avaya Meeting Exchange Enterprise Edition 5.2 integrates with Avaya Aura Communication Manager using open standard SIP protocols and supports a broad range of conference types. Information in these Application Notes has been obtained through Solution Integration compliance testing and additional technical discussions. Testing was conducted at the Avaya Solution and Interoperability Test Lab. 1 of 23

1. Introduction These Application Notes describe the configuration steps required to implement Transport Layer Security (TLS) for SIP signaling and Secure Real-time Transport Protocol (SRTP) for media security on Avaya Meeting Exchange Enterprise Edition 5.2 and Avaya Aura Messaging 6.2. TLS adds authenticity to SIP sessions by enabling clients and servers to exchange verifiable identity certificates (Mutual Authentication) prior to engaging in encrypted communications. This offers the following security advantages:- TLS prevents identity theft, where an interloper gains access by impersonating a trusted SIP endpoint in the network. TLS implements signaling encryption to overcome eavesdropping (packet sniffing) and man-in-the-middle attacks (intruder interrupting the dialog or modifying the signaling data) by negotiating a dynamically generated symmetric key and using ciphers to encrypt TLS handshakes. TLS uses X.509 certificates and cryptography to verify the identity of clients and servers, and to exchange a symmetric key (based on a shared secret) which encrypts data flowing between the parties across a network. X.509 identity certificates can be self-signed or signed by a Certificate Authority, the latter is an entity that issues digital certificates which confirm the ownership of a public key by the named subject of the certificate. TLS operates on top of the TCP network layer. To ensure ongoing security, the connection may be renegotiated periodically. SRTP is a variation of the standard RTP protocol with enhancements to provide message authentication and encryption, adding a layer of security to RTP. SRTP requires endpoints to agree on a cryptographic algorithm and to exchange keys prior to commencing transmission. Once secured, transmission is protected from replay attacks and alteration by unapproved sources. SRTP uses the AES cipher to encrypt and decrypt messages and the HMAC-SHA1 algorithm to authenticate the message and protect its integrity. Avaya Aura Messaging (AAM) is a feature rich voicemail solution offering sophisticated capabilities and an enhanced user interface. Features include Unified Messaging, Speech Auto Attendant, Voice recognition and text message/email notification of voicemails. Avaya Meeting Exchange Enterprise Edition 5.2 (MX) is an audio conferencing solution that uses SIP protocols to integrate with a communication network, providing enhanced features and support for event driven or ad-hoc conference types and supports integration with Lotus Sametime, Microsoft Live Meeting and Adobe Connect Professional. 2 of 23

2. Interoperability Testing These Application Notes focus primarily on securing AAM and MX SIP communications with TLS and SRTP in an Avaya Aura Communication Manager environment. Securing administration functions (e.g., web management) are also presented where it further enhances security. It is assumed the basic configuration steps necessary to integrate AAM and MX in the communications environment have already been completed. Applicable documents are listed in the Additional References section (Section 9) at the end of this document. Intended users of these Applications Notes should be familiar with Avaya installation procedures and necessary operating procedures. It is desirable to carry out procedures during a maintenance window as many configuration changes require restarting equipment and may result in a temporary loss of service. 2.1. Test Description and Coverage AAM test cases included forwarding of calls from internal and PSTN users to Avaya IP deskphones registered as SIP users on Session Manager (all using TLS and SRTP). Message notification, retrieval and deletion were also tested. MX test cases included ad-hoc conferencing, scheduled conferencing, in-conference features (presenter/chair modes, mute/drop participants). Dial-out to both internal and PSTN users was tested. 2.2. Test Results and Observations All test cases were successful. Meeting Exchange 5.2 does not support shuffling when SRTP is used; all testing was performed in a non-shuffled environment (i.e., direct media only). It was also noted the MX SRTP replay checking feature had to be disabled to get DTMF working for PSTN callers. See Section 6.3. 3 of 23

3. Reference Configuration The diagram below shows the test configuration used. Avaya Aura Messaging and Avaya Meeting Exchange TM are installed in an Avaya Aura communications infrastructure; with SIP proxy services provided by an Avaya Aura Session Manager and PBX features supplied by an Avaya Aura Communication Manager. Avaya IP Deskphone 9641 users have mailboxes configured on Avaya Aura Messaging, with the coverage feature on Communication Manager configured to route unanswered calls to Avaya Aura Messaging. User accounts were created on Meeting Exchange with a range of typical conferencing features. Figure 1: Avaya Meeting Exchange TM and Avaya Aura Messaging Reference Diagram 4 of 23

4. Equipment and Software Validated The following equipment and software were used for the sample configuration provided: Equipment/Software Avaya Aura System Manager on Avaya S8800 Server Avaya Aura Session Manager on Avaya S8800 Server Avaya Aura Communication Manager running on Avaya S8800 Server Avaya Meeting Exchange TM on Avaya S8800 Server Avaya Aura Messaging on Avaya S8800 Server Avaya 9641 IP Deskphone AudioCodes Mediant 3000 Media Gateway 3.0 Hewlett Packard Compaq 6000 Pro Microtower PC Release/Version Release 6.2 FP2 Version: 6.3.2.4.1399 Release 6.2 FP2 (6.3.2) Build 6.3.2.0.632023 Release 6.2 FP2 Version: 6.3.0.124.0-21000 5.2 SP2 plus Bridge Patch 5.2.2.19.1 Release 6.2 SP2 Avaya one-x Deskphone SIP Release 6.3.0 Build: 96x1-IPT-SIP-R6_3_092313 R3.0 Firmware Version 6.60A.026.001 Microsoft Windows Server 2008 R2 Enterprise SP1 x64 Active Directory Certificate Services Role 5 of 23

5. Configure Avaya Aura Messaging for TLS and SRTP This procedure will demonstrate how to configure AAM to use a third-party Root Certificate which will replace the default Avaya certificate used to authenticate endpoints during TLS handshake negotiations. In addition, the default AAM identity certificate will be replaced with a new identify certificate generated by the third-party Certificate Authority (CA). To ensure interoperation with other telecommunications endpoints, it is important to add (or replace) the new CA certificate on all SIP endpoints and on all other Avaya Aura components such as Session Manager and Communication Manager in the communications network. This procedure assumes basic AAM configuration has been carried out prior to implementing these steps. 5.1. Configure new Third-party Certificate on Avaya Aura Messaging Obtain a copy of the new third-party CA certificate from the telecommunications systems administrator. Use a Secure File Transfer Protocol (SFTP) client, such as Filezila or WinSCP, to connect to the AAM server IP address (using the administrator account). Copy the third-party Root CA Certificate from a local computer to the directory /var/home/ftp/pub on AAM. NextProject\Certs_PostApril2nd\ Certificates certificate.key third-party.pem certificate.cer certificate.pem third-party.pem Using a SSH terminal emulator application, (e.g., PuTTY), connect to AAM (not shown). Log into AAM using the administrator username and password. Enter the following command at the prompt: tlscertmanage I <third-party> </var/home/ftp/pub/third-party.pem> where <third-party> is a descriptive name for the new CA certificate and </var/home/ftp/pub/third-party.pem> is the full path and name of the.pem file copied from the local computer to AAM. This command adds the new CA certificate into the AAM certificates store. It must be activated before it will be used for TLS. 6 of 23

Logon to AAM using a web browser (Mozilla Firefox supported) and the administrator account (not shown). Select the Server (Maintenance) page from the Administration menu. From the side menu, select Security Trusted Certificates and then click Add. A new page opens. In the text box, enter the name of the CA.pem file previous installed (i.e., third-party.pem) and click the Open button. third-party.pem 7 of 23

The Trusted Certificates page opens. This page manages the installed trusted certificates and configures what services can use these certificates. Some information about the CA certificate is displayed, including Issued To, Issued By and Expiration Date. Type the third-party certificate name in the text box (third-party.pem) and check all the check boxes. When ready, click the Add button. rootca rootca third-party.pem The new trusted CA certificate is now added to AAM s trusted certificates store and has been configured to authenticate against all services. 8 of 23

5.2. Create a Certificate Signing Request for Avaya Aura Messaging The previous step added a new CA certificate to AAM. AAM also needs a new TLS identity certificate that is signed by the same CA. The new TLS identity certificate will be offered to clients/servers during TLS negotiations and will be authenticated by endpoints using their own root CA certificates. The first step is to generate a Certificate Signing Request (CSR) for AAM. Logon to the AAM Server using a web browser; select the Server (Maintenance) page from the Administration menu. On the side menu, select Security Certificate Signing Request. Click on the New Request button (not shown). The Certificate Signing Request Form opens. Complete the fields with appropriate values, as shown below. Select RSA Key size of 2048. Click the Generate Request button when ready. US Colorado Denver 9 of 23

A new page opens showing the CSR. Copy all the text from -----BEGIN CERTIFICATE REQUEST----- up to and including -----END CERTIFICATE REQUEST----- Copy the text to a text editor (e.g., Notepad) and save the file as aam_csr.pem. When ready, click the Continue button (not shown). The CSR is now ready for signing by a third-party CA. The signed CSR will later be imported into AAM to complete the procedure. 10 of 23

5.3. Sign the Avaya Aura Messaging Certificate Signing Request using a Third-party Root CA Server There are many variants of root CA servers; the following procedure uses a Microsoft root CA server. Using a web browser, logon to the root CA server. A typical URL might be as follows: https://<fqdn_of_certificate_server>/certsrv If the administrator has not logged in previously, an access error occurs and administrator is required to enter appropriate login credentials in a Windows Security dialog box. Press the OK button when ready. 192.168.1.142 The CA server home page opens. Click on the Request a certificate link. 11 of 23

On the next page (not shown), click the advanced certificate request link and a new page opens. Open aam_csr.pem created in Section 5.2 using Notepad and paste the contents into the Saved Request: text edit box ensuring all text is copied. In the Certificate Template: area, select an appropriate template (e.g., Webserver-Enterprise) from the drop-down menu. Click on the Submit > button. The Certificate Issued page opens. Ensure the Base 64 encoded radio button is checked. Click the Download certificate link, a file selector opens allowing the file to be saved. Save the file with a.cer extension and a descriptive name, e.g., aamsigned.cer. 12 of 23

5.4. Import the Signed Certificate into Avaya Aura Messaging Copy the signed certificate file aamsigned.cer to the /var//home/ftp/pub directory on AAM (see Section 5.1 for information on how to do this step). On the AAM Server, select the Server (Maintenance) page from the Administration menu. Select Security Server/Application Certificates. Click the Add button. In the next page (not shown), enter the name of the signed certificate file aamsigned.cer. Click the Open button. On the next page check all the Certificate Repositories and click Add. Restart the AAM Server to complete the certificate installation. rootca 13 of 23

5.5. Configure Avaya Aura Messaging Telephony Integration With new TLS certificates installed, AAM must be configured for TLS and SRTP (if not already done). The following procedure will show the important TLS and SRTP configuration settings. Using a web browser, logon to AAM (see Section 5.1) and select Messaging from the Administration drop down menu. Select Telephony Settings (Application) Telephony Integration. Configure the Basic Configuration values as shown in the red box. Ensure all ports are 5061. The IP addresses for Connection 1 and Connection 2 are the Session Manager(s) SM100 IP addresses. The SIP Domain value for both Messaging and Switch will be the same as the Session Manager SIP Domain. 2 192.168.1.64 192.168.1.66 192.168.1.133 14 of 23

Scroll down the page and click on the Show Advanced Options button (not shown). A new configuration area opens. Ensure Media Encryption is using the same encryption algorithm as Communication Manager and that Media Encryption During CapNeg is Enabled. Click the Save button when ready. Restart the AAM server. This completes configuration of Avaya Aura Messaging for TLS and SRTP with third-party certificates. 15 of 23

6. Configure Avaya Meeting Exchange TM for TLS and SRTP using Third-party Certificates Since Avaya Meeting Exchange TM 5.2 does not have a Web or GUI interface, configuration changes are made by editing text files and saving the new configuration to the MX server. The following procedure shows how to configure MX for TLS and SRTP using third-party certificates. 6.1. Add a Trusted Root Certificate to Avaya Meeting Exchange TM MX stores trusted root certificates in a certificate bundle (large flat file). To add a new certificate authority certificate, the certificate must be copied into the certificate bundle. Certificates trusted by MX are stored in /usr/local/ssl/certs/cacert.pem. If only one trusted root certificate is being used, the trusted root CA certificate can replace CAcert.pem. Obtain a copy of the root CA certificate used in Section 5.1 (third-party.pem) and open the file in a text editor (e.g., Notepad). Log into the MX command line interface using a SSH client (e.g., PuTTY or similar) using the craft account. Issue the command su sroot and enter the sroot password. Issue the command: vi /usr/local/ssl/certs/cacert.pem Paste the contents of third-party.pem to the bottom of the file. Alternatively, clear all text from CAcert.pem and paste third-party.pem into it. Save CAcert.pem. Restart MX bridge using the command: service bridge restart 16 of 23

6.2. Create new Private Keys and Generate a Certificate Signing Request for Avaya Meeting Exchange Log into MX Command Line interface as in Section 6.1 as craft and su to sroot. Copy the original certs and keys in /usr/local/ssl/certs to new files as backup using the following Linux commands: cd /usr/local/ssl/certs cp CliCert1.pem CliCert1.backup.pem cp ServCert1.pem ServCert1.backup.pem cp CliKey1.pem CliKey1.backup.pem cp ServKey1.pem ServKey1.backup.pem Create a new private key called CliKey1.pem with password CliKey1. Note: this is a default password and it must match the passphrase in the MX tlsdef.h header file. Create a CSR using CliKey1.pem private key. OpenSSL will be used to perform these actions, type the following at the command prompt: openssl req -out MXCert1.csr -new -newkey rsa:2048 -nodes -keyout CliKey1.pem Enter the various Certificate details when prompted (e.g., US, Colorado, Denver, etc.). Ensure the MX server FQDN is used for the common name. Enter a passphrase for the private key (take note of this). Create a new private key called ServKey1.pem with password ServKey1 (matching the passphrase in the header file) and create a CSR using ServKey1.pem private key: openssl req -out MXServCert1.csr -new -newkey rsa:2048 -nodes -keyout ServKey1.pem Enter the various Certificate details when prompted. There are two CSR s generated. Get both CSRs signed by the third-party CA, using the procedure described in Section 5.3. Copy the signed certs back into /usr/local/ssl/certs directory (using SFTP or similar) on MX and rename them as ServCert1.pem and CliCert1.pem. Restart the bridge using the service bridge restart command. 17 of 23

6.3. Configure Avaya Meeting Exchange TM for TLS and SRTP MX may already be configured for TLS and SRTP. Use the following procedure to verify the configuration files. Logon to MX using a SSH client (PuTTY or similar) and su sroot. Issue the command: vi /usr/ipcb/config/system.cfg Locate the following sections and ensure sips is being used, transport=tls and the port values is 5061. # request we will be listening to MyListener=sips:6000@192.168.1.124:5061;transport=tls # if this setting is populated will Overwrite the contact field in responses respcontact=sips:6000@192.168.1.124:5061;transport=tls Issue the command: vi /usr/ipcb/config/softmediaserver.cfg Locate the following section: #SRTP config Ensure the settings are as shown here. # [description: Whether or not SRTP should be used for audio streams. 0 = disabled 1 = enabled.] # [type: int] # [runtime: false] securityenabled=1 # [description: Encryption and Authentication algorithms to use for SRTP with RTP.] # [type: string] # [runtime: false] srtpcryptosuite=aes_cm_128_hmac_sha1_80 18 of 23

Issue the command: vi /usr/ipcb/config/audiopreferences.cfg Examine the list of codecs and ensure the values match the codecs offered by other SIP endpoints in the communications infrastructure. # audiopreferences.cfg # This table is an ordered list of MIME subtypes specifying the codecs # supported by this media server. The list is specified in the order in which # an SDP offer will list the various MIME subtypes on the m=audio line. # For static payload type numbers (i.e. numbers between 0-96) please use # the iana registered numbering scheme. # See: http://www.iana.org/assignments/rtp-parameters mimesubtype payloadtype Performance PCMU 0 10 PCMA 8 10 #G722 9 85 G729 18 118 #ilbc30 97 140 #ilbc20 98 140 #wbpcmu 102 10 #wbpcma 103 10 telephone-event 101 10 #isac 104 150 G726_16 105 54 #G726_24 106 54 #G726_32 107 54 #G726_40 108 54 Issue the command: vi /usr/ipcb/config/softmediaserver.cfg Add the following lines to the end of this file # disables the MX SRTP replay checking (wi01021987) srtppacketreplaychecking=0 Issue the command: service mx-bridge restart Verify PSN100178 has been applied to MX server. See Section 9 for more information. This completes configuration of Avaya Meeting Exchange TM for TLS and SRTP with third-party certificates. 19 of 23

7. Verification Steps 7.1. Avaya Aura Messaging Place a call from an internal station to another internal station. Allow the call to go to coverage. Confirm the call diverts to AAM and the mailbox prompts are correct. Leave a voice message for the user. On hang-up, confirm the called user s message waiting lamp illuminates. Using the called phone, place a call to AAM, login to the user s mailbox and listen to the message. Delete the voice mail, confirm the message waiting lamp extinguishes. Repeat the above sequence except place the call from a PSTN location. Logon to Avaya Aura Session Manager using a SSH client and the craft account. At the command line, enter the following command: tracesm uni dt (hit the enter key) Place a call to an internal station from a PSTN phone and allow it to go to coverage. Observe the outgoing call to AAM on the SIP trace. Confirm the call is using SIPS and the SDP contains information on cryptographic options. Logon to Avaya Aura Communication Manager using the SAT interface (craft account) and enter the following command: status trunk x (where x is the SIP trunk between Communication Manager and Session Manager). Page through the screens until the active trunk member is located. In the example below, member 0002/032 is active. status trunk 2 Page 3 TRUNK GROUP STATUS Member Port Service State Mtce Connected Ports Busy 0002/029 T00035 in-service/idle no 0002/030 T00036 in-service/idle no 0002/031 T00037 in-service/idle no 0002/032 T00038 in-service/active no T00050 20 of 23

Issue the command status trunk 0002/032 and scroll to Page 3. Observe the SRTP encryption scheme in use, it should be as configured in Section 5.5. status trunk 0002/032 Page 3 of 3 SRC PORT TO DEST PORT TALKPATH src port: T00038 T00038:TX:192.168.187.37:35010/g711u/20ms/1-srtp-aescm128-hmac80 T00050:RX: 192.168.187.120:37118/g711u/20ms/1-srtp-aescm128-hmac80 7.2. Avaya Meeting Exchange TM Using a selection of stations (internal and PSTN), dial into a conference. Confirm all users can hear each other and that bridge functions such as mute work. Logon to Avaya Aura Communication Manager using the SAT interface (craft account) and enter the following command: status trunk x (where x is the SIP trunk between Communication Manager and Session Manager). Page through the screens until the active trunk member is located. In the example below, member 0002/032 is active. status trunk 3 Page 3 TRUNK GROUP STATUS Member Port Service State Mtce Connected Ports Busy 0003/11 T00007 in-service/idle no 0003/12 T00008 in-service/active no T00015 Issue the command status trunk 0003/032 and scroll to Page 3. Observe the SRTP encryption scheme in use; it should be as configured in Section 6.3. status trunk 0002/032 Page 3 of 3 SRC PORT TO DEST PORT TALKPATH src port: T00038 T00012:TX:192.168.187.37:35010/g711u/20ms/1-srtp-aescm128-hmac80 T00015:RX: 192.168.187.120:37118/g711u/20ms/1-srtp-aescm128-hmac80 21 of 23

8. Conclusion These Application Notes describe how to configure Avaya Aura Messaging and Avaya Meeting Exchange TM to use Transport Layer Security and Secure Real-time Transport Protocol as a security enhancement for networks that require high immunity from message interception and modification. One issue was found with Avaya Meeting Exchange TM and DTMF from PSTN callers, see Section 2.2 for details. 9. Additional References Further Avaya Product documentation relevant to these Application Notes may be available at http://support.avaya.com. [1] Administering Meeting Exchange Servers Release 5.2.2 February 18, 2013 04-603708 Issue 1. [2] Configuring Avaya Aura System Manager 6.2 FP2 and Avaya Aura Session Manager 6.2 FP2 to use Third-Party Security Certificates for Transport Layer Security. [3] Administering Avaya Aura Messaging Release 6.2 Issue 2.2 December 2013 [4] Administering Avaya Aura System Manager Release 6.3 07 Oct 2013 [5] PSN100178 Oct 2013. See link below: https://support.avaya.com/public/index?page=content&id=psn100178&group=ug_public [6] RFC 5246 - The Transport Layer Security (TLS) Protocol - Available from http://www.ietf.org/ [7] RFC3711 - The Secure Real-time Transport Protocol (SRTP) - Available from http://www.ietf.org/ 22 of 23

Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by and are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners. The information provided in these Application Notes is subject to change without notice. The configurations, technical data, and recommendations provided in these Application Notes are believed to be accurate and dependable, but are presented without express or implied warranty. Users are responsible for their application of any products specified in these Application Notes. Please e-mail any questions or comments pertaining to these Application Notes along with the full title name and filename, located in the lower right corner, directly to the Avaya Solution & Interoperability Test Lab at interoplabnotes@list.avaya.com 23 of 23