Juniper Networks SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, and SRX650 Services Gateways Non-Proprietary FIPS 140-2 Cryptographic Module Security Policy Version: 1.1 Date: July 26, 2016 Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, California 94089 USA 408.745.2000 1.888 JUNIPER www.juniper.net Copyright Juniper, 2016 Version 1.1 Page 1 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Table of Contents 1 Introduction .................................................................................................................... 4 1.1 Hardware and Physical Cryptographic Boundary .........................................................................7 1.2 Mode of Operation.................................................................................................................... 14 1.3 Firmware Load ........................................................................................................................... 15 1.4 Zeroization................................................................................................................................. 16 2 Cryptographic Functionality ........................................................................................... 17 2.1 Disallowed Algorithms............................................................................................................... 20 2.2 Critical Security Parameters ...................................................................................................... 20 3 Roles, Authentication and Services ................................................................................ 22 3.1 Roles and Authentication of Operators to Roles ...................................................................... 22 3.2 Authentication Methods ........................................................................................................... 22 3.3 Services ...................................................................................................................................... 22 4 Self-tests........................................................................................................................ 23 5 Physical Security Policy .................................................................................................. 27 5.1 General Tamper Seal Placement and Application Instructions ................................................. 27 5.2 SRX100 and SRX110 (1 seal) ...................................................................................................... 27 5.3 SRX210 (3 seals) ........................................................................................................................ 28 5.4 SRX220 (5 seals) ........................................................................................................................ 28 5.5 SRX240 (8 seals) ........................................................................................................................ 29 5.6 SRX550 (19 seals) ...................................................................................................................... 30 5.7 SRX650 (19 seals) ...................................................................................................................... 31 6 Security Rules and Guidance .......................................................................................... 33 7 References and Definitions ............................................................................................ 34 List of Tables Table 1 – Cryptographic Module Configurations .......................................................................................... 4 Table 2 - Security Level of Security Requirements........................................................................................ 5 Table 3 - Ports and Interfaces .................................................................................................................... 14 Table 4 - Approved and CAVP Validated Cryptographic Functions ............................................................ 17 Table 5 - Non-Approved but Allowed Cryptographic Functions ................................................................. 19 Table 6 - Protocols Allowed in FIPS Mode .................................................................................................. 19 Table 7 - Critical Security Parameters (CSPs) .............................................................................................. 20 Table 8 - Public Keys.................................................................................................................................... 21 Table 9 - Authenticated Services ................................................................................................................ 22 Table 10 - Unauthenticated traffic .............................................................................................................. 23 Table 11 - CSP Access Rights within Services .............................................................................................. 23 Table 12 – Physical Security Inspection Guidelines .................................................................................... 27 Copyright Juniper, 2016 Version 1.1 Page 2 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Table 13 – References ................................................................................................................................. 34 Table 14 – Acronyms and Definitions ......................................................................................................... 34 Table 15 – Datasheets ................................................................................................................................. 35 List of Figures Figure 1 – SRX100 Profile View ..................................................................................................................... 7 Figure 2 – SRX100 Bottom View ................................................................................................................... 7 Figure 3 - SRX110 Profile View ...................................................................................................................... 8 Figure 4 - SRX110 Bottom View .................................................................................................................... 8 Figure 5 – SRX210 Top View.......................................................................................................................... 9 Figure 6 – SRX210 Bottom View ................................................................................................................... 9 Figure 7 – SRX220 Top View........................................................................................................................ 10 Figure 8 – SRX220 Bottom View ................................................................................................................. 10 Figure 9 – SRX240 Profile View ................................................................................................................... 11 Figure 10 – SRX240 Bottom View ............................................................................................................... 11 Figure 11 - SRX550 Profile View .................................................................................................................. 11 Figure 12 - SRX550 Bottom View ................................................................................................................ 12 Figure 13 - SRX650 Profile View .................................................................................................................. 12 Figure 14 - SRX650 Bottom View ................................................................................................................ 13 Figure 15: SRX100 Tamper-Evident Seal Placement- One Seal................................................................... 27 Figure 16: SRX110 Tamper-Evident Seal Placement- One Seal................................................................... 28 Figure 17: SRX210 Tamper-Evident Seal Placement-Three Seals ............................................................... 28 Figure 18: SRX220 Tamper-Evident Seal Placement- Five Seals ................................................................. 29 Figure 19: SRX240 Tamper-Evident Seal Placement-Eight Seals ................................................................ 29 Figure 20: SRX550 Tamper-Evident Seal Placement on Front and Right Side-Twelve Seals ...................... 31 Figure 21: SRX550 Tamper-Evident Seal Placement on Rear and Left Side- Seven Seals ........................... 31 Figure 22: SRX650 Tamper-Evident Seal Placement on Front and Right Side- Twelve Seals ..................... 32 Figure 23: SRX650 Tamper-Evident Seal Placement on Rear and Left Side- Seven Seals ........................... 32 Copyright Juniper, 2016 Version 1.1 Page 3 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 1 Introduction The Juniper Networks SRX Series Services Gateways are a series of secure routers that provide essential capabilities to connect, secure, and manage work force locations sized from handfuls to hundreds of users. By consolidating fast, highly available switching, routing, security, and applications capabilities in a single device, enterprises can economically deliver new services, safe connectivity, and a satisfying end user experience. All models run Juniper’s JUNOS firmware – in this case, a specific FIPS-compliant version called JUNOS-FIPS, version 12.1X46-D40. The firmware image is junos-srxsme-12.1X46-D40.4- fips.tgz and the firmware Status service identifies itself as in the “Junos 12.1X46-D40.4 (FIPS edition)”. This Security Policy covers the “Branch” models – the SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, and SRX650 models. They are meant for corporate branch offices of various sizes. (Intended size is proportional to model number.) The cryptographic modules are defined as multiple-chip standalone modules that execute JUNOS-FIPS firmware on any of the Juniper Networks SRX-Series gateways listed in the table below. Table 1 – Cryptographic Module Configurations Model Hardware Versions Firmware Distinguishing Features SRX100H JUNOS-FIPS 8 x 10/100 ports; ADSL2+WAN; No I/O SRX100 SRX100H2 12.1X46-D40 expansion slots SRX100H-TAA SRX110H2-VA SRX110H2-VB JUNOS-FIPS 8 x 10/100 ports; VDSL; No I/O expansion SRX110 SRX110H-VA 12.1X46-D40 slots; no PoE SRX110H-VB SRX210HE SRX210HE2 SRX210HE2-POE 2 x 10/100/1000 + 6 x 10/100; 1 I/O SRX210HE-POE JUNOS-FIPS SRX210 expansion slots; up to 4 PoE; 3G WAN SRX210HE-POE-TAA 12.1X46-D40 option SRX210HE-TAA SRX210H2-POE-TAA SRX210H2-TAA SRX220H SRX220H2 JUNOS-FIPS SRX220 8 x 10/100/1000; 2 I/O expansion slots SRX220H-POE 12.1X46-D40 SRX220H2-POE SRX240H SRX240H2 SRX240H2-DC SRX240H2-POE SRX240H-DC JUNOS-FIPS 16 x 10/100/1000; 4 SFP; 4 I/O expansion SRX240 SRX240H-POE 12.1X46-D40 slots SRX240H-POE-TAA SRX240H-TAA SRX240H2-DC-TAA SRX240H2-POE-TAA Copyright Juniper, 2016 Version 1.1 Page 4 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). SRX240H2-TAA SRX550-645AP SRX550-645DP JUNOS-FIPS 6 x 10/100/1000 + 4 SFP; 8 I/O expansion SRX550 SRX550-645AP-TAA 12.1X46-D40 slots SRX550-645DP-TAA SRX650-BASE-SRE6-645AP 4 x 10/100/1000; 8 I/O expansion slots; JUNOS-FIPS SRX650 SRX650-BASE-SRE6-645DP slots for additional Service/Routing 12.1X46-D40 SRX650B-SRE6-645AP-TAA engines All JNPR-FIPS-TAMPER-LBLS N/A Tamper-Evident Seals Each Hardware Version for a model is identical in physical form factor, materials, and assembly methods. The Hardware Version differences for a model are considered non-security relevant. The differences denoted by the various suffixes are described below: • H – High Memory – 1 GB RAM • H2 – High Memory 2 – 2 GB RAM • E – Enhanced – higher processor speed • TAA – Trade Adjustment Assistance – refers to TAA complaint component sourcing. Specification for the components are identical to non-TAA versions. • VA – VDSL2/ADSL2+over POTS • VB – VDSL2/ADSL2+over ISDN BRI • POE – Power over Ethernet Output • DC – Direct Current Power Input • AP – Alternating Current Power Input • DP – Direct Current Power Input The modules are designed to meet FIPS 140-2 Level 2 overall: Table 2 - Security Level of Security Requirements Area Description Level 2 1 Module Specification 2 2 Ports and Interfaces 3 3 Roles and Services 2 4 Finite State Model 2 5 Physical Security 2 6 Operational Environment 2 7 Key Management 8 EMI/EMC 2 2 9 Self-test 3 10 Design Assurance N/A 11 Mitigation of Other Attacks Overall 2 Copyright Juniper, 2016 Version 1.1 Page 5 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). The modules have a limited operational environment as per the FIPS 140-2 definitions. They include a firmware load service to support necessary updates. New firmware versions within the scope of this validation must be validated through the FIPS 140-2 CMVP. Any other firmware loaded into these modules is out of the scope of this validation and require a separate FIPS 140-2 validation. The modules do not implement any mitigations of other attacks as defined by FIPS 140-2. Copyright Juniper, 2016 Version 1.1 Page 6 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 1.1 Hardware and Physical Cryptographic Boundary The physical forms of the module’s various models are depicted in Figures 1-14 below. For all models the cryptographic boundary is defined as the outer edge of the chassis, but for the SRX550 and SRX650 the IO cards are excluded. The modules do not rely on external devices for input and output. Figure 1 – SRX100 Profile View Figure 2 – SRX100 Bottom View Copyright Juniper, 2016 Version 1.1 Page 7 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Figure 3 - SRX110 Profile View Figure 4 - SRX110 Bottom View Copyright Juniper, 2016 Version 1.1 Page 8 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Figure 5 – SRX210 Top View Figure 6 – SRX210 Bottom View Copyright Juniper, 2016 Version 1.1 Page 9 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Figure 7 – SRX220 Top View Figure 8 – SRX220 Bottom View Copyright Juniper, 2016 Version 1.1 Page 10 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Figure 9 – SRX240 Profile View Figure 10 – SRX240 Bottom View Figure 11 - SRX550 Profile View Copyright Juniper, 2016 Version 1.1 Page 11 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Figure 12 - SRX550 Bottom View Figure 13 - SRX650 Profile View Copyright Juniper, 2016 Version 1.1 Page 12 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Figure 14 - SRX650 Bottom View Copyright Juniper, 2016 Version 1.1 Page 13 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Table 3 - Ports and Interfaces Port Description Logical Interface Type Ethernet LAN Communications Control in, Data in, Data out, Status out Serial Console serial port Control in, Status out Power Power connector Power Reset Reset Control in LED Status indicator lighting Status out USB Firmware load port Control in, Data in WAN SHDSL, VDSL, T1, E1 Control in, Data in, Data out, Status out 1.2 Mode of Operation Follow the instructions in Section 5 to apply the tamper seals to the module. Once the tamper seals have been applied as shown in this document, the JUNOS-FIPS firmware image is installed on the device, and integrity and self-tests have run successfully on initial power-on, the module is operating in the approved mode. The Crypto-Officer must ensure that the backup image of the firmware is also a JUNOS- FIPS image by issuing the request system snapshot command. If the module was previously in a non-Approved mode of operation, the Cryptographic Officer must zeroize the CSPs by following the instructions in Section 1.3. Then, the CO must run the following commands to configure SSH to use FIPS approved and FIPS allowed algorithms: co@fips-srx# set system services ssh hostkey-algorithm ssh-ecdsa co@fips-srx# set system services ssh hostkey-algorithm no-ssh-rsa co@fips-srx# set system services ssh hostkey-algorithm no-ssh-dss co@fips-srx# set system services ssh hostkey-algorithm no-ssh-ed25519 co@fips-srx# commit The CO can change the preference of SSH key exchange methods using the following command: co@fips-srx# set system services ssh key-exchange - dh-group14-sha1, ecdh-sha2-nistp256, ecdh-sha2-nistp384, group-exchange-sha1, or group-exchange-sha2 Note: These methods are always proposed during SSH session negotiation. Explicitly specifying a method moves the algorithm up in the list of proposed algorithms during the SSH session establishment. The CO can change the preference of SSH cipher algorithms using the following command: co@fips-srx# set system services ssh ciphers - 3des-cbc, aes128-cbc, aes128-ctr, aes192-cbc, aes192-ctr, aes256-cbc, aes256-ctr Copyright Juniper, 2016 Version 1.1 Page 14 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Note: These algorithms are always proposed during SSH session negotiation. Explicitly specifying an algorithm moves the algorithm up in the list of proposed algorithms during the SSH session establishment. The CO can change the preference of SSH MAC algorithms or enable additional Approved algorithms using the following command: co@fips-srx# set system services ssh macs - hmac-sha1, hmac-sha1-96, hmac-sha2-256, hmac-sha2-512, hmac-sha1-96-etm@openssh.com, hmac-sha1-etm@openssh.com, hmac-sha2-256- etm@openssh.com, hmac-sha2-512-etm@openssh.com Note: hmac-sha1 and hmac-sha1-96 are always proposed during SSH session negotiation. Explicitly specifying either algorithm moves it up in the list of proposed algorithms during the SSH session establishment. Specifying any other MAC algorithm adds it to the list of algorithms proposed. For each IPsec tunnel configured, the CO must run the following command to configure the algorithms: co@fips-srx# set system security ipsec authentication-algorithm - hmac-sha-256-128, hmac-sha1-96 co@fips-srx# set system security ipsec encryption-algorithm - 3des-cbc, aes-128-cbc, aes-128-gcm, aes-192-cbc, aes-192- gcm, aes-256-cbc, aes-256-gcm Note: Use of AES-GCM is only FIPS approved when it is configured for use in conjunction with IKEv2. The “show version” command will indicate if the module is operating in FIPS mode (e.g. JUNOS Software Release [12.1X46-D40] (FIPS edition)), run “show system services ssh”, and run “show security ipsec” to verify that only the FIPS approved and FIPS allowed algorithms are configured for SSH and IPsec as specified above. 1.3 Firmware Load The cryptographic module implements a firmware load service which allows the loading of legacy firmware (legacy-use of digital signature verification using SHA-1 as defined by SP800-131Ar1). To comply with SP 800-131Ar1, the Crypto Officer must manually determine when a legacy firmware load is being performed and determine if the correct type of signature is being verified. Warning: Legacy firmware might not be FIPS 140-2 Validated or meet SP 800-131Ar1 requirements. The Crypto Officer must determine whether legacy firmware meets their organization’s compliance and certification requirements. When newer firmware is being loaded, the Crypto Officer must verify the presence of an ECDSA signature for the junos and junos-boot portions of the image by running: % tar ztf .tgz | grep esig The Crypto Officer must verify the output show presence of an esig file for both the junos and junos- boot portions of the image. For example: % tar ztf junos-srxsme-12.1X46-D40.4-fips.tgz | grep esig junos-boot-srxsme-12.1X46-D40.4-fips.esig Copyright Juniper, 2016 Version 1.1 Page 15 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). junos-srxsme-12.1X46-D40.4-fips.esig If the two esig files are not present, the Crypto Officer must not install the image. If the two esig files are present or the Crypto Officer is installing a legacy image, installation may continue using the following command: co@fips-srx> request system software add [no-validate] [no-copy] .tgz [reboot] The module will automatically verify that the image signature(s) are valid. 1.4 Zeroization The cryptographic module provides a non-Approved mode of operation in which non-approved cryptographic algorithms are supported. When transitioning between the non-Approved mode of operation and the Approved mode of operation, the Cryptographic Officer must run the following commands to zeroize the Approved mode CSPs: co@fips-srx> start shell co@fips-srx% rm –P - each persistent private or secret key other than the SSH host keys and the X.509 keys for IKE. co@fips-srx% rm –P /var/db/certs/common/certificate-request/* co@fips-srx% exit co@fips-srx> request system zeroize Note: The Cryptographic Officer must retain control of the module while zeroization is in process. Copyright Juniper, 2016 Version 1.1 Page 16 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 2 Cryptographic Functionality The module implements the FIPS Approved and Non-Approved but Allowed cryptographic functions listed in Tables 4 and 5 below. Table 6 summarizes the high level protocol algorithm support. The module does not implement algorithms that require vendor affirmation. Table 4 - Approved and CAVP Validated Cryptographic Functions Implementation Reference Mode Functions Strength Cert 2039, 2040, IPsec Triple-DES SP 800-20 TCBC Encrypt and decrypt 112 (3-Key) 2041, 2042, 2043 3657, FIPS 197 3658, CBC IPsec AES SP 800-38A Encrypt and decrypt 128, 192, 256 3659, GCM SP 800-38D 3660, 3661 3075, 3076, 80 (SHA-1) IPsec SHA FIPS 180-4 Hash generation 3077, 128 (SHA-256) 3078, 3079 2407, 128 (HMAC-SHA-1) 2408, IPsec HMAC FIPS 198-1 HMAC Gen, Ver 256 (HMAC-SHA- 2409, 256) 2410, 2411 IKE Triple-DES SP 800-20 TCBC Encrypt and decrypt 112 2035 FIPS 197 IKE AES CBC Encrypt and decrypt 128, 192, 256 3656 SP 800-38A 80 (SHA-1) IKE SHA FIPS 180-4 Hash generation 128 (SHA-256) 3074 192 (SHA-384) 128 (HMAC-SHA-1) 256 (HMAC-SHA- IKE HMAC FIPS 198-1 HMAC Gen, Ver 2406 256, HMAC-SHA- 384) IKE KDF SP 800-135 IKE v1/v2 KDF 112-256 659 764, 765, 128 (P-256) IKE ECDSA FIPS 186-4 KeyGen, SigGen, SigVer 766, 192 (P-384) 767, 768 1890, IKE RSA FIPS 186-4 SigGen, SigVer 112 (2048 bit) 1891, 1892, Copyright Juniper, 2016 Version 1.1 Page 17 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 1893, 1894 1027, 1028, IKE DSA FIPS 186-4 KeyGen 112 (2048 bit) 1029, 1030, 1031 SSH Triple-DES SP 800-20 TCBC Encrypt and decrypt 112 (3-Key) 2036 FIPS 197 CBC SSH AES Encrypt and decrypt 128, 192, 256 3650 SP 800-38A CTR 80 (SHA-1) SSH SHA FIPS 180-4 Hash generation 128 (SHA-256) 3068 256 (SHA-512) 128 (HMAC-SHA-1) 256 (HMAC-SHA- SSH HMAC FIPS 198-1 HMAC Gen, Ver 2400 256, HMAC-SHA- 512) KeyGen, SigVer 112 (2048 bit) SSH RSA FIPS 186-4 1885 SigVer 128 (3072 bit) 112 (P-224) SSH ECDSA FIPS 186-4 KeyGen, SigGen, SigVer 128 (P-256) 758 192 (P-384) SSH DSA FIPS 186-4 KeyGen 112 (2048 bit) 1022 256 (HMAC-SHA- DRBG SP 800-90A HMAC Random generation 981 256) SSH KDF SP 800-135 SSHv2 KDF 112-256 660 Copyright Juniper, 2016 Version 1.1 Page 18 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Table 5 - Non-Approved but Allowed Cryptographic Functions Algorithm Reference [IG] D.8 Diffie-Hellman (key agreement; key establishment Non-SP 800-56A Compliant methodology provides between 112 and 192 bits of encryption Diffie-Hellman strength). Non-SP 800-56A Compliant [IG] D.8 EC Diffie-Hellman (key agreement; key establishment Elliptic Curve Diffie-Hellman methodology provides 128 or 192 bits of encryption strength). [IG] 7.11 Hardware Non-Deterministic RNG used to seed the FIPS NDRNG Approved DRBG. [IG] A.8 Hash Message Authentication Code truncated to 96-bits. HMAC-SHA-1-96 Allowed for use in FIPS mode. Table 6 - Protocols Allowed in FIPS Mode Protocol Key Exchange Auth Cipher Integrity Oakley Group 14 (DH L = 2048 HMAC-SHA- RSA 2048 bit, N = 224 bit) 1-96 Pre-Shared 3 Key Triple-DES Oakley Group 19 (P-256) HMAC-SHA- IKEv1/v2 Secret AES CBC Oakley Group 20 (P-384) 256 ECDSA P-256 128/192/256 Oakley Group 24 (DH L = 2048 HMAC-SHA- ECDSA P-384 bit, N = 224 bit) 384 IKEv1 with optional: • Oakley Group 14 (DH L = 2048 bit , N = 224 bit) 3 Key Triple-DES • Oakley Group 19 (P-256) IKEv1 AES CBC 128/192/256 • Oakley Group 20 (P-384) • Oakley Group 24 (DH L = HMAC-SHA- 2048 bit, N = 224) 1-96 IPsec ESP HMAC-SHA- IKEv2 with optional: 3 Key Triple-DES 256-128 • Oakley Group 14 (DH L = AES CBC 2048 bit, N = 224 bit) 128/192/256 • Oakley Group 19 (P-256) IKEv2 AES GCM • Oakley Group 20 (P-384) 128/192/256 16 • Oakley Group 24 (DH L = octet ICV 2048 bit, N = 224 bit) Diffie-hellman-group- exchange-sha1 (L = 2048 bit, 3072 bit, 4096 bit, 6144 bit, HMAC-SHA- 7680 bit, or 8192 bit; N = 256 3 Key Triple-DES 1-96 bit, 320 bit, 384 bit, 512 bit, or AES CBC HMAC-SHA-1 SSHv2 1024 bit) ECDSA P-256 128/192/256 HMAC-SHA- Diffie-hellman-group- AES CTR 256 exchange-sha2 (L = 2048 bit, 128/192/256 HMAC-SHA- 3072 bit, 4096 bit, 6144 bit, 512 7680 bit, or 8192 bit; N = 256 bit, 320 bit, 384 bit, 512 bit, or Copyright Juniper, 2016 Version 1.1 Page 19 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 1024 bit) Diffie-hellman-group14-sha1 (L = 2048 bit; N = 256 bit, 320 bit, 384 bit, 512 bit, or 1024 bit) ECDH-sha2-nistp256 ECDH-sha2-nistp384 These protocols have not been reviewed or tested by the CAVP and CMVP. The IKE and SSH algorithms allow independent selection of key exchange, authentication, cipher and integrity. In Table 6 above, each column of options for a given protocol is independent, and may be used in any viable combination. These security functions are available in the SSH connect (non-compliant) service. 2.1 Disallowed Algorithms These algorithms are non-Approved algorithms that are disabled when the module is operated in an Approved mode of operation. • ssh-dss (DSA SigGen, SigVer; non-compliant) • dh-group1-sha1 (Diffie-Hellman (non-compliant key agreement; key establishment methodology provides less than 112 bits of encryption strength) • hmac-md5 • hmac-md5-96 • hmac-md5-96-etm@openssh.com • hmac-md5-etm@openssh.com • hmac-ripemd160 • hmac-ripemd160-etm@openssh.com • umac-128-etm@openssh.com • umac-64-etm@openssh.com • umac-64@openssh.com • arcfour • arcfour128 • arcfour256 • blowfish-cbc • cast128-cbc 2.2 Critical Security Parameters All CSPs and public keys used by the module are described in this section. Table 7 - Critical Security Parameters (CSPs) Name Description and usage DRBG_Seed Seed material used to seed or reseed the DRBG DRBG_State V and Key values for the HMAC_DRBG SSH Private host key. 1st time SSH is configured, the keys are generated. ECDSA P-256. SSH PHK Used to identify the host. Copyright Juniper, 2016 Version 1.1 Page 20 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). SSH Diffie-Hellman private component. Ephemeral Diffie-Hellman private key used in SSH. SSH DH DH (N = 256 bit, 320 bit, 384 bit, 512 bit, or 1024 bit 1), ECDH P-256, or ECDH P-384 SSH-SEK SSH Session Key; Session keys used with SSH. TDES (3key), AES, HMAC. ESP-SEK IPSec ESP Session Keys. TDES (3 key), AES, HMAC. IKE-PSK Pre-Shared Key used to authenticate IKE connections. IKE-Priv IKE Private Key. RSA 2048, ECDSA P-256, or ECDSA P-384 IKE-SKEYID IKE SKEYID. IKE secret used to derive IKE and IPsec ESP session keys. IKE-SEK IKE Session Keys. TDES (3 key), AES, HMAC. IKE Diffie-Hellman private component. Ephemeral Diffie-Hellman private key used in IKE. IKE-DH-PRI DH N = 224 bit, ECDH P-256, or ECDH P-384 CO-PW ASCII Text used to authenticate the CO. User-PW ASCII Text used to authenticate the User. Table 8 - Public Keys Name Description and usage SSH-PUB SSH Public Host Key used to identify the host. ECDSA P-256. Diffie-Hellman public component. Ephemeral Diffie-Hellman public key used in SSH key SSH-DH-PUB establishment. DH (L = 2048 bit, 3072 bit, 4096 bit, 6144 bit, 7680 bit, or 8192 bit), ECDH P- 256, or ECDH P-384 IKE-PUB IKE Public Key RSA 2048, ECDSA P-256, or ECDSA P-384 Diffie-Hellman public component. Ephemeral Diffie-Hellman public key used in IKE key IKE-DH-PUB establishment. DH L = 2048 bit, ECDH P-256, or ECDH P-384 User Authentication Public Keys. Used to authenticate users to the module. ECDSA P256 or P- Auth-UPub 384 Auth-COPub CO Authentication Public Keys. Used to authenticate CO to the module. ECDSA P256 or P-384 JuniperRootCA. RSA 2048 X.509 Certificate; Used to verify the validity of the Juniper Package- Root-CA CA at software load. JuniperRootEC CA. ECDSA P-256 X.509 Certificate; Used to verify the validity of the Juniper RootEC CA Package CA at software load and also at runtime for integrity. PackageCA. RSA 2048 X.509 Certificate; Used to verify the validity of legacy Juniper Images at Package-CA software load. PackageEC PackageEC CA. ECDSA P-256 X.509 Certificate; Used to verify the validity the Juniper Image at CA software load and also at runtime for integrity. 1 SSH generates a Diffie-Hellman private key that is 2x the bit length of the longest symmetric or MAC key negotiated. Copyright Juniper, 2016 Version 1.1 Page 21 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 3 Roles, Authentication and Services 3.1 Roles and Authentication of Operators to Roles The module supports two roles: Cryptographic Officer (CO) and User. The module supports concurrent operators, but does not support a maintenance role and/or bypass capability. The module enforces the separation of roles using either identity-based operator authentication. The Cryptographic Officer role configures and monitors the module via a console or SSH connection. As root or super-user, the Cryptographic Officer has permission to view and edit secrets within the module. The User role monitors the router via the console or SSH. The user role may not change the configuration. 3.2 Authentication Methods The module implements two forms of Identity-Based authentication, Username and password over the Console and SSH as well as Username and public key over SSH. Password authentication: The module enforces 10-character passwords (at minimum) chosen from the 96 human readable ASCII characters. The maximum password length is 20-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 nine (9) 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. ECDSA signature verification: SSH public-key authentication. Processing constraints allow for a maximum of 5.6e7 ECDSA attempts per minute. The module supports ECDSA (P-256 and P-384). The probability of a success with multiple consecutive attempts in a one-minute period is 5.6e7/(2128). 3.3 Services All services implemented by the module are listed in the tables below. Table 11 lists the access to CSPs by each service. Table 9 - Authenticated Services Service Description CO User Configure Security relevant configuration x security Configure Non-security relevant configuration x Secure Traffic IPsec protected connection (ESP) x Status Show status x x Zeroize Destroy all CSPs x Copyright Juniper, 2016 Version 1.1 Page 22 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Initiate SSH connection for SSH monitoring and SSH connect x x control (CLI) IPsec connect Initiate IPsec connection (IKE) x Console access Console monitoring and control (CLI) x x Remote reset Software initiated reset x Table 10 - Unauthenticated traffic Service Description Local reset Hardware reset or power cycle Traffic Traffic requiring no cryptographic services Table 11 - CSP Access Rights within Services CSPs DRBG_State DRBG_Seed IKE-DH-PRI IKE-SKEYID User-PW SSH PHK SSH-SEK ESP-SEK IKE-Priv IKE-PSK IKE-SEK SSH DH CO-PW Service W W Configure security -- E GW -- -- -- W GW -- -- -- -- -- Configure -- -- -- -- -- -- -- -- -- -- -- -- -- Secure traffic -- -- -- -- -- E -- -- -- E -- -- -- Status -- -- -- -- -- -- -- -- -- -- -- Z Z Zeroize -- Z Z -- -- -- Z Z -- -- -- E E SSH connect -- E E GE GE -- -- -- -- -- -- -- -- IPsec connect -- E -- -- -- G E E G G G E E Console access -- -- -- -- -- -- -- -- -- -- -- Z Z Remote reset GE G -- Z Z Z -- -- Z Z Z Z Z Local reset GE G -- Z Z Z -- -- Z Z Z -- -- Traffic -- -- -- -- -- -- -- -- -- -- -- G = Generate: The module generates the CSP R = Read: The CSP is read from the module (e.g. the CSP is output) E = Execute: The module executes using the CSP W = Write: The CSP is updated or written to the module Z = Zeroize: The module zeroizes the CSP. 3.4 Non-Approved Services The following services are available in the non-Approved mode of operation. The security functions provided by the non-Approved services are identical to the Approved counterparts with the exception of SSH Connect (non-compliant). SSH Connect (non-compliant) supports the security functions identified in Section 2.1 and the SSHv2 row of Table 6. Copyright Juniper, 2016 Version 1.1 Page 23 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Table 12 - Authenticated Services Service Description CO User Configure security Security relevant configuration x (non-compliant) Configure (non- Non-security relevant configuration x compliant) Secure Traffic (non- IPsec protected connection (ESP) x compliant) Status (non- Show status x x compliant) Zeroize (non- Destroy all CSPs x compliant) SSH connect (non- Initiate SSH connection for SSH monitoring and x x compliant) control (CLI) IPsec connect (non- Initiate IPsec connection (IKE) x compliant) Console access (non- Console monitoring and control (CLI) x x compliant) Remote reset (non- Software initiated reset x compliant) Table 13 - Unauthenticated traffic Service Description Local reset (non- Hardware reset or power cycle compliant) Traffic (non- Traffic requiring no cryptographic services compliant) Copyright Juniper, 2016 Version 1.1 Page 24 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 4 Self-tests Each time the module is powered up, it tests that the cryptographic algorithms still operate correctly and that sensitive data have not been damaged. Power-up self–tests are available on demand by power cycling the module. On power up or reset, the module performs the self-tests described below. All KATs must be completed successfully prior to any other use of cryptography by the module. If one of the KATs fails, the module enters the Critical Failure error state. The module performs the following power-up self-tests: • Firmware Integrity check using ECDSA P-256 with SHA-256 • QuickSec JSF Hardware Accelerated KATs o AES-CBC Encrypt KAT o ASE-CBC Decrypt KAT o AES-GCM Encrypt KAT o ASE-GCM Decrypt KAT o RSA 2048 w/ SHA-256 Sign KAT o RSA 2048 w/ SHA-256 Verify KAT o ECDSA P-256 w/ SHA-256 Sign/Verify PCT • QuickSec Hardware Accelerated KATs o Triple-DES-CBC Encrypt KAT o Triple-DES-CBC Decrypt KAT o HMAC-SHA-1 KAT o HMAC-SHA-256 KAT • OpenSSL KATs o SP 800-90A HMAC DRBG KAT  Health-tests initialize, re-seed, and generate. o ECDSA P-256 Sign/Verify PCT o ECDH P-256 KAT  Derivation of the expected shared secret. o RSA 2048 w/ SHA-256 Sign KAT o RSA 2048 w/ SHA-256 Verify KAT o Triple-DES-CBC Encrypt KAT o Triple-DES-CBC Decrypt KAT o HMAC-SHA-1 KAT o HMAC-SHA-256 KAT o HMAC-SHA-384 KAT o HMAC-SHA-512 KAT o SHA-256 KAT o AES-CBC Encrypt KAT o ASE-CBC Decrypt KAT o KDF-SSH KAT • QuickSec KATs o Triple-DES-CBC Encrypt KAT o Triple-DES-CBC Decrypt KAT o HMAC-SHA1 KAT o HMAC-SHA-256 KAT Copyright Juniper, 2016 Version 1.1 Page 25 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). o HMAC-SHA-384 KAT o AES-CBC Encrypt KAT o ASE-CBC Decrypt KAT o KDF-IKE-V1 KAT o KDF-IKE-V2 KAT • Critical Function Test The cryptographic module performs a verification of a limited operational environment, o and verification of optional non-critical packages. The module also performs the following conditional self-tests: • Continuous RNG Test on the SP 800-90A HMAC-DRBG • Continuous RNG test on the NDRNG • Pairwise consistency test when generating DSA, ECDSA, and RSA key pairs. • Firmware Load Test (ECDSA or RSA signature verification) Copyright Juniper, 2016 Version 1.1 Page 26 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 5 Physical Security Policy The module’s physical embodiment is that of a multi-chip standalone device that meets Level 2 Physical Security requirements. The module is completely enclosed in a rectangular nickel or clear zinc coated, cold rolled steel, plated steel and brushed aluminum enclosure. There are no ventilation holes, gaps, slits, cracks, slots, or crevices that would allow for any sort of observation of any component contained within the cryptographic boundary. Tamper-evident seals allow the operator to tell if the enclosure has been breached. These seals are not factory-installed and must be applied by the Cryptographic Officer. (Seals are available for order from Juniper using part number JNPR-FIPS-TAMPER-LBLS.) The tamper- evident seals shall be installed for the module to operate in a FIPS mode of operation. The Cryptographic Officer is responsible for securing and having control at all times of any unused seals and 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 the module is returned to a FIPS Approved state. Table 14 – Physical Security Inspection Guidelines Physical Security Recommended Frequency of Inspection/Test Guidance Details Mechanism Inspection/Test Tamper seals, opaque Once per month by the Seals should be free of any tamper metal enclosure. Cryptographic Officer. evidence. 5.1 General Tamper Seal Placement and Application Instructions For all seal applications, the Cryptographic Officer should observe the following instructions: • Handle the seals with care. Do not touch the adhesive side. • Before applying a seal, ensure the location of application is clean, dry, and clear of any residue. • Place the seal on the module, applying firm pressure across it to ensure adhesion. Allow at least 1 hour for the adhesive to cure. 5.2 SRX100 and SRX110 (1 seal) A tamper-evident seal must be applied to the following location: • The top of the chassis, covering one of the chassis screws. Figure 15: SRX100 Tamper-Evident Seal Placement- One Seal Copyright Juniper, 2016 Version 1.1 Page 27 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Figure 16: SRX110 Tamper-Evident Seal Placement- One Seal 5.3 SRX210 (3 seals) Tamper-evident seals must be applied to the following locations: • The top of the chassis, covering one of the chassis screws. • The I/O Slot o Two seals, horizontally across the right and left edges of the interface card or cover plate. Figure 17: SRX210 Tamper-Evident Seal Placement-Three Seals 5.4 SRX220 (5 seals) Tamper-evident seals must be applied to the following locations: • The front of the module: Copyright Juniper, 2016 Version 1.1 Page 28 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). One seal, horizontally across the left edge of the leftmost installed interface card or o cover plate. o One seal, horizontally across the right edge of the leftmost installed interface card or cover plate, and extending on to the edge of the rightmost installed interface card or cover plate. o One seal, vertically across both the rightmost installed interface card or cover plate and the compact flash card slot below it, extending on to the top and bottom of the chassis. • The left and right sides of the module: o One seal extending from the top to the bottom of the chassis. Figure 18: SRX220 Tamper-Evident Seal Placement- Five Seals 5.5 SRX240 (8 seals) Tamper-evident seals must be applied to the following locations: • The front of the module, vertically, across each of the installed interface cards, or slot cover plates, extending on to the top and bottom of the chassis of the module • The left and right sides of the module, extending from the top of the chassis to the bottom. Figure 19: SRX240 Tamper-Evident Seal Placement-Eight Seals Copyright Juniper, 2016 Version 1.1 Page 29 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 5.6 SRX550 (19 seals) The IOCs in the SRX550 are considered non-security relevant and are excluded from the requirements of FIPS 140-2. They do not perform cryptography and a malfunction cannot cause other components to malfunction, disclose CSPs, or output plaintext data. Tamper-evident seals must be applied to the following locations: • The front of the module: o Four seals, horizontally across the corner between the front plate and right side. Three of them should be directly down from sticking-out screws; the fourth should be near the top. o One seal, vertically, immediately to the left of the lower three seals previously mentioned. Should cover all three of the sub-plates and reach around to the bottom plate as well. o One seal, vertically, immediately to the left of RJ45 jacks 16 and 17. Should stick to the sub-plate containing said RJ45 jacks, the sub-plate immediately below, and should reach around and stick to the top plate as well. o One seal, vertically, to the right of and beneath (i.e. adjacent corner with) RJ45 jacks 15. Should stick to the sub-plate containing said RJ45 jack, the two sub-plates below, and reach around and stick to the bottom plate. o One seal, horizontally, attached to the two sub-plates directly below the sub-plate containing RJ45 jacks 0-15. o One seal, vertically, attached below RJ45 jacks 0-3, sticking to that sub-plate, and the two below. It should go between jacks 0/4 and 0/5. o One seal, horizontally, touching corners with RJ45 jack 1. Sticks to that sub plate and the one to the left. Be careful not to interfere with the jack below and to the left of the “CONSOLE” USB-MiniB receptacle. o One seal, horizontally, directly above the RJ45 jack to the left of the “CONSOLE” USB- MiniB receptacle. Should cover the same sub-plates as the previous seal. • On the right side of the module, ensure that four horizontal seals are indeed stuck to the far-left side of the right-side plate. Also: o One seal, vertical, on the far right side. It should extend downwards and stick to the bottom plate. • On the left side: o One seal, vertical, in the middle. It should extend downwards and stick to the bottom plate. • On the back: o Two seals, vertical; one on the sub-plate holding the power input and the one above it. Each should extend to the vertically adjacent plate (so both touch both plates) and to the top (upper seal) and bottom (lower seal) plates. o Two seals, vertical; one on the black sub-plate and another on the small sliver sub-plate below it. The latter should extend to tough the black sub-plate as well, and each one should touch either the top (upper seal) or bottom (lower seal). o Two seals, vertical, on the far-right sub-plate. One should stick to top plate, the other to bottom plate. Copyright Juniper, 2016 Version 1.1 Page 30 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Figure 20: SRX550 Tamper-Evident Seal Placement on Front and Right Side-Twelve Seals Figure 21: SRX550 Tamper-Evident Seal Placement on Rear and Left Side- Seven Seals 5.7 SRX650 (19 seals) The IOCs in the SRX650 are considered non-security relevant and are excluded from the requirements of FIPS 140-2. They do not perform cryptography and a malfunction cannot cause other components to malfunction, disclose CSPs, or output plaintext data. Tamper-evident seals must be applied to the following locations: • The front of the module: o Two seals, vertically across the center part of each of the installed interface cards, or slot cover plates, numbered 1 through 4 extending on to the top and bottom of the chassis of the module. o Two seals, vertically across the center part of each of the installed interface cards, or slot cover plates, numbered 5 through 8 extending on to the top and bottom of the chassis of the module. Copyright Juniper, 2016 Version 1.1 Page 31 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). One seal, vertically, across the left edge of the slot covers marked 3 and 4, extending o from the bottom of the chassis on to the bottom of the slot cover marked 2. o Four lseals, horizontally across the right edge of the slot covers marked 5-8, extending on to the right side of the chassis. o Two seals, horizontally across the left edge of the slot covers marked 1 and 2, extending on to the left front face of the chassis. • One seal to both the left and right sides of the module, extending from the side of the chassis on to the bottom. • The rear of the module: o Two seals, vertically across the central part each of the installed interface cards, or slot cover plates, extending on to the top and bottom of the chassis of the module. o Two seals, vertically across each of the installed power supplies or cover plates, extending on to the top and bottom of the chassis of the module. o Two seals, vertically across the air filter cover plate, extending on to the top and bottom of the chassis of the module. Figure 22: SRX650 Tamper-Evident Seal Placement on Front and Right Side- Twelve Seals Figure 23: SRX650 Tamper-Evident Seal Placement on Rear and Left Side- Seven Seals Copyright Juniper, 2016 Version 1.1 Page 32 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 6 Security Rules and Guidance The module design corresponds to the security rules below. The term must in this context specifically refers to a requirement for correct usage of the module in the Approved mode; all other statements indicate a security rule implemented by the module. 1. The module clears previous authentications on power cycle. 2. When the module has not been placed in a valid role, the operator does not have access to any cryptographic services. 3. Power up self-tests do not require any operator action. 4. Data output is inhibited during key generation, self-tests, zeroization, and error states. 5. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. 6. There are no restrictions on which keys or CSPs are zeroized by the zeroization service. 7. The module does not support a maintenance interface or role. 8. The module does not support manual key entry. 9. The module does not output intermediate key values. 10. The module requires two independent internal actions to be performed prior to outputing plaintext CSPs. 11. The cryptographic officer must determine whether firmware being loaded is a legacy use of the firmware load service. 12. The cryptographic officer must retain control of the module while zeroization is in process. Copyright Juniper, 2016 Version 1.1 Page 33 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). 7 References and Definitions The following standards are referred to in this Security Policy. Table 15 – References Abbreviation Full Specification Name Security Requirements for Cryptographic Modules, May 25, 2001 [FIPS140-2] Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms [SP800-131A] and Key Lengths, January 2011 Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation [IG] Program Table 16 – Acronyms and Definitions Acronym Definition AES Advanced Encryption Standard DH Diffie-Hellman DSA Digital Signature Algorithm ECDH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm EMC Electromagnetic Compatibility ESP Encapsulating Security Payload FIPS Federal Information Processing Standard HMAC Keyed-Hash Message Authentication Code ICV Integrity Check Value (i.e. Tag) IKE Internet Key Exchange Protocol IOC Input/Output Card IPsec Internet Protocol Security MD5 Message Digest 5 NPC Network Processing Card RE Routing Engine RSA Public-key encryption technology developed by RSA Data Security, Inc. SHA Secure Hash Algorithms SPC Services Processing Card SSH Secure Shell Triple-DES Triple - Data Encryption Standard Copyright Juniper, 2016 Version 1.1 Page 34 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision). Table 17 – Datasheets Model Title URL SRX100 SRX Series Service http://www.juniper.net/assets/us/en/local/pdf/datasheets/1000281- SRX110 Gateways for the en.pdf SRX210 Branch SRX220 SRX240 SRX550 SRX650 Copyright Juniper, 2016 Version 1.1 Page 35 of 35 Juniper Networks Public Material – May be reproduced only in its original entirety (without revision).