COTS SECURITY GUIDANCE (CSG) VOICE OVER INTERNET PROTOCOL (VoIP)

COTS SECURITY GUIDANCE (CSG) VOICE OVER INTERNET PROTOCOL (VoIP) CSG-04\G August

This page intentionally left blank.

Foreword The Voiceover Internet Protocol (CSG-04\G) is an unclassified publication, issued under the authority of the Chief, Communications Security Establishment Canada (CSEC). Suggestions for amendments should be forwarded through departmental communications security channels to your Client Services Representative at CSEC. For further information, please contact CSEC s ITS Client Services area by e-mail at itsclientservices@cse-cst.gc.ca or call (613) 991-7654. Effective Date This publication takes effect on 08/28/. Carey Frey Director, IT Security Industry Program Government of Canada, Communications Security Establishment Canada It is not permissible to make copies or extracts from this publication without the written consent of CSEC. i

This page intentionally left blank. ii

Table of Contents Foreword... i Effective Date... i Table of Contents... iii List of Tables... iv List of Figures... iv 1 Introduction... 1 2 VoIP Overview... 1 2.1 Components... 1 2.1.1 End Unit... 1 2.1.2 Call Server... 2 2.1.3 PSTN gateway... 2 2.1.4 Networking infrastructure... 2 2.2 Call Placement... 3 2.3 Analogue to Digital Coding and Decoding... 3 2.3.1 Speech CODEC standards... 3 2.3.2 Facsimile Transmission using VoIP... 3 2.4 Protocols... 4 3 Security Concerns... 5 3.1 Confidentiality... 5 3.1.1 Opportunistic Encryption... 5 3.2 Availability... 6 3.3 Integrity... 6 3.4 Authentication... 6 3.5 Architecture... 6 3.6 Policy... 7 3.6.1 Periodic Review of Emergency Services Location Information... 7 4 Glossary and Acronyms... 8 4.1 Glossary... 8 4.2 Acronyms... 8 4.3 Technical References... 9 iii

List of Tables Table 1: Security Features Checklist: Voice over Internet Protocol... 10 List of Figures Figure 1: VoIP Components and Architecture... 2 iv

1 Introduction VoIP refers to a technology used to carry voice traffic over packet-switched Internet Protocol (IP) networks, ideally allowing for cost savings and consolidation of infrastructure elements. 2 VoIP Overview VoIP systems use a range of protocols to manage calls and to carry the voice traffic between users. There are a wide variety of telephones, conferencing units, and software applications that run on users personal computers (PCs) that provide VoIP functionality. A VoIP system can interface with the Public Switched Telephone Network (PSTN) in several different ways, and there are a number of security concerns when voice traffic is added to a data network. 2.1 Components Although component names vary depending on the vendor and the protocols in use, there are several common features that all VoIP networks have. Figure 1 shows a sample corporate VoIP implementation demonstrating these components. 2.1.1 End Unit There must be an end unit, or equivalent to the telephone, for each user. This may resemble a conventional phone, or it may be a software application on a user s PC, a mobile unit, or a conferencing unit. This will be referred to as the handset. There are three types of handset that can be used to connect. 2.1.1.1 Conventional Telephone A conventional analog telephone can be connected to a VoIP network using an Analog Telephone Adapter (ATA). The ATA has at least two ports a Foreign Exchange Station (FXS) port with an RJ-11 jack for connecting an analog telephone and a network port, usually an RJ-45 jack for connecting to an Ethernet Local Area Network (LAN). 2.1.1.2 IP Telephone An IP telephone looks like a conventional telephone, but instead of an RJ-11 telephone jack, it has a network port, usually an RJ-45 Ethernet LAN jack to connect to a VoIP network. 2.1.1.3 Wireless IP Telephone A wireless IP telephone has a Wireless Local Area Network (WLAN) interface to connect via a Wireless Access Point (WAP) to a VoIP network. 2.1.1.4 Software VoIP calls can be made from a computer equipped with a microphone, headset and sound card, if the appropriate software is installed. 1

Figure 1: VoIP Components and Architecture 2.1.2 Call Server To place the call and manage user locations, there must be one or more call managers or call servers. The functionality may be split between two or more servers, but these servers need to send and receive management traffic to and from the end units and between each other. 2.1.3 PSTN gateway A gateway to the PSTN is required. This may be located on the customer premises, or it may be at the vendor s location or some other location. 2.1.4 Networking infrastructure Networking infrastructure such as cabling and switches is required. If this infrastructure is shared anywhere along the path with traffic from other sources, then one or more firewalls are required. This infrastructure is similar to that required for conventional data networks, but because of the high traffic volume and Quality of Service (QoS) requirements of VoIP networks, the equipment in place for the data network may not suffice. 2

2.2 Call Placement To place a call, there are several steps that take place: a. A user dials the other party s number using a handset, just as they would when using a conventional telephone. Here, however, the similarity ends. b. The handset contacts the call manager, which translates the phone number into an IP address that the handset can contact. This IP address may be that of the other party, or it may be the address of a gateway to the PSTN. This takes place using a call management protocol such as H.323, the Session Initiation Protocol (SIP), or a proprietary vendorspecific protocol. c. The handset attempts to contact the other party; this may pass through several layers of network infrastructure. If successful, the call begins, and the voice data and call management data flow between the callers. The voice data is often compressed for greater efficiency, and typically uses the Real-time Transport Protocol (RTP). Call management traffic between the two endpoints is typically transmitted using the Realtime Transport Control Protocol (RTCP). d. When the users hang up, the handsets signal each other via a call management protocol such as RTCP, and the call is terminated. 2.3 Analogue to Digital Coding and Decoding VoIP uses Coder/Decoder software (CODEC) that is optimized for converting analogue voice to digital. Tones which are outside the normal range of human hearing, or which are otherwise not required for rendering the conversation intelligible, may be filtered out to improve QoS. 2.3.1 Speech CODEC standards Speech CODEC standards include: G.723.1 (5.3k/6.3k) G.729A/B G.726 G.711(A-law/u-law) Detailed description of these CODEC standards is outside the scope of this guidance. 2.3.2 Facsimile Transmission using VoIP Because VoIP CODECs are normally optimized for voice transmission, some implementations may have difficulty in sending or receiving facsimile (fax) transmissions. Fax over IP (FoIP) can be implemented using the T38 protocol (defined in Request for Comments (RFC) 3362) and requires a T38 capable VOIP gateway as well as a T38 capable fax machine, fax card or fax software. Most modern multi function fax machines support T38. 3

Connecting a conventional fax machine directly to a VoIP line may work, but fax transmissions are likely to encounter problems. The best CODEC for this implementation is the G 711 codec, which has a minimum of compression. 2.4 Protocols Detailed descriptions of VoIP protocols are outside the scope of this document. 4

3 Security Concerns VoIP systems raise a number of security concerns that exist neither in the conventional PSTN nor in purely data networks, as well as some more general concerns. 3.1 Confidentiality Confidentiality can be divided into two domains: call traffic (the actual content of the conversations), and call management (knowledge of who called whom). Obtaining both kinds of information is considerably easier than it is for calls made using the PSTN. Because they are designed to mimic conventional data networks, VoIP networks are susceptible to the same packet-sniffing attacks as other networks. Packet sniffers are widely available for free and are easily installed onto any PC. The use of switches does raise the bar to a certain extent, but attacks such as Address Resolution Protocol (ARP) spoofing can negate this. End-toend encryption can be implemented using certain secure protocols such as Secure Real-time Transport Protocol (SRTP) or by implementing a virtual private network (VPN), but these measures are not in widespread use at the time of writing. A compromised management server or PSTN gateway would provide access to all the traffic that passes through that server; these servers are much more accessible to attackers than the switches and PBXs of the telephone companies. Similarly, the use of PC-based clients adds the risk of access to the VoIP traffic from other, potentially malicious, applications. For these reasons and others, VoIP traffic should be segregated from data traffic. This can be done physically (which negates some of the reasons for adopting VoIP in the first place) or logically, such as with IP subnets (layer 3) or Virtual LANs (VLANs) (layer 2). Physical controls are essential in VoIP systems. The expertise required to intercept data traffic is much more widely available than the expertise to intercept a regular telephone call, and traffic analysis (who is calling whom) can be performed even if encryption is in use. VoIP installations located in the U.S. are required to support Communications Assistance for Law Enforcement Act (CALEA) wiretap capability, and may fall under the umbrella of any domestic surveillance programs. This potentially affects Canadian installations that use a PSTN gateway located at a vendor s site in the U.S. 3.1.1 Opportunistic Encryption Opportunistic Encryption (OE) refers to any system that attempts to encrypt the communications channel, but falls back to weaker encryption or unencrypted communications if no encryption method can be agreed on, or in order to maintain data rates necessary for QoS levels if line conditions degrade. This is sometimes described as "Better Than Nothing Security", as it does not guarantee any security Although opportunistic encryption makes the encryption easy to implement, it should not be relied on. When using a VoIP implementation that provides opportunistic encryption, users need to assume that the conversation is unencrypted and govern themselves accordingly. 5

3.2 Availability Availability is one of the prime concerns regarding user acceptance of a VoIP system. The calls must go through reliably, the system must be available even during a power outage, and the quality of the calls must be similar to those placed over the PSTN. Unfortunately, measures implemented to improve other aspects of security, such as firewalls and encryption, tend to have an adverse effect on availability because they add to the initial call setup time and/or the time required to process voice-data during the conversation. Redundant servers and a redundant Internet connection (where applicable) can help to ensure availability. 3.3 Integrity Like confidentiality, call integrity and call management integrity are vulnerable to data network attacks. An attacker could set up a falsified call management server to launch man-in-the-middle attacks, or could redirect and modify traffic using ARP spoofing, among others. The comments relating to confidentiality are generally applicable to integrity as well, since packets that can be intercepted can be modified. 3.4 Authentication The PSTN relies largely on the physical layout of the landlines to determine caller identity. However, this cannot be used reliably for VoIP systems, since packets can originate anywhere and packet headers are easy to forge. Authentication is a concern primarily during call set-up; the situation of an attacker being able to mimic one of the parties midway through a conversation is unlikely but possible. Callers will usually recognise each other s voices if they know each other, but a VoIP handset should have a way to validate the identity of the call management server to prevent man-in-the-middle attacks. Conversely, the call management server should know that the handset is authorised to make the call it is making, and is not, say, someone engaging in long-distance toll fraud. This not only affects the caller ID display. Emergency 911 services need to know the exact location of the caller; not all VoIP systems can provide this data with accuracy. Password management is a key area of security. Many incidents take place because of the presence of default passwords and/or accounts. Default passwords should be able to be changed on all components, including handsets, call management servers, PSTN gateways, and other network components. 3.5 Architecture Because of the complexity of a VoIP network, it is important to have well-documented network architecture in place. In addition to the more obvious components such as end-user handsets, call management servers, PSTN gateways and firewalls, this also should address systems that require a reliable telephone connection such as alarm systems. Firewalls and Network Address Translation (NAT) gateways should be used to protect handsets, call management servers, PSTN gateways, and other components from potentially hostile traffic 6

such as that encountered on the Internet. These firewalls and NAT gateways need to understand the protocols used by the VoIP system to avoid having to open large holes in the firewall and/or NAT, because most of the VoIP protocols do not use fixed Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) ports. There are other protocol-related issues; H.323, in particular, carries TCP / UDP port and IP address information in the application-layer section of the packet, making NAT traversal problematic. Both SIP and H.323 require that the handset sends its IP address to the call management server during initialization; if this handset is located behind NAT, the address provided is most likely unreachable. The means by which the various architecture elements are managed remotely also should be taken into consideration, since it is often impractical to manage all components strictly locally. Protocols such as Telnet, Simple Network Management Protocol (SNMP), Hypertext Transfer Protocol (HTTP), and Trivial File Transfer Protocol (TFTP) are commonly used but not secure; better alternatives include Secure Shell (SSH) and Secure Sockets Layer (SSL) / Transport Layer Security (TLS). 3.6 Policy 3.6.1 Periodic Review of Emergency Services Location Information Many VoIP providers use a default location, provided by the user or administrator when registering the service, to display to Emergency Services operators when a 911 emergency call is placed. Where applicable, there should be a policy to periodically review the registrant s location information for Emergency Services. Failure to ensure this information is up-to-date may result in emergency services being misdirected and will delay help in a possible life-threatening emergency. 7

4 Glossary and Acronyms 4.1 Glossary Packet sniffer Spoof Spoofing 4.2 Acronyms 3DES AES AH ARP CMVP CODEC CRL CSEC DES EAL ESP FIPS FoIP HTTP HTTPS IDS IKE IP IPS IPSec IT ITU Software that observes and records network traffic (National Institute of Science and Technology (NIST) Special Publication (SP) 800-61) Attempt by an unauthorized entity to gain access to a system by posing as an authorized user (SANS: http://www.sans.org/resources/glossary.php) IP spoofing refers to sending a network packet that appears to come from a source other than its actual source. (NIST SP 800-48) It involves 1) the ability to receive a message by masquerading as the legitimate receiving destination, or 2) masquerading as the sending machine and sending a message to a destination (Federal Information Processing Standard (FIPS) 191) Triple-Data Encryption Standard (Triple-DES) Advanced Encryption Standard Authentication Header Address Resolution Protocol Cryptographic Module Validation Program Coder/Decoder Certificate Revocation List Communication Security Establishment Canada Data Encryption Standard Evaluation Assurance Level Encapsulating Security Payload Federal Information Processing Standard Fax over IP Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Intrusion Detection System Internet Key Exchange Internet Protocol Intrusion Prevention System Internet Protocol Security Information Technology International Telecommunication Union 8

LAN Local Area Network NAT Network Address Translation NIST National Institute of Science and Technology OCSP Online Certificate Status Protocol PC Personal Computer PKI Public Key Infrastructure PSTN Public Switched Telephone Network QoS Quality of Service RTCP Real-time Transport Control Protocol RTP Real-time Transport Protocol SIP Session Initiation Protocol SNMP Simple Network Management Protocol SP Special Publication SSH Secure Shell SRTP Secure Real-time Transport Protocol SSL Secure Sockets Layer TCP Transmission Control Protocol TFTP Trivial File Transfer Protocol TLS Transport Layer Security UDP User Datagram Protocol VoIP Voice over IP VPN Virtual Private Network WAP Wireless Access Point WEP Wired Equivalent Privacy WPA2 Wi-Fi Protected Access 2 4.3 Technical References ITSA-11E CMVP CSE Approved Cryptographic Algorithms for the Protection of Protected Information and for Electronic Authentication and Authorization Applications within the Government of Canada; http://www.csecst.gc.ca/documents/publications/itsa-asti/itsa11e-eng.pdf Cryptographic Module Validation Program (http://www.cse-cst.gc.ca/itssti/services/industry-prog-industrie/cmvp-pvmc-eng.html) 9

Table 1: Security Features Checklist: Voice over Internet Protocol Product Name: Item Security Features Checklist for VOIP Products 1.0 Recommended Security Features 1.1 Encryption The product should be capable of encrypting all voice traffic passing through it according to the cryptographic standards specified at Item 5.0below. 1.1.1 Wireless Encryption Wireless handsets should implement IEEE 802.11i security enhancements. Wi-Fi Protected Access 2 (WPA2) is a Wi-Fi Alliance certified interoperable implementation of the mandatory subset of IEEE 802.11i security enhancements. 1.1.2 Opportunistic Encryption 1.2 Caller ID The product should not rely solely on opportunistic encryption The product should fully support Caller ID services. 1.3 Emergency Services (911) Caller Location The product should provide full caller location data for emergency services (911). 1.3.1 Emergency Services (911) Caller Location Registrant-provided The product should advise emergency services if the caller location provided is a default location provided by the user upon registration. 1.3.2 Emergency Services (911) Caller Location for Mobile VoIP 1.4 Availability 1.4.1 Latency 1.4.2 CODEC The product should advise emergency services if the caller is calling from a mobile or wireless VoIP handset. The product should be available for use at all times, including during a power outage. Backup power will need to be provided to end-user handsets and to network elements such as call management servers. The product should provide a maximum latency of 150ms for one-way traffic to provide equivalent service to a conventional telephone system For VoIP traffic, the product should use a CODEC that is optimized for analogue voice to digital conversion. For FoIP traffic, the product should use a CODEC that is suitable for facsimile traffic. 1.4.3 Redundant Internet / PSTN Connection The product should support a redundant connection to the Internet and/or to the PSTN. 10

Product Name: Item Security Features Checklist for VOIP Products 1.5 Network elements Other Network elements such as NAT gateways, firewalls, routers, switches, intrusion detection systems, and other devices that are required for, but not exclusive to, VoIP services, should be compatible with the VoIP installation. 1.5.1 VoIP protocols The following network elements should be compatible with VoIP protocols: NAT Gateways Firewalls and other packet filters Intrusion Detection Systems 1.5.1.1 NAT Gateways NAT gateways should support VoIP protocols such as H.323, SIP, and others as applicable. This is because VoIP ports are often dynamically allocated, and because the end-user handsets need to communicate as directly as possible with one another 1.5.1.2 Firewalls and other packet filters Firewalls and other packet filters should support VoIP protocols such as H.323, SIP, and others as applicable. This is because VoIP ports are often dynamically allocated, which can cause difficulties for traffic inspection. 1.5.1.3 Intrusion detection systems Intrusion detection systems should support VoIP protocols such as H.323, SIP, and others as applicable. This is because VoIP ports are often dynamically allocated, which can cause difficulties for packet inspection. 1.5.2 Quality of Service Indicators The following network elements should be compatible with QoS Indicators: Firewalls and other packet filters Intrusion Detection Systems Routers and Switches This will ensure that the Firewalls, Intrusion Detection Systems, routers and switches can prioritize traffic based on QoS feedback in order to maintain acceptable levels of voice quality and robustness of service. 1.5.2.1 Firewalls and other packet filters Firewalls and other packet filters should support QoS indicators within VoIP traffic and should prioritize traffic accordingly. 1.5.2.2 Routers and Switches Routers, switches and other similar devices that only perform traffic forwarding should support QoS indicators within VoIP traffic and should prioritize traffic accordingly. 1.5.2.3 Intrusion Detection Systems In-line intrusion detection systems should support QoS indicators within VoIP traffic and should prioritize traffic accordingly. 1.5.3 Remote Management of Network Elements All network elements should support a secure means of remote management, such as SSH and/or HyperText Transfer Protocol Secure (HTTPS); un-encrypted management should not be permitted. This is to ensure that management traffic is protected from unauthorized viewing and/or modification in transit. 11

Product Name: Item Security Features Checklist for VOIP Products 1.6 Segregation of Traffic The product should segregate VoIP and general-purpose data traffic on distinct physical and/or logical partitions, and should include packet filtering capabilities to prevent traffic from one entering the other. This is to prevent disruption of services by unexpected traffic, and to prevent call spoofing from the data network. 1.7 Location of VoIP to PSTN Gateway The VoIP to PSTN gateway should be located on-site, or if not it should be located at a secure location in Canada and the connection between the gateways should be via VPN. 1.8 Use of Hardware End-User Handsets The product should only include hardware-based end-user handsets, i.e. no software-based PC clients. The decision should be based on risk vs. benefits vs. threat 2.0 Conformance to Protocol Standards 2.1 Internet Protocol Security The product should support the Internet Protocol Security (IPSec) standard for encryption and authentication. This standard should support Authentication Header (AH) for authentication and Encapsulating Security Payload (ESP) for authentication and encryption. 2.2 Transport Layer Security The product should support TLS. 2.3 Secure Real-time Transport Protocol The product should support the SRTP. 2.4 MIKEY Protocol The product should support the Multimedia Internet Keying (MIKey) Protocol. This will provide a key management scheme that can be used for real-time applications and, in particular, that supports the SRTP. 2.4.1 Key Exchange If the Multimedia Internet Keying (MIKEY) protocol is used, key exchange should be implemented using the algorithms supported in section 5.0 below. 2.4.2 Key Transport Encryption If the Multimedia Internet Keying (MIKEY) protocol is used, the algorithms supported in section 5.0below should be used for key transport encryption. 2.5 Internet Key Exchange 3.0 Authentication The product should support the Internet Key Exchange (IKE) standard for key exchange. This will ensure that the shared symmetric session encryption key is established in a secure manner. 12

Product Name: Item Security Features Checklist for VOIP Products 3.1 Passwords The product should support the departmental / agency security policy or guideline. 3.1.1 Long Passwords on End-User Handsets The product should support the use of long passwords or Personal Identification Numbers (PINs), at least 6 numbers in length, on end-user handsets that only have a telephone keypad. 3.1.2 Password Compatibility Where passwords are used, the product should support a choice of password length and format that is compliant with the corporate password policy. 3.1.3 Password Lockout The product should be configurable to allow locking out a user after a number of failed attempts to log in. 3.1.3.1 Password Lockout - Number of Failed Attempts The product should be configurable to allow an administrator to set the number of failed attempts allowed by a user before the user is logged out. 3.1.3.2 Password Lockout Length of Lockout Period The product should be configurable to allow an administrator to set the length of time a user is locked out after repeated failed login attempts. 3.2 Public Key Infrastructure Based Authentication The product should support integration with a Public Key Infrastructure (PKI) that conforms to the PKI standards at Item 4.0 below or to relevant departmental standards. his will provide strong authentication through public key cryptography, and if conformant to Government of Canada (GC) PKI standards, will likely support interoperability with other GC departments. 3.3 Multi-factor Authentication The product should support 2-factor or 3-factor authentication of the user. 4.0 Public Key Infrastructure Standards 4.1 X.509 The product should support the International Telecommunication Union (ITU) X.509 standard for public key certificates, and should support an appropriate X.509 compliant repository for those certificates. This will help ensure that the product will integrate well into the networking infrastructure and ensures the PKI is scalable and based upon industry standards. 4.2 LDAP Repository The product should support integrations with a Lightweight Directory Access Protocol (LDAP) database. This will help ensure that the product will integrate well into a PKI infrastructure. 4.3 Certificate Revocation The product should support the revocation of certificates either through the posting of Certificate Revocation Lists (CRLs) (RFC 3280) in a public repository, or the on-line access to revocation information using Online Certificate Status Protocol (OCSP) (RFC 2560). 13

Product Name: Item Security Features Checklist for VOIP Products 4.4 Cryptographic Algorithms The product should support the algorithms specified at Item 5.0below. This will ensure compliance with GC policy for the encryption of sensitive information and the digital signature of committal information. 5.0 Cryptographic Standards 5.1 Encryption Algorithms The product should use one of the following encryption algorithms approved by CSEC for the use of the Government of Canada for encrypting protected information: Advanced Encryption Standard (AES) with key length of 128, 192, or 256 bits Triple- Data Encryption Standard (3DES) with 2- or 3-key option 5.2 Key Establishment Algorithms The product should use one of the following algorithms approved by CSEC for the use of the Government of Canada for the establishment of encryption keys: Rivest, Shamir, Adleman (RSA) Other algorithms based on exponentiation of finite fields (e.g., Diffie-Hellman) Key Exchange Algorithm (KEA) Elliptic Curve algorithms For the first two, the modulus should be a minimum of 1024 bits in length; this should increase to 2048 bits by the end of 2010. For Elliptic Curve algorithms over a prime field, the elliptic curve size should be a minimum of 192 bits in length. For EC algorithms over a binary field, the degree of the field should be a minimum of 163 bits in length. These numbers should increase to 256 bits and 283 bits respectively by the end of 2010. 5.3 Digital Signature Algorithms The product should use one of the following algorithms approved by CSEC for the use of the Government of Canada for digital signature applications: RSA Digital Signature Algorithm (DSA) Other algorithms based on exponentiation of finite fields (e.g., El-Gamal) Elliptic Curve (EC) Digital Signature Algorithm (ECDSA) For EC algorithms over a prime field, the elliptic curve size should be a minimum of 192 bits in length. For EC algorithms over a binary field, the degree of the field should be a minimum of 163 bits in length. These numbers should increase to 256 bits and 283 bits respectively by the end of 2010. 5.4 Hashing Algorithms If applicable, the product should use one of the following hash algorithms approved by CSEC for the use of the Government of Canada: Secure Hash Algorithm 1 (SHA-1) SHA-224 SHA-256 SHA-384 SHA-512 14

Product Name: Item Security Features Checklist for VOIP Products 5.5 Cryptoperiod If applicable, the product should allow cryptographic keys used by the product to be changed at intervals no greater than the specified interval approved by CSEC for each cryptographic algorithm. 6.0 Assurance Standards 6.1 Federal Information Processing Standards The product should implement cryptographic module validated by the Cryptographic Module Validation Program to one of the following standards: FIPS 140-1 FIPS 140-2 6.2 Cryptographic Algorithm Validation Program The cryptographic module should implement cryptographic algorithms validated by the Cryptographic Algorithm Validation Program to the specified standard. 6.3 Common Criteria Evaluation Assurance Level For products evaluated under the Common Criteria, the product should meet Evaluation Assurance Level (EAL) 3 or higher. 6.3.1 Protection Profile or Security Target For products evaluated under the Common Criteria, the product should be evaluated to a Protection Profile or Security Target that addresses security features that are relevant to the organization. 7.0 Configurability 7.1 Changeable Default Values Where default security settings exist, the product should be configurable to change default values, and the default values should be changed upon installation. This will prevent unauthorized users connecting to or using the product by logging in or connecting using the factory default values. 7.2 Allow or Disallow Encryption The product should be configurable to ensure that encryption can be enabled when required, and this capability should be enabled upon installation. This will ensure that only authorized users and administrators have access to the information processed by the product. 7.3 Allow or Disallow Authentication The product should be configurable to ensure that authentication can be enabled when required, and this capability should be enabled upon installation. This will ensure that only authorized users and administrators have access to the functionality of the product. 7.4 Logging The product should be configurable to log transactions in accordance with the organization s security policies. This capability should be enabled in accordance with the organization s security policies upon installation. 15

Product Name: Item Security Features Checklist for VOIP Products 8.0 Usability 8.1 Configuration by Users The product should not require any configuration by users. This prevents users from misconfiguring the product, and ensures that they will use the product appropriately and not look for ways to get around using it. 8.2 Authentication by Users The product should demand no more than a single authentication transaction by the user prior to becoming fully functional. 8.3 Maintenance by Administrators 8.4 Failed logins The product should require no more maintenance and support than a standard commercial server operating system. Administrator should be able to set the maximum number of failed logins. This number should be adjustable based on policy. 8.5 Reconfiguration by Administrators The product should not require daily or weekly reconfiguration by administrators, following an initial configuration period of several months. 8.6 Password Recovery (Self-help) The product should provide a self-help password recovery mechanism. 8.6.1 Password Recovery Question If a password recovery question is used, the user should not be allowed to specify the wording of the question. 8.7 Password Recovery (Administrator-assisted) 9.0 Manageability The product should provide an administrator-assisted password recovery mechanism. 9.1 Central Management The product should be capable of being centrally managed and administered on a TCP/IP network. This will ensure that the product can be supported without having to physically access each product device on the network. 9.2 Authentication of Management Traffic All administrative and management traffic between the central console and the distributed products is to be authenticated according to the authentication standards given at Item 3.0 above. This will ensure that unauthorized users cannot change the configuration of the products on the network. 9.3 Encryption of Management Traffic All administrative and management traffic between the central console and the distributed products is to be encrypted according to the cryptographic standards given at Item 5.0 above. This will ensure that unauthorized users cannot access product information or sensitive information gathered by the products on the network. 16

Product Name: Item Security Features Checklist for VOIP Products 10.0 Scalability 10.1 The product should be capable of scaling to service small organizational networks (i.e. supporting less than 500 users) to large organizational networks (i.e. supporting 50,000 users or more). 17