What changed in Juniper SRX Services Gateway VPN STIG V3R2V3R2 changes

Title

The Juniper SRX Services Gateway VPN must use AES256 encryption for the IPsec proposal to protect the confidentiality of remote access sessions.

Check text

Verify all Internet Key Exchange (IKE) proposals are set to use the AESAES256 encryption algorithm. [edit] show security ipsec View the value of the encryption algorithm for each defined proposal. If the value of the encryption algorithm for any IPsec proposal is not set to use an AESAES256 algorithm, this is a finding.

Fix text

The following example commands configure the IPsec (phase 2) proposals. The option may also be configured to use the aes-128-cbc, aes-192-cbc, or aes-256-cbc algorithms. [edit] set security ipsec proposal &ltIPSEC-PROPOSAL-NAME> encryption-algorithm aes-256-cbc

Discussion

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. The Advance Encryption Standard (AES) encryption is critical to ensuring the privacy of the IPsec session; it is imperative that AES is used for encryption operations. The CNSSP 15 compliant algorithms recommended by the NSA for IPsec are AES 256 with SHA384 and cbc or gsm confidentiality mode. Remote access is access to DoD-non-publicDOD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonnonorganization-organization-controlled network. Remote access methods include broadband and wireless connections. While there is much debate about the security and performance of AES, there is a consensus that AES is significantly more secure than other algorithms currently supported by IPsec implementations. AES is available in three key sizes: 128, 192, and 256 bits, versus the 56 bit DES. Therefore, there are approximately 1021 times more AES 128-bit keys than DES 56-bit keys. In addition, AES uses a block size of 128 bits—twice the size of DES or 3DES.

V-214672 in V3R2

Title

The Juniper SRX Services Gateway VPN must use AESAES256 encryption for the Internet Key Exchange (IKE) proposal to protect the confidentiality of remote access sessions.

Check text

Verify all IKE proposals are set to use the AESAES256 encryption algorithm. [edit] show security ike View the value of the encryption algorithm for each defined proposal. If the value of the encryption algorithm for any IKE proposal is not setconfigured to use an AES algorithmAES256, this is a finding.

Fix text

The following example commands configure the IKE (phase 1) proposals. The option may also be configured to use the aes-128-cbc, aes-192-cbc, or aes-256-cbc algorithms. [edit] set security ike proposal &ltIKE-PROPOSAL-NAME> encryption-algorithm aes-256-cbc

Discussion

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. The Advance Encryption Standard (AES) algorithm is critical to ensuring the privacy of the IKE session responsible for establishing the security association and key exchange for an IPsec tunnel. AES is used for encryption operations. The CNSSP 15 compliant algorithms recommended by the NSA for IKE are AES256 with SHA384 and DH-16 or higher. Remote access is access to DoD-non-publicDOD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonnonorganization-organization-controlled network. Remote access methods include broadband and wireless connections. While there is much debate about the security and performance of AES, there is a consensus that AES is significantly more secure than other algorithms currently supported by IPsec implementations. AES is available in three key sizes: 128, 192, and 256 bits, versus the 56 bit DES. Therefore, there are approximately 1021 times more AES 128-bit keys than DES 56-bit keys. In addition, AES uses a block size of 128 bits—twice the size of DES or 3DES.

V-214673 in V3R2

Title

The Juniper SRX Services Gateway VPN must implbement a FIPS-140-2 valconfigureda to used Diffie-Hellman (DH) group 15 or higher.

Severity

mediumhigh

Check text

Verify all IKE proposals are set to use a FIPS-validated dh-group. [edit] show security ike &ltP1-PROPOSAL-NAME> View the IKE options dh-group option. If the IKE option is not set to a FIPS- 140-2/140-3 validated dh-group, this is a finding.

Fix text

The following command is an example of how to configure the IKE (phase 1) proposals. The following groups are allowed for use in DoD: DH Groups 14 (2048-bit MODP) - 19 (256-bit Random ECP), 20 (384-bit Random ECP), 5 (1536-bit MODP), 24 (2048-bit MODP with 256-bit POS). Example: [edit] set security ike proposal &ltP1-PROPOSAL-NAME> dh-group group14group19

Discussion

Use of an approved DH algorithm ensures the Internet Key Exchange (IKE) (phase 1) proposal uses FIPS-validated key management techniques and processes in the production, storage, and control of private/secret cryptographic keys. The security of the DH key exchange is based on the difficulty of solving the discrete logarithm infrom which the key was derived from. Hence, the larger the modulus, the more secure the generated key is considered to be. The DH group selected must have a minimum of a 3072-bit modulus to protect up to TOP SECRET.

V-214674 in V3R2

Title

The Juniper SRX Services Gateway VPN must be configured to use IPsec with SHA1SHA256 or greater to negotiate hashing to protect the integrity of remote access sessions.

Check text

Verify all IPSec proposals are set to use the sha-256 hashing algorithm. [edit] show security ipsec proposal &ltIPSEC-PROPOSAL-NAME> View the value of the encryption algorithm for each defined proposal. If the value of the encryption algorithm option for all defined proposals is not set to use SHA1SHA256 or greater, this is a finding.

Fix text

The following example commands configure the IPSec proposal. set security ipsec proposal &ltIPSEC-PROPOSAL-NAME> authentication-algorithm &lthmac-sha-256-128 | hmac-sha-256-96 | hmac-sha1-96>128

Discussion

Without strong cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access VPN provides access to DoDDOD non-publicnonpublic information systems by an authorized user (or an information system) communicating through an external, nonnonorganization-organization-controlled network.

CCIs

CCI-001453CCI-001453,CCI-000803

V-214675 in V3R2

Severity

lowmedium

Check text

AskNavigate to the siteIKE representative which proposal implements Suite Bconfiguration. [edit] show security ike gateway &ltike-peer-name> ViewIf the configuredDPD options. If theare dead-peer-detection is not configured, this is a finding.

Fix text

For site-to-site VPN, configure an Internet Key Exchange (IKE) gateway that includes dead-peer-detectionDPD parameters such as in the following example. set security ike gateway IKE-PEER ike-policy IKE-POLICY set security ike gateway IKE-PEER address &ltPeer IP Address> set security ike gateway IKE-PEER dead-peer-detection always-send set security ike gateway IKE-PEER dead-peer-detection interval 10 set security ike gateway IKE-PEER dead-peer-detection threshold 2 set security ike gateway IKE-PEER local-identity inet &ltIPv4 Address in Certificate> set security ike gateway IKE-PEER remote-identity inet &ltIPv4 Address in Remote Certificate> set security ike gateway IKE-PEER external-interface &ltinterface name> set security ike gateway IKE-PEER version v2-only For dynamic (remote access) VPN, the TCP keep-alive for remote access is implemented in the Juniper SRX Firewall STIG.

Discussion

Idle TCP sessions can be susceptible to unauthorized access and hijacking attacks. ByIKE default,Dead routersPeer doDetection not(DPD) continually test whether a previously connected TCP endpoint is still reachable. If one end of a TCPprotocol connectionthat idlesverifies out or terminates abnormally, the oppositeavailability end of theIPsec connectionpeer maydevices still believe the session is available. These "orphaned" sessions use up valuable router resources and can also be hijacked by ansending attacker.encrypted ToIKE mitigatePhase this1 risk,notification routerspayloads must be configured to send periodic keep alive messages to check that the remote end of a session is still connectedpeers. Note: IfFor thedynamic (remote deviceaccess) fails to respond to the TCP keep alive messageVPN, the sending router will clear the connection and free resources allocated to the session. The TCP keep-alive for remote access is implemented in the Juniper SRX Firewall STIG.

V-214689 in V3R2

Title

The Juniper SRX Services Gateway VPN Internet Key Exchange (IKE) must usebe cryptographyconfigured thatto isuse compliantan withapproved SuiteCommercial BSolution parametersfor Classified (CSfC) when transporting classified traffic across an unclassified network.

Check text

AskIf the sitedevice representativeis whichnot proposalused implementsto Suitetransport Bclassified traffic across an unclassified network, this is not applicable. [edit] show security ike &ltsuiteb-proposal-name> View the configured options. If the valueIKE ofproposal theencryption authentication-methodalgorithms and other options are not setconfigured forin Suitecompliance Bwith complianceCSfC, this is a finding.

Fix text

TheNavigate followingto example commands configure the IKE (phase 1) Suite B proposal. Note that SRX must have Junos 12stanza.1X46 or Example later to support SuiteBstanza. [edit] set security ike proposal suiteb&ltname-proposal> set ike proposal suiteb&ltname-proposal> authentication-method ecdsa-signatures-384 set ike proposal suiteb&ltname-proposal> dh-group group20 set ike proposal suiteb&ltname-proposal> authentication-algorithm sha-384 set ike proposal suiteb&ltname-proposal> encryption-algorithm aes-256-cbc

Discussion

Use of weak or untested encryption algorithms undermines the purposes of utilizingusing encryption to protect data. The networkNational elementSecurity mustAgency/Central implementSecurity cryptographicService's modules(NSA/CSS) adheringCSfC toProgram theenables highercommercial standardsproducts approvedto bybe theused federalin governmentlayered sincesolutions thisto providesprotect assuranceclassified theyNational haveSecurity beenSystems tested(NSS) and validateddata. RFC 6379Currently, Suite B Cryptographic Suites for IPsec defines four cryptographic useralgorithms interface suites for deploying IPsec. Each suite provides choices for Encapsulating Security Payload (ESP) and IKE. The four suites are differentiatedspecified by theNIST choice of IKE authentication and key exchange, cryptographic algorithm strengths, and whether ESP is to provide both confidentiality and integrity or integrity only. The suite names are basedused onby theNSA's AdvancedInformation EncryptionAssurance StandardDirectorate (AES)in modesolutions andapproved AES key length specified for ESP.protecting Two suites are defined for transporting classified information up to SECRET level—one for both confidentiality and integrityunclassified and one for integrity onlyNSS. ThereHowever, arequantum alsoresistant twoalgorithms suiteswill definedbe required for transportingfuture classifiedrequired informationSuite upB to TOP SECRET levelimplementations.

V-214690 in V3R2

Check text

Verify all Internet Key Exchange (IKE) proposals are set to use the AES encryption algorithmAES256. [edit] show security ike View the value of the encryption algorithm for each defined proposal. If the value of the authentication method and other options are not set to use FIPS-compliantvalidated values, this is a finding.

Fix text

The following example commands configure the IKE (phase 1) proposal. [edit] set security ike proposal &ltP1-PROPOSAL> authentication-method rsa-signatures set security ike proposal p1-proposal dh-group group14group19 set security ike proposal p1-proposal authentication-algorithm sha-256384 set security ike proposal p1-proposal encryption-algorithm aes-256-cbc set security ike proposal p1-proposal lifetime-seconds 86400

Discussion

Use of weak or untested encryption algorithms undermines the purposes of utilizingusing encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

V-214691 in V3R2

CCIs

CCI-001941CCI-001941,CCI-001942

V-214696 in V3R2