Skip to end of metadata
Go to start of metadata

Internet Protocol Security

Internet Protocol Security (IPSec) enables access control, integrity, data origin authentication, replay packet protection and confidentiality of IP traffic.

VoIP solutions provide a way to achieve cost savings by converging voice and data traffic and carrying it over the lower-cost Internet versus the traditional telephone network. However, VoIP traffic is vulnerable to interception and disruption while being carried over the public IP network. Fortunately, the same principles, tools, and techniques used to protect data networks apply to voice, which is essentially another application carried on the existing data network infrastructure. IPSec is one of the widely used techniques to provide this much needed protection at the IP level. Hence the decision was made to add IPSec support into the VX platform.

IPSec (RFC2401) is a framework of open standards for ensuring private, secure communications over Internet Protocol (IP) networks, through the use of cryptographic security services. IPSec provides protection against private network and Internet attacks through end-to-end security. The services that it provides are as follows:

  • Access control--To filter and treat (drop, pass, secure) traffic based on the filters.
  • Replay protection--To prevent intruders from inserting pre-recorded packets back into a stream.
  • Integrity--To ensure that the transmitted data has arrived at destination without undetected alternation.
  • Origin authentication--To guarantee that the data received is the same as the data sent and that the claimed sender is in fact the actual sender.
  • Privacy/confidentiality--To ensure that only the intended recipients know what was being sent, and unintended parties cannot.

IPSec uses a suite of protocols to provide the services mentioned above. The following three are on the top of the list of protocol suite:

  • AH (Authentication Header - RFC2402) provides a packet-level authentication service.
  • ESP (Encapsulating Security Payload - RFC2406) provides encryption plus authentication.
  • IKE (Internet Key Exchange - RFC2409) negotiates connection parameters, including keys.
FIPS Compliancy

FIPS, in general, are standards published by the U.S. National Institute of Standards and Technology (NIST), after approval by the Department of Commerce; used as a guideline for federal procurements.

FIPS PUB 140-2 specifies the security requirements that are satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information. The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include cryptographic module specification, cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks.

Authentication Header (AH)

VX supports Authentication Header protocol to provide authentication, integrity, and anti-replay for the entire packet (both the IP header and the data payload carried in the packet).

AH does not provide confidentiality, which means it does not encrypt the data. The data is readable, but protected from modification.

VX supports the following algorithms to sign the packet:

  • HMAC with MD5 (Hash-based Message Authentication Code with Message Digest version 5)
  • HMAC with SHA-1(Hash-based Message Authentication Code with secure hash algorithm 1)
Encapsulating Security Payload (ESP)

VX supports Encapsulating Security Payload (ESP) protocol to provide confidentiality, in addition to authentication, integrity, and anti-replay.

VX supports the following algorithms to sign the packet:

  • HMAC with MD5
  • HMAC with SHA-1
  • NULL Authentication Algorithm

VX supports the following algorithms for encryption:

  • DES (Digital Encryption System)
  • 3DES (Triple DES)
  • AES (128/192/256 bits) (Advanced Encryption Standard)
  • NULL Encryption Algorithm

Either authentication or encryption (or both) has to be enabled. They can not be NULL at the same time.

Key Management

VX supports Internet Key Exchange (IKE) to provide a way to negotiate connection parameters and dynamic re-keying capability. Manual key exchange is not supported in this release.

IKE consists of 2 phases: phase 1, where IKE SA (Security Association) is negotiated and phase 2 where IPSEC SA is negotiated.

When VX is the initiator of the key exchange, all combinations of the following is included in Phase 1.

  • Encryption Algorithms: 3DES, DES, AES
  • Hash Algorithms: MD5, SHA1
  • Authentication Algorithms: Certificates, Preshared Keys
  • Diffie Hellman Group: Group 1, Group 2

When VX is the responder to the key exchange request, the proposals from the peer is matched against the available algorithms that are listed above.

In both cases (VX as the initiator or responder) the preference order of the algorithms are as listed above (3DES is preferred to the other 3 encryption algorithms, MD5 is preferred to SHA1, certificates are preferred to PSKs etc.).

In case of algorithms for IPSec SA, VX uses the user-configured ones in the negotiations during Phase 2.

IPSec Modes

IPSec in transport mode protects the IP payload only, whereas tunnel mode protects the whole IP packet.

VX supports both transport and tunnel modes. The support includes all possible combination of modes and protocols: AH in transport or tunnel mode, ESP in transport or tunnel mode. AH in transport mode signs part of the IP header as well.

When both AH and ESP are used in transport mode, ESP is applied first. Otherwise integrity is not applicable to the ESP header.

Secure Transport Protocols

VX uses RTP and VTP (proprietary Voice Transport Protocol) as transport protocol for voice data packets. VTP is used for communicating with other VX nodes. RTP is used by SIP and H.323 for default data transport. RTP packets are vulnerable to attacks such as forging and replay. Transport Layer Security (TLS) feature in VX provides security for SIP signaling, but there is no protection for VoIP data packets. Secure RTP/VTP (SRTP/SVTP) provides security services to VoIP calls using RTP and VTP.

SRTP facilitates secure transmission of voice packets for VoIP calls using RTP as transport. Only SIP calls can be secured using SRTP in VX Release 4.1. Every SIP line has a setting for RTP security. If RTP security is enabled for SIP call, the SDP of the INVITE is used to negotiate the security parameters. SRTP by itself does provide full security without a secure signaling connection. Although the VoIP data stream is secured by the SRTP, the master key sent in the SIP INVITE is not secure if the signaling path is not secured. For signaling channel security, TLS is used in VX. See TLS Enhancements for more information about TLS.

VX uses VTP as transport protocol for communication between two VX nodes. This protocol is also not secured by any encryption technique. Under the SRTP/SVTP feature, security for VTP trunks is also provided.

Secure RTP

The Secure RTP (SRTP) protocol is used to secure RTP payload. The implementation of RTP in VX is for unicast media streams.

SRTP protocol is composed of following components:

  • Encryption and decryption

SRTP supports payload encryption of the RTP payload. The encrypted portion is the exact size as that of the plaintext. No padding for the RTP payload is used. the following transforms are used for encryption/decryption in VX SRTP:

  • AES in counter mode (AES*CM) with 128 bit encryption key
  • NULL cipher - when no confidentiality for the RTP is requested
  • Authentication

In SRTP, the RTP header is not encrypted. The authenticated portion of the SRTP packet consists of the RTP header and the encrypted payload. For authentication, HMAC-SHA1 is used with an authentication tag of 80/32 bits.

  • Replay Protection

For replay protection, a list of the sequence numbers of the good received packets is maintained by SRTP. The packets arriving with sequence numbers lagging behind by more than 'SRTP window size' are considered as re-injected after interception by an adversary. VX implementation uses a window size of 64.

  • Master Key/Salt Generation

A Master key is generated using random number generation by crypto accelerator chip. A Master salt is also generated in the same way. Only one master key per session is supported. A Master key has a corresponding MKI which is unique for every session.

  • Key Exchange

SRTP by itself does not provide any mechanism for key exchange. Another key exchange protocol is required for this purpose. SDP is used in VX for key exchange for SIP calls. TLS is used in VX to provide the signaling security.

  • Re-keying

When the master key expires, re-keying is required. This is also done out-of-band using SDP. In VX, MKI is used for re-keying purpose. After rekey offer is accepted, the old master key is discarded and new key is used. Modification of any parameter other than master key and KDR associated with the new master key in the middle of the call is not allowed.

  • Key Derivation

One SRTP session requires 3 keys (encryption key and salt, and the authentication key). Key derivation is used to derive the keys from one master key in a cryptographically secure way. AES-CM PRF with 128 bit master key are used for key derivation. KDR, the key derivation rate parameter, defines the rate at which the keys are derived again during the lifetime of a session.

  • Security Parameter Negotiation

SDP-Security Descriptions For Media Streams (version 09) defines the parameters to configure security for SRTP unicast media stream in one offer/answer transaction. The SDP crypto attribute requires a data security protocol to ensure the security of the SDP message. TLS is used in VX to provide the signaling security. TLS configuration must be explicitly done by the system administrator. If the TLS is not selected for the SIP call and it is configured for secure media; a warning is generated.

Secure VTP

Between two VX nodes, VTP is used for media. This feature provides security for VTP in a way similar to SRTP.

Secure VTP (SVTP) can operate in two modes.

  • VTP call security--protecting a single VTP stream inside the packed VTP frame. A VTP frame may be composed of secured and un-secured VTP streams. The encryption and authentication is performed before frame packing and authentication and decryption is performed after frame unpacking.
  • VTP Tunnel security--Security is provided for the packed VTP frame. This mode is supported.

For encryption, decryption and authentication the same options as in SRTP are available.

Key management is different from SRTP. BSP is the signaling protocol used for VTP. BSP by itself is not secure. Therefore, if the master keys are exchanged over BSP, these may not be secure. IPSEC would be needed to provide that level of security. See TLS Enhancementsfor more information.

SVTP protocol is composed of following components.

  • Encryption and decryption

Following methods are supported for encryption and decryption.

  • AES in counter mode (AES*CM) with 128 bit encryption key
  • NULL cipher - when no confidentiality for the VTP is requested
  • Authentication

For authentication, HMAC-SHA1 is used with an authentication tag of 80/32 bits.

  • Master Key/Salt Generation

Master key can be selected using one of the following methods.

  • Auto-generated--Nodes are acting as end nodes for security. Software will automatically generate the master key.
  • Relay/Forward--In case the node is acting as security relay, the key from incoming stream can be used and same key is forwarded in the outgoing stream also. These nodes do not decrypt/re-encrypt the secure media.
  • Key Exchange

If a pre-shared key is not used, the key would be exchanged using BSP protocol. It is assumed that IPSEC would provide necessary security for this exchange.

  • Re-keying

When the master key expires, re-keying is required. This is also done out-of-band using BSP similar to SRTP. MKI is used for re-keying purpose. After a rekey offer is accepted, the old master key is discarded and the new key is used.

  • Key Derivation

There are three keys for one SVTP connection (encryption key and salt, authentication key). Key derivation is used to derive the keys from one master key in a cryptographically secure way. AES-CM PRF with 128 bit master key is used for key derivation. KDR, the key derivation rate parameter defines the rate at which the session keys are derived again during the lifetime of a session.

  • Security Parameter Negotiation

Based on the deployment mode, the security parameters are negotiated as media class intersection. If the VX node is acting as an end node for SVTP, the BSP signaling is be generated based on the user setting of media class. If the VX node is acting as the SVTP relay, the incoming SDP signaling message is converted into equivalent BSP message. For implementation details see the VXbuilder User Guide.

New VX Capabilities

SRTP is implemented as a layer between RTP and UDP in VX. Following functions have been added to VX for SRTP.

  • Using SDP (SIP-TLS) for key management, re-keying and configuration of security parameters for SRTP
  • Using BSP for key management, re-keying and configuration of security parameters for SVTP
  • Session context management -- Maintaining transform dependent and transform independent parameters associated with an SRTP/SVTP session.
  • Master Key and master salt generation--Random numbers are generated for master key and master salt.
  • Key Derivation--Authentication key, encryption key, and salt are derived from master key and salt.
  • Packet authentication --If the packet fails authentication according to the method defined in the crypto-context of its session, it is dropped.
  • Encryption and decryption - In the transmit direction, the RTP packet will be encrypted based on the crypto context for the call/session. After that it will be passed to the UDP layer. In the receive direction, the SRTP packet will be decrypted based on the crypto-context of the corresponding session. If it fails in decryption, the packet will be dropped.
  • Replay Protection--Maintaining a replay list for preventing replay attacks. If the packet is out of the replay window, it is dropped.
  • Protocol conversion needed for security application. This includes RTP<>SRTP, SRTP<>SVTP, RTP<->SVTP.
  • VTP version 4 for SVTP.

Information Assurance Compliance

Information Assurance compliance ensures management of IT operations in a secure manner.Information operations need to be followed that protect and defend information systems (IS) by ensuring their availability, integrity, authentication, confidentiality and no repudiation. This includes providing for restoration of information systems by incorporating protection, detection and reaction capabilities.

Session Time Out

VX provides a session time-out feature such that if there is no communication exchanged over a SSH or Telnet session for an administrator-specified period of time, the session is ended.

Login Retries and Lockout Timer

The administrator will be able to set login retries and a lockout timer. If a login fails more than the number of retries set, the user will be locked out for the specified duration.

Lockout Event Notification

An event notification in form of alarm and trap will be generated upon detection of a user lockout occurrence. The severity of these would be set to 'Warning'. However, unlocking of a user account will not generate notifications.

Privilege Assignments

VX provides the ability to assign user privileges for all classifications of users through the VXBuilder as well as CLI. It is assumed that user privilege means access level 0-15.

Active User Display

VX displays all active users upon request by user over a SSH or Telnet CLI session.

User Management

VX will have the capability to enable/disable a user through CLI and VXbuilder. It is assumed that suspending a user is same as disabling.

User Account Validity

VX supports the monitoring of user activity. It is assumed that it has to take into account the interval between a user's logout and next login. After a specified time interval, if that user has never been used during that time interval, VX will disable the user and user will need to contact administrator to re-enable the account. This time interval will be a configurable from CLI as well as VXbuilder.

The default time interval to disable a VX user who has not logged in will be set at 30 days (and be configurable by the System Administrator through CLI as well as VXbuilder for duration ranging from 0 day to 365 days).

Changeable Password

VX allows the user password to be changeable through both CLI as well as VXbuilder. This process requires the re-authentication of user's identity. While changing the password from by way of VXbuilder, the user has the following options:

  • To change a password for a specific level
  • To change a password for all levels

It is be not possible to change a password by way of VXwatch as this application is a monitoring tool.

Change on First Login

VX requires a user accessing the system for the first time to change the initially valid password. Unless a user successfully changes the initial password, it will not be considered as a login. In the CLI and in VXbuilder the user is offered the change password mechanism on first login.

Terminate Sessions

VX provides the capability to terminate any SSH or Telnet session on VX through the CLI. VXBuilder does not maintain any connection with VX so it will not deal with live sessions.

Password Aging

VX enforces password aging (i.e. require passwords to be changed after a specified interval). A password's age is configurable from CLI as well as by way of VXbuilder. The default for the system-wide password aging is 30 days with an interval allowed between 20 and 90 days. In the case where a password is not changed within this time interval, the user will be asked to change the password on login. The user will be able to access the system only if the password is successfully changed.

Password Standard

Passwords are required to be made up of at least 6 characters having at least 1 letter, 1 number and 1 special character each. Another requirement is that username should not be a part of password.

Special characters that can be used in the VX password is any character which is not a numeral i.e. 0 to 9 or Alphabetic ('A' to 'Z' and 'a' to 'z'). The following is a list of special characters from the ASCII table of characters:

ASCII Value Special Character

33 !

34 "

35 #

36 $

37 %

38 &

39 '

40 (

41 )

42 *

43 +

44 , (comma)

45 -

46 . (Dot)

47 /

58 :

59 ; (semi-colon)

60 <

61 =

62 >

63 ?

64 @

91 [

92 \

93 ]

94 ^

95 * (underscore)

96 `

123 {

124 |

125 }

126 ~

Password Reuse

VX provides a mechanism to limit reuse of passwords following password aging. The number of past passwords which would not be allowed will be configurable through CLI as well as VXbuilder.

Legal Warnings

The user is prompted before logging-in warning against unauthorized login into the system. Similarly, a message is displayed on successful login informing the user about usage policies and guidelines. These messages are configurable so that they may be customized according to local laws and company policies.

User Feedback

For invalid user authentication procedures, VX generates user feedback that provides NO information other than "Access Denied." The feedback will NOT reveal which part of the user-entered information (user-name or password) was incorrect.

Security Events

VX generates security events and alarms through the CLI and SNMP interface, including but not limited to the following:

  • System access attempts (both valid and invalid)
  • Unauthorized attempts to access restricted data
  • Modification of security records
  • Change of identification to privileged user ids
Audit Log

VX provides a wrap-around log auditing user activities accomplished through all the management interfaces such as VXbuilder as well as Telnet and SSH CLI session. For each session created by user a new log would be generated at path VX/PUBLIC/Userlogs/. A session could be a Telnet, SSH or transmit from SB. Log provides following information to administrator:

  • Username
  • IP Address from which the session was established
  • Type of Session (SSH, Telnet or SBCP)
  • Time and Date
  • Commands given by user for CLI logs
  • Config-IDs modified by a SBCP transmit
Audit Log Events

A single security audit log (alarm log) will be maintained for each VX node that tracks and records security events such as log in, log out, failed attempts etc. The audit log should contain each security event, including:

  • User name, date and time
  • Action type (login, logout, failed attempt, etc.)
  • Location of login (client IP address)

Following security events are logged through the Alarm system:

  • Successful Login
  • Failed Login
  • Password Change
  • User-Lockout
  • No labels