XSR-1805, XSR-1850, and XSR-3250 (Hardware Version: REV 0A-G, Software Version: REL 6.3, Firmware Version: REL 6.3) FIPS 140-2 Non-Proprietary Security Policy Level 2 Validation Version 1.00 September 2003 © Copyright 2003 Enterasys Networks This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Table of Contents INTRODUCTION............................................................................................................. 3 PURPOSE ....................................................................................................................... 3 REFERENCES ................................................................................................................. 3 DOCUMENT ORGANIZATION ............................................................................................. 3 ENTERASYS NETWORKS XSR-1805, XSR-1850, AND XSR-3250 ............................. 5 OVERVIEW ..................................................................................................................... 5 CRYPTOGRAPHIC MODULE .............................................................................................. 6 MODULE INTERFACES ..................................................................................................... 8 ROLES AND SERVICES ................................................................................................... 11 Crypto Officer Role.................................................................................................. 11 User Role ................................................................................................................ 14 Authentication Mechanisms .................................................................................... 14 PHYSICAL SECURITY ..................................................................................................... 14 OPERATIONAL ENVIRONMENT ........................................................................................ 14 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................. 16 Key Generation ....................................................................................................... 18 Key Establishment................................................................................................... 18 Key Entry and Output .............................................................................................. 18 Key Storage ............................................................................................................ 19 Key Zeroization ....................................................................................................... 19 SELF-TESTS ................................................................................................................. 20 DESIGN ASSURANCE ..................................................................................................... 21 MITIGATION OF OTHER ATTACKS .................................................................................... 21 SECURE OPERATION ................................................................................................. 22 CRYPTO OFFICER GUIDANCE ......................................................................................... 22 Initial Setup ............................................................................................................. 22 Management ........................................................................................................... 23 USER GUIDANCE .......................................................................................................... 24 ACRONYMS ................................................................................................................. 25 © Copyright 2003 Enterasys Networks Page 2 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Introduction Purpose This document is a nonproprietary Cryptographic Module Security Policy for the Enterasys Networks XSR-1805, XSR-1850, and XSR-3250 appliances. This security policy describes how the XSR-1805, XSR-1850, and XSR-3250 meet the security requirements of FIPS 140-2 and how to run the modules in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 2 FIPS 140-2 validation of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 -- Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the NIST Web site at http://csrc.nist.gov/cryptval/. The Enterasys Networks XSR-1805, XSR-1850, and XSR-3250 appliances are referenced in this document as X-Pedition Security Routers, XSR modules, and the modules. The XSR-1805 and XSR-1850 modules are also referenced as the XSR-18xx modules. The differences between the three modules are cited where appropriate. References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: The Enterasys Networks Web site (http://www.enterasys.com/) contains information on all Enterasys Networks products. The NIST Validated Modules Web site (http://csrc.ncsl.nist.gov/cryptval/) contains contact information for answers to technical or sales-related questions for the module. Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: Vendor Evidence document Finite State Machine Other supporting documentation as additional references © Copyright 2003 Enterasys Networks Page 3 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to Enterasys Networks. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Enterasys Networks and can be released only under appropriate non-disclosure agreements. For access to these documents, please contact Enterasys Networks. © Copyright 2003 Enterasys Networks Page 4 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ENTERASYS NETWORKS XSR-1805, XSR-1850, AND XSR-3250 Overview Part of the Enterasys Networks X-Pedition Security Router (XSR) series, the XSR-1805, XSR-1850, and XSR-3250 modules are networking devices that combine a broad range of IP routing features, a broad range of WAN interfaces and a rich suite of network security functions, including site-to-site and remote access VPN connectivity and policy managed, stateful-inspection firewall functionality. The XSR-18xx modules were designed to meet the requirements of the branch office, while the XSR-3250 was specifically designed for the regional office. A typical deployment of the modules is shown in Figure 1 below. Figure 1 ­ Typical Deployment of the XSR Modules The XSR-1805 is an entry-level, modular router in a desktop form factor delivering powerful performance and features to address the WAN, VPN, and firewall needs of remote offices. The XSR-1850 varies mainly in its performance and type of enclosure, when compared to the XSR-1805. Delivering faster performance; a rack- mount form factor; and the option for redundant power, the XSR-1850 is © Copyright 2003 Enterasys Networks Page 5 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ideal to support mission- critical applications extending to the branch office. The XSR-3250 offers nearly ten times the performance speed of the XSR- 1850 and approximately 15 times more VPN tunnels. Coupling these features with the six network interface module (NIM) slots makes the XSR- 3250 ideally suited to a regional office required to terminate up to six T3/E3 or 24 T1/E1 connections. A redundant power supply is included. The features of each XSR module are summarized in Table 1. XSR Model XSR-1805 XSR-1850 XSR-3250 NIM Slots 2 2 6 Fixed 10/100/1000 LAN 2 10/100 2 10/100 3 Ports Optional Gigabit N/A N/A Mini-GBIC Ethernet Redundant Power No Option Standard Supplies VPN Accelerator Embedded Embedded Embedded Flash Memory 8 MB 8 MB 8 MB (upgradeable) (upgradeable) DRAM 32 MB 64 MB 256 MB (upgradeable) (upgradeable) (upgradeable) External Compact Flash Yes Yes Yes Table 1 - Features At-a-Glance Some highlighted security features of the XSR modules are: · Telnet over IPSec or SSHv2-secured remote management of the modules · Site-to-Site application VPN using IPSec · Remote access VPN using L2TP over IPSec · Access control through assigned privilege level · User, certificate, and host key database files encrypted with a master encryption key Cryptographic Module The XSR modules were evaluated as multi-chip standalone cryptographic modules. The metal enclosure physically encloses the complete set of hardware and software components, and represents the cryptographic boundary of each module. © Copyright 2003 Enterasys Networks Page 6 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The hardware components for the XSR-18xx modules vary slightly to meet the performance level for each module. The XSR-1850 is an enhancement of the XSR-1805 consisting of the following additional features: · Two fans · External power source connector · One PMC slot for PPMC card · 19" 1.5 U rack-mount chassis · 64 MB of DRAM Due to the large difference in performance levels, the XSR-3250 hardware components vary quite significantly, when compared to the XSR-18xx modules. The main differences include the following: · Different processor with two CPU cores · Different hardware encryption accelerator · Two extra NIM Carrier Cards (NCC) slots with two NIM slots on each card · One extra Ethernet port connected to both a miniGBIC module and a RJ45 connector · Dual load-sharing power supplies · Redundant fans · 256 MB of DRAM XSR NIMs will operate on all three XSR modules. All three modules use the software version XSR Release 6.3. The modules software components consists of three separate executables linked individually: · Bootrom · Power-up Diagnostics · Software image © Copyright 2003 Enterasys Networks Page 7 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. The software image is contained in a single file with the power-up diagnostics. It is based on the Nortel Open IP design model and runs on top of the VxWorks operating system. The modules are intended to meet overall FIPS 140-2 Level 2 requirements (see Table 2). Section Section Title Level 1 Cryptographic Module Specification 2 2 Cryptographic Module Ports and Interfaces 2 3 Roles, Services, and Authentication 2 4 Finite State Model 2 5 Physical Security 2 6 Operational Environment N/A 7 Cryptographic Key Management 2 8 EMI/EMC 2 9 Self-tests 2 10 Design Assurance 2 11 Mitigation of Other Attacks N/A Table 2 ­ Intended Level Per FIPS 140-2 Section Module Interfaces The XSR-1805 provides a number of physical ports: · Two 10/100BaseT FastEthernet LAN ports · One console port · Two PCM slots · One PCMCIA slot for the optional CompactFlash card © Copyright 2003 Enterasys Networks Page 8 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. · Ten status LEDs · One power connector · One power switch · One default configuration button The XSR-1850 implements the same physical ports as the XSR-1805 and the following additional ones: · External power source connector · PPMC slot for Processor The XSR-3250 varies to the XSR-1805 modules as follows: · One additional power source connector © Copyright 2003 Enterasys Networks Page 9 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. · Three 10/100/1000BaseT GigabitEthernet LAN ports with two LEDs on each port, instead of the two 10/100BaseT FastEthernet LAN ports · Mini-Gigabit Interface Converter (MGBIC) fiberoptic port plus two LEDs · Two NCC slots with two NIM slots on each card · No power switch · No default configuration button All of these physical ports are separated into logical interfaces defined by FIPS 140-2, as described in Table 3: Module Physical Ports FIPS 140-2 Logical Interface Network ports Data input interface Network ports Data output interface Network ports, console port, Control input interface power switch (XSR-18xx only), default button (XSR-18xx only) Network ports, console port, Status output interface LEDs Power connector(s) Power interface Table 3 ­ FIPS 140-2 Logical Interfaces Data input and output, control input, and status output are defined as follows: · Data input and output are the packets that use the firewall, VPN, and routing functionalities of the modules. · Control input consists of manual control inputs for power and reset through the power and reset switch. It also consists of all of the data that is entered into the module while using the management interfaces. · Status output consists of the status indicators displayed through the LEDs and the status data that is output from the modules while using the management interfaces. The modules distinguish between different forms of data, control, and status traffic over the network ports by analyzing the packets header information and contents. © Copyright 2003 Enterasys Networks Page 10 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Roles and Services The module supports role-based and identity-based authentication1. There are two main roles in the module (as required by FIPS 140-2) that operators may assume: a Crypto Officer role and User role. Crypto Officer Role The Crypto Officer role has the ability to configure, manage, and monitor the module. Three management interfaces can be used for this purpose: · CLI ­ The Crypto Officer can use the CLI to perform non-security- sensitive and security-sensitive monitoring and configuration. The CLI can be accessed locally by using the console port or remotely by using Telnet over IPSec or the SSHv2 secured management session. · SNMP ­ The Crypto Officer can use SNMPv3 to remotely perform non-security-sensitive monitoring and configuration. · Bootrom Monitor Mode ­ In Bootrom monitor mode, the Crypto Officer can reboot, update the Bootrom, issue file system-related commands, modify network parameters, and issue various show commands. The Crypto Officer can only enter this mode by pressing the key combination CTRL-C during the first five seconds of initialization. It can also be entered if Bootrom cannot find a valid software file. Due to the different privilege levels (0-15) that can be assigned to each user, the Crypto Officer role can be split into different types of management users: · Super Crypto Officer ­ Management users with a privilege level of 15 assume the Super Crypto Officer role. Since 15 is the highest privilege level available, the Super Crypto Officer can issue all the configuration and monitoring commands available through the CLI and SNMP. Only the Super Crypto Officer can enter Bootrom monitor mode. · Junior Crypto Officer ­ Management users with a privilege level of 10 assume the Junior Crypto Officer role. The Junior Crypto Officer can issue all monitoring commands with higher security level and some configuration commands. Examples of commands are: show running-config and show interfaces, and all SNMP show commands. 1 Please note that overall the modules meet the level 2 requirements for Roles and Services. © Copyright 2003 Enterasys Networks Page 11 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. · Read-only Crypto Officer ­ Management users with privilege level zero assume the Read-only Crypto Officer role. The Read-only Crypto Officer can only issue monitoring commands with low security level. Examples of commands are: show version and show clock. Descriptions of the services available to the Crypto Officer role are provided in the table below. Service Description Input Output Critical Security Parameter (CSP) Access SSH Provide SSH key SSH outputs and DSA (SSHv2) host authenticated and agreement data key pair (read encrypted remote parameters, SSH access), Diffie- management inputs, and data Hellman key pair sessions while (read/write using the CLI access), session key for SSH (read/write access), PRNG keys (read access); Crypto Officer's password (read access) IKE/IPSec Provide IKE inputs and IKE outputs, RSA key pair for authenticated and data; IPSec inputs, status, and data; IKE (read access), encrypted remote commands, and IPSec outputs, Diffie-Hellman key management data status, and data pair for IKE sessions while (read/write using Telnet to access), pre- access the CLI shared keys for functionality IKE (read access); Session keys for IPSec (read/write access) SNMP Non-security- Commands and Status of Crypto Officer's sensitive configuration data commands, SNMP password monitoring and configuration data (read/write access) configuration using SNMPv3 (with standard MIB-II and proprietary MIB support) Bootrom Monitor Reboot, update the Commands and Status of Crypto Officer's Mode Bootrom, issue file configuration data commands, Bootrom password system-related configuration data (read/write access) commands, modify network parameters, and issue various show commands Configuring Create or specify Commands and Status of Master encryption Network master encryption configuration data commands and key (read/write © Copyright 2003 Enterasys Networks Page 12 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Management key; create DSA configuration data access), DSA host host key for key pair (read/write SSHv2; create access), Crypto management users Officer's password and set their for CLI and SNMP password and (read/write access) privilege level; configure the SNMP agent Configuring the Define the T1/E1 Commands and Status of None T1/E1 Subsystem subsystem configuration data commands and Interfaces functionality configuration data Configuring the Define the platform Commands and Status of None XSR Platform subsystem configuration data commands and software of the configuration data module by entering Bootrom Monitor Mode, File System, fault report, message logging, and other platform related commands Configuring Define Commands and Status of None Hardware synchronization configuration data commands and Controllers features for module configuration data Configuring the Set IP functionality Commands and Status of None Internet Protocol configuration data commands and configuration data Configuring Frame Define Frame Commands and Status of None Relay Relay interface configuration data commands and features configuration data Configuring ISDN Configure BRI/PRI Commands and Status of None functionality on configuration data commands and module configuration data Configuring Quality Configure QOS Commands and Status of None of Service (QOS) values for module configuration data commands and configuration data Configuring the Configure Public Commands and Status of RSA keys pair VPN Key Infrastructure configuration data commands and (read/write (PKI); configure the configuration data access), Preshared Internet Key key (read/write Exchange (IKE) access) Security Protocol; configure the IPSec protocol Configuring DHCP Configure DHCP Commands and Status of None on module configuration data commands and configuration data Configuring Define security Commands and Status of AAA user Security features for configuration data commands and password module, including configuration data (read/write Access List, AAA, access), RADIUS and firewall password functionality (read/write access) Configuring Define the Commands and Status of None. © Copyright 2003 Enterasys Networks Page 13 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Firewall authorization configuration data. commands and information for configuration data. network traffic that flows through the box. Table 4 ­ Crypto Officer Services, Descriptions, Inputs and Outputs, and CSPs User Role The User role accesses the module's IPSec and IKE services. Service descriptions, inputs and outputs, and CSPs are listed in the following table: Service Description Input Output CSP IKE Access the module IKE IKE inputs and data IKE outputs, RSA key pair for functionality to status, and data IKE (read authenticate to the access); Diffie- module and negotiate IKE Hellman key and IPSec session keys pair for IKE (read and write access); pre- shared keys for IKE (read access) IPSec Access the module's IPSec inputs, IPSec outputs, Session keys for IPSec services in order to commands, and status, and data IPSec (read and secure network traffic data write access) Table 5 ­ User Services, Descriptions, Inputs and Outputs Authentication Mechanisms The module supports role-based and identity-based authentication. Role- based authentication is performed before the Super Crypto Officer enters Bootrom monitor mode and authenticates with just a password (and no user ID). Identity-based authentication is performed for all other types of Crypto Officer and User authentication. These include password-based authentication, RSA-based authentication, and HMAC-based authentication mechanisms. The estimated strength of each authentication mechanism is described below. Authentication Type Role Strength Password-based Crypto Officer Passwords are required to be at least six authentication (CLI, SNMP, characters long. Numeric, alphabetic (upper and Bootrom monitor mode) and lowercase), and keyboard and extended characters can be used, which gives a total of 95 characters to choose from. Considering only the case-insensitive alphabet using a password with repetition, the number of potential passwords is 26^6. RSA-based authentication User RSA signing and verification is used to (IKE) authenticate to the module during IKE. This © Copyright 2003 Enterasys Networks Page 14 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. mechanism is as strong as the RSA algorithm using a 1024 bit key pair. Pre-shared key-based User HMAC SHA-1 generation and verification is authentication (IKE) used to authenticate to the module during IKE with preshared keys. This mechanism is as strong as the HMAC with SHA-1 algorithm. Additionally, preshared keys must be at least six characters long. Even if only uppercase letters were used without repetition for a six character preshared key, the probability of randomly guessing the correct sequence is one in 165,765,600. Table 6 ­ Estimated Strength of Authentication Mechanisms The firewall mechanism can only be configured by the Crypto-Officer who authorizes the traffic that flows through the module. Physical Security The XSR modules are multi-chip standalone cryptographic modules, which were tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC Rules. The modules are entirely contained within hard metal enclosures. The enclosure is resistant to probing and is opaque within the visible spectrum. The enclosures have been designed to satisfy level 2 physical security requirements. The ventilation holes on all three modules have been designed with baffling and less than 1/16th an inch diameter. Additionally, for the XSR-1850 and the XSR-3250, as soon as a cover (top or bottom) is removed, the nonvolatile RAM of the Real Time Clock chip is cleared, causing the master encryption key, which is used to encrypt user, certificate, and host key database files, to be zeroized. All three modules require tamper-evident labels to be applied to protect and to notify of any tampering with the modules. Depending on whether the NIM slots are used, the XSR-1805 requires a minimum of seven and a maximum of nine labels to be applied, the XSR-1850 requires a minimum of five and a maximum of seven labels, and the XSR-3250 requires a minimum of four and a maximum of six labels. The labels are employed by the Crypto Officer as described in the Installation Guide: Attaching XSR Security Labels. Operational Environment The operational environment requirements do not apply to these modules. The XSR modules do not provide a general-purpose operating system, but rather a non-modifiable and embedded operating system. © Copyright 2003 Enterasys Networks Page 15 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Cryptographic Key Management The modules implement the following FIPS-approved algorithms: Type Algorithm Standard Certificate Number Symmetric AES (CBC) FIPS 197 Cert. #48, #106, #107 Triple-DES (CBC and FIPS 46-3 Cert. #158, #218, #219, ECB) #220 DES (CBC) FIPS 46-3 Cert. #204, #238, #239, #240 Asymmetric DSA FIPS 186-2 Change Cert. #97 Notice 1 RSA Digital Signature PKCS #1 Vendor affirmed Hash function SHA-1 FIPS 180-1 Cert. #143, #197, #198, #199 MAC HMAC SHA-1 FIPS 198 Cert. #143, #197, #198, #199; vendor affirmed PRNG Appendix 3.1 (Algorithm FIPS 186-2 Change N/A 1) for computing DSA Notice 1 keys Appendix 3.1 for general purpose Table 7 ­ FIPS-Approved Algorithm supported by the Module Note: DES should be used for legacy purposes only. The modules implement the following non-FIPS-approved algorithms: · HMAC MD5 · MD5 · MD4 · 40-bit and 128-bit RC4 · CAST · Blowfish · Twofish · ARCfour · Diffie-Hellman (permitted for use in a FIPS-approved mode of operation) Cryptographic algorithms are implemented in software and in hardware by © Copyright 2003 Enterasys Networks Page 16 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. the encryption accelerators. The encryption accelerators implement the following FIPS-approved algorithms: · XSR-18xx ­ Triple-DES, DES, and HMAC SHA-1 · XSR-3250 ­ AES, Triple-DES, DES, and HMAC SHA-1 Cryptographic processing is performed during SSHv2, SNMPv3, IKE, IPSec, and when accessing and storing database files. The module supports the following critical and non-critical security parameters: CSPs and non- CSPs and non- Generation Storage Use critical SPs critical SPs type Key encryption 168-bit TDES key External Hard-coded in Encrypts master key plaintext encryption key Master encryption 168-bit TDES key Internal ­ using Stored encrypted Encrypts user data, key FIPS 186-2 PRNG in NVRAM of the certificates, and Or Dallas DS1687 DSA host key, and External real time clock the load test HMAC chip SHA-1 key DSA host key pair 160-bit DSA Internal ­ using Stored encrypted Module private key and FIPS 186-2 PRNG in Flash authentication 1024-bit DSA during SSHv2 public key IKE RSA key pair 1024-bit RSA Internal ­ using Stored encrypted Module private/public key FIPS 186-2 PRNG in Flash authentication pair during IKE IKE User RSA 1024-bit RSA External Stored encrypted User authentication public keys public key in Flash during IKE Pre-shared keys 6-character pre- External Stored encrypted User and module shared key in Flash authentication during IKE IKE Diffie-Hellman 768/1024/1536-bit Internal ­ using Stored in plaintext Key agreement key pair Diffie-Hellman FIPS 186-2 PRNG in memory during IKE private/public key pair IKE User Diffie- 768/1024/1536-bit External Stored in plaintext Key agreement Hellman public key Diffie-Hellman in memory during IKE public key SSHv2 Diffie- 768/1024/1536-bit Internal ­ using Stored in plaintext Key agreement Hellman key pair Diffie-Hellman FIPS 186-2 PRNG in memory during SSHv2 private/public key pair SSHv2 User Diffie- 768/1024/1536-bit External Stored in plaintext Key agreement Hellman public key Diffie-Hellman in memory during SSHv2 public key SSHv2 session 168-bit TDES or Established during Stored in plaintext Secure SSH traffic keys 128/192/256-bit the SSH key in memory AES keys; HMAC exchange using SHA-1 keys the Diffie-Hellman key agreement © Copyright 2003 Enterasys Networks Page 17 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. IPSec session 56-bit DES, 168-bit Established during Stored in plaintext Secure IPSec keys TDES, or the Diffie-Hellman in memory traffic 128/192/256-bit key agreement AES keys; HMAC SHA-1 key Load test HMAC 80-bit HMAC External Stored encrypted Compute and verify SHA-1 key SHA-1 key in NVRAM of the the HMAC SHA-1 real time clock value for the chip software load test Passwords 6-character External If stored in Crypto Officer password configuration file, authentication for (SNMPv3 requires passwords are accessing the at least 8 stored in plaintext management characters) in Flash; if stored interfaces (CLI, in user.dat, SNMPv3, and passwords are Bootrom Moniot stored encrypted Mode), RADIUS in Flash; Bootrom authentication passwords are stored in plaintext in NVRAM of the real time clock Table 8 ­ Listing CSPs for the Module Key Generation The RSA key pair used during IKE, the DSA host key pair used during SSHv2, and the Diffie-Hellman key pairs used during IPSec and SSHv2 are all generated within the module. Additionally, each module gives the option to generate the 3-key Triple-DES master encryption key within the module. All keys that are generated within a module are generated using a FIPS-approved PRNG. Key Establishment The modules implement SSHv2 and IKE for automatic key establishment. These protocols implement the Diffie-Hellman key agreement to establish shared secrets. Key Entry and Output Three types of secret keys can be entered in plaintext form into the modules: the master encryption key, pre-shared keys, and the load test HMAC SHA-1 key. The master encryption key can either be specified or generated within the module. Pre-shared keys, if chosen as the authentication method for IKE, must always be entered into the module by the Crypto Officer. The HMAC SHA-1 key must be entered into the module before a valid software file is loaded into the module. The three keys are entered electronically if the SSH or the Telnet over IPSec secured remote session is used or manually if the module is accessed locally through the console port. When these keys are manually entered, a manual key entry test is performed. © Copyright 2003 Enterasys Networks Page 18 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. If the master encryption key is generated within the module, the module outputs the key to the console as soon as the key is generated in order for the Crypto Officer to note down and store the key securely outside of the module. This is required, since the Crypto Officer must enter the current key before changing or removing it. The master secret key can only be configured through the serial console or over an SSH tunnel. Key Storage The three-key Triple-DES key encryption key used to encrypt the master encryption key is hard-coded in plaintext form. The master encryption key is stored encrypted in the extended NVRAM of the Real Time Clock chip. This 3-key Triple-DES key is used to encrypt the user data, certificates, and host key database files (user.dat, cert.dat and hostkey.dat) stored in Flash. Hostkey.dat contains the DSA host key pair, cert.dat contains the certificates (including the module's RSA key pair), and user.dat contains all other CSPs set for the users (pre-shared keys and passwords). The master encryption key is also used to encrypt the load test HMAC SHA-1 key, which is also stored in the NVRAM of the Real Time Clock chip. The CLI passwords are stored in plaintext form in the startup-config file in Flash. The SNMP passwords are stored in plaintext form in the private- config file in Flash. The Bootrom password is stored in NVRAM of the Real Time Clock. Session keys are stored in plaintext form in RAM. Key Zeroization The CSPs contained within the database files and the load test HMAC SHA-1 key do not need to be zeroized, since they are encrypted with the master encryption key. The master encryption key can be zeroized by either overwriting the key with a new one, removing it through the CLI, or by pressing the default configuration button (XSR-18xx only) or entering the bootrom password incorrectly five times (XSR-3250). Pressing this button reboots the module and enforces default configuration. The hard- coded key encryption key used to encrypt the master encryption key can be zeroized by formatting the Flash file system or CompactFlash card. Passwords can be zeroized by overwriting them with new ones or by pressing the default configuration button (XSR-18xx only). Session keys can be zeroized by rebooting the module. © Copyright 2003 Enterasys Networks Page 19 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Self-Tests The module performs a set of self-tests in order to ensure proper operation in compliance with FIPS 140-2. These self-tests are run during power-up (power-up self-tests) or when certain conditions are met (conditional self-tests). Power-up Self-tests: · Software integrity tests: the modules use an EDC, in the form of an MD5 checksum, to check the integrity of its various components · Cryptographic algorithm tests: o AES-CBC KAT o DES-CBC KAT o Triple-DES-CBC KAT o PRNG KAT o RSA pair-wise consistency test (signing and verification) o DSA pair-wise consistency test o SHA-1 KAT o HMAC SHA-1 KAT · Bypass mode test: the module performs SHA-1 check value verification to ensure that the IPSec policies are not modified. · Software load test: the module uses HMAC SHA-1 to check the validity of the software. Only validated software can be loaded into the modules. · Critical function test: during cold boot, the module performs power- up diagnostics to verify the functionality of installed hardware (memory and interfaces). Conditional Self-tests: · RSA pair-wise consistency test: this test is performed when RSA keys are generated for IKE. · DSA pair-wise consistency test: this test is performed when DSA keys are generated for SSHv2. © Copyright 2003 Enterasys Networks Page 20 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. · Continuous random number generator test: this test is constantly run to detect failure of the random number generator of the module. · Manual key entry test: when entering a pre-shared key, master encryption key, or load test HMAC SHA-1 key, the module performs the manual key entry test by requesting the Crypto Officer to enter the key in twice. · Software load test: the module uses HMAC SHA-1 to check the validity of the software. Only validated software can be loaded into the modules. · Bypass mode test: the module performs SHA-1 check value verification to ensure that the policy files are not modified. If any of the power-up self-tests fail (excluding the interface diagnostic tests), the module enters the Critical Error state and reboots. When the power-up software load test fails, the module enters the Critical Error state, rather than rebooting the module deletes the invalid software file and enters the Bootrom Monitor Mode state. If any of the conditional self-tests fail (except for the continuous RNG test and the bypass mode test), the module enters the Non-Critical Error state. All cryptographic processing and data output for the problem service is halted until the error state is cleared by the Crypto Officer. If the continuous RNG test or the conditional bypass mode test fails, the module will enter the Critical Error state and reboot. When the module fails a power-up or conditional self-test, it will output an error indicator via the console port. Design Assurance Source code and associated documentation files are managed and recorded by using the configuration management tool ClearCase. The Enterasys hardware data, which includes Description, Part Data, Part Type, BOM, Manufacturers, Changes, History, and hardware documents are managed and recorded using Agile Workplace. The FIPS documentation were managed and recorded by using Microsoft Visual Source Safe version 6.0. Mitigation of Other Attacks The modules do not employ security mechanisms to mitigate specific attacks. © Copyright 2003 Enterasys Networks Page 21 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. SECURE OPERATION The XSR modules meet level 2 requirements for FIPS 140-2. The sections below describe how to place and keep the module in a FIPS-approved mode of operation. The Crypto Officer must ensure that the module is kept in a FIPS-approved mode of operation. The procedures are described in "Crypto Officer Guidance". The User can use the module after the Crypto Officer changes the mode of operation to FIPS mode. The secure operation for the User is described in "User Guidance" on page 24. Crypto Officer Guidance The secure operation procedures for the Crypto Officer are covered in the initial setup and Management section. Following these procedures ensure that the module runs in a FIPS-compliant manner. Initial Setup The Crypto Officer receives the module in a carton. Within the carton the module is placed inside an ESD bag. The Crypto Officer should examine the carton and the ESD bag for evidence of tampering. Tamper-evidence includes tears, scratches, and other irregularities in the packaging. Since the module does not enforce an access control mechanism before it is initialized, the Crypto Officer must maintain control of the module at all times until the initial setup is complete. Before turning on the module, the Crypto Officer must ensure that the module meets level 2 physical security requirements. To satisfy these requirements, the Crypto Officer must apply the tamper-evident labels provided in the FIPS kit. The Installation Guide: Attaching XSR Security Labels detail how the labels must be applied to each module. After all the labels are in place, the Crypto Officer can open a Console session to the XSR using Microsoft's HyperTerminal, Procomm or other program. The session properties must be set as follows: BPS ­ 9600, Data bits ­ 8, Parity ­ none, Stop bits ­ 1, Flow control ­ none. Setting Passwords During the first five seconds of initialization, the Crypto Officer must press the key combination CTRL-C to enter Bootrom monitor mode. After the Crypto Officer accesses the mode, the Crypto Officer must set the at least six character long Bootrom password. To set the Bootrom password 1. Enter bp © Copyright 2003 Enterasys Networks Page 22 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. 2. At the prompt , press Enter. 3. At the prompt , enter the password. 4. At the prompt , re-enter the password. 5. At the prompt, enter bc for cold boot. The Crypto Officer must now set the at least six character long CLI password. To set the CLI password 1. When the XSR login appears, enter admin and enter no (blank) password. 2. At the CLI prompt, enter enable to acquire Privileged EXEC mode. 3. Enter configure to acquire Global mode. 4. Enter username privilege 15 password secret 0 . 5. Enter exit. 6. Enter copy running-config startup-config. 7. At the prompt, enter y. If the Super Crypto Officer name is not admin, the Super Crypto Officer must log into the newly created account and delete the admin user. After setting the Bootrom and CLI passwords, the Crypto Officer can configure the LAN ports and activate SSH to enable the remote management of the module. For directions, refer to the XSR Quick Start Guide, XSR Getting Started Guide, XSR User's Guide, and the CLI Reference Guide. Management The Crypto Officer must ensure that the module is always operating in a FIPS-approved mode of operation. This can be achieved by ensuring the following: · Passwords must be at least six characters long. · Telnet access must be disabled unless used over IPSec. © Copyright 2003 Enterasys Networks Page 23 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. · Dial backup access must be disabled. · Syslog remote logging must be disabled. · VPN services can only be provided by IPSec or L2TP over IPSec. · Only SNMPv3 can be enabled. · If cryptographic algorithms can be set for services (such as IKE/IPSec and SNMP), only FIPS-approved algorithms can be specified. These include the following: o AES o Triple-DES o DES o SHA-1 o HMAC SHA-1 o DSA o RSA signature and verification · FTP and TFTP can only be used to load valid software files. (FTP and TFTP over IPSec can be used to transfer configuration files.) · The module logs must be monitored. If a strange activity is found, the Crypto Officer should take the module off line and investigate. · The tamper-evident labels must be regularly examined for signs of tampering. User Guidance The User accesses the module VPN functionality as an IPSec client. Although outside the boundary of the module, the User should be careful not to provide authentication information and session keys to other parties. © Copyright 2003 Enterasys Networks Page 24 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ACRONYMS AAA Authentication, Authorization, and Accounting AES Advanced Encryption Standard ANSI American National Standards Institute BOM Bill of Materials CLI Command Line Interface CSP Critical Security Parameter DES Data Encryption Standard DSA Digital Signature Standard EDC Error Detection Code EMC Electromagnetic Compatibility EMI Electromagnetic Interference ESD Electro Static Dissipative FCC Federal Communication Commission FIPS Federal Information Processing Standard FTP File Transfer Protocol IKE Internet Key Exchange IPSec IP Security KAT Known Answer Test L2TP Layer 2 Tunneling Protocol LAN Local Area Network LED Light Emitting Diode MAC Message Authentication Code MIB Management Information Base NIM Network Interface Module NIST National Institute of Standards and Technology NVRAM Nonvolatile Random Access Memory PRNG Pseudo Random Number Generator RAM Random Access Memory RADIUS Remote Authentication Dial-in User Service RSA Rivest Shamir and Adleman SHA Secure Hash Algorithm SNMP Simple Network Management Protocol SP Security Parameters SSH Secure Shell TFTP Trivial File Transfer Protocol VPN Virtual Private Network WAN Wide Area Network XSR X-Pedition Security Router © Copyright 2003 Enterasys Networks Page 25 of 25 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.