This document may be freely distributed in its entirety without modification
FIPS 140-2 Level 2 Security Policy
For
AX Series Advanced Traffic Manager AX2500,
AX2600-GCF, AX3000-11-GCF, AX5100,
AX5200-11, AX1030, AX3030, AX3400,
AX3200-12, AX3530 and AX5630, and Thunder
Series Application Delivery Controller TH1030S,
TH3030S, TH5430S, and TH6430S
Document Version 0.9
Non-Proprietary Security Policy for AX Series and Thunder Series 2
Table of Contents
1 Module Description......................................................................................................3
2 Cryptographic Boundary ..............................................................................................4
3 Ports and Interfaces ......................................................................................................8
4 Roles, Services and Authentication...............................................................................9
5 Security Functions......................................................................................................10
6 Key Management .......................................................................................................11
7 Self Tests....................................................................................................................12
8 Physical Security........................................................................................................13
9 Secure Operation........................................................................................................13
9.1 Approved Mode of Operation ..............................................................................13
Non-Proprietary Security Policy for AX Series and Thunder Series 3
1 Module Description
A10 Networks' AX Series and Thunder Series is a traffic manager designed to help
enterprises and ISPs with application availability through a Web Application Delivery
Platform. These AX Series and Thunder Series appliances are integrated 64-bit models.
Commonly, clients and servers use Hypertext Transfer Protocol Secure (HTTPS) 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.
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 HTTPS
handshake. The module will respond with a digital certificate. From the client’s
perspective, this certificate comes from the server. Once the HTTPS handshake is
complete, the client begins an encrypted client-server session with the module.
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 the module. There is no need to wait
for DNS entries to propagate for new servers. A new server can be added to the
configuration for the virtual server, and the new real server should then become
accessible immediately.
The module supports SSH, HTTPS, and console management interfaces.
Non-Proprietary Security Policy for AX Series and Thunder Series 4
For the purposes of FIPS 140-2 the AX Series Advanced Traffic Manager or Thunder
Series Application Delivery Controller 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 R261-GR1-P7 or R270-P2
AX Series Advanced Traffic Manager AX2600-GCF R261-GR1-P7 or R270-P2
AX Series Advanced Traffic Manager AX3000-11-GCF R261-GR1-P7 or R270-P2
AX Series Advanced Traffic Manager AX5100 R261-GR1-P7 or R270-P2
AX Series Advanced Traffic Manager AX5200-11 R261-GR1-P7 or R270-P2
AX Series Advanced Traffic Manager AX1030 R270-P2
AX Series Advanced Traffic Manager AX3030 R270-P2
AX Series Advanced Traffic Manager AX3400 R270-P2
AX Series Advanced Traffic Manager AX3200-12 R270-P2
AX Series Advanced Traffic Manager AX3530 R270-P2
AX Series Advanced Traffic Manager AX5630 R270-P2
Thunder Series Application Delivery Controller TH1030S R271-P2
Thunder Series Application Delivery Controller TH3030S R271-P2
Thunder Series Application Delivery Controller TH5430S R271-P2
Thunder Series Application Delivery Controller TH6430S R271-P2
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
Non-Proprietary Security Policy for AX Series and Thunder Series 5
Figure 2. AX Series Advanced Traffic Manager AX2600-GCF
Figure 3. AX Series Advanced Traffic Manager AX3000-11-GCF
Figure 4. AX Series Advanced Traffic Manager AX5100
Figure 5. AX Series Advanced Traffic Manager AX5200-11
Figure 6. AX Series Advanced Traffic Manager AX1030
Non-Proprietary Security Policy for AX Series and Thunder Series 6
Figure 7. AX Series Advanced Traffic Manager AX3030
Figure 8. AX Series Advanced Traffic Manager AX3400
Figure 9. AX Series Advanced Traffic Manager AX3200-12
Figure 10. AX Series Advanced Traffic Manager AX3530
Figure 11. AX Series Advanced Traffic Manager AX5630
Non-Proprietary Security Policy for AX Series and Thunder Series 7
Figure 12. Thunder Series Application Delivery Controller TH1030S
Figure 13. Thunder Series Application Delivery Controller TH3030S
Figure 14. Thunder Series Application Delivery Controller TH5430S
Figure 15. Thunder Series Application Delivery Controller TH6430S
Non-Proprietary Security Policy for AX Series and Thunder Series 8
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-11-GCF: 21
AX5100: 13
AX5200-11: 21
AX1030:9
AX3030:11
AX3400:29
AX3200-12:29
AX3530:20
AX5630:34
TH1030S:12
TH3030S:14
TH5430S:22
TH6430S:22
Serial Console Port 1 Control Input, Status output,
Data Output
USB Ports AX2500: 1 Disabled
AX2600-GCF: 1
AX3000-11-GCF:1
AX5100: 2
AX5200-11: 2
AX1030:2
AX3030:2
AX3400:2
AX3200-12:2
AX3530:1
AX5630:1
TH1030S:1
TH3030S:1
TH5430S:1
TH6430S:1
Power Switch 1 Control Input
Alarm off button AX3030:0 Control Input
TH3030S:0
AX1030:0
TH1030S:0
All other: 1
Non-Proprietary Security Policy for AX Series and Thunder Series 9
Port Name Count Interface(s)
Power Port AX1030:1 Power Input
TH1030S:1
AX5630:3
All other: 2
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. RSA keys can be used for connections via SSH.
The module uses passwords of at least 8 characters, or at least
1024 bit RSA key, 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 and Thunder Series 10
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
network connection
User TLS keys: E
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, 2013
HMAC 985, 1011, 1016, 1017, 1444
Triple DES 1092, 1124, 1128, 1129, 1463
AES 1693, 1739, 1740, 2329
RSA Sign/verify 829, 858, 862, 863, 1202
ANSI X9.31 PRNG 900, 1088
The module implements the following non-Approved cryptographic algorithms that are
allowed in the Approved mode for protection of sensitive data:
Non-Proprietary Security Policy for AX Series and Thunder Series 11
Algorithm Usage
Diffie-Hellman Used for key establishment in SSH version 2 handshake.
Provides between 80 or 112 bits of encryption strength.
RSA encrypt/decrypt Used for key establishment in TLS handshake. Provides 80 bits
of encryption strength.
The module also implements other cryptographic algorithms:
Algorithm Usage
MD5 Used by RADIUS
Used by the SNMP protocol
HMAC-MD5 Used by the SNMP protocol
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
encryption key and TLS
HMAC key
Plaintext in RAM
TLS Triple-DES or AES
encryption key
Used to encrypt data in TLS
protocol
Plaintext in RAM
TLS HMAC key Used to protect integrity of
data in TLS protocol
Plaintext in RAM
TLS server RSA certificate
and private key
Used to encrypt the TLS
master secret during the
TLS handshake
Plaintext in RAM
Plaintext in flash
SSH Diffie-Hellman keys Used for key establishment
during the handshake
Plaintext in RAM
Certification Authority RSA
Certificate
Used to verify client
certificate during the TLS
handshake
Plaintext in RAM
Plaintext in flash
SSH RSA key pair Used for authentication
during the SSH handshake
Plaintext in RAM
Plaintext in flash
SSH master secret Used to derive SSH
encryption key and SSH
HMAC key
Plaintext in RAM
SSH Triple-DES or AES
encryption keys
Used to encrypt SSH data Plaintext in RAM
SSH HMAC keys Used to protect integrity of
SSH data
Plaintext in RAM
Non-Proprietary Security Policy for AX Series and Thunder Series 12
Name and type Usage Storage
ANSI X9.31 PRNG1 Seed
and Seed Key
Used to initialize the PRNG
to a random state
Plaintext in RAM
ANSI X9.31 PRNG2 Seed
and Seed Key
Used to initialize the PRNG
to a random state
Plaintext in RAM
Firmware load verification
HMAC SHA-1 Key
Used to verify firmware
components
Plaintext in RAM
Plaintext in flash
Passwords Used to authenticate users Plaintext in RAM
Plaintext in flash
SNMP Secret Used to authenticate Crypto
Officers accessing SNMP
management interface
Plaintext in RAM
Plaintext in flash
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 and Thunder Series 13
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.
The module generates cryptographic keys whose strengths are modified by available
entropy – 160-bits.