JUNOS-FIPS 9.3 L2 OS Cryptographic Module Security Policy For the M Series, MX Series and T Series Routers Document Version: 1.0 Date: September 14, 2010 1 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Table of Contents Table of Contents ....................................................................................................................................................................................... 2 List of Tables ............................................................................................................................................................................................. 2 1. Module Overview .................................................................................................................................................................................. 3 2. Security Level ........................................................................................................................................................................................ 5 3. Modes of Operation ............................................................................................................................................................................... 5 Approved Mode of Operation ...................................................................................................................................................... 5 Non-FIPS Mode of Operation ..................................................................................................................................................... 6 4. Ports and Interfaces ................................................................................................................................................................................ 6 5. Identification and Authentication Policy ............................................................................................................................................... 6 Assumption of Roles ................................................................................................................................................................... 6 6. Access Control Policy ............................................................................................................................................................................ 9 Roles and Services ....................................................................................................................................................................... 9 Unauthenticated Services .......................................................................................................................................................... 10 Definition of Critical Security Parameters (CSPs) .................................................................................................................... 10 Definition of Public Keys .......................................................................................................................................................... 12 Definition of CSP Modes of Access .......................................................................................................................................... 13 7. Operational Environment ..................................................................................................................................................................... 14 8. Security Rules ..................................................................................................................................................................................... 14 9. Physical Security Policy ...................................................................................................................................................................... 15 Physical Security Mechanisms .................................................................................................................................................. 15 Tamper Label Evidence ............................................................................................................................................................. 16 10. Mitigation of Other Attacks Policy .................................................................................................................................................... 16 11. Acronyms ........................................................................................................................................................................................... 16 Appendix A, Tamper Label Placements .................................................................................................................................................. 18 Tamper Label Placement Label Application Instructions.......................................................................................................... 18 List of Tables Table 1. JUNOS-FIPS 9.3 L2 OS Series/Platform/RE......................................................................................................................... 3 Table 2. Security Level ........................................................................................................................................................................ 5 Table 3. Roles and Required Identification and Authentication .......................................................................................................... 7 Table 4. Strengths of Authentication Mechanisms .............................................................................................................................. 8 Table 5. Services Authorized for Roles ............................................................................................................................................... 9 Table 6. Table of CSPs ...................................................................................................................................................................... 10 Table 7. Table of Public Keys ............................................................................................................................................................ 12 Table 8. CSP Access Rights within Roles & Services ....................................................................................................................... 13 Table 9. Inspection/Testing of Physical Security Mechanisms .......................................................................................................... 16 Table 10. Mitigation of Other Attacks ................................................................................................................................................. 16 2 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module 1. Module Overview The JUNOS-FIPS 9.3 L2 OS Cryptographic Module for M Series, MX Series, and T Series routers (hereafter referred to as JUNOS- FIPS 9.3 L2 OS) executes on a multiple-chip embedded routing engine with Juniper Networks M Series Multiservice Edge Routers, Juniper Networks MX Series 3D Universal Edge Routers, and Juniper Networks T Series Core Routers. The validated version of JUNOS-FIPS 9.3 L2 OS is 9.3R2.8; the image is junos-juniper-9.3R2.8-fips.tgz. See Table 1 below for hardware platform specifics. JUNOS-FIPS 9.3 L2 OS is a release of the JUNOS operating system, the first routing operating system designed specifically for the Internet. JUNOS is currently deployed in the largest and fastest-growing networks worldwide. A full suite of industrial-strength routing protocols, a flexible policy language, and a leading MPLS implementation efficiently scale to large numbers of network interfaces and routes. JUNOS-FIPS 9.3 L2 OS, the logical cryptographic boundary, meets the requirements of the FIPS Publication 140-2. JUNOS-FIPS 9.3 L2 OS is a firmware-only module designed to operate on Routing Engine (RE) hardware, which is equivalent to PC hardware. The cryptographic module’s operational environment is a limited operational environment. The physical cryptographic boundary is formed by embedding a RE within a platform chassis, which is provided by the M Series, MX Series, and T Series chassis. The combinations of the configurations are shown in Table 1. Figure 1 below represents the module boundary. Additional boundary configuration requirements are specified in Appendix A. Table 1. JUNOS-FIPS 9.3 L2 OS Series/Platform/RE Series Platform Routing Engine M Series M40e RE-A-1000-2048 - 1GHz processor with 2GB of memory M120 RE-A-1000-2048 - 1GHz processor with 2GB of memory M120 RE-A-2000-4096 - 2GHz processor with 4GB of memory M320 RE-A-1000-2048 - 1GHz processor with 2GB of memory M320 RE-A-2000-4096 - 2GHz processor with 4GB of memory MX Series MX240 RE-S-2000-4096 - 2GHz processor with 4GB of memory MX480 RE-S-2000-4096 - 2GHz processor with 4GB of memory MX960 RE-S-2000-4096 - 2GHz processor with 4GB of memory T Series T320 RE-A-2000-4096 - 2GHz processor with 4GB of memory T640 RE-A-2000-4096 - 2GHz processor with 4GB of memory T1600 RE-A-2000-4096 - 2GHz processor with 4GB of memory 3 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Figure 1. Diagram of the Cryptographic Module Platform Chassis (PCM) Platform Chassis - Routing Engine Install Slot Routing Engine Data Input (LCM) JUNOS-FIPS 9.3 L2 OS 9.3R2.8 Data Output Control Input Status Output COM CPU RAM Fixed Ethernet Disk Controller Logical cryptographic module (LCM) boundary Physical cryptographic module (PCM) boundary 4 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module 2. Security Level The cryptographic module, which is a multiple-chip embedded embodiment, meets the overall requirements applicable to Level 2 security of FIPS 140-2. Table 2. Security Level Security Requirements Section Level Cryptographic Module Specification 2 Module Ports and Interfaces 2 Roles, Services and Authentication 2 Finite State Model 2 Physical Security 2 Operational Environment N/A Cryptographic Key Management 2 EMI/EMC 2 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A 3. Modes of Operation Approved Mode of Operation The cryptographic module supports FIPS-Approved algorithms as follows:  AES 128, 192, 256 for encryption/decryption  ECDSA with Curve P-192 for digital signature generation and verification  DSA with 1024-bit keys for digital signature generation and verification  RSA with 1024 or 2048-bit keys for digital signature generation and verification  Triple-DES (three key) for encryption/decryption  SHA-1 for hashing  SHA-2 for hashing (SHA-224, SHA-256, SHA-384, SHA-512)  HMAC-SHA-1  HMAC-SHA-256  AES-128-CMAC  FIPS 186-2 RNG (with Change Notice) The cryptographic module also supports the following non-Approved algorithms:  RSA with 1024-bit keys (key wrapping; key establishment methodology provides 80 bits of encryption strength)  MD5 for hashing (used during authentication) 5 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module  Diffie-Hellman with 1024-bit keys (key agreement; key establishment methodology provides 80 bits of encryption strength)  Non-Approved RNG (used to seed Approved FIPS 186-2 RNG) The cryptographic module supports the commercially available TLS, IKEv1, and SSH-2 protocols for key establishment in accordance with FIPS 140-2 Annex D. The cryptographic module relies on the implemented deterministic random number generator (RNG) that is compliant with FIPS 186- 2 for generation of all cryptographic keys in accordance with FIPS 140-2 Annex C. Non-FIPS Mode of Operation The cryptographic module does not provide a non-Approved mode of operation. 4. Ports and Interfaces The cryptographic module supports the following physical ports and corresponding logical interfaces:  Ethernet: Data Input, Data Output, Control Input, Status Outputs  Serial: Data Input, Data Output, Control Input, Status Outputs  Power interface: Power Input  LEDs: Status Output The flow of input and output of data, control, and status is managed by the cryptographic module’s defined service interfaces. These physical interfaces are mapped to the logical interfaces which include SSH-2, TLS (Ethernet) and Console (Serial). 5. Identification and Authentication Policy Assumption of Roles The cryptographic module supports six distinct operator roles as follows:  User  Cryptographic Officer (CO)  AS2-FIPS PIC  RE-to-RE  IKE Peer  Protocol Peer The cryptographic module shall enforce the separation of roles using either identity-based or role-based operator authentication; the cryptographic module meets Level 2 requirements because identity-based authentication is not enforced for all authorized services. 6 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Table 3. Roles and Required Identification and Authentication Role Type of Authentication Authentication Data  Via Console: Username and password User Identity-based operator authentication  Via TLS: Username and password  Via SSH-2: Password or RSA signature verification or DSA signature verification  Via RADIUS or TACACS+: pre-shared secret, minimum Role-based authentication 10 characters  Via Console: Username and password Cryptographic Officer Identity-based operator authentication  Via TLS: Username and password  Via SSH-2: Password or RSA signature verification or DSA signature verification  Via RADIUS or TACACS+: pre-shared secret, minimum Role-based authentication 10 characters AS2-FIPS PIC Identity-based operator authentication Serial Number (6 bytes) and password (32 bytes) RE-to-RE Identity-based operator authentication Pre-shared keys The RE role will use pre-shared keys for secure communication. IKE Peer Identity-based operator authentication IKE pre-shared keys Uses IKE to establish keys to be used by the PIC for IPsec communication with IPsec clients. Protocol Peer Role-based authentication Will use pre-shared keys to send encrypted traffic. Uses TCP/UDP MD5 MAC only to authenticate operator. Alternatively, a manually configured IPsec SA can be used for authentication. 7 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Table 4. Strengths of Authentication Mechanisms Authentication Mechanism Strength of Mechanism Username and password The module enforces 10-character passwords (at minimum) chosen from the 96+ human readable ASCII characters. The module enforces a timed access mechanism as follows: For the first two failed attempts (assuming 0 time to process), no timed access is enforced. Upon the third attempt, the module enforces a 5-second delay. Each failed attempt thereafter results in an additional 5-second delay above the previous (e.g. 4th failed attempt = 10-second delay, 5th failed attempt = 15-second delay, 6th failed attempt = 20-second delay, 7th failed attempt = 25-second delay). This leads to a maximum of 7 possible attempts in a one-minute period for each getty. The best approach for the attacker would be to disconnect after 4 failed attempts, and wait for a new getty to be spawned. This would allow the attacker to perform roughly 9.6 attempts per minute (576 attempts per hour/60 mins); this would be rounded down to 9 per minute, because there is no such thing as 0.6 attempts. Thus the probability of a successful random attempt is 1/9610, which is less than 1/1 million. The probability of a success with multiple consecutive attempts in a one-minute period is 9/(9610), which is less than 1/100,000. RSA signature The module supports RSA (1024 or 2048-bit), which has a minimum equivalent computational resistance to attack of either 280 or 2112 depending on the modulus size. Thus the probability of a successful random attempt is 1/(280) or 1/ (2112), which are both less than 1/1,000,000. The probability of a success with multiple consecutive attempts in a one-minute period is 5.6e7/(280) or 5.6e7/(2112), which are both less than 1/100,000. DSA signature The module supports DSA (1024-bit only) which have an equivalent computational resistance to attack of 280. Thus the probability of a successful random attempt is 1/ 280, which is less than 1/1,000,000. The probability of a success with multiple consecutive attempts in a one-minute period is 5.6e7/(280), which is less than 1/100,000. AS2-FIPS PIC password The module supports 32 byte passwords to authenticate the PIC. Thus the probability of a successful random attempt is 1/ (25532), which is less than 1/1,000,000. The probability of a success with multiple consecutive attempts in a one minute period is 4,940,716 /(25532), which is less than 1/100,000. RE-to-RE pre-shared keys The module uses 160-bit HMAC keys for RE-to-RE authentication. Thus the probability of a successful random attempt is 1/(2160), which is less than 1/1,000,000. The probability of a success with multiple consecutive attempts in a one-minute period is 54,347,880/(2160), which is less than 1/100,000. IKE pre-shared keys The module uses 160-bit HMAC keys for RE-to-RE authentication. Thus the probability of a successful random attempt is 1/(2160), which is less than 1/1 million. The probability of a success with multiple consecutive attempts in a one minute period is 54,347,880/(2160), which is less than 1/100,000. Protocol peer pre-shared keys The module supports TCP-MD5 with a 128-bit pre-shared key. Thus the probability of a successful random attempt is 1/ (2128), which is less than 1/1,000,000. The probability of a success with multiple consecutive attempts in a one minute period is 54,347,880/(2128), which is less than 1/100,000. 8 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module 6. Access Control Policy Roles and Services Table 5. Services Authorized for Roles Role Authorized Services  Configuration Management: Allows the user to configure the router. User:  Router Control: Allows the user to modify the state of the router. (Example: shutdown, Configures and monitors the router via the console, SSH-2, or TLS. reboot)  Status Checks: Allows the user to get the current status of the router  JUNOScript: Provides script handling service for module via SSH-2 or TLS session.  SSH-2: Provides encrypted login via the SSH-2 protocol.  TLS: Provides encrypted login via the TLS protocol.  Console Access: Provides direct login access via the console.  Configuration Management: Allows the CO to configure the router. Cryptographic Officer:  Router Control: Allows the user to modify the state of the router. (Example: shutdown, Configures and monitors the RE via the console, SSH-2, or TLS. reboot) Also has permissions to view and  Status Checks: Allows the user to get the current status of the router. edit secrets within the RE.  Zeroize: Allows the user to zeroize the configuration (all CSPs) within the module.  Load New Software: Allows the verification and loading of new software into the router. Note: Loading of software invalidates the module’s FIPS 140-2 validation.  JUNOScript: Provides script handling service for module via SSH-2 or TLS session.  SSH-2: Provides encrypted login via the SSH-2 protocol.  TLS: Provides encrypted login via the TLS protocol.  Console Access: Provides direct login access via the console.  Receives SAs: Allows the PIC to receive the SAs associated with a particular IPsec AS2-FIPS PIC tunnel.  Secure IPC Tunnel: Allows the PIC to communicate with the RE using a secure tunnel.  Configuration Management: Allows propagation of configuration database to the backup RE-to-RE RE. The RE role is able to communicate  Router Control: Allows the master RE to control the state of the backup RE. with other REs to enable failover capabilities.  Status Checks: This service will allow the user to get the current status of the router (ports, number of packets, uptime, and so forth)  Secure Transport: Allows the master RE to communicate with the backup RE using a secure IPsec connection.  Secure IPC Tunnel: Allows the PIC to communicate with the RE using a secure tunnel. 9 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module  Key Agreement: Allows the negotiation of keys for use with an IPsec tunnel. IKE Peer This role performs IKE negotiation with the RE. The IKE peer will create SAs for the AS2-FIPS PIC to use when using IPsec with a VPN client in cyberspace.  Mutual Authentication: Allows validating a known protocol peer. Protocol Peer  Protocol Exchange: Allows the peers to communicate using an agreed-upon protocol. This role allows remote router to communicate with the RE via  Secure Protocol Transport: Allows IPsec connection between protocol peer and router. standard networking protocols. The supported routing protocols (BGP, ISIS, LDP, MSDP, OSPF, RIP2, RSVP, VRRP, and NTP) authenticate peers to each other for purpose of updating routing tables. Unauthenticated Services The cryptographic module supports the following unauthenticated services:  PIC Software Image Load: Downloads PIC software image to PIC.  Receive Service Set Configuration: Allows the PIC to receive service set configuration database.  Show Status: Provides the current status of the cryptographic module.  Self-tests: Executes the suite of self-tests required by FIPS 140-2.  Routing Protocols: Unauthenticated routing protocols (e.g., TCP, UDP)  SNMP Traps (Status) Definition of Critical Security Parameters (CSPs) Table 6. Table of CSPs CSP Description SSH-2 Private Host Key The first time SSH-2 is configured, the key is generated. RSA, DSA. Used to Identify the host. 1024-bit length set as minimum. SSH-2 Session Key Session keys used with SSH-2, TDES (3 key), AES 128, 192, 256, HMAC-SHA-1 key (160), DH Private Key 1024 TLS Host Certificate, Private Portion X.509 certificates for TLS for authentication. RSA or DSA TLS Session Parameters Session keys used with TLS, TDES (2 or 3 key), AES 128, 192, 256, HMAC-SHA-1; Pre-master Secret User Authentication Key HMAC-SHA-1 Key Used to authenticate users to the module. CO Authentication Key HMAC-SHA-1 Key Used to authenticate COs to the module. 10 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module CSP Description IPsec SAs Session keys used within IPsec. TDES (3 key), HMAC-SHA-1 IKE Session Parameters Nonces, DH Private Key 1024-bit keys, TDES, HMAC-SHA-1, used within IKE Secure IPC (Internal) Session Key TDES (3 Key) Used to communicate securely between the RE and the PIC RE-to-RE Authentication Key HMAC Key (Manual IPsec SA) 160 bit key with 96 bit truncated MAC. RE-to-RE Encryption Key TDES key (Manual IPsec SA) Protocol Peer Authentication Keys TCP-MD5 key to authenticate the routing peer role for the following protocols: BGP, ISIS, LDP, MSDP, OSPF, RIP2, RSVP, VRRP, NTP, APSCP ASPIC password 32 byte password RADIUS shared secret Used to authenticate COs and Users (10 chars minimum) This includes the Authentication Data Block TACACS+ shared secret Used to authenticate COs and Users (10 chars minimum) This includes the Authentication Data Block Manual SA for PIC Entered into the RE, which is then passed over to the PIC for use by PIC with IPSEC RNG State Internal state and seed key of RNG 11 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Definition of Public Keys Table 7. Table of Public Keys Key Description/Usage SSH-2 Public Host Key First time SSH-2 is configured, the key is generated. RSA (1024 or 2048-bit), DSA. Identify the host. TLS Host Certificate, Public Portion X.509 certificates for TLS for authentication. RSA (1024 or 2048-bit) or DSA User Authentication Public Keys Used to authenticate users to the module. RSA (1024 or 2048-bit) or DSA CO Authentication Public Keys Used to authenticate CO to the module. RSA (1024 or 2048-bit) or DSA JuniperRootCA RSA 2048-bit X.509 certificate Used to verify the validity of the Juniper image at software load and also at runtime for integrity. EngineeringCA RSA 2048-bit X.509 certificate Used to verify the validity of the Juniper image at software load and also at runtime for integrity. PackageCA RSA 2048-bit X.509 certificate Used to verify the validity of the Juniper image at software load and also at runtime for integrity. PackageProduction RSA 2048-bit X.509 certificate Certificate that holds the public key of the signing key that was used to generate all the signatures used on the packages and signature lists. RE RSA Verify Key (Public Authentication key) RSA 1024-bit key sent to the PIC to sign data to allow the PIC to authenticate to the RE by having the PIC sign data that is verified by the RE. PIC RSA Verify (Public Authentication) Key RSA 1024-bit key to allow the RE to authenticate to the PIC by signing data and having the PIC verify the signature. PIC RSA Encrypt Key RSA 1024-bit key used to encrypt the TDES session key. RE RSA Encrypt Key RSA 1024-bit key sent to the PIC; note that the PIC never uses this key. DH Public Keys Used within IKE and SSH-2 for key establishment. 12 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Definition of CSP Modes of Access Table 8 defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as follows: Table 8. CSP Access Rights within Roles & Services Role Service Cryptographic Keys and CSP Access Operation CO User RE-to- AS2- IKE Prot. R=Read, W=Write, D=Delete RE FIPS Peer Peer PIC X All CSPs (R, W, D) Configuration Management X Configuration No access to CSPs Management X All CSPs (R, W) Configuration Management X X X Router Control No access to CSPs X X X Status Checks No access to CSPs X All CSPs (D) Zeroize X Relevant IPsec SAs (R) Receives SAs X IPsec SAs (R) Key Agreement X Relevant Authentication data: (R) Mutual Authentication X Protocol Exchange No access to CSPs (OSPF, VRRP, etc) X Load New Software No access to CSPs X All CSPs (R, W, D) JUNOScript X JUNOScript No access to CSPs X X SSH-2 session key (R) SSH-2 X X TLS session parameters (R) TLS X X Console Access CO Authentication Key, User Authentication Key (R) X X Secure IPC Tunnel Secure IPC (Internal) Session Key (R) 13 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module X Secure transport RE-to-RE Encryption Key, RE-to-RE Authentication Key (R) X Secure Protocol Protocol Peer Authentication Keys (R) transport 7. Operational Environment The FIPS 140-2 Area 6 Operational Environment requirements are not applicable because the cryptographic module is a limited operational environment. 8. Security Rules The cryptographic module’s design corresponds to the cryptographic module’s security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-2 Level 2 module. 1. The cryptographic module shall provide six distinct operator roles. These are the User role, the Cryptographic Officer role, RE-to- RE role, AS2-FIPS PIC role, IKE Peer role, and Protocol Peer role. 2. The cryptographic module shall support both role-based and identity-based authentication mechanisms. 3. Authentication of identity to an authorized role is required for all services that modify, disclose, or substitute CSPs, use Approved security functions, or otherwise affect the security of the cryptographic module. 4. The cryptographic module shall perform the following tests:  Power up tests A. Cryptographic algorithm tests DES - KAT1 i. ii. TDES - KAT iii. AES - KAT iv. AES - CMAC KAT v. SHA-1 KAT vi. SHA-224, 256, 384, 512 KAT vii. HMAC-SHA-1 KAT viii. HMAC-SHA-256 KAT ix. ECDH KAT x. ECDSA pairwise consistency test (sign/verify) and KAT xi. RSA pairwise consistency test (sign/verify and encrypt/decrypt) and KAT xii. DSA pairwise consistency test (sign/verify) and KAT xiii. FIPS 186-2 RNG KAT xiv. KDF-IKEv1 KAT B. Firmware integrity test: i. RSA digital signature verification (PKCS1.5, 2048-bit key, SHA-1) and SHA-1 hash verification C. Critical functions tests i. Verification of Limited Environment ii. Verification of Integrity of Optional Packages  Conditional tests A. Pairwise consistency tests 1 The DES function is used to implement TDES and is not otherwise available for use in the cryptomodule. 14 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module i. ECDSA Pairwise Consistency test ii. RSA pairwise consistency test (sign/verify and encrypt/decrypt) iii. DSA pairwise consistency test (sign/verify) B. Firmware load test: RSA digital signature verification (2048-bit key) C. Manual key entry test: duplicate key entries test D. Continuous random number generator test: performed on the Approved FIPS 186-2, Appendix 3.1 RNG, and on a non-Approved RNG that is used to seed the Approved RNG. E. Bypass test is not applicable. 5. Any time the cryptographic module is in an idle state, the operator shall be capable of commanding the module to perform the power-up self-test by power-cycling the module. 6. Prior to each use, the internal RNG shall be tested using the continuous random number generation conditional test. 7. Data output shall be inhibited during self-tests and error states. 8. Key generation, manual key entry and zeroization processes shall be logically isolated from data output. 9. Status information shall not contain CSPs or sensitive data that if misused could lead to a compromise of the module. 10. The module shall support concurrent operators. 11. The FIPS module is a combination of Routing Engine and Juniper router platform chassis in which the RE is installed. The Routing Engine must be installed in one of the approved platforms as listed in Table 1, per Juniper installation guidance. The installation shall include the placement of tamper labels installed in specific locations on the module. To operate in the FIPS Approved mode of operation, the module must be installed and tamper labels applied to the routing engine hardware as specified in Appendix A for the tamper label locations. 12. The Crypto Officer is responsible for properly controlling and installing tamper evident labels. Additionally, the Crypto Officer is responsible for the direct control and observation of any changes to the module such as reconfigurations where the tamper evident seals or security appliances are removed or installed to ensure the security of the module is maintained during such changes and that the module is returned to a FIPS Approved state. 13. The validation of the firmware is invalid upon porting of the firmware module to systems not defined in this security policy. 9. Physical Security Policy Physical Security Mechanisms The JUNOS-FIPS 9.3 L2 OS firmware module’s physical embodiment, as represented by the tested platform, is a multi-chip embedded routing engine that meets Level 2 physical security requirements. 15 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Table 9. Inspection/Testing of Physical Security Mechanisms Physical Security Mechanisms Recommended Frequency of Inspection/Test Guidance Details Inspection/Test Tamper labels, opaque metal enclosure. Upon receipt of the module and per Labels should be free of any tamper To operate in the FIPS Approved mode security policy of end user. evidence. of operation, the module Routing Engine The Crypto-Officer must inspect all tamper must be installed within a specified label locations and embedded chassis chassis with tamper labels applied to the components for proper configuration. hardware as specified in Appendix A for the tamper label locations. The Routing Engine slot and tamper labels must be examined every time hardware configuration changes affect adjacent slots or the module routing engine. The Crypto- Officer shall ensure tampering of the module through the chassis openings has not occurred. Tamper Label Evidence Figure 2. Tampered Label 10. Mitigation of Other Attacks Policy The module has not been designed to mitigate attacks that are outside the scope of FIPS 140-2. Table 10. Mitigation of Other Attacks Other Attacks Mitigation Mechanism Specific Limitations N/A N/A N/A 11. Acronyms ACRONYM DESCRIPTION AES Advanced Encryption Standard CB Control Board DES Data Encryption Standard 16 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module DSA Digital Signature Algorithm EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard GMPLS General Multiprotocol Label Switching HMAC-SHA-1 Keyed-Hash Message Authentication Code IKE Internet Key Exchange Protocol IPsec Internet Protocol Security MD5 Message Digest 5 MPLS Multiprotocol Label Switching PCG Packet Forwarding Engine (PFE) Clock Generator (PCG) PIC Physical Interface Card RADIUS Remote Authentication Dial-In User Service RE Routing Engine RNG Random Number Generator (aka. Pseudo Random Number Generator) RSA Public-key encryption technology developed by RSA Data Security, Inc. The acronym stands for Rivest, Shamir, and Adelman. SA Security Association SHA-1 Secure Hash Algorithms SSH Secure Shell SSL Secure Sockets Layer TACACS Terminal Access Controller Access Control System TCP Transmission Control Protocol TDES Triple - Data Encryption Standard TLS Transport Layer Security UDP User Datagram Protocol 17 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Appendix A, Tamper Label Placements Tamper Label Placement Label Application Instructions For all label applications, observe the following instructions:  Handle the labels with care. Do not touch the adhesive side.  All surfaces to which the labels will be applied must be clean and dry. Ensure all surfaces are clean and clear of any residue.  Apply with firm pressure across the label to ensure adhesion. Allow at least 1 hour for the adhesive to cure. Figure 3. M40e with Routing Engine Tamper Label Placement (6 Tamper Labels) PCG to RE (2) RE to PCG to Chassis Chassis (2) (2) The M40e houses the RE-A-1000-2048. The physical environment for the logical boundary is formed by embedding the routing engines within the specified chassis. For the M40e chassis, two routing engines and PCG units are mounted and sealed in place with six (6) tamper evident labels. The label placement for the physical boundary is identified in Figure 3 by the red highlights. Given the context of tamper evidence testing, the routing engines are protected from removal using tamper evident labels. The configuration of the mounting slots of the PCG and chassis for the routing engines form a steel frame and panel assembly. Figure 4. M120 with Routing Engine Tamper Label Placement (3 Tamper Labels) CB to CB to Chassis Chassis (1) (1) RE to CB (1) The M120 houses either the RE-A-1000-2048 or the RE-A-2000-4096. The physical boundary environment for the logical boundary is formed by embedding the routing engine within the specified chassis. With the M120 chassis, the physical boundary is the routing engine units mounted in M120 control board trays and sealed in place with three (3) tamper evident labels. The label placement for the physical boundary is identified in Figure 4 by the red highlights. 18 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Figure 5. M320 with Routing Engine Tamper Label Placement (5 Tamper Labels) RE to CB slot 0 RE to RE to Chassis Chassis (2) (2) The M320 houses the RE-A-1000-2048 or RE-A-2000-4096. The physical boundary environment for the logical boundary is formed by embedding the routing engines within the specified chassis. For the M320 chassis, two routing engine units are mounted and sealed in place with five (5) tamper evident labels. The control board for slot 0 must also be mounted. The label placement for the physical boundary is identified in Figure 5 by the red highlights. Figure 6. MX240, MX480, and MX960 with Routing Engine Tamper Label Placement (6 Tamper Labels) CB to CB to Chassis Chassis (2) (2) CB to RE CB to RE (1) (1) The MX240, MX480 and MX960 house the RE-S-2000-4096. The physical boundary environment for the logical boundary is formed by embedding the routing engines within a specified chassis. For the MX240, MX480 and MX960 chassis, two routing engine units are mounted within the control board trays and sealed in place with six (6) tamper evident labels. The adjacent slot next to the control boards must be populated with a blanking tray or other auxiliary functional unit (e.g., dense port concentrators). The label placement for the physical boundary is identified in Figure 6 by the red highlights. 19 © Juniper Networks, Inc. JUNOS-FIPS 9.3 L2 OS Cryptographic Module Figure 7. T320, T640, and T1600 with Routing Engine Tamper Label Placement (6 Tamper Labels) CB to RE (1) RE to RE to Chassis Chassis (2) (2) CB to RE (1) Figure 8. Alternate View - T320, T640, and T1600 with Routing Engine Tamper Label Corner Placement for CB to RE The T320, T640 and T1600 house the RE-A-2000-4096. The physical boundary environment for the logical boundary is formed by embedding the routing engines within the specified chassis. For the T320, T640 and T1600 chassis, two routing engines and a control board unit are mounted and sealed in place with six (6) tamper evident labels. The label placement for the physical boundary is identified in Figure 7 by the red highlights. Figure 8 shows the topography and proper corner placement between the control boards and routing engines. 20 © Juniper Networks, Inc. Corporate and Sales Headquarters APAC Headquarters EMEA Headquarters Juniper Networks, Inc. Juniper Networks (Hong Kong) Juniper Networks Ireland 1194 North Mathilda Avenue 26/F, Cityplaza One Airside Business Park Sunnyvale, CA 94089 USA 1111 King’s Road Swords, County Dublin, Ireland Phone: 888.JUNIPER (888.586.4737) Taikoo Shing, Hong Kong Phone: 35.31.8903.600 or 408.745.2000 Phone: 852.2332.3636 EMEA Sales: 00800.4586.4737 Fax: 408.745.2100 Fax: 35.31.8903.601 Fax: 852.2574.7803 Copyright 2010 Juniper Networks, Inc. May be reproduced only in its entirety [without revision]. Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Mon 2010 21 © Juniper Networks, Inc.