Howto:Security works with innovaphone

Applies To

• all innovaphone devices

More Information

Security issues in VoIP installations become more and more important to customers. While innovaphone very early has implemented a security framework based on the H.235 standard for H.323 supporting authentication and message integrity, the need for encryption to enforce privacy more and more emerges as a requirement.

This paper discusses the existing mechanisms in the version 6,7,8 and 9 release.

Risks

Voice over IP applications are like all other data applications exposed to a number of security threats.

These threats can be categorized as follows

• Availability

• Privacy

• Integrity

• Authenticity

• Accountability

Availability

As all devices attached to a network, VoIP devices may be subject to attacks against the availability of their offered services.

Such so-called Denial of Service Attacks may be attempted using various strategies, including amongst others exploiting weaknesses of the implementation or legal but excessive use of offered resources.

Privacy

As with all communication systems, VoIP devices may be misused to disclose confidential information. With telephone systems, this obviously involves unauthorized access to voice conversations. Moreover, access to configuration data (such as registration accounts, passwords, and extension numbers) can be of interest to attackers as well as call data (such as time and source/destination of calls).

Integrity

The integrity of call signalling data as well as of the voice communication itself can be of utmost importance. Spoofing of calling party ids for example may be used to obtain unaccounted access to particular resources (such as long distance calls or special services). But also more subtle and non-obvious tampering with call signalling data like faking cause codes (signalling busy when the party in fact does not respond) etc. or silently changing a call destination may cause severe harm.

Security Features implemented in Version 6

innovaphone products today feature a number of security features.

This article provides a rundown of the essential features and how they are enabled.

Securing Configuration Data

All configurations for innovaphone devices are stored in local flash memory.

While access to the data through normal interfaces is password protected, the content can potentially be examined if an attacker has physical access to the device (this would require disassembly of the device and examination of the flash EPROM).

Whenever you pass a configured device to someone else (e.g. when selling it), you should keep this in mind. If this is a concern, erase the data before (see related articles below). Configuration data can be dumped to text format using the “Config show” command.

From version 5 on, the resulting text file does not contain any clear-text passwords. Still, remaining configuration information may be considered sensitive. So be careful when providing this information to 3rd parties.

Because passwords are encrypted in the config file, you will need to remember the admin password of the device being dumped in order to load it to another device later on.

Securing Access to Configuration Data

innovaphone devices are configured through a web based interface using HTTP or HTTPS access.

HTTP

For HTTP authentication, both basic authentication (which is not encrypted) as well as digest authentication is available. You should make sure the browser you are using supports digest authentication which allows for reasonable security against password snooping and man-in-the-middle attacks. There is an option to enforce digest authentication in the “General Settings” (in other words, to disable basic authentication).

However, since the PBX’s SOAP interface is based on HTTP too, all SOAP clients not supporting digest authentication (and the TAPI driver currently is such a client) would be disabled using this option.

innovaphone devices feature non-protected access to the devices home page.

This is convenient; however, it may reveal some critical information to random port scanners targeting a device from the Internet. You may thus choose to password protect even the home page using an option in the “General Settings” area.

By default, all HTTP clients can gain access to the device configuration provided they have the right password. However, there is an option to restrict HTTP access generally to a particular host or network. This option allows you to restrict all HTTP access (and thus administrative access too) e.g. to hosts from within your own LAN.

If remote configuration access is required though (which would be disabled by this setting), you may consider to setup an administrative PPTP (or PPP over ISDN) dial-in access to the device. Many innovaphone devices do support such kind of dial-in out of the box. You would then use the “assign remote IP address” option and assign a local ip address to the dial-in client. This way, remote configuration is still possible and additionally secured by the PPTP encryption layer.

Due to the computational overhead of HTTPS, HTTP payload traffic is not encrypted in innovaphone devices. If payload encryption is critical to you for administration access, make sure you configure an encrypted PPTP dial-in access for configuration as described above.

There is a legacy, telnet based access to the configuration layer. Telnet is inherently unsafe since it transfers unencrypted passwords. It is not recommended to use this. From build 04-5807 on, telnet access is disabled by default. Previous builds can disable telnet access by specifying “/port 0” on the TELNET0 config file line.

HTTPS

HTTPS is supported in the since Version 6 Service Release 2 (V6 SR2). RFC 2818 defines use of TLS (Transport Level Security, RFC 2246) to secure the HTTP protocol.

Managing Accounts

All administrative functions are secured by account names and passwords. It is strongly recommended neither to keep the default account nor the default password setting.

Access to VoIP resources

Access to VoIP resources (such as gatekeeper registrations and access to trunk lines) can be secured by account and password. If securing VoIP resources is an issue, make sure that all gatekeeper accounts are secured by a password. You may even want to consider disallowing any registration without password, even from within the local area network. This can be done in the “general settings” area of the PBX.

To protect your trunk lines from unintended access, make sure to configure all gateways (GWxx entries) properly. For gatekeeper type entries, make sure there is a password, for gateway type entries, make sure the configured netmask suits your needs. Double check all routing entries to avoid unintended access e.g. to trunk lines.

PPP and PPTP

When using built-in dial-in (PPP, PPTP) interfaces, PAP, CHAP, MS-CHAPv1 and Ms-CHAPv2 are supported. PAP by design does not allow for password encryption and is thus not recommended. The CHAP variations do support password encryption using MD4 and DES and are therefore reasonably secure.

There is no payload encryption available for PPP (that is, PPP over ISDN) and PPPoE (i.e. xDSL). However, using ISDN dialup, payload encryption is not really an issue.

PPTP however features powerful payload encryption in addition to password encryption. It is using SHA-1 for session key encryption and RC4 up to 128bit for payload encryption. If payload encryption is an issue to you, you should check the “enable encryption” flag in the PPTP configuration. Keep in mind that payload encryption incurs computational overhead and the number of concurrent PPTP session the device can handle is reduced. Using PPTP is an option if fully payload encrypted configuration access is a requirement (see above).

RAS Registrations

H323 user account passwords are obviously sensitive information. innovaphone devices feature RAS RegistrationRequest (RRQ) password encryption based on the H.235 standard (H.235v2 Annex D – Baseline Security Profile). By requiring knowledge of a shared secret on both ends, mutual authentication is provided by this mechanism.

H.225 Signalling

Based on the H.235 authentication (see above), H.225 signalling messages carry a signature which ensure message integrity in both directions. While message content may still be looked at and thus possibly sensitive information may be disclosed, this mechanism effectively disallows corruption of call, authentication and accounting data and renders man-in-the-middle attacks ineffective.

RTP

RTP (i.e. media stream) traffic is not encrypted with Version 6. However, media stream endpoints are negotiated securely (see above), so that content spoofing is made difficult.

SIP message security

The current SIP implementation features mutual digest authentication and a reasonable protection against spoofed identities, there is currently no message digest signature available in SIP messages. The integrity of SIP messages thus is not ensured as is the integrity of H.225 and RAS messages (see above).

SOAP Client account

SOAP clients (such as the TAPI driver or the Operator) require an account/password for authentication at the HTTP layer. Although the devices admin account can be used for that, it is better practice to use the PBX user password for this. For the HTTP credentials, you can use the PBX users “Name” as account and it’s “Password” as the password. You will use the “Long Name” as SOAP access user name.

When configuring the TAPI driver e.g., you would create a user with Long Name _TAPI_, Name tapi and a password. You would then use tapi/password as Gateway Platform Access/Account/Password and _TAPI_ as PBX Access/Username.

SNMP

SNMP is only for monitoring and does not allow any configuration changes. You may want to restrict the list of “accepted hosts” using the gateway applets SNMP area. You may want to change the “community” to a non-standard value.

ISDN data calls

ISDN data calls are accepted by innovaphone devices as voice calls are and they are routed similarly. Although innovaphone devices may be configured to terminate a data call and thus access the local network via dial-in, this option must be explicitly enabled.

Denial of Service attacks

Like any other network device, innovaphone devices may be a target for a denial of service attack. It is therefore recommended, to protect against malicious access using standard firewall techniques. However, innovaphone devices feature a built-in DoS filter which will discard unreasonable inbound traffic. Also, it is based on a dedicated and proprietary operating system which is usually not a target for viruses and other malicious code.

Arp Spoofing

Tools performing VoIP privacy attacks have been made publicly available in order to tap in to VoIP conversations in a local area network. These attacks are based on spoofing layer 2 networks addresses to create a man-in-the-middle scenario where a conversation can be recorded without service interruption to the original participants.

Basically, the attack is based on the fact that the mapping between IP addresses and Layer2 (MAC) addresses is usually built on-the-fly using a protocol (ARP) that has no security built in. Attackers can change this association without notice and thus redirect any traffic to themselves. These kind of attacks have been addressed in V6.

innovaphone ARP stacks will reject unexpected changes to the address mapping, and furthermore cease any traffic to the poisened mac address for 5 seconds. This featre needs to be enabled Reference7:Configuration/ETH/IP with Check ARP.

This way, an Arp spoofing attempt will be seen as service interruption by the end users, giving the network administrator a chance to investigate.

Availability

innovaphone devices have proved to be very robust and reliable. However, if availability is of utmost importance, redundancy options are available which allow for outstanding protection against loss of service.

Also, all innovaphone devices may be powered via power over Ethernet (PoE) which when combined with an uninterrupted power supply (UPS) ensure seamless operation even in the case of a local power failure.

PoE may be used concurrently with a local power supply.

Additional Security Features in Version 7

Although at present there are a number of security features implemented in innovaphone VoIP devices, there is still a lack of protection for the privacy of communications. This reflects the fact that previously, the source of attacks usually was expected to be outside of the own organization.

Such risks have been defended using sophisticated firewalls and VPN appliances on the own network border which provide for encryption and thus privacy protection. However, today’s security risks are more and more expected to emerge from within the organization.

The inability of contemporary local area network equipment to provide for encryption and thus privacy of communications puts the burden on the application. VoIP application as well as other data applications must provide for end-to-end encryption.

The V7 introduces a number of features which help to defend against the risks of security attacks.

SRTP

Secure RTP is a security mechanism defined by RFC 3711. SRTP can be used for voice encryption with H.323 and SIP. SRTP encrypts the RTP stream with AES. As a result the key will be chosen randomly on both sites and sent with the signaling data.

Only if both sites have activated encryption SRTP is used.

SRTP can not be forced.

innovaphone supports with Version 7:

• AES-128
• AES-192
• AES-256

all with 32 or 80 bit SHA1 hashed message authentication codes (HMAC).

TLS

The TLS protocol obsoletes SSL and allows applications to communicate across a network in a way designed to prevent eavesdropping, tampering, and message forgery. TLS provides endpoint authentication and communications privacy over the Internet using cryptography.

Typically, only the server is authenticated (i.e., its identity is ensured) while the client remains unauthenticated; this means that the end user (whether an individual or an application, such as a Web browser) can be sure with whom they are communicating. The next level of security—in which both ends of the conversation are sure with whom they are communicating—is known as mutual authentication. Mutual authentication requires public key infrastructure (PKI) deployment to clients.

TLS is needed for

• HTTPS
• secure SIP (SIPS)

innovaphone supports TLS with the following methods:

• RSA with 3DES
• RSA with AES-128
• RSA with AES-256

all with SHA1 hashes.

H.235

We currently use H.235v2 Annex D – Baseline Security Profile. It relies on symmetric techniques and provides authentication and/or message integrity based on shared secrets. H.235v3 Annex G – SRTP & MIKEY usage discusses a key management scheme suitable for use of SRTP (FRC 3711).

As SRTP does not specify a key management scheme by itself, the MSEC working group within the IETF discusses key management solutions and currently favours MIKEY. MIKEY defines AES as mandatory transport encryption enforces the use of X.509v3 certificates for public key encryption and digital signatures.

innovaphone implemented H.235 key Exchange for SRTP in Version 7.

SIPS

SIPS is SIP over TLS, which is mandated for proxies, redirect servers and registrars by RFC 3261. However, use of TLS requires a secure transport protocol, i.e. TCP.

Due to the enhanced performance of AES over 3DES, RFC 3853 updates the original 3DES encryption requirement found in RFC 3261 to require AES for S/MIME.

As RFC 3261 does not support the negotiation of security mechanisms to be used between parties, RFC 3329 defines a number of extra header fields to facilitate the negotiation of security mechanism between a SIP UA and its next hop server.

The mechanisms supported are: TLS, HTTP Digest, IPsec with IKE, manually keyed IPsec without IKE, S/MIME.

SIPS is supported since version 7.

Telnet

The secure shell protocol as per RFC 4251 can be used to apply content encryption to telnet sessions. We will not implement secure shell as we do not recommended to use Telnet at all, and telnet access is disabled by default.

LDAP

LDAP uses the SASL security as per RFC 2222. Unfortunately, this does not account for content encryption. LDAP v3 thus has defined extension for use of TLS with LDAP (in RFC 2830).

With Version 9 innovaphone will support LDAP via TLS

SNMP

SNMP versions 1 and 2 have been considered “insecure”. SNMP Version 3 includes considerably enhanced security mechanisms (as per RFC 3414). Unfortunately, this puts some difficult burden on SNMP implementations resulting in a rather little deployment compared to SNMP V2. There will be no SNMP security implementation on innovaphone side, as it is read only on the devices.

802.1X port security

Port security secures physical ports by enforcing a user authentication before allowing data transfer through a given Ethernet switch port. The endpoint needs to perform this authentication in order to be able to communicate.

As VoIP telephones usually work as an Ethernet switch (featuring a second “PC port”) they would need to enforce port security on this second port too in order not to compromise the security setup. The switch implementation must support multiple authentications on one port.

innovaphone supports the 802.1x feature on all products.

X.509 Certificates

Cryptographic certificates assign a public key to an identity. This is needed for the authentication of communication endpoints. The X.509 standard defines one commonly used format for such certificates.

innovaphone supports management functionality for both trusted CA certificates and device certificates / private keys.

Additional Security Features in Version 8

Kerberos based Authentication

A single innovaphone device can act as an authentication server for all other innovaphone devices. User accounts that are managed on the authentication server can be used to login on each device in the installation. You can also configure devices to accept user accounts from a PBX (full admin rights) or a Windows domain.

IP Filter

Separate IP filter for log-ins with password and without password.

Additional Security Features in Version 9

Object Device

• In case of registrations to a PBX using incorrect passwords, all other registrations to the relevant object are blocked for 20secs.

• It is possible to define at the object (for each device ) that the admin password is needed to log in.

• It is possible to delete all devices at an object and thus completely deny any registration.

HTTP Access Filter

Support for multiple networks in IP filter for the HTTP server (administration).

Unknown registrations

It is possible to use the admin password for unknown registrations (deployment of new endpoints).

Voicemail

The innovaphone voicemail supports SRTP via H.323 or SIPS.

LDAP via TLS

With version 9 innovaphone supports LDAP via TLS, for LDAP replication between master/slave/standby/standby-slave PBX.

Conclusion

Given the fact that today’s IT managers consider threats originating from inside the organisation as (at least) as critical as those originating externally, the only viable solution is a combination of media stream and signalling encryption performed directly by the endpoints.

Fortunately, both relevant signalling protocols in the PBX environment (H.323 and SIP) seem to converge as far as the media stream encryption (SRTP) and the key management are concerned. This should ensure end-to-end compatibility between SIP and H.323 endpoints. The necessary definitions for use of SRTP with H.323 are part of H.235-Annex G, for SIP it is SIPS - SIP via TCP and TLS. innovaphone has implemented SRTP according to H.235 Annex G as well as according to the SIP/SDP (SIPS/TLS) key management. The TLS is also used for HTTP, it requires an X.509 public key/certificate.infrastructure in place.

As the security of data transfer used for configuration is considered crucial, HTTPS is a mandatory requirement. This implies the existence of an X.509 certificate on each device. innovaphone devices entertain various http-based client connections to foreign http servers (e.g. for voice announcements, configuration provisioning). Since these connections are (at least) as critical as configuration sessions where the device acts as an http server, both proper http digest authentication and also TLS content encryption (https) is implemented by innovaphone.

The use of telnet to access innovaphone devices is deprecated and thus there is no need to address possible security issues related to the telnet access. As a “best practice” rule it is recommended to disable telnet access anyway (which in fact is the default configuration anyway).

While innovaphone devices do support SNMP, they do not allow any modification or retrieval of sensitive data using this mechanism. It is merely meant to facilitate maintaining devices health status. SNMP should be guarded against risk originating externally anyway (e.g. using firewall techniques). Risks originating from inside the organisation are considered less important. innovaphone will thus stay with the current SNMP v1 implementation.

innovaphone systems make extensive use of LDAP queries to synchronize distributed PBX systems. These communications obviously carry sensitive data (although from the very beginning there were no passwords conveyed in clear). innovaphone has implemented TLS for LDAP for inter-PBX communication. Securing LDAP access by clients (i.e. phones) to organisational directory services is considered less important as the conveyed data usually is not as critical. Also, existing directory servers may not support TLS for LDAP.

While 802.1X port security adds some extra barrier against certain types of internal risks, it also creates a number of open issues. Telephones usually are considered to work even if they are currently not authenticated by user. This may be mandatory for emergency calls for example. Use of port security would then mandate the storage of a fixed password within the non-volatile memory of an IP phone. Furthermore, the authentication of the second (PC) port needs to be performed with 802.1.x multiple authentications. innovaphone has implemented 802.1x on all of its devices.

Related Articles

Howto:Protection against Brute Force Attacks

Howto:How to physically erase flash memory content

Howto:SIPS will work with V7

Howto:Certificate management in V7

Howto:DECT Security

Reference9:PBX/Config/Security