FIPS 140-2 Level 2 Security Policy For AX Series Advanced Traffic Manager AX2500, AX2600-GCF, AX3000-GCF, AX5100 and AX5200 Document Version 0.3 This document may be freely distributed in its entirety without modification Non-Proprietary Security Policy for AX Series Advanced Traffic Manager 2 Table of Contents 1 Module Description......................................................................................................3 2 Cryptographic Boundary ..............................................................................................4 3 Ports and Interfaces ......................................................................................................5 4 Roles, Services and Authentication...............................................................................6 5 Security Functions........................................................................................................7 6 Key Management .........................................................................................................8 7 Self Tests......................................................................................................................9 8 Physical Security........................................................................................................10 9 Secure Operation ........................................................................................................10 9.1 Approved Mode of Operation ..............................................................................10 Non-Proprietary Security Policy for AX Series Advanced Traffic Manager 3 1 Module Description A10 Networks' AX Series is a traffic manager designed to help enterprises and ISPs with application availability through a Web Application Delivery Platform. These AX Series appliances are integrated 64-bit models. Commonly, clients and servers use Transport Layer Security (TLS) to secure traffic. Hardware acceleration is used for TLS encryption of data. For example, a client that is using a shopping application on a server will encrypt data before sending it to the server. The server will decrypt the client’s data, and then send an encrypted reply to the client. The client will decrypt the server reply, and so on. The AX devices support TLS version 1.0. TLS works using certificates and keys. Typically, a client will begin a secure session by sending an HTTPS request to a virtual endpoint. The request begins an TLS handshake. The AX device will respond with a digital certificate. From the client’s perspective, this certificate comes from the server. Once the TLS handshake is complete, the client begins an encrypted client-server session with the AX device. Server farms can easily be grown in response to changing traffic flow, while protecting the servers behind a common virtual endpoint. From the perspective of a client who accesses services, requests go to and arrive from a single endpoint. The client is unaware that the server is in fact multiple servers managed by an AX device. There is no need to wait for DNS entries to propagate for new servers. A new server can be added to the AX configuration for the virtual server, and the new real server should then become accessible immediately. The TOE supports SSH and HTTPS management interfaces. Non-Proprietary Security Policy for AX Series Advanced Traffic Manager 4 The module supports SSH, HTTPS, and console management interfaces. For the purposes of FIPS 140-2 the AX Series Advanced Traffic Manager is classified as multi-chip standalone module. FIPS 140-2 conformance testing of the module was performed at Security Level 2. The following configurations were tested: Module Name and Version Firmware versions AX Series Advanced Traffic Manager AX2500 2.6.1-P2 build 28 AX Series Advanced Traffic Manager AX2600-GCF 2.6.1-P2 build 28 AX Series Advanced Traffic Manager AX3000-GCF 2.6.1-P2 build 28 AX Series Advanced Traffic Manager AX5100 2.6.1-P2 build 28 AX Series Advanced Traffic Manager AX5200 2.6.1-P2 build 28 2 Cryptographic Boundary The hardware and firmware components of the module are enclosed in a metal enclosure which is the cryptographic boundary of the module. The removable panels of the enclosure are protected by tamper-evident labels. The enclosure is opaque within the visible spectrum. An image of the module is provided below: Figure 1. AX Series Advanced Traffic Manager AX2500 Figure 2. AX Series Advanced Traffic Manager AX2600-GCF Non-Proprietary Security Policy for AX Series Advanced Traffic Manager 5 Figure 3. AX Series Advanced Traffic Manager AX3000-GCF Figure 4. AX Series Advanced Traffic Manager AX5100 Figure 5. AX Series Advanced Traffic Manager AX5200 3 Ports and Interfaces The module includes the following physical ports and logical interfaces. Port Name Count Interface(s) Ethernet Port AX2500: 13 Data Input, Data Output, Control Input, Status Output AX2600-GCF: 25 AX3000-GCF: 21 AX5100: 13 AX5200: 21 Serial Console Port 1 Control Input, Status output, Data Output Non-Proprietary Security Policy for AX Series Advanced Traffic Manager 6 Port Name Count Interface(s) USB Ports AX2500: 1 Disabled AX2600-GCF: 1 AX3000-GCF: 1 AX5100: 2 AX5200: 2 Power Switch 1 Control Input Alarm off button 1 Control Input Power Port 2 Power Input LEDs correspond to the Status output interface. 4 Roles, Services and Authentication The module provides the following roles: a User role and Crypto Officer role. The Crypto Officers initialize and manage the module. Users employ the cryptographic services provided by the module. The table below provides information on authentication mechanisms employed by each role. Role Authentication Mechanism User Client Certificates are used for user authentication. The module uses client certificates with at least 1024 bit RSA key, which corresponds to 80 bits of security, therefore the probability is less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur. For multiple attempts to use the authentication mechanism during a one-minute period, the probability is less than one in 100,000 that a random attempt will succeed or a false acceptance will occur due to the authentication process performance limitation. Crypto Officer Passwords are used for connections via Console, SSH, and Web User Interface. The module uses passwords of at least 8 characters, therefore the probability is less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur. For multiple attempts to use the authentication mechanism during a one-minute period, the probability is less than one in 100,000 that a random attempt will succeed or a false acceptance will occur due to the authentication process performance limitation. Non-Proprietary Security Policy for AX Series Advanced Traffic Manager 7 The module provides the following services to the operators: Service Role Access to Cryptographic Keys and CSPs R- read; W – write or generate; E-execute Installation of the Module Crypto Officer Password: W TLS server certificate: W SSH keys: E ANSI X9.31 seed and key: E Login Crypto Officer Password: E SSH Keys: E TLS Keys: E ANSI X9.31 seed and key: E Run self-test Crypto Officer N/A Show status Crypto Officer N/A Reboot Crypto Officer N/A Update firmware Crypto Officer Firmware load verification HMAC SHA-1 firmware load verification key: E Zeroize Crypto Officer All keys: W Establishment of secure User TLS keys: E network connection TLS Certificate: E ANSI X9.31 seed and key: E 5 Security Functions The table below lists approved cryptographic algorithms employed by the module. Algorithm Certificate Number SHS 1480, 1519, 1524, 1525 HMAC 985, 1011, 1016, 1017 Triple DES 1092, 1124, 1128, 1129 AES 1693 AES 1 1739, 1740 RSA Sign/verify 829, 858, 862, 863 ANSI X9.31 PRNG 900, 933 1 The maximum allowed key length is 128 bits. Larger AES key sizes shall not be used. Non-Proprietary Security Policy for AX Series Advanced Traffic Manager 8 The table below lists non-Approved cryptographic algorithms employed by the module Algorithm Usage MD5 Used by RADIUS Used during TLS handshake Used by the SNMP2 protocol Used by the SNMP2 protocol HMAC-MD5 Diffie-Hellman Used for key establishment in SSH version 2 handshake. Provides between 80 and 112 bits of encryption strength. RSA encrypt/decrypt Used for key establishment in TLS handshake. Provides 80 bits of encryption strength. 6 Key Management The following cryptographic keys and CSPs are supported by the module. Name and type Usage Storage TLS master secret Used to derive TLS data Plaintext in RAM encryption key and TLS HMAC key TLS Triple-DES or AES Used to encrypt data in TLS Plaintext in RAM encryption key protocol TLS HMAC key Used to protect integrity of Plaintext in RAM data in TLS protocol TLS server RSA certificate Used to encrypt the TLS Plaintext in RAM and private key master secret during the Plaintext in flash TLS handshake SSH Diffie-Hellman keys Used for key establishment Plaintext in RAM during the handshake Certification Authority RSA Used to verify client Plaintext in RAM Certificate certificate during the EAP- Plaintext in flash TLS handshake SSH RSA key pair Used to authenticate the Plaintext in RAM module to the SSH client Plaintext in flash during the SSH handshake SSH master secret Used to derive SSH Plaintext in RAM encryption key and SSH HMAC key SSH Triple-DES or AES Used to encrypt SSH data Plaintext in RAM encryption keys SSH HMAC keys Used to protect integrity of Plaintext in RAM SSH data 2 Non-sensitive data only . Non-Proprietary Security Policy for AX Series Advanced Traffic Manager 9 Name and type Usage Storage ANSI X9.31 PRNG1 Seed Used to initialize the PRNG Plaintext in RAM and Seed Key to a random state ANSI X9.31 PRNG2 Seed Used to initialize the PRNG Plaintext in RAM and Seed Key to a random state Firmware load verification Used to verify firmware Plaintext in RAM HMAC SHA-1 Key components Plaintext in flash Passwords Used to authenticate users Plaintext in RAM Plaintext in flash SNMP Secret Used to authenticate Crypto Plaintext in RAM Officers accessing SNMP Plaintext in flash management interface 7 Self Tests The module runs a set of self-tests on power-up. If one of the self-tests fails, the module transitions into an error state where all data output and cryptographic operations are disabled. The module runs power-up self-tests for the following algorithms: Algorithm Test AES Known Answer Test TDES Known Answer Test SHS Known Answer Test HMAC Known Answer Test ANSI X9.31 PRNG Known Answer Test RSA Known Answer Test Firmware integrity HMAC-SHA-1 of the firmware image During the module operation the following conditional self-tests are performed: Condition Test Random Number Generation Continuous PRNG Test Firmware Load Firmware Load Test using HMAC SHA1 RSA Key Pair generation Pairwise Consistency Check (Sign/Verify, Encrypt/Decrypt) Non-Proprietary Security Policy for AX Series Advanced Traffic Manager 10 8 Physical Security The module consists of production-grade components enclosed in a metal enclosure. The enclosure is opaque within the visible spectrum. The module is protected by tamper evident labels in accordance with FIPS 140-2 Level 2 Physical Security requirements. The tamper evident labels are applied at the factory to provide evidence of tampering if a panel is removed. The Crypto Officer must check the integrity of the tamper evident labels upon receipt of the module and periodically thereafter. Upon discovery of tampering the Crypto Officer must immediately disable the module and return the module to the manufacturer. 9 Secure Operation 9.1 Approved Mode of Operation The module is intended to always operate in the Approved Mode of Operation. Module documentation provides detailed setup procedures and guidance for the users and administrators. Module users and administrators shall keep all authentication data confidential and shall not allow unauthorized access to the module. Module users shall not use AES key sizes larger than 128 bits.